4420
21.06.2005, aktualisiert am 10.08.2006
6261
7
0
Riesen Problem mit DynDNS und 2 Routern über VPN!!!
Hallo,
also wir haben bei einem Kunden mit 2 Standorten an einem Standort einen Terminalserver installiert. Die User von Standort B greifen über VPN und Remotedesktop auf den Terminalserver an Standort A zu. Wir haben auf beiden Seiten denselben Router (einen SMC Barricade) installiert. Die Verbindungsherstellung ist auch kein Problem. Wir haben das Problem der dynamischen IP an beiden Orten mit einem DynDNS Namen versucht zu lösen.
Das klappt auch eigentlich......nur tritt ziemlich oft folgendes Problem auf:
Zu unregelmäßigen Abständen oder wenn man den Router an einem Standort neustartet, kommen die Anwender von Standort B nicht mehr über den DynDNS Namen auf den Terminalserver. Wenn man in der Eingabeaufforderung versucht den DynDNS Namen anzupingen, versucht Windows immer noch einen Ping auf die alte IP. Somit ist ja klar dass man nicht mehr auf den Terminalserver kommt. Man muss also irgendwie erst die richtige IP herausfinden....und das ist mit Telefonieren verbunden, da kein Rechner an Standort B mehr den DynDNS Namen anpingen kann. Das ist aber keine Lösung auf Dauer.
Wir haben schon versucht an Standort A und an Standort B einen DynDNS Updater zu installieren.....das bringt ja aber auch nichts, da der ja immer nur die WAN des jeweiligen Standortes updated.
Ein anderer Versuch war, dass man den Dienst "DNSClient" neustartet.....das funktioniert aber nur ganz selten, dass dann wieder die neue IP geholt wird!"
Kennt jemand dieses Phänomen und weiß eventuell eine Lösung! Wäre sehr wichtig und ich wäre Euch sehr dankbar!!!
also wir haben bei einem Kunden mit 2 Standorten an einem Standort einen Terminalserver installiert. Die User von Standort B greifen über VPN und Remotedesktop auf den Terminalserver an Standort A zu. Wir haben auf beiden Seiten denselben Router (einen SMC Barricade) installiert. Die Verbindungsherstellung ist auch kein Problem. Wir haben das Problem der dynamischen IP an beiden Orten mit einem DynDNS Namen versucht zu lösen.
Das klappt auch eigentlich......nur tritt ziemlich oft folgendes Problem auf:
Zu unregelmäßigen Abständen oder wenn man den Router an einem Standort neustartet, kommen die Anwender von Standort B nicht mehr über den DynDNS Namen auf den Terminalserver. Wenn man in der Eingabeaufforderung versucht den DynDNS Namen anzupingen, versucht Windows immer noch einen Ping auf die alte IP. Somit ist ja klar dass man nicht mehr auf den Terminalserver kommt. Man muss also irgendwie erst die richtige IP herausfinden....und das ist mit Telefonieren verbunden, da kein Rechner an Standort B mehr den DynDNS Namen anpingen kann. Das ist aber keine Lösung auf Dauer.
Wir haben schon versucht an Standort A und an Standort B einen DynDNS Updater zu installieren.....das bringt ja aber auch nichts, da der ja immer nur die WAN des jeweiligen Standortes updated.
Ein anderer Versuch war, dass man den Dienst "DNSClient" neustartet.....das funktioniert aber nur ganz selten, dass dann wieder die neue IP geholt wird!"
Kennt jemand dieses Phänomen und weiß eventuell eine Lösung! Wäre sehr wichtig und ich wäre Euch sehr dankbar!!!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 12152
Url: https://administrator.de/contentid/12152
Ausgedruckt am: 20.11.2024 um 17:11 Uhr
7 Kommentare
Neuester Kommentar
Besorgt euch einen Qualitäöts Router mit eigenem VPN.
z.B.: den Draytek Vigor 2900GI (kann 32VPN-Kanäle zugleich).
Mit dem baut mandie VPN-Verbindung nicht auf den Server, sondern auf den Router auf (ist sicherer, da ein Loch weniger in der FW).
Ausseerdem hat er ein ISDN Backup, d.h. man kann sich per ISDN einwählen und wenn nötig, DYNDNS neustarten.
Meine Erfahrung zeigt aber, dass es nicht nötiog, da dieser Router eigentlich bei meinen Kunden schon bis zu 9 Monate problrmlos läuft.
z.B.: den Draytek Vigor 2900GI (kann 32VPN-Kanäle zugleich).
Mit dem baut mandie VPN-Verbindung nicht auf den Server, sondern auf den Router auf (ist sicherer, da ein Loch weniger in der FW).
Ausseerdem hat er ein ISDN Backup, d.h. man kann sich per ISDN einwählen und wenn nötig, DYNDNS neustarten.
Meine Erfahrung zeigt aber, dass es nicht nötiog, da dieser Router eigentlich bei meinen Kunden schon bis zu 9 Monate problrmlos läuft.
ja wir sind gerade eh am Testen mit 2 VPN Routern zwischen Buero und Privat!! HAben aber nicht den Draytek sondern nen Netgear ProSafe VPN FVS318v3! Hat jemand VPN Erfahrungen mit diesem Router gemacht???
Kannst noch 2 STück vom 328er Typ von Netgear von mir haben, und das günstig.
Die liegen seit nem halben Jahr hier rum, weil die dinger ein absoluter Schrott sind.
Die liegen seit nem halben Jahr hier rum, weil die dinger ein absoluter Schrott sind.
Also um nochmal auf dein Problem mit dem VPN im jetzigen Zustand zu kommen. Ich benütze auch DynDNS und hab auch den Updater installiert. Bei mir funktioniert das. Ich hab praktisch den Updater auf der Maschine installiert auf die ich zugreifen will und dem Rechner eine feste IP gegeben. Dann eine eingehende Verbindung mit den Benutzern eingestellt. Im Router unter den NAT einstellungen die Weiterleitung für den Port 1723 (PPTP) auf die feste IP.
Vom Geschäft aus eine neue Verbindung erstellt mit den Namen der in DynDNS eingestragen ist. Der Updater muss schon sein sonst weiß ja DynDNS nicht welche öffentliche IP du hast, die halt vom Router. Außer du hast eine feste bei deinem Host-Provider eingestragen. Dann kommt die Anfrage zum Router und der weiß ja dann dass diese Anfrage auf Port 1723 zu der festen IP gehört auf die du zugreifen willst.
Du kannst ja den Updater so einstellen das er sich in kürzeren Abständen aktualisiert. Oder du sagst einem Mitarbeiter in der anderen Firma das er den Updater Manuell aktualisiert.
Vom Geschäft aus eine neue Verbindung erstellt mit den Namen der in DynDNS eingestragen ist. Der Updater muss schon sein sonst weiß ja DynDNS nicht welche öffentliche IP du hast, die halt vom Router. Außer du hast eine feste bei deinem Host-Provider eingestragen. Dann kommt die Anfrage zum Router und der weiß ja dann dass diese Anfrage auf Port 1723 zu der festen IP gehört auf die du zugreifen willst.
Du kannst ja den Updater so einstellen das er sich in kürzeren Abständen aktualisiert. Oder du sagst einem Mitarbeiter in der anderen Firma das er den Updater Manuell aktualisiert.
So habe ich das ja auch gemacht! Nur funktioniert das nicht immer! Eingehende Verbindungen hab ich soweit ich weiß nicht erstellt! Das ist aber der einzigste Unterschied!
Das Problem ist ganz einfach dass manche der Clients trotzdem noch die alte IP des Dyn DNS anpingen. Der Server hat keine Probleme, der hat immer die aktuellste IP für DynDNS! Das Problem liegt aber bei den Clients!
Wenn sich um 12 Uhr die IP vom Internet Provider ändert und ich davor via VPN über Dyn DNS connected war, dann werde ich Punkt 12 vom VPN getrennt und kann mich nicht mehr einwählen. Irgendwo wird die alte IP des Dyn DNS auf den Clients gecacht! Und das ist absolut nicht wegzubekommen.
Das Problem ist ganz einfach dass manche der Clients trotzdem noch die alte IP des Dyn DNS anpingen. Der Server hat keine Probleme, der hat immer die aktuellste IP für DynDNS! Das Problem liegt aber bei den Clients!
Wenn sich um 12 Uhr die IP vom Internet Provider ändert und ich davor via VPN über Dyn DNS connected war, dann werde ich Punkt 12 vom VPN getrennt und kann mich nicht mehr einwählen. Irgendwo wird die alte IP des Dyn DNS auf den Clients gecacht! Und das ist absolut nicht wegzubekommen.
hast du schonmal probiert ob es einen unterschied macht, wenn du disconnected wirst und danach beim updater auf "manuell detect ip" gehst. dann holt er sich nicht nach einer bestimmten zeit die ip, sondern sofort. der Updater muss schon auf den server installiert sein auf den du zugreifen willst. nicht auf den clients. der Updater ist ja dafür zuständig das dyndns die neue öffentliche ip vom router weiß. falls dann eine anfrage von draußen kommt, weiß der router das er diese anfrage auf (Port 1723) zu dem Server "Sowieso" (der mit dem Updater) weiterleitet. Das musst du nur im Router unter NAT konfigurieren. bei den clients hast du eine VPN-Verbindung erstellt,oder?
(--> neue Verbindung erstellen, Verbindung mit dem Netzwerk am Arbeitsplatz herstellen, VPN-Verbindung, Name für Verbindung eintippen, keine Anfangsverbindung wählen, Hostnamen: "sowieso.dyndns.org" oder öffentliche IP eingeben, Smartcard verwenden oder nicht und dann "Fertigstellen".
die öffentliche ip überprüfst du über den Router oder du pingst deinen Hostnamen in DynDNS an z.B. "ping sowieso.dyndns.org".
Wie hast du das eigentlich mit der Einwahl gemacht, wenn du keine "Eingehende Verbindung" am Server erstellt hast. Ich hab da bei der "Eingehenden Verbindung" die Benutzer eingestellt die auf den Server dürfen und zu welcher Gruppe sie gehören.
Gruß ELE
(--> neue Verbindung erstellen, Verbindung mit dem Netzwerk am Arbeitsplatz herstellen, VPN-Verbindung, Name für Verbindung eintippen, keine Anfangsverbindung wählen, Hostnamen: "sowieso.dyndns.org" oder öffentliche IP eingeben, Smartcard verwenden oder nicht und dann "Fertigstellen".
die öffentliche ip überprüfst du über den Router oder du pingst deinen Hostnamen in DynDNS an z.B. "ping sowieso.dyndns.org".
Wie hast du das eigentlich mit der Einwahl gemacht, wenn du keine "Eingehende Verbindung" am Server erstellt hast. Ich hab da bei der "Eingehenden Verbindung" die Benutzer eingestellt die auf den Server dürfen und zu welcher Gruppe sie gehören.
Gruß ELE
Ich habe selbst über mehrere Jahre (seit Ende 2003) mit Netgear FVS 318 (Version 1) erfolgreich 2 Standorte mit einander
verbunden. Wir verwenden neben rdp (MS Terminalserver-Protokol) auch ein Dutzend weitere Protokolle über die gleiche
VPN-Verbindung.
Ich glaube der Knackpunkt in deiner Konfiguration stellt das DNS-Cache-Verhalten von MS dar. Die Implementation in Windows
ist disbezüglich schlichtwegs erbärmlich. Bei uns ist dieses Problem aus einem Grund nie aufgetreten: die Verbindung zwischen
den Windows-Systemen erfolgt IP-basierend. Beide Netze arbeiten mit unterschiedlichen internen Adressbereichen
(z.B. 192.168.1.0/24 und 192.168.2.0/24). Als Folge dessen kann via VPN über die Netgearboxen ein transparenter Zugriff
erfolgen. Die ganze DynDNS-Geschichte wird so durch die Netgear-Geräte problemlos gelöst und das mühsame DNS-Cache-
Verhalten von Windows kommt dadurch nicht zum tragen.
Du bist meiner Ansicht nach auf dem richtigen Weg: Router als VPN-Endpunkte und dadurch transparenter Zugriff (Routing)
für die Server.
Eine kleine Anmerkung am Rande: unsere Netgearboxen klemmen ca. alle 4 Wochen mal und müssen neu gestartet werden.
Ansonsten funktioniert der oben beschriebene Betrieb bei uns seit Anfangs 2004.
Gruss, Roger.
verbunden. Wir verwenden neben rdp (MS Terminalserver-Protokol) auch ein Dutzend weitere Protokolle über die gleiche
VPN-Verbindung.
Ich glaube der Knackpunkt in deiner Konfiguration stellt das DNS-Cache-Verhalten von MS dar. Die Implementation in Windows
ist disbezüglich schlichtwegs erbärmlich. Bei uns ist dieses Problem aus einem Grund nie aufgetreten: die Verbindung zwischen
den Windows-Systemen erfolgt IP-basierend. Beide Netze arbeiten mit unterschiedlichen internen Adressbereichen
(z.B. 192.168.1.0/24 und 192.168.2.0/24). Als Folge dessen kann via VPN über die Netgearboxen ein transparenter Zugriff
erfolgen. Die ganze DynDNS-Geschichte wird so durch die Netgear-Geräte problemlos gelöst und das mühsame DNS-Cache-
Verhalten von Windows kommt dadurch nicht zum tragen.
Du bist meiner Ansicht nach auf dem richtigen Weg: Router als VPN-Endpunkte und dadurch transparenter Zugriff (Routing)
für die Server.
Eine kleine Anmerkung am Rande: unsere Netgearboxen klemmen ca. alle 4 Wochen mal und müssen neu gestartet werden.
Ansonsten funktioniert der oben beschriebene Betrieb bei uns seit Anfangs 2004.
Gruss, Roger.
