Fernwartung mit DynDNS
Hallo Leute!
Habe Zuhause folgende Konstellation:
Möchte nun eine Fernwartung mittels Remote Desktop übers Internet (mit DynDNS-Name) auf den „Server“ (WinXP-Prof. SP3) 192.168.1.10 realisieren!
Um das hin zu kriegen, müsste es doch reichen, das Port 3389 in der Firewall freizuschalten und das Port-Forwarding folgendermaßen einzutragen:
Auf Speedtouch: Port 3389 auf 10.0.0.140 (WLAN-Router) weiterleiten und vom WLAN-Router auf 192.168.1.10!
Hab ich da einen Denkfehler, oder warum funktioniert das so nicht?
Habe Zuhause folgende Konstellation:
Möchte nun eine Fernwartung mittels Remote Desktop übers Internet (mit DynDNS-Name) auf den „Server“ (WinXP-Prof. SP3) 192.168.1.10 realisieren!
Um das hin zu kriegen, müsste es doch reichen, das Port 3389 in der Firewall freizuschalten und das Port-Forwarding folgendermaßen einzutragen:
Auf Speedtouch: Port 3389 auf 10.0.0.140 (WLAN-Router) weiterleiten und vom WLAN-Router auf 192.168.1.10!
Hab ich da einen Denkfehler, oder warum funktioniert das so nicht?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 92600
Url: https://administrator.de/contentid/92600
Ausgedruckt am: 05.11.2024 um 06:11 Uhr
10 Kommentare
Neuester Kommentar
salü edvmädchenfürales
entweder du machst es so wie arch-stanton dir rät oder ansonsten könntest du auf dem speedtouch direkt die portweiterleitung auf die End-IP 192.168.1.10 leiten - dafür musst du beim speedtouch router jedoch noch eine statische route eintragen, damit dieser weiss, hinter welchem router sich das netz 192.168.1.0 befindet! diese würde dann wie folgt aussehen:
Netz: 192.168.1.0 Subnetmaske: 255.255.255.0 Gateway: 192.168.0.140
gruss tacker
entweder du machst es so wie arch-stanton dir rät oder ansonsten könntest du auf dem speedtouch direkt die portweiterleitung auf die End-IP 192.168.1.10 leiten - dafür musst du beim speedtouch router jedoch noch eine statische route eintragen, damit dieser weiss, hinter welchem router sich das netz 192.168.1.0 befindet! diese würde dann wie folgt aussehen:
Netz: 192.168.1.0 Subnetmaske: 255.255.255.0 Gateway: 192.168.0.140
gruss tacker
@tacker
Diese Route ist kompletter Unsinn, denn ein Netzwerk 192.168.0.0 /24 gibt es gar nicht in seinem Netz !! Das Bild zeigt das eindeutig und es empfiehlt sich vor dem Tippen nachzudenken !
Am Speedtouch ist lokal ein 10er Netz dran ! Wenn, dann muss die Route richtig lauten:
Netz: 192.168.1.0 Subnetmaske: 255.255.255.0 Gateway: 10.0.0.140
So oder so ist sie aber auch vollkommen überflüssig, denn edvmädch.. macht auf dem NetGear NAT. Er maskiert also sein gesamtes WLAN auf die LAN IP Adresse 10.0.0.140.
Das WLAN Netzwerk 192.168.1.0 taucht also gar nicht mehr im 10er Netz auf sondern alle Packete aus diesem Netz werden geNATtet auf die 10.0.0.140 und tauchen deshalb NUR mit dieser IP auf.
Das ist gewissermaßen eine "DMZ des kleinen Mannes" wie sie auch hier beschrieben ist:
http://www.heise.de/netze/DMZ-selbst-gebaut--/artikel/78397
In der Beziehung ist die Route ziemlich sinnlos, denn der Speedtouch weiss deshalb gar nicht das sich hinter der 10.0.0.140 ein anderes Netz verbirgt.
Eigentlich müsste die dopplete Port Weiterleitung funktionieren ! Der Speedtouch sollte TCP 3389 (RDP) lokal auf die 10.0.0.140 weiterleiten und der NetGear dann lokal auf die 192.168.1.10.
Es ist aber möglich das das an einer MTU Problematik scheitert oder an der fehlerhaften Implementation der Port Weiterleitung.
Das kannst du aber ganz einfach mal prüfen:
Hänge einen PC mit einem Packet Sniffer in das 10.0.0.0er Netz und prüfe einmal ob der Speetouch diese eingehenden Packete wirklich lokal in das Netz weiterreicht !!
Irgendeiner deine Router macht das vermutlich nicht.
Als Sniffer verwendest du den
www.wireshark.org
oder den MS Net Monitor:
http://www.microsoft.com/downloads/details.aspx?FamilyID=18b1d59d-f4d8- ...
Um dir aber das Leben nicht schwer zu machen und wenn du diese DMZ Lösung im WLAN nicht wirklich unbedingt benötigst aus Sicherheitsgründen, dann mache den NetGear Router einfach zum dummen WLAN Accesspoint und gut is....!
Wie das geht wird in diesem Tutorial in der Alternative 3 genau beschrieben:
Kopplung von 2 Routern am DSL Port
Dann hast du die NAT Problematik nicht mehr und arbeitest transparent im 10.0.0.0 /24 er Netzwerk und dann reicht ein einfaches Port Forwarding von TCP 3389 auf das WLAN Endgerät dann in diesem Netz um RDP problemlos zum Laufen zu bringen !!!
Diese Route ist kompletter Unsinn, denn ein Netzwerk 192.168.0.0 /24 gibt es gar nicht in seinem Netz !! Das Bild zeigt das eindeutig und es empfiehlt sich vor dem Tippen nachzudenken !
Am Speedtouch ist lokal ein 10er Netz dran ! Wenn, dann muss die Route richtig lauten:
Netz: 192.168.1.0 Subnetmaske: 255.255.255.0 Gateway: 10.0.0.140
So oder so ist sie aber auch vollkommen überflüssig, denn edvmädch.. macht auf dem NetGear NAT. Er maskiert also sein gesamtes WLAN auf die LAN IP Adresse 10.0.0.140.
Das WLAN Netzwerk 192.168.1.0 taucht also gar nicht mehr im 10er Netz auf sondern alle Packete aus diesem Netz werden geNATtet auf die 10.0.0.140 und tauchen deshalb NUR mit dieser IP auf.
Das ist gewissermaßen eine "DMZ des kleinen Mannes" wie sie auch hier beschrieben ist:
http://www.heise.de/netze/DMZ-selbst-gebaut--/artikel/78397
In der Beziehung ist die Route ziemlich sinnlos, denn der Speedtouch weiss deshalb gar nicht das sich hinter der 10.0.0.140 ein anderes Netz verbirgt.
Eigentlich müsste die dopplete Port Weiterleitung funktionieren ! Der Speedtouch sollte TCP 3389 (RDP) lokal auf die 10.0.0.140 weiterleiten und der NetGear dann lokal auf die 192.168.1.10.
Es ist aber möglich das das an einer MTU Problematik scheitert oder an der fehlerhaften Implementation der Port Weiterleitung.
Das kannst du aber ganz einfach mal prüfen:
Hänge einen PC mit einem Packet Sniffer in das 10.0.0.0er Netz und prüfe einmal ob der Speetouch diese eingehenden Packete wirklich lokal in das Netz weiterreicht !!
Irgendeiner deine Router macht das vermutlich nicht.
Als Sniffer verwendest du den
www.wireshark.org
oder den MS Net Monitor:
http://www.microsoft.com/downloads/details.aspx?FamilyID=18b1d59d-f4d8- ...
Um dir aber das Leben nicht schwer zu machen und wenn du diese DMZ Lösung im WLAN nicht wirklich unbedingt benötigst aus Sicherheitsgründen, dann mache den NetGear Router einfach zum dummen WLAN Accesspoint und gut is....!
Wie das geht wird in diesem Tutorial in der Alternative 3 genau beschrieben:
Kopplung von 2 Routern am DSL Port
Dann hast du die NAT Problematik nicht mehr und arbeitest transparent im 10.0.0.0 /24 er Netzwerk und dann reicht ein einfaches Port Forwarding von TCP 3389 auf das WLAN Endgerät dann in diesem Netz um RDP problemlos zum Laufen zu bringen !!!
Nein, das kommst du nicht ?? Wie soll das gehen, das sind 2 unterschiedliche IP Netze !! Ausserdem schreibst du nicht ob dein PC nur per WLAN erreichbar ist oder nicht.
Wenn du kein WLAN benötigst und ein Kabel nutzen kanns, dann brauchst du den NetGear gar nicht mehr...das ist klar.
Deine Zeichnung lässt nur vermuten, das der PC nur per WLAN angebunden ist und der Router selber kein WLAN hat....
Deine Alternativen sähen dann so aus:
Das 192.168er Netz kommt in so einem Szenario gar nicht mehr vor wenn der NetGear als reiner AP läuft !
Natürlich bist du nicht gezwungen den PC per WLAN anzubinden, eine Kabelverbindung klappt natürlich auch !
Im hellblauen Kreis siehst du die WLAN Alternative. Alles ohne Kreis ist die Kabellösung !!
Wenn du kein WLAN benötigst und ein Kabel nutzen kanns, dann brauchst du den NetGear gar nicht mehr...das ist klar.
Deine Zeichnung lässt nur vermuten, das der PC nur per WLAN angebunden ist und der Router selber kein WLAN hat....
Deine Alternativen sähen dann so aus:
Das 192.168er Netz kommt in so einem Szenario gar nicht mehr vor wenn der NetGear als reiner AP läuft !
Natürlich bist du nicht gezwungen den PC per WLAN anzubinden, eine Kabelverbindung klappt natürlich auch !
Im hellblauen Kreis siehst du die WLAN Alternative. Alles ohne Kreis ist die Kabellösung !!
Ein Problem natürlich der dann offene RDP Zugang. Ggf. macht es Sinn diesen Zugang etwas zu verscheiern indem du dem RDP auf dem Server einen anderen TCP Port zuweist. Das hilft Scanner usw. in die Irre zu führen, da diese meist nur die default Ports scannen
Das Anpassen des RDP Zielports geht über die Registry mit
Start -> Ausführen regedit im Wert HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp wo du dann im Wert PortNumber einfach den TCP Port einträgst.
Z.B. TCP 53389 statt des Default Werts 3389.
Wenn du nun den Client aufmachst dann gibst du als Ziel an name.dyndns.org:53389 Also immer den Port mit :53389 übergeben. So kannst du einigermassen sicher sein das nicht jeder Script Kiddie dir die Maschine kompromitiert
Das Port Forwarding musst du dann natürlich entsprechend auf diesen neuen TCP Port anpassen !!
Das Anpassen des RDP Zielports geht über die Registry mit
Start -> Ausführen regedit im Wert HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp wo du dann im Wert PortNumber einfach den TCP Port einträgst.
Z.B. TCP 53389 statt des Default Werts 3389.
Wenn du nun den Client aufmachst dann gibst du als Ziel an name.dyndns.org:53389 Also immer den Port mit :53389 übergeben. So kannst du einigermassen sicher sein das nicht jeder Script Kiddie dir die Maschine kompromitiert
Das Port Forwarding musst du dann natürlich entsprechend auf diesen neuen TCP Port anpassen !!