DDNS: Im eigenen LAN "falsch" aufgelöst

Krawumpel · 09. Jul 2014

Hallo zusammen,

ich wollte heute mal meine CloudStation einrichten was soweit auch geklappt hat.
Um die DiskStation (eine DS214) von außen erreichbar zu machen, habe ich mich bei einem DDNS Dienst registriert. Auch das klappt problemlos.

Allerdings tauch bei mir jetzt folgendes Problem auf und ich weiß nicht, wie ich das umgehen / lösen kann:

Befinde ich mich außerhalb meines eigenen LAN's (z.B. mit dem iPhone im LTE Netz) klappt die Synchronisierung mit der CloudStation ("Nur WLAN-Sync" ist deaktiviert). Befindet sich das iPhone dann in meinem heimischen Netz klappt die Synchronisierung nicht mehr und DS Cloud versucht permanent, eine Verbindung herzustellen.

Ich habe auf meinem Mac mal ein Traceroute laufen lassen und dabei gesehen, dass die DDSN Adresse mit der IP aufgelöst wird, die mein Router von meinem Provider (Kabel Deutschland) zugewiesen bekommen hat. Das ist ja auch korrekt so. Innerhalb meines eigenen LAN's scheint dies jedoch zu dem Problem zu führen, dass DS Cloud (auch der CloudStation Client für OS X) keine Verbindung herstellen kann.

Hat jemand eine Idee, was ich da machen kann? Ich möchte ungern ständig die Serverdaten im DS Cloud client von IP (im LAN) und DDNS Adresse (außerhalb) ändern müssen.

Vielen Dank schon einmal im Voraus.

Alex

Fusion · 09. Jul 2014

Was hast du denn für einen Router?

Krawumpel · 09. Jul 2014

Ich habe einen Belkin N750 DB und die Portweiterleitung (6690) ist auch eingerichtet (Zugriff aus dem WWW klappt ja auch).

Fusion · 09. Jul 2014

Es geht mir auch eher darum, ob der Router einen Loopback korrekt erkennt, wenn er merkt, dass die angeforderte Zieladresse im eigenen LAN liegt.

Edit: Feature nennt sich NAT Loopback und wird mit Stock-Firmware meines Wissens nicht unterstützt. Eventuell hilft hier DD-WRT oder OpenWRT.

Krawumpel · 09. Jul 2014

Mir dünkt, das bekommt er nicht gebacken

Fusion · 09. Jul 2014

Wie gesagt, evtl. sind 3rd-party firmwares eine Lösung. Habe ich mir aber nicht angesehen jetzt.

Als Workaround könnte noch gehen, dass du von extern via VPN in dein Netz verbindest und dann in den Apps nur die lokalen Adressen verwendest.
Mit OpenVPN geht das zumindest vom Android aus relativ gut.

Krawumpel · 09. Jul 2014

Ich hab mal ein bisschen bzgl. des Routers gegoogelt... der beherrscht tatsächlich kein Loopback.

Das wäre in der Tat ein Workaround (der mir auch schon in den Sinn kam). Allerdings einer, der für mich in Frage käme.

ottosykora · 09. Jul 2014

Problem mit dem Loopback habe ich jetzt auch, noch keine brauchbare Lösung in Sicht auch wenn mein Router es grundsätzlich unterstützt.

Ein kleiner Problem besteht auch mit einem SSL Zertifikat für https.
Dieser wurde zum Bsp auf die DDNS Adresse erstellt.
Versucht man nun die gleiche Verbindung aus dem lokalen Netz, dann kann man es nicht mit dem ddns machen, muss die lokale IP eingeben. Nur dafür hat man nun kein SSL Zertifikat und damit wird die Verbindung unmöglich. Klar lokal kann man auch http statt https machen, aber dann darf man nicht alle http Verbindungsversuche automatisch zu den https Ports leiten (wie es üblich ist).
Also wenn man mit dem VPN zugreift und dann 'lokal' arbeitet, muss man wohl darauf achten dass entweder http möglich ist oder die Zertifikate gleich auf die lokale iP ausstellen.

Fusion · 10. Jul 2014

Oder du erstellst für die lokalen Zugriffe Ausnahmegenehmigungen. Die Verbindung bleibt ja trotzdem verschlüsselt, auch wenn die Common Name Prüfung in dem Fall fehlschlägt.
Zudem kann man ja http auch lassen solange Port 5000 nicht auf die DS weitergeleitet werden ist es von außen ja nicht erreichbar.
Für den Web-Server kann man dann auch ein rewrite in htaccess auf https veranlassen, wenn man Port 80 überhaupt offen lassen will.
Bei dem ganzen Thema wollte ich mich aber selbst auch nochmal einlesen, ob ich dem Web-Server nicht auch mehrere Zertifikate unterschieben kann für verschiedene urls.

Mit meinem Asus RT-AC68U hatte ich zwischenzeitlich auch mal Probleme (bis Firmware gefixt wurde) mit dem NAT-Loopback. Das lag damals an CTF, einer Hardware-Beschleunigung für den Paket-Durchsatz von extern nach intern. Viele Router schaffen mit Beschleunigung in die Richtung GBit/s während sie auf ihre CPU alleine gestellt nur in der Gegend 100-200 MBit/s schaffen. Für die meisten Internetzugänge reicht das aber immer noch aus heutzutage. Zumindest testweise lohnt also mal solch ein Feature auszuschalten und evtl. nach einem Update zu schauen, wenn es danach besser läuft. Asus hatte das Problem gefixt und Loopback läuft inzwischen auch mit Beschleunigung.

ottosykora · 10. Jul 2014

Ja hast Recht, ich bin an das Problem mit den Schlüsseln gekommen als ich mich lokal , also mit der IP, mit Webdav (netuse) verbinden wollte. Das ging dann nicht, die Schlüssel waren für die DDNS url und wurden also nicht anerkannt.

Was jedoch geht: statt der IP schreibe ich 'diskstation' in die url und damit geht es wieder.

Mit der NAT-Loopback Problematik finde ich keine echte Lösung bis jetzt. Lange ging alles normal, also ddns url auch von innen aus. Dann plötzlich nicht. Habe dann bei dem Provider Router unter Diagnostic Tools die Möglichkeit gefunden von dem Router aus Ping und Tracert zu machen. Habe es einigemale gemacht und danach ging alles wieder normal.
Nach einigen Wochen ging es wieder nicht. Seit dem bringe ich es nicht fertig, was auch immer ich einstelle, mit der ddns url kann ich von innen nicht an die DS. Aufgelöst wird alles richtig, also DNS macht es korrekt. Aber auch direkte Anfrage an die externe IP endent nur im Timeout.

Darum weiss ich dass mein Router es grundsätzlich kann, aber irgendetwas hindert ihn daran. Würde mal gerne was von Experten hören , was soll man weiter testen oder suchen damit es wieder geht?

Fusion · 10. Jul 2014

@ottosykora - welchen Provider Router und Netzzugang kommt denn bei dir zum Einsatz?

skahde · 10. Jul 2014

ottosykora schrieb:
Darum weiss ich dass mein Router es grundsätzlich kann, aber irgendetwas hindert ihn daran. Würde mal gerne was von Experten hören , was soll man weiter testen oder suchen damit es wieder geht?

Grundsätzlich sollte die Namensauflösung so konfiguriert sein, dass bei Eingabe des fqdn aus dem LAN ein nslookup die interne Adresse des Servers ausspuckt und aus dem Internet die NAT-Adresse. Dazu braucht es kein NAT-Loopback sondern eine korrekte Konfiguration der Host- und Domainnamen auf den Komponenten. Erst wenn es hier klemmt, fragt der Router im Internet nach der Namensauflösung für den internen Server und bekommt vom DDNS die NAT-Adresse zurückgeliefert.

jahlives · 10. Jul 2014

@ottosykora
setz einen lokalen DNS Server auf, löse darauf deinen dyndns Namen auf die LAN IP auf und schon kannst du via dyndns Namen auch https machen. Oder trag die Auflöung in die Hostsdatei deines Clients ein.

ottosykora · 10. Jul 2014

Fusion schrieb:
@ottosykora - welchen Provider Router und Netzzugang kommt denn bei dir zum Einsatz?

Pirelli Centro Grande der Swisscom

Ging früher gut, seit einigen Wochen nicht mehr. Der Provider Help kann nicht helfen, Zugang zu Internet geht, also haben die ihre Pflicht getan.

ottosykora · 10. Jul 2014

skahde schrieb:
Grundsätzlich sollte die Namensauflösung so konfiguriert sein, dass bei Eingabe des fqdn aus dem LAN ein nslookup die interne Adresse des Servers ausspuckt und aus dem Internet die NAT-Adresse. Dazu braucht es kein NAT-Loopback sondern eine korrekte Konfiguration der Host- und Domainnamen auf den Komponenten. Erst wenn es hier klemmt, fragt der Router im Internet nach der Namensauflösung für den internen Server und bekommt vom DDNS die NAT-Adresse zurückgeliefert.

Ja da ist was dran!
Es gab schon einige male Probleme damit, dann habe ich jeweils aus der Admin Oberfläche des Routers die ddns url angepingt und schon ging es wieder. Also so was wie wenn ich damit eine Hosts Datei oder so was erstellt habe. Kein Ahnung aber was im Detail passiert ist in dem Router. Der hat einfach in den diversen Tabs eines 'Diagnostic' und von da kann man etwas pingen oder ein tracert machen. Mehr sehe ich nicht.

Habe ich dann jeweils von dem PC gepingt, hat es schön nach der externen IP aufgelöst und eben die externe IP angepingt. Und das ging ganz normal.
Die Auflösung geht immer noch, aber die Antwort von der externen IP kommt nicht.

Wo soll ich die Host und Domain Namen auf den Komponenten konfigurieren? Ich meine habe es vorher nicht gemacht, alles ging prima, geht nun seit einigen Wochen einfach nicht mehr. Ich bin mir jedoch nicht bewusst etwas geändert zu haben.
Auf Linux war das jeweils eine Text Datei, aber in Windows habe ich bis jetzt noch nie ein Hosts Datei erstellt oder editiert oder so was.

ottosykora · 10. Jul 2014

jahlives schrieb:
@ottosykora
setz einen lokalen DNS Server auf, löse darauf deinen dyndns Namen auf die LAN IP auf und schon kannst du via dyndns Namen auch https machen. Oder trag die Auflöung in die Hostsdatei deines Clients ein.

Ja DNS Server, gut habe es schon mal angeschaut, den auf DS installiert, bin mit der Konfiguration jedoch noch etwas überfordert momentan ;-)

Die Host Datei des Clients, na ja, wenn ich wüsste wo ich diese in einem normalen w7 Rechner suchen müsste und warum ging es vorher und nun nicht mehr?

ottosykora · 10. Jul 2014

Gut, also in dem ersten w7 habe ich die hosts gefunden und den Eintrag gemacht, ja klar, das geht zwar nun alles normal.

Bin noch nicht ganz sicher was passiert wenn ich mit so einem Laptop dann woanders bin und dann soll der eigentlich einen richtigen DNS fragen nach der IP.
Geht das dann oder bleibt der Client dann auf die Suche nach der lokalen IP fixiert? Oder fragt er dann gleich den DNS wenn er lokal nichts findet?

Bei den mobilen habe ich eigentlich so weit gar keine Ahnung ob man es dort auch einstellen kann oder nicht.

jahlives · 11. Jul 2014

http://de.wikipedia.org/wiki/Hosts-Datei#Pfade_unter_verschiedenen_Betriebssystemen
drum ist die Hosts Datei keine sehr flexible Lösung. Sobald du ausserhalb des LANs bist, hast du ein Problem wenn du die Hosts nicht wieder anpasst.
Ich mache es immer via DNS Server im LAN und der wird per dhcp als DNS an die Clients geliefert

Fusion · 11. Jul 2014

@jahlives - da zeigt sich mal wieder die Erfahrung. Lokaler DNS scheint echt die bessere Lösung, dann ist auch egal, ob das Loopback funktioniert (was bei mir der Fall ist mit AC68U) und ich könnte mir evtl. die Hosts auch sparen mit denen ich per Kurznamen auf die anderen Devices im LAN zugreife (z.B. Router: ssh user@asus oder die Diskstation ssh user@syno). Und auch VPN-Clients bei denen das Loopback nicht funzt (vermutlich weil ich trotz OpenVPN noch ne weitere Route hinzufügen müßte. Ist nur immer so trocken zum Einlesen) wären dann vielleicht gegessen.
Muß ich mir die Tage mal reinziehen. Danke für den Einwurf.