DynDNS mit fremdem und eigenem Router (Konfig. am zweiten)

Das ist technisch nicht möglich ! Der DynDNS Prozess MUSS immer auf dem Router sein der auch physisch die DSL Adresse für den remoten Zugang hostet die letztlich von außen erreicht werden muss um auch in dein Netz hinter diesem Router zu gelangen. Alles andere ist Unsinn, auch wenn es ggf. durch 3 Hintertüren funktionieren sollte.
Du kannst also niemals den DynDNS Prozess auf deinem Router laufen lassen, denn der müsste dann ja zwangsläufig eine falsche IP Adresse bzw. eine Adresse die er selber ja gar nicht hat an DynDNS reporten.
Die DSL IP Adresse der Vermieterrouters ist also das zentrale Gateway um von außen in euer Netz zu kommen. Dort musst du auch ggf. IP Portforwarding eintragen die dir eingehende Sessions von außen dann an die richtigen internen IP Adressen (wie z.B. dann dein Router) forwardet.
So mit Bordmitteln wie du es vorhast und einem Consumer DSL Anschluss lässt sich eine vollkommende Trennung technisch nicht realisieren !
Eine zentrale Wohnungsverwaltung würde bzw. müsste sowas auch anders regeln...

Oh? Das heißt, mein Netz hier funktioniert gar nicht ... schade eigentlich, ist mir in den letzten drei Jahren gar nicht aufgefallen ;) Noch dazu ist diese "Hintertür" erstaunlich gut dokumentiert ...

Also, ich sehe das immer noch so, dass es geht, und zwar mit den normalen Mitteln.

-nik

Du machst einen Denkfehler, weil du scheinbarden DynDNS Prozess nicht kennst.... Natürlich funktioniert das, denn dein DynDNS Client der nicht auf dem Router selber sitzt sendet ein Packet ab an den DynDNS Server. Die letzte Instanz aber die das NAT macht, bestimmt welche IP Adresse bei DynDNS gemeldet wird, den es wird genau dieses Packet mit einem Skript am DynDNS Server ausgelesen.
Das heisst dieser letzte Instanz Router bestimmt letztlich die DynDNS Adresse zum DynDNS Hostnamen.
In dem o.a. Szenario spiegelt das aber niemals die tatsächliche Netzwerkstruktur wider und du musst erhebliche Verrenkungen machen mit Port Forwarding etc.

Grotti74 will aber eine vollkommene Entkopplung dieser Prozesse mit seinen 2 Routern, und das ist so niemals möglich ohne diesen Ursprungsrouter auch anzufassen, der ja nun mal nicht seiner ist. Das würde nur klappen wenn dieser Router kein NAT macht, er also von seinem Provider
a.) eine feste IP und ...
b.) ein fleines öffentliches Subnetz bekommen würde.
Erst dann ist eine Lösung problemlos möglich, da dann der erste Route nur IP routen müsste und er alle VPN Funktionen, Port Forwarding etc. auf seinen Router problemlos separieren könnte.
Wenn du für diese Funktion eine Lösung hast in einem klassischen Consumer DSL Umfeld wo du per PPPoE dynamisch wechselnde IP Adressen bekommst und nur eine Einzige, wäre es ja toll die Lösung mal hier zu posten. Nicht nur mich würde die sicher interessieren....

Nein, das ist schlicht und ergreifend falsch. Der DynDNS-Client sendet im Klartext die IP-Adresse mit, die er senden möchte. Das steht sogar in der Dokumentation, grabe ich nachher mal raus ...

So, hier mal die Knowledge Base von ddclient unter Linux. Im Abschnitt "IP Detection" steht recht deutlich, dass ddclient wohl IMMER auf irgendeine Art die IP herausfindet und mitsendet. Da ddclient sich an das von DynDNS benutzte Protokoll hält, dürfte das also Standard sein.

http://www.dyndns.com/support/kb/using_ddclient_with_dyndns_services.ht ...

-nik

Schön und gut. Wenn du aber nun eine Maschine hinter dem Router hast im lokalen Netz der nun seine IP Adresse detektiert und sie dann mit seinem DynDNS Client and den Dienst sendet dann hat er ja eine Adresse für sich selber detektiert die aus dem lokalen Netz kommt. Also meist eine RFC 1918 Adresse (Private IP). Die wird DynDNS niemals in einen öffentlichen DNS Server übernehmen.
Wäre ja auch kompletter Blödsinn denn RFC 1918 Adressen werden im Internet nicht geroutet wie du ja auch weisst.
Deine Theorie hat also auch einen Haken und kann so nicht stimmen, denn der Router durch den dieses DynDNS Packet vom Client läuft wird ja nicht ins Datenfeld dieses Packetes sehen und dann sagen...Ooopsa da kommt ein DynDNS Packet, da will ich mal schnell den Inhalt ändern und die vom Client detektierte IP Adresse im datenfeld schnell mit meiner aktuellen NAT IP Adresse überschreiben. Router arbeiten nur auf OSI Layer 3 also ist das Unsinn anzunehmen.
Fragt sich nun wieder...was ist denn nun richtig ??

Ich zitiere denn mal die Knowledge Base:

"ddclient supports detecting the public IP address either directly from a hardware interface, from a status page provided by a NAT router, * or via our CheckIP service *. Due to this flexibility, ddclient can be used in almost any possible network configuration."

Bei dem markierten CheckIP Service kommt IMMER die so genannte "öffentliche" Adresse raus.

Genau das ist aber das Verfahren was oben beschrieben ist mit dem Auslesen der Quell IP Adresse über ein Webserverscript. Das rennt zwar verdeckt bei DynDNS intern wird aber so gemacht...und genau das hattest du ja angezweifelt... ?!
Damit sollte dieser DynDNS Ausflug erstmal beendet sein und Grotti74 gehört wieder der Thread, der sich wohl aus lauter Angst gar nicht mehr zu Wort gemeldet hat um uns mitzuteilen wie es nun weitergeht mit seinem Thread....

Dann war es wohl ein Missverständnis, denn ich habe deine Aussage so verstanden, dass der Client seine "öffentliceh" IP NIEMALS irgendwo anders herbekommen kann als von seinem eigenen Interface ... aber naja, irgendwie wird das hier unübersichtlich, nehmen wir DDNS einfach wie es ist

Also wie du schon sagtest, back to the topic.