VNC über DynDNS
Susanne Junghans
habe auf meiner fritz!box fon wlan 7050 dyndns aktiviert
und eingehende vnc-verbindungen (port 5900) an eine client-ip
weitergeleitet. wie kann ich erreichen, daß ich auch mehrere
clients fernwarten kann?
ist die sache überhaupt einigermassen sicher, oder sollte man
sowas nur über vpn machen (kann mein router leider nicht).
viele grüße
susanne
Frank Röder
So etwas würde ich bleiben lassen.
Du kannst auch mehrere Rechner fernwarten wenn Du für jeden VNC Server
einen eigenen Port definierst und dann auf dem Router für jeden Port ein
Forwarding einrichtest auf die jeweilige Client IP.
--
Viele Grüße
Frank Röder
Joachim Conrad
Susanne Junghans schrieb:
> habe auf meiner fritz!box fon wlan 7050 dyndns aktiviert
> und eingehende vnc-verbindungen (port 5900) an eine client-ip
> weitergeleitet.
Wieso VNC? XP bringt doch einen Remotedesktop mit.
> wie kann ich erreichen, daß ich auch mehrere
> clients fernwarten kann?
Dann musst du jeweils andere Ports verwenden.
> ist die sache überhaupt einigermassen sicher, oder sollte man
> sowas nur über vpn machen (kann mein router leider nicht).
Besser wäre dies. Du könntest auch eine eingehende VPN-Verbindung auf
einem XP PC terminieren lassen, halte ich noch für besser als die völlig
ungeschützte Verbindung, dazu musst du auf dem Router TCP Port 1723 auf
den "VPN-Server" weiterleiten und das GRE Protokoll durchlassen(VPN
Pass-Through unterstützen).
Tschau
Joachim
--
Joachim Conrad - MS-MVP Windows Networking
Antworten bitte nur in der NG
Die genannte E-Mail Adresse existiert, die Eingänge werden
allerdings automatisch gelöscht.
Ralf Breuer
Hallo Susanne,
> habe auf meiner fritz!box fon wlan 7050 dyndns aktiviert
> und eingehende vnc-verbindungen (port 5900) an eine client-ip
> weitergeleitet. wie kann ich erreichen, daß ich auch mehrere
> clients fernwarten kann?
Im einfachsten Fall machst Du "Computer-Hopping" ;-)
Du kannst auf dem Client-PC VNC-Viewer starten und den nächsten PC anwählen.
> ist die sache überhaupt einigermassen sicher, oder sollte man
> sowas nur über vpn machen (kann mein router leider nicht).
Zwei Möglichkeiten:
Du könntest statt einer VNC-Verbindung eine VPN-Verbindung weiterleiten.
Beispiel:
Der Computer hat eine Netzwerkkarte mit IP 192.168.0.10 und ist an einen
Router angeschlossen.
Über den Router soll ein eingehender VPN-Tunnel eingerichtet werden.
Netzwerkverbindungen, neue Verbindung erstellen, eine erweiterte Verbindung
einrichten, eingehende Verbindung zulassen, kein Haken an
Verbindungsgeräten, VPN-Verbindung zulassen, erwünschte Benutzer anhaken,
TCP/IP, Eigenschaften, TCP/IP-Adressen angeben aus einem anderen Subnetz,
z.B. 192.168.1.1 bis 192.168.1.5. Evt. oben den Haken setzen, wenn der
VPN-Server in das lokale Subnetz routen soll.
Der Router muss Port 1723 an die Netzwerkkarte 192.168.0.10 weiterleiten und
das IP-Protokoll 47 (GRE) durchlassen.
Wenn nun eine VPN-Verbindung von außen aufgebaut wird, erhält der VPN-Server
die IP 192.168.1.1 und der (erste) Client die IP 192.168.1.2.
In der Windows Firewall werden die Einstellungen automatisch angepasst. Zu
prüfen: Systemsteuerung, Windows-Firewall, Erweitert,
Netzwerkverbindungseinstellungen, Einstellungen, Haken bei eingehende
Verbindung (PPTP), Zeile markieren, bearbeiten, Name oder IP: die IP des
Servers, also 192.168.0.10 bzw. der Computername, externe und interne
Portnummer 1723 TCP.
Zweite Möglichkeit:
Die VNC-Verbindung verschlüsseln. Von Ultra-VNC weiß ich, dass es ein Plugin
gibt:
http://ultravnc.sourceforge.net/features/encryption.html
--
Gruß
Ralf
Ich mag kein TOFU. Siehe http://learn.to/quote
Bei Direkt-Mails NOSPAM entfernen
Diana Bulthaupt at
UltraVNC bietet einen Repeater, den Du auf einem der Rechner im Netzverbund
laufen lassen musst. Den kannst Du dann wie einen Proxy verwenden. Dem
Viewer kannst Du sagen, dass er die Verbindung über den Repeater aufbauen
soll. Nach aussen brauchst Du dann nur eine eingehende IP zum Repeater frei
zu schalten. Das ist eine sehr elegante Lösung mit minimalem
Konfigurationsaufwand. Die Server können alle auf Ihrem Default Port 5900
belassen werden. Den Proxy stellst Du z.B. auf Port 5500 ein und diesen Port
öffnest Du. Die Rechner im Verbund dürfen dabei allerdings nicht voneinander
abgeschottet sein und der Rechner auf dem der Proxy läuft, muss den
zusätzlichen Traffic abhaben können.
Zum Verschüsseln gibt es zum UltraVNC ein Data Stream Modifcation (DSM)
Plugin, dass Du zum Verschlüsseln einsetzen kannst. Das einzusetzen ist um
einiges einfacher als einen VNP Tunnel einzurichten.
Das Pflichtpasswort bietet einen gewissen Schutz, könnte aber im Extremfall
gescannt werden, da es ohne das Plugin unverschlüsselt übers Netz geht.
Falls die VNC Server immer laufen sollen, würde ich Sie nicht ungeschützt
ans Netz hängen.
Alternativ liesse sich vom Server eine Reverse Verbindung aufbauen. Dann
bräuchtest Du Serverseitig keinen eingehenden Port zu öffnen. Das erfordert
aber eine Interaktion am Server beim Verbindungsaufbau oder eine Automatik
(z.B. über Geplante Tasks) die immer wieder versucht zu einer Gegenstelle
eine Verbindung zu einem Viewer der in den Listen Mode geschaltet wird
aufzubauen.
Die Remote Desktop Lösung die Standardmässig bei XP dabei ist, ist eine
tolle Lösung, weil Sie objekt orientiert arbeitet. Im Gegensatz zu VNC oder
NetMeeting wird nicht der Bildschirminhalt pixelweise übertragen sondern
eben Objektinformationen. Das reduziert das Datenvolumen. Ausserdem greift
das Sicherheitskonzept von MS beim einloggen (ist bei UltraVNC allerdings
auch realisiert). Nachteilig kann sein, das der Serverbildschirm dunkel
wird, was nicht so toll ist wenn jemand Unterstützng angefragt hat. Nächstes
Problem in Deinem Fall könnte sein, dass Du nur an einen PC ran kommst, weil
man den Port bei der Anwahl des Servers nicht angeben kann. Es wird der Fest
vorgegeben Port verwendet und dann musst Du den Router dauernd umbiegen um
einen anderen PC zu erreichen.
Grüßle
Diana
Joachim Conrad
Diana Bulthaupt schrieb:
> Nachteilig
> kann sein, das der Serverbildschirm dunkel wird, was nicht so toll
> ist wenn jemand Unterstützng angefragt hat. Nächstes Problem in
> Deinem Fall könnte sein, dass Du nur an einen PC ran kommst, weil man
> den Port bei der Anwahl des Servers nicht angeben kann.
Doch kann man und den Port auf den der "VPN-Server" lauscht lässt sich
auch anpassen:
HKLM\System\CurrentControlSet\Control\Class\
{4D36E972-E325-11CE-BFC1-08002bE10318}\<000x>, hier musst du den WAN
Miniport (PPTP) suchen. Dort gibt es den Eintrag "TcpPortNumber", den
kannst du ändern. Ein Neustart ist notwendig. Mittels "netstat -an"
prüfen ob der PC tatsächlich an dem gewünschtem Port lauscht(bei
eingehenden Verbindungen)
Diana Bulthaupt at
danke für die Info. Man lernt nie aus.
> Doch kann man und den Port auf den der "VPN-Server" lauscht lässt sich
> auch anpassen:
>
> HKLM\System\CurrentControlSet\Control\Class\
> {4D36E972-E325-11CE-BFC1-08002bE10318}\<000x>, hier musst du den WAN
> Miniport (PPTP) suchen. Dort gibt es den Eintrag "TcpPortNumber", den
> kannst du ändern. Ein Neustart ist notwendig. Mittels "netstat -an"
> prüfen ob der PC tatsächlich an dem gewünschtem Port lauscht(bei
> eingehenden Verbindungen)
TcpPortNumber finde ich auf meinem Rechner unter ...\0007 und steht auf
1723. Das ist der Port des Host?, den der Client vorraussetzt?
Wie gebe ich dann beim Verbindungsaufbau am Client einen anderen Port an
(kein VPN im Einsatz, vielleicht so <ComputerName>:<Port>)?
Wenn Du mir jetzt noch verraten könntest, wie man die Session am Host
mitverfolgen kann (kein schwarzer Bildschirm, bzw. nur Ameldefenster
sichtbar) dann werfe ich unsere VNC Lösung über Board und steig auf
RemoteDesktop um :-).
Gruß
Diana
Joachim Conrad
Diana Bulthaupt schrieb:
> danke für die Info.
Gern geschehen. :)
> Man lernt nie aus.
Wem sagst du das. ;)
>> Doch kann man und den Port auf den der "VPN-Server" lauscht lässt
>> sich auch anpassen:
>>
>> HKLM\System\CurrentControlSet\Control\Class\
>> {4D36E972-E325-11CE-BFC1-08002bE10318}\<000x>, hier musst du den WAN
>> Miniport (PPTP) suchen. Dort gibt es den Eintrag "TcpPortNumber", den
>> kannst du ändern. Ein Neustart ist notwendig. Mittels "netstat -an"
>> prüfen ob der PC tatsächlich an dem gewünschtem Port lauscht(bei
>> eingehenden Verbindungen)
>
> TcpPortNumber finde ich auf meinem Rechner unter ...\0007 und steht
> auf 1723. Das ist der Port des Host?
Jep und darüber kannst du auch den Standard-Port des Clients ändern,
wenn du beim Verbindungsaufbau keinen Port explizit angibst.
> Wie gebe ich dann beim Verbindungsaufbau am Client einen anderen Port
> an (kein VPN im Einsatz, vielleicht so <ComputerName>:<Port>)?
Ja, genauso.
> Wenn Du mir jetzt noch verraten könntest, wie man die Session am Host
> mitverfolgen kann (kein schwarzer Bildschirm, bzw. nur Ameldefenster
> sichtbar) dann werfe ich unsere VNC Lösung über Board und steig auf
> RemoteDesktop um :-).
Tja, da hast du meinen wunden Punkt erwischt. Das geht AFAIK nicht mit
dem Remotedesktop, aber mit der Remoteunterstützung, die ich aber
eigentlich nie verwende und deswegen auch nicht viel dazu sagen kann.
Thomas Henkel
> Zum Verschüsseln gibt es zum UltraVNC ein Data Stream Modifcation (DSM)
> Plugin, dass Du zum Verschlüsseln einsetzen kannst. Das einzusetzen ist um
> einiges einfacher als einen VNP Tunnel einzurichten.
> Das Pflichtpasswort bietet einen gewissen Schutz, könnte aber im Extremfall
> gescannt werden, da es ohne das Plugin unverschlüsselt übers Netz geht.
Nein. Wenn bei UltraVNC ein DSM-Plugin verwendet wird, wird auch das
Passwort verschlüsselt übertragen.
> Die Remote Desktop Lösung die Standardmässig bei XP dabei ist, ist eine
> tolle Lösung, weil Sie objekt orientiert arbeitet. Im Gegensatz zu VNC oder
> NetMeeting wird nicht der Bildschirminhalt pixelweise übertragen sondern
> eben Objektinformationen. Das reduziert das Datenvolumen.
Ich lese immer wieder, dass Remote Desktop so schnell im Vergleich zu
anderen Lösungen sein soll. Ich kann das hier in der Praxis nicht
nachvollziehen. Bei mir läuft UltraVNC mindestens so schnell wie Remote
Desktop, auf Schmalband-Verbindungen wie DSL oder gar ISDN sogar deutlich
schneller. Mit Remote Desktop konnte ich selbst über eine DSL-Leitung nie
ernsthaft arbeiten. Mit UltraVNC geht das sogar mit ISDN noch ganz
erträglich, notfalls auch runtergerechnet in 16 Farben und etwas unscharf.
:-) Und mit meiner derzeitigen DSL-Anbindung (512 kBit Upload) lässt sich
fast flüssig auf dem entfernten Rechner arbeiten. Lediglich der Mauszeiger
ruckelt ab und zu und es dauert 1-2 Sekunden, wenn der Bildschirm komplett
neu übertragen werden muss (z.B. wenn ein bildschirmfüllendes Fenster
geöffnet wird).
> Ausserdem greift
> das Sicherheitskonzept von MS beim einloggen (ist bei UltraVNC allerdings
> auch realisiert). Nachteilig kann sein, das der Serverbildschirm dunkel
> wird, was nicht so toll ist wenn jemand Unterstützng angefragt hat.
Wenn man sich mit der Benutzerkennung des Benutzers einloggt, der an dem
Rechner bereits lokal angemeldet ist, wird der Bildschirm bei Remote
Desktop nicht nur dunkel, sondern der Benutzer wird komplett auf die
entfernte Verbindung "geroutet". Das Problem dabei: wird die Verbindung
unterbrochen (ob nun gewollt durch eine Abmeldung oder ungewollt durch eine
unterbrochene Leitung), werden alle Programme beendet und der Benutzer von
dem Rechner endgültig abgemeldet. Das wiederum ist *richtig* ärgerlich,
wenn man Programme auf dem entfernten Rechner starten und sie eine Weile
laufen lassen will. Dann muss man die Verbindung die ganze Zeit über
aufrecht erhalten und beten, dass die Telefonleitung hält oder nicht
ausgerechnet gerade die 24h-Zwangstrennung des DSL-Providers zuschlägt...
Tom
Diana Bulthaupt at
> > TcpPortNumber finde ich auf meinem Rechner unter ...\0007 und steht
> > auf 1723. Das ist der Port des Host?
>
> Jep und darüber kannst du auch den Standard-Port des Clients ändern,
> wenn du beim Verbindungsaufbau keinen Port explizit angibst.
So geht das also.
> Tja, da hast du meinen wunden Punkt erwischt. Das geht AFAIK nicht mit
> dem Remotedesktop, aber mit der Remoteunterstützung, die ich aber
> eigentlich nie verwende und deswegen auch nicht viel dazu sagen kann.
Aha erwischt ;-). Die Remoteunterstützung wäre ok, wenn man das Ticket nicht
generieren müsste. Kann ich keinem Kunden zumuten. Ausserdem wird noch der
Frame gebildet, der zuviel Platz auf einem kleinen Display (800x600)
braucht.
Wenn das MS mal etwas überarbeiten würde, könnten die anderen Lösungen auf
dem Markt einpacken. Wird sich da bei Longhorn etwas ändern?
Gruß
Diana
Michael H. Fischer
> Aha erwischt ;-). Die Remoteunterstützung wäre ok, wenn man das Ticket nicht
> generieren müsste. Kann ich keinem Kunden zumuten
Doch, kannst du. Sorry, aber warum ist eingentlich fast jeder Supporter
der Meinung, dass ausgerechnet seine Kunden dümmer sind als geschnitten
Brot?
Da machst du einmal eine schöne Schritt für Schritt Anleitung,
gegebenenfalls mit hübschen bunten Bildchen, drückst denen das in die
Hand, gehst es einmal mit ihnen durch und du wirst überrascht sein, wozu
deine Kunden alles in der Lage sind.
MfG
Michael H. Fischer
--
Freeware und Antworten rund um NT/W2K/XP: http://www.derfisch.de/
Die XP Nano FAQ: http://www.derfisch.de/xpnf.php
Windows Tuning Mythen: http://www.derfisch.de/Tuning-Mythen.html
Diana Bulthaupt at
> > Aha erwischt ;-). Die Remoteunterstützung wäre ok, wenn man das Ticket
nicht
> > generieren müsste. Kann ich keinem Kunden zumuten
>
> Doch, kannst du. Sorry, aber warum ist eingentlich fast jeder Supporter
> der Meinung, dass ausgerechnet seine Kunden dümmer sind als geschnitten
> Brot?
Es geht nicht nur darum, ob Sie dumm sind sondern um effektives
unkompliziertes Arbeiten. Auf unserer Maschinensoftware gibt es z.B.
garkeine XP Shell. Damit fängt es schon an. Das war früher mal anders und
dann gab es formatierte Festplatten und Arbeiter die auf
Produktionsmaschinen Spiele installiert haben, um sich die Nachtschicht um
die Ohren zu schlagen. Mit den dabei entstehenden Problemen ist unser
Service und zum Teil auch die Entwicklung ganz schön beschäftigt gewesen.
Jemand der Zentral eine Maschine administrieren will, hat kein Interesse
daran, zu jeder Maschine zu laufen und ein Ticket zu generieren und wenn er
sich auf die Maschiene loggen will, wieder hinzuwetzen um den Zugang zu
quitieren. Sonst bräuchte man wie in der IBM Werbung den schnellsten Mann
der Welt mit XP statt Tunix Erfahrung :-).
>
> Da machst du einmal eine schöne Schritt für Schritt Anleitung,
> gegebenenfalls mit hübschen bunten Bildchen, drückst denen das in die
> Hand, gehst es einmal mit ihnen durch und du wirst überrascht sein, wozu
> deine Kunden alles in der Lage sind.
Scheidet aus obigen gründen aus und wozu diesen Aufwand treiben? Das ganze
müsste dann in allen möglichen Sprachen übersetzt werden, die Leute müssten
geschult werden. Und wenn Sie mal support bräuchten, dann haben Sie längst
vergessen, wie man ein Ticket erstellt. Das Ticket muss man ja noch zum
Supporter bringen. Das kann dann auch nochmal kompliziert werden. Es geht
deutlich einfacher.
Von unseren Admins im Haus verwendet keiner die Remote Assisten Lösung, um
aus der Ferne zu administrieren. Die setzen UltraVNC ein.
Es ist wirklich schade um dieses Remote Assistent Feature von XP. Dieses
kümmerliche Fristen in der Ecke hat es eigentlich nicht verdient. Das würde
sich aber ändern, wenn sich MS dazu entschliessen würde den Zugang zu
vereinfachen.
Gruß
Diana
Diana Bulthaupt at
> > Zum Verschüsseln gibt es zum UltraVNC ein Data Stream Modifcation (DSM)
> > Plugin, dass Du zum Verschlüsseln einsetzen kannst. Das einzusetzen ist
um
> > einiges einfacher als einen VNP Tunnel einzurichten.
> > Das Pflichtpasswort bietet einen gewissen Schutz, könnte aber im
Extremfall
> > gescannt werden, da es ohne das Plugin unverschlüsselt übers Netz geht.
>
> Nein. Wenn bei UltraVNC ein DSM-Plugin verwendet wird, wird auch das
> Passwort verschlüsselt übertragen.
Yep, so steht es aber auch oben :-).
> Ich lese immer wieder, dass Remote Desktop so schnell im Vergleich zu
> anderen Lösungen sein soll. Ich kann das hier in der Praxis nicht
> nachvollziehen. Bei mir läuft UltraVNC mindestens so schnell wie Remote
> Desktop, auf Schmalband-Verbindungen wie DSL oder gar ISDN sogar deutlich
> schneller. Mit Remote Desktop konnte ich selbst über eine DSL-Leitung nie
> ernsthaft arbeiten. Mit UltraVNC geht das sogar mit ISDN noch ganz
> erträglich, notfalls auch runtergerechnet in 16 Farben und etwas unscharf.
> :-) Und mit meiner derzeitigen DSL-Anbindung (512 kBit Upload) lässt sich
> fast flüssig auf dem entfernten Rechner arbeiten. Lediglich der Mauszeiger
> ruckelt ab und zu und es dauert 1-2 Sekunden, wenn der Bildschirm komplett
> neu übertragen werden muss (z.B. wenn ein bildschirmfüllendes Fenster
> geöffnet wird).
Habs bisher nur im Intranet ausprobiert und da hatte ich schon den Eindruck,
dass Remote Desktop schneller ist. Ausserdem gibt es nicht mal Bereiche die
nicht abgedated werden.
Will aber nicht ausschliessen, dass Deine Erfahrungen richtig sind. Mit
UltraVNC administriere ich schon mal über DSL mit nur 128KB Upload und das
geht auch noch ganz gut.
> Wenn man sich mit der Benutzerkennung des Benutzers einloggt, der an dem
> Rechner bereits lokal angemeldet ist, wird der Bildschirm bei Remote
> Desktop nicht nur dunkel, sondern der Benutzer wird komplett auf die
> entfernte Verbindung "geroutet". Das Problem dabei: wird die Verbindung
> unterbrochen (ob nun gewollt durch eine Abmeldung oder ungewollt durch
eine
> unterbrochene Leitung), werden alle Programme beendet und der Benutzer von
> dem Rechner endgültig abgemeldet. Das wiederum ist *richtig* ärgerlich,
> wenn man Programme auf dem entfernten Rechner starten und sie eine Weile
> laufen lassen will. Dann muss man die Verbindung die ganze Zeit über
> aufrecht erhalten und beten, dass die Telefonleitung hält oder nicht
> ausgerechnet gerade die 24h-Zwangstrennung des DSL-Providers zuschlägt...
>
> Tom
Guter Hinweis. Gerade über eine externe Leitung kann die Verbindung schon
mal abbrechen. Datenverlust und alle Programme neu starten zu müssen, wäre
nicht so toll. Bei VNC startet man einfach den Viewer nochmal und hängt sich
wieder dran.
Diana
Thomas Bliesener
> On Fri, 4 Nov 2005 23:31:42 +0100, Diana Bulthaupt wrote:
>
> Wenn bei UltraVNC ein DSM-Plugin verwendet wird, wird auch das
> Passwort verschlüsselt übertragen.
>
> [...]
> Bei mir läuft UltraVNC mindestens so schnell wie Remote Desktop,
> auf Schmalband-Verbindungen wie DSL oder gar ISDN sogar deutlich
> schneller.
Kann ich nur bestätigen. Bewährt sich hervorragend beim Support für
Heimarbeitsplätze mit schmaler Anbindung, ohne XP und mit dem didaktischen
Erfordernis, die Lösungen zu sehen und zu verstehen. Nur in Messenger
Communities, soweit auf XP, setzt sich auch mal Remoteunterstützung durch.
Besonders komfortabel ist das installationsfreie "VNC Single Click"
http://sc.uvnc.com/index.php?section=12 - säh ich gern im Werkzeugkasten
kommender Windowsversionen ...
--
FAQ Messenger & Netmeeting: http://www.uni-essen.de/kitt/faq-nm.htm
Tschüß, regards, salut, Thomas Bliesener, MVP http://tinyurl.com/clss3