DYNDNS wird nicht aktualisiert
Ein kleines Problem macht mächtig Ärger
Hallo liebes Forum,
lange Zeit war alles ruhig, nun hab ich mal wieder ein kleines aber sehr nerviges Problem. Wir machen mittlerweile alle 2 Tage ein Backup unseres Systems, dieses Backup sende ich derzeit über ein immer bestehende Verbindung zu einem FTP Server mittels DYNDNS Account auf einen entfernten Server. Das funktioniert weitaus besser als ich zuvor angenommen hatte. Mein Problem ist allerdings folgendes:
Sender:
Windows Server 2003 SP2 Standart
DSL 6000 mit fester IP
Filezilla 3.3.4
Empfänger
Windows Server 2003 SP2 Standart
DSL 2000 mit DYNDNS Acc.
IIS 6.0 mit eingerichtetem FTP Server
Zum Problem. Der Empfänger hat eine softwareseitige DYNDNS-Aktualisierung. Funktioniert 1. Sahne. Ich habe gerademal eine Ausfallzeit von 5min bis die neue IP am DYNDNS hinterlegt ist. Jetzt ist es jedoch so, dass die Übermittlung ca 14 Std. in Anspruch nimmt, auch aufgrund der niedigen Datenrate die ich angesetzt habe um unseren Firmenanschluss nicht zusehr zu verlangsamen. Jetzt ist es vorgekommen das die Übermittlung noch gelaufen hat als die DYNDNS durch den 24Std. IP-Wechsel, am Empfänger, unterbrochen wurde. Das hatte ich auch eingeplant. Deshalb habe ich in Filezille eine Reconnectzeit von 600 Sekunden gestellt und 50 Wiederholungen angegeben um auch etwas längere Zeiten überbrücken zu können. Wenn ich allerdings an meinen Sender-Server gehe und die ftp://dyndns.adresse.com eingebe ruft er nicht wie erwartet, die FTP Seite auf sondern versucht unter der längst abgelaufenen IP den Server aufzurufen. Selbst wenn ich über "cmd" die DNS anpinge, nimmt er immerwieder die alte IP Adresse. Also er aktualisiert diese gar nicht. Gehe ich an einen Client und pinge von dort aus die DNS an, kommt auch eine Antwort da dieser die richtige, aktuelle IP anpingt. Ich kann am Sender machen was ich will erst wenn ich einen Neustart mache, aktualisiert er den DYNDNS und hinterlegt die aktuelle IP. Bis nach 24 Std. am Empfänger wieder die IP gewechselt wird.
Hat vieleicht irgendwer eine Ahnung wie ich dieses Problem beheben kann. Mir fehlt da jeglicher Ansatz.
Vielen Dank im vorraus
Simon
Hallo liebes Forum,
lange Zeit war alles ruhig, nun hab ich mal wieder ein kleines aber sehr nerviges Problem. Wir machen mittlerweile alle 2 Tage ein Backup unseres Systems, dieses Backup sende ich derzeit über ein immer bestehende Verbindung zu einem FTP Server mittels DYNDNS Account auf einen entfernten Server. Das funktioniert weitaus besser als ich zuvor angenommen hatte. Mein Problem ist allerdings folgendes:
Sender:
Windows Server 2003 SP2 Standart
DSL 6000 mit fester IP
Filezilla 3.3.4
Empfänger
Windows Server 2003 SP2 Standart
DSL 2000 mit DYNDNS Acc.
IIS 6.0 mit eingerichtetem FTP Server
Zum Problem. Der Empfänger hat eine softwareseitige DYNDNS-Aktualisierung. Funktioniert 1. Sahne. Ich habe gerademal eine Ausfallzeit von 5min bis die neue IP am DYNDNS hinterlegt ist. Jetzt ist es jedoch so, dass die Übermittlung ca 14 Std. in Anspruch nimmt, auch aufgrund der niedigen Datenrate die ich angesetzt habe um unseren Firmenanschluss nicht zusehr zu verlangsamen. Jetzt ist es vorgekommen das die Übermittlung noch gelaufen hat als die DYNDNS durch den 24Std. IP-Wechsel, am Empfänger, unterbrochen wurde. Das hatte ich auch eingeplant. Deshalb habe ich in Filezille eine Reconnectzeit von 600 Sekunden gestellt und 50 Wiederholungen angegeben um auch etwas längere Zeiten überbrücken zu können. Wenn ich allerdings an meinen Sender-Server gehe und die ftp://dyndns.adresse.com eingebe ruft er nicht wie erwartet, die FTP Seite auf sondern versucht unter der längst abgelaufenen IP den Server aufzurufen. Selbst wenn ich über "cmd" die DNS anpinge, nimmt er immerwieder die alte IP Adresse. Also er aktualisiert diese gar nicht. Gehe ich an einen Client und pinge von dort aus die DNS an, kommt auch eine Antwort da dieser die richtige, aktuelle IP anpingt. Ich kann am Sender machen was ich will erst wenn ich einen Neustart mache, aktualisiert er den DYNDNS und hinterlegt die aktuelle IP. Bis nach 24 Std. am Empfänger wieder die IP gewechselt wird.
Hat vieleicht irgendwer eine Ahnung wie ich dieses Problem beheben kann. Mir fehlt da jeglicher Ansatz.
Vielen Dank im vorraus
Simon
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 132998
Url: https://administrator.de/forum/dyndns-wird-nicht-aktualisiert-132998.html
Ausgedruckt am: 23.12.2024 um 07:12 Uhr
16 Kommentare
Neuester Kommentar
Hallo Simon,
dein Filezilla hat immer noch die ursprungliche IP im Speicher. Das ist ja auch bei dir erkennbar da ein anderer Client problemlos auf die dann neue IP pingt. Starte mal ein CMD Fenster und mache dort ein "ping name.dny.dns -t" . Du wirst feststellen, irgendwann gibt es keine Antworten mehr. Selbst das beenden des CMD Fensters hilft nicht direkt weiter, da die IP im Cache liegt. Entweder die zeit abwarten bis der cache abgelaufen ist , oder ipconfig /flushdns usw. das betrifft aber jetzt nur das CMD beispiel.
Ob du FileZilla sagen kannst, in einer laufenden Upload Sitzung auf einer neuen IP weiter zu machen, das kann ich dir nicht sagen.
Peter
[Nachtrag]
Deine Überschrift ist falsch. DynDns wird schon aktualisiert, dein laufender Client nicht.
[Nachtrag]
dein Filezilla hat immer noch die ursprungliche IP im Speicher. Das ist ja auch bei dir erkennbar da ein anderer Client problemlos auf die dann neue IP pingt. Starte mal ein CMD Fenster und mache dort ein "ping name.dny.dns -t" . Du wirst feststellen, irgendwann gibt es keine Antworten mehr. Selbst das beenden des CMD Fensters hilft nicht direkt weiter, da die IP im Cache liegt. Entweder die zeit abwarten bis der cache abgelaufen ist , oder ipconfig /flushdns usw. das betrifft aber jetzt nur das CMD beispiel.
Ob du FileZilla sagen kannst, in einer laufenden Upload Sitzung auf einer neuen IP weiter zu machen, das kann ich dir nicht sagen.
Peter
[Nachtrag]
Deine Überschrift ist falsch. DynDns wird schon aktualisiert, dein laufender Client nicht.
[Nachtrag]
Sind die Server direkt im Internet exponiert ?? (hoffentlich nicht) oder ist ein Router davor ?
Wenn ein Router davor ist gehört der DynDNS Client niemals auf ein Endgerät hinder der NAT Firewall des Routers sondern immer auf den Router selber, da hier der NAT Prozess sitzt und nicht auf den Endgeräten. Dann kann es zu solchen Phänomenen kommen mit DynDNS und du solltest den Client dann auf dem Router in desse Setup aktivieren...und auf den Servern dann natürlich deaktivieren.
Das obige gilt natürlich nur wenn die Anbindung mit Routern gemacht ist und nicht direkt.
Aber wer stellt heutzutage auch schon einen Server mit MS Betriebsystem direkt ins Netz...eigentlich keiner dem sein Server lieb ist !
Wenn ein Router davor ist gehört der DynDNS Client niemals auf ein Endgerät hinder der NAT Firewall des Routers sondern immer auf den Router selber, da hier der NAT Prozess sitzt und nicht auf den Endgeräten. Dann kann es zu solchen Phänomenen kommen mit DynDNS und du solltest den Client dann auf dem Router in desse Setup aktivieren...und auf den Servern dann natürlich deaktivieren.
Das obige gilt natürlich nur wenn die Anbindung mit Routern gemacht ist und nicht direkt.
Aber wer stellt heutzutage auch schon einen Server mit MS Betriebsystem direkt ins Netz...eigentlich keiner dem sein Server lieb ist !
Hi aqui,
ich habe allerdings bei den meisten preiswert Routern (AVM, Netgear, D-Link, Linksys etc) die efahrung machen müssen, das bei Fester IP mit xDSL wie beispielsweise der Business DSL der T-COM, Dyndns dann nicht mehr vom Router aus aktualisiert wird. Da die IP sich ja nach einer zwangstrennung NICHT ändert, haben die Router keine veranlassung die IP bei Dyndns zu aktualisieren. Ergebniss: nach 4 Wochen fliegt der Eintrag aus der Dyndns datenbank. Da ist dann ein Dyndns Updater auf einen Client/Server die bessere wahl. Auch bei einigen Stadtwerken hier wo mittlerweile ein ethernet mit DSL bandbreiten angeboten wird, haben die Router (die ja dann einfache ethernet Router sind) kein veranlassung die IP zu aktualiseren, da die Stadtwerke hier einfach zu 99% die gleiche IP verwenden. (Bei einem Kunden wurde für 19 Monaten die IP nicht geändert, obwohl 122 kurzzeitige trennungen vorhanden sind. Erst nachdem der Ethernetanschluß für 10 Minuten getrennt war, gab es eine neue IP. Und nein, diese Stadwerke Verkaufen keine Feste IP).
Ansonsten völlig klar, der Dyndns muss auf den Router
Aber zum obigen Thema, Simon hatte ja geschrieben das die IP an einem anderen Client nach der zwangstrennung schon die neue, richtige war. Damit hat die Ip Aktualisierung bei Dyndns ja einwandfrei funktioniert.
Peter
@aqui: Es gibt immer noch zu viele die ihre Rechner ungeschützt ins Internet stellen und es werden nicht weniger.
ich habe allerdings bei den meisten preiswert Routern (AVM, Netgear, D-Link, Linksys etc) die efahrung machen müssen, das bei Fester IP mit xDSL wie beispielsweise der Business DSL der T-COM, Dyndns dann nicht mehr vom Router aus aktualisiert wird. Da die IP sich ja nach einer zwangstrennung NICHT ändert, haben die Router keine veranlassung die IP bei Dyndns zu aktualisieren. Ergebniss: nach 4 Wochen fliegt der Eintrag aus der Dyndns datenbank. Da ist dann ein Dyndns Updater auf einen Client/Server die bessere wahl. Auch bei einigen Stadtwerken hier wo mittlerweile ein ethernet mit DSL bandbreiten angeboten wird, haben die Router (die ja dann einfache ethernet Router sind) kein veranlassung die IP zu aktualiseren, da die Stadtwerke hier einfach zu 99% die gleiche IP verwenden. (Bei einem Kunden wurde für 19 Monaten die IP nicht geändert, obwohl 122 kurzzeitige trennungen vorhanden sind. Erst nachdem der Ethernetanschluß für 10 Minuten getrennt war, gab es eine neue IP. Und nein, diese Stadwerke Verkaufen keine Feste IP).
Ansonsten völlig klar, der Dyndns muss auf den Router
Aber zum obigen Thema, Simon hatte ja geschrieben das die IP an einem anderen Client nach der zwangstrennung schon die neue, richtige war. Damit hat die Ip Aktualisierung bei Dyndns ja einwandfrei funktioniert.
Peter
@aqui: Es gibt immer noch zu viele die ihre Rechner ungeschützt ins Internet stellen und es werden nicht weniger.
Hallochen,
irgendwie ist da total der Wurm drin oder? Zumindest im Verständnis.
Du sagst du hast 1 Kiste hinter ner festen IP und 1 Kiste hinter ner dyndns Adresse. Aber auch sagst du, das der Anschluss hinter dem die dyndns Kiste steht auch eine feste IP hat??
ich versteh das auch so wie aqui, er hat vollkommen Recht, das macht dyndns mehr als überflüssig.
Und dein Argument mit den IPs merken kann ich auch so gar nicht nachvollziehen, wenn du Backups fährst, passiert das doch automatisch oder? Da wird die Gegenüber IP einmal eingetragen und gut ist.
Und sollten sie nicht automatisch laufen und du keine Lust hast die IP Adresse immer aus ner Textdatei zu kopieren, dann kauf dir doch ne Domain für nen Euro im Monat und mach eine Weiterleitung.
Gruß
dante!
irgendwie ist da total der Wurm drin oder? Zumindest im Verständnis.
Du sagst du hast 1 Kiste hinter ner festen IP und 1 Kiste hinter ner dyndns Adresse. Aber auch sagst du, das der Anschluss hinter dem die dyndns Kiste steht auch eine feste IP hat??
ich versteh das auch so wie aqui, er hat vollkommen Recht, das macht dyndns mehr als überflüssig.
Und dein Argument mit den IPs merken kann ich auch so gar nicht nachvollziehen, wenn du Backups fährst, passiert das doch automatisch oder? Da wird die Gegenüber IP einmal eingetragen und gut ist.
Und sollten sie nicht automatisch laufen und du keine Lust hast die IP Adresse immer aus ner Textdatei zu kopieren, dann kauf dir doch ne Domain für nen Euro im Monat und mach eine Weiterleitung.
Gruß
dante!
Hallo Simon,
da es sich ja um eine Aussenstelle von euch handelt, stellt sich doch die Frage warum du kein VPN machst? Damit kann sich dann die WAN IP der Zweigstelle ändern soviel die will, solange dein VPN innerhalb deiner timeout für dein Filezilla wieder verbunden ist, hast du doch keine Probleme mehr. Du würdest ja dann mit internen IP's arbeiten, und die ändern sich ja eigentlich nicht, sondern sind wieder nachdem der VPN steht wieder verfügbar. Und, du musst den Telnet Port gar nicht offen und auf den Server weitergeleitet haben.
Vielleicht können deine noch nicht genannten Router (hast du ja, oder?) schon VPN.
Alles andere ist doch murks.
Peter
da es sich ja um eine Aussenstelle von euch handelt, stellt sich doch die Frage warum du kein VPN machst? Damit kann sich dann die WAN IP der Zweigstelle ändern soviel die will, solange dein VPN innerhalb deiner timeout für dein Filezilla wieder verbunden ist, hast du doch keine Probleme mehr. Du würdest ja dann mit internen IP's arbeiten, und die ändern sich ja eigentlich nicht, sondern sind wieder nachdem der VPN steht wieder verfügbar. Und, du musst den Telnet Port gar nicht offen und auf den Server weitergeleitet haben.
Vielleicht können deine noch nicht genannten Router (hast du ja, oder?) schon VPN.
Alles andere ist doch murks.
Peter
@JollyJumper83
...und immer noch hast du uns nicht mitgeteilt ob du so leichtsinnig bist und die Server direkt (also ohne NAT Router) im Internet betreibst oder eben mit NAT Router, was man nur hoffen kann.
Wenn dem so ist gilt immer noch der Apell den DynDNS Client auf dem Router zu implementieren wo er auch hingehört und eben NICHT als Client auf die Server !
Wir nehmen mal nicht an das du so leichtsinnig und unbedarft bist einen MS Server direkt im Internet zu betreiben wie nur Sicherheits Neandertaler es machen würden... Wenn das Lucky Luke wüsste....
Ansonsten gilt der Kommentar in Bezug auf VPN von Pjordorf. Kundige ITler die wissen was sie tun lösen das mit einem VPN. Wie das geht kannst du ach bei MS nachlesen:
http://www.microsoft.com/downloads/details.aspx?familyid=a93e566c-92c7- ...
...und immer noch hast du uns nicht mitgeteilt ob du so leichtsinnig bist und die Server direkt (also ohne NAT Router) im Internet betreibst oder eben mit NAT Router, was man nur hoffen kann.
Wenn dem so ist gilt immer noch der Apell den DynDNS Client auf dem Router zu implementieren wo er auch hingehört und eben NICHT als Client auf die Server !
Wir nehmen mal nicht an das du so leichtsinnig und unbedarft bist einen MS Server direkt im Internet zu betreiben wie nur Sicherheits Neandertaler es machen würden... Wenn das Lucky Luke wüsste....
Ansonsten gilt der Kommentar in Bezug auf VPN von Pjordorf. Kundige ITler die wissen was sie tun lösen das mit einem VPN. Wie das geht kannst du ach bei MS nachlesen:
http://www.microsoft.com/downloads/details.aspx?familyid=a93e566c-92c7- ...
Der Service auf dem Server kann die IP nicht zum DynDNS schicken bzw. wenn er das machen würde würde er ja eine falsche IP Adresse schicken, denn er schickt eine RFC 1918 IP Adresse also eine aus einem privaten_Netz da du ja wie du selber sagst hinter einem NAT Router sitzt und du lokal vermutlich diese IP Adressen nutzt.
Deshalb sollte dir auch spätestens jetzt die Sinnlosigkeit bzw. Fehlerhaftigkeit dieses Verfahrens klar sein, da sich diese IP nie ändert (denn bei einem Server ist sie logischerweise statisch) und der DynDNS Client somit nie oder sehr selten eine IP an den Dienst schickt.
Deshalb gehört der Client auf den Router wo diese IPs auch nach jeder Zwangstrennung korrekt reportet werden.
Wenn das nicht geschieht dann ist das ein Frmware Bug der in der Regel aber sofort mit einem korrekten und aktuellen FW Update behoben ist. DynDNS hat letztens seine Server IPs umgestellt, deshalb ist so ein Update schon wichtig, das sollte dann auch deine Problem sofort lösen.
Zum Thema Sicherheit des Clients ist es sicher nicht dramatisch sollte dir aber zumindestens Bauchschmerzen bereiten. Der Client hält eine Verbindung vom Server zum DynDNS Dienst. Damit ist in der NAT Translation Tabelle des Routers permanent ein Eintrag vorhanden der mit diesem Zielport direkt auf den Server zeigt. Jemand mit Fachkenntnissen kann sich zumindest mit diesem Port Zugang zum Server verschaffen. Im medizinischen Bereich ist sowas aus Datenschutzgründen ein absolutes no go was ein gelernter Systemadministrator ja auch weiss, denn sonst stehen eines Tages schnell mal die Dalton Brüder am Server !!!
Generell ist sowas eine Frickelei und unprofessionell. Kundige ITler investieren 10 Euro mehr in einen VPN Router wie z.B. Draytek und andere die selber VPNs terminieren und so einen sicheren Zugang zu einem Zielnetz gewähren ohne Löcher in die NAT FWs bohren zu müssen oder Frickleien mit DynDNS Clients im internen Netz wie in deinem o.a. Konzept !
Deshalb sollte dir auch spätestens jetzt die Sinnlosigkeit bzw. Fehlerhaftigkeit dieses Verfahrens klar sein, da sich diese IP nie ändert (denn bei einem Server ist sie logischerweise statisch) und der DynDNS Client somit nie oder sehr selten eine IP an den Dienst schickt.
Deshalb gehört der Client auf den Router wo diese IPs auch nach jeder Zwangstrennung korrekt reportet werden.
Wenn das nicht geschieht dann ist das ein Frmware Bug der in der Regel aber sofort mit einem korrekten und aktuellen FW Update behoben ist. DynDNS hat letztens seine Server IPs umgestellt, deshalb ist so ein Update schon wichtig, das sollte dann auch deine Problem sofort lösen.
Zum Thema Sicherheit des Clients ist es sicher nicht dramatisch sollte dir aber zumindestens Bauchschmerzen bereiten. Der Client hält eine Verbindung vom Server zum DynDNS Dienst. Damit ist in der NAT Translation Tabelle des Routers permanent ein Eintrag vorhanden der mit diesem Zielport direkt auf den Server zeigt. Jemand mit Fachkenntnissen kann sich zumindest mit diesem Port Zugang zum Server verschaffen. Im medizinischen Bereich ist sowas aus Datenschutzgründen ein absolutes no go was ein gelernter Systemadministrator ja auch weiss, denn sonst stehen eines Tages schnell mal die Dalton Brüder am Server !!!
Generell ist sowas eine Frickelei und unprofessionell. Kundige ITler investieren 10 Euro mehr in einen VPN Router wie z.B. Draytek und andere die selber VPNs terminieren und so einen sicheren Zugang zu einem Zielnetz gewähren ohne Löcher in die NAT FWs bohren zu müssen oder Frickleien mit DynDNS Clients im internen Netz wie in deinem o.a. Konzept !
Hallo Simon,
Aber dir ist schon klar, das dein Konzept einer Datensicherung wo du für das Upload alleine 14 Stunden benötigst nicht gerade klug gewählt ist.
Peter
Ich habe ach heute diese ganze Kiste mit dem FTP übern Jordan geworfen und eine VPN eingerichtet , wobei ich ganz
klar sagen muss es handelt sich um zwei unterschiedliche Domänen.
Und, das stört doch nicht.klar sagen muss es handelt sich um zwei unterschiedliche Domänen.
Die Verbindung steht zwar und ich kann auh die Datei
mittels Netzlaufwerk übertragen, ich bin mir aber nicht sicher wie das wird wenn nach 24 Std. die Verbindung unterbrochen
wird. Dann wird doch bestimmt auch der Upload unterbrochen oder ?
Klar wird der unterbrochen. Aber dein VPN baut sich ja hoffentlich wieder Automatisch auf (VPN über Hardware gelöst?) und dann ist doch die IP für den Upload wieder verfügbar. Da du den Timeout ja schon bei Filezilla hochgesetzt hast sollte das doch dann weiter gehen.mittels Netzlaufwerk übertragen, ich bin mir aber nicht sicher wie das wird wenn nach 24 Std. die Verbindung unterbrochen
wird. Dann wird doch bestimmt auch der Upload unterbrochen oder ?
Aber dir ist schon klar, das dein Konzept einer Datensicherung wo du für das Upload alleine 14 Stunden benötigst nicht gerade klug gewählt ist.
Peter