Routingproblem für einen TerminalServer in einer Virtuellen Maschine
Hallo Community,
wir haben folgende Ausgangssituation:
Problem:
Remotedesktop auf unsere IP funktioniert nicht.
Wir sind zumindest davon ausgegangen das es so funktionieren sollte. Der alte Server kennt ja schließlich das Netz 192.168.1.0 weil er ja in beiden Netzen beheimatet ist.
Aber offensichtlich leitet der alte Server die IP nicht weiter. Wir haben auch schon versucht auf dem Server einen Statische Route für das Netz 192.168.1.0 anzulegen und gaben als Gateway die .1.10 an. Das ist er ja aber eigentlich selbst. Er kennt ja beide Netze geh ich mal davon aus. Wo könne denn der Hase hier begraben sein?? Was kann ich auf dem Server noch einstellen dass er die Anfrage weiterleitet? Ach übrigens funktioniert es tadellos wenn man sich im .1.0 Netz befindet. also hinter dem alten server. Wenn ich an der FB direkt hänge geht natürlich nix. Liegt also irgendwo am alten Server.
Ich hoffe ihr habt genug Infos um mir da weiterzuhelfen. Würde mich sehr freuen!
Gruß
Christian
wir haben folgende Ausgangssituation:
- eine öffentliche IP adresse im Bereich 195.*.*.*
- eine FritzBox die diese IP hat und intern über die 192.168.0.100
- einen älteren Server mit 2 Netzwerkkarten. Eine Karte hat die IP 192.168.0.10 (externes Netz) und eine 192.168.1.10 (intern)
- einen neuen QuadCore Server mit Windows Server 2008 Standard und aktuell Virtual Server 2005 R2 SP1 in dem momentan ein Windows Server 2003 R2 System mit TerminalServer Diensten läuft. Der 2008er hat die IP 192.168.1.20 und der VServer darin die 192.168.1.21
- Auf der FritzBox ist eine Portweiterleitung für 3389 auf die IP 192.168.1.21 eingerichtet zusätzlich dazu ein Statische Route für das Netz 192.168.1.0 (weil die FB das Netz nicht kennt) auf das Gateway 192.168.0.10 auf unserem alten Server
Problem:
Remotedesktop auf unsere IP funktioniert nicht.
Wir sind zumindest davon ausgegangen das es so funktionieren sollte. Der alte Server kennt ja schließlich das Netz 192.168.1.0 weil er ja in beiden Netzen beheimatet ist.
Aber offensichtlich leitet der alte Server die IP nicht weiter. Wir haben auch schon versucht auf dem Server einen Statische Route für das Netz 192.168.1.0 anzulegen und gaben als Gateway die .1.10 an. Das ist er ja aber eigentlich selbst. Er kennt ja beide Netze geh ich mal davon aus. Wo könne denn der Hase hier begraben sein?? Was kann ich auf dem Server noch einstellen dass er die Anfrage weiterleitet? Ach übrigens funktioniert es tadellos wenn man sich im .1.0 Netz befindet. also hinter dem alten server. Wenn ich an der FB direkt hänge geht natürlich nix. Liegt also irgendwo am alten Server.
Ich hoffe ihr habt genug Infos um mir da weiterzuhelfen. Würde mich sehr freuen!
Gruß
Christian
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 83596
Url: https://administrator.de/contentid/83596
Ausgedruckt am: 22.11.2024 um 11:11 Uhr
7 Kommentare
Neuester Kommentar
Klar das du das Port Forwarding auch auf dem Server einrichten musst !! Woher soll er denn sonst bitte wissen das das Packet nicht für IHN ist denn ihr forwardet es ja auf der FB direkt an seine IP Adresse.
Wie das geht kannst du in der MS Knowledgebase nachlesen:
http://technet2.microsoft.com/WindowsServer/de/Library/6dd18466-d9dc-43 ...
Grundlagen zu deinem Design stehen in diesem Tutorial:
Wie das geht kannst du in der MS Knowledgebase nachlesen:
http://technet2.microsoft.com/WindowsServer/de/Library/6dd18466-d9dc-43 ...
Grundlagen zu deinem Design stehen in diesem Tutorial:
Ahem, Port Forwarding ist kein Routing !! Da hast du wohl etwas durcheinandergebracht, oder ??!!
Wenn der Server das nicht weiterleitet, dann hast du keine Chance. Eine statische Route ist Unsinn wie du ja auch selber schon bemerkt hast.
Was an deiner Beschreibung aber vollkommen unklar ist, ist dein letzter Satz ! Du schreibst: "Ach übrigens funktioniert es tadellos wenn man sich im .1.0 Netz befindet...."
Deine per RDP zu administrierenden Server befinden sich ja aber auch in genau dem .1.0er Netz mit ihren IP Adressen 192.168.1.20/24 und 192.168.1.21/24.
Da der virtuelle Server per Bridging (also Layer 2) am Host hängt spielt Routing hier also keine Rolle denn alles ist im .1.0er IP Segment !
Das widerspricht dann ja eigentlich deinem geschilderten Problem... ???
Wenn der Server das nicht weiterleitet, dann hast du keine Chance. Eine statische Route ist Unsinn wie du ja auch selber schon bemerkt hast.
Was an deiner Beschreibung aber vollkommen unklar ist, ist dein letzter Satz ! Du schreibst: "Ach übrigens funktioniert es tadellos wenn man sich im .1.0 Netz befindet...."
Deine per RDP zu administrierenden Server befinden sich ja aber auch in genau dem .1.0er Netz mit ihren IP Adressen 192.168.1.20/24 und 192.168.1.21/24.
Da der virtuelle Server per Bridging (also Layer 2) am Host hängt spielt Routing hier also keine Rolle denn alles ist im .1.0er IP Segment !
Das widerspricht dann ja eigentlich deinem geschilderten Problem... ???
Wie gesagt, du musst dem alten Server sagen, das er das Packet forwarden soll. Wenn er das nicht macht liegt dort der Hase im Pfeffer (...und das an Ostern )
Als erstes solltest du auch mal verifizieren ob die FB diese remoten RDP Packete auch wirklich forwardet mit der korrekten Adresse !
Recht häufig funktionieren Port Forwardings nämlich bei Routern nicht wenn sie auf IP Adressen zeigen, die nicht im lokalen LAN liegen. Leider auch dann wenn man eine korrekte statische Route eingegeben hat. Ein typischer Firmware Fehler solcher Router...
Dazu solltest du mal einen Sniffer wie den www.WIRESHARK.org oder den Mircrosoft-Netmonitor in das .0.0er Segment (extern) einschleifen und überhaupt prüfen ob die FB das Packet weitersendet.
Wenn sie es nicht tut aus den o.a. Gründen hast du da das Problem.
Dann hast du als Ausweg immer noch die 2 Hop Lösung also RDP auf den alten Server und von da RDP auf den Neuen... Unschön aber machbar...
Als erstes solltest du auch mal verifizieren ob die FB diese remoten RDP Packete auch wirklich forwardet mit der korrekten Adresse !
Recht häufig funktionieren Port Forwardings nämlich bei Routern nicht wenn sie auf IP Adressen zeigen, die nicht im lokalen LAN liegen. Leider auch dann wenn man eine korrekte statische Route eingegeben hat. Ein typischer Firmware Fehler solcher Router...
Dazu solltest du mal einen Sniffer wie den www.WIRESHARK.org oder den Mircrosoft-Netmonitor in das .0.0er Segment (extern) einschleifen und überhaupt prüfen ob die FB das Packet weitersendet.
Wenn sie es nicht tut aus den o.a. Gründen hast du da das Problem.
Dann hast du als Ausweg immer noch die 2 Hop Lösung also RDP auf den alten Server und von da RDP auf den Neuen... Unschön aber machbar...
"Ich wage mal die Behauptung anzustellen, dass es AVM schon noch zusammen bringt ..." Mmmhh du solltest nicht allzuviel Vertrauen darein legen sondern besser selbst nachmessen, dann bist du wirklich sicher.
Auch die stellen nur Router für den Consumer Bereich her in dem es nur um den Preis geht...sonst nichts ! Professionelle Router (Cisco etc.) können damit problemlos umgehen aber in dem Consumer Sektor ist das leider nicht der Fall, da solche Konstrukte wie du sie hast im Privat- und Heimbereich eher selten sind. Im Firmenumfeld allerdings nicht, das ist klar !
Hier prallen dann immer Anspruch und Wirklichkeit oft hart aufeinander wenn mal wieder der letzte Euro gespart wurde...
Also Fazit: Nachmessen ist besser. Erst wenn du diese Packete mit dem Sniffer siehst, dann kannst auch sicher wissen, das sie wenigstens am alten Serverankommen !
Dann gilt es hier weiterzumachen. Die MS Knowledgebase hat einen recht knappen Artikel zum Thema Port Weiterleitung:
http://technet2.microsoft.com/WindowsServer/de/Library/6dd18466-d9dc-43 ...
Auch die stellen nur Router für den Consumer Bereich her in dem es nur um den Preis geht...sonst nichts ! Professionelle Router (Cisco etc.) können damit problemlos umgehen aber in dem Consumer Sektor ist das leider nicht der Fall, da solche Konstrukte wie du sie hast im Privat- und Heimbereich eher selten sind. Im Firmenumfeld allerdings nicht, das ist klar !
Hier prallen dann immer Anspruch und Wirklichkeit oft hart aufeinander wenn mal wieder der letzte Euro gespart wurde...
Also Fazit: Nachmessen ist besser. Erst wenn du diese Packete mit dem Sniffer siehst, dann kannst auch sicher wissen, das sie wenigstens am alten Serverankommen !
Dann gilt es hier weiterzumachen. Die MS Knowledgebase hat einen recht knappen Artikel zum Thema Port Weiterleitung:
http://technet2.microsoft.com/WindowsServer/de/Library/6dd18466-d9dc-43 ...