12
DynDNS mit fremdem und eigenem Router (Konfig. am zweiten)
Router 1: fremdes Gerät, Konfiguration belassen ; Router 2: meiner, soll entsprechend konfiguriert werden
Hi,
also ich hänge am WLAN-_fähigen_ Router meines Vermieters, der wenig Ahnung von Computerei hat. Das Admin-PW habe ich zwar, aber ich möchte aus der Sache ja auch was lernen: nämlich, wie man einen Fremdrouter nutzt, ohne ihn gravierend zu verändern.
Der Router könnte ja in meiner nächsten Wohnung von einer Hausverwaltung sein, die das ganze Haus mit Netz versorgt! Die HV wird dann sicher nicht wollen, dass sich jeder "seinen" Service installiert ; bzw. gerade DynDNS wird dann nur 1x gehen können!
--
Meine ganzen Spielereien (z. B. kabellose Datenübertragung Firmen-Lappi <-> homeoffice PC) möchte ich nach Möglichkeit in meinem WLAN Router (Netgear WGR614 v7) eintragen und den Fremd-Router möglichst in Ruhe lassen und nur Internet von ihm beziehen.
Nur gibt es bei DynDNS ein Problem: DynDNS *WEISS* ja gar nix von irgendwelchen C-Klassen-Adressen! Hinten kommt ja nur 192.168.xx.yy raus...also wie soll DynDNS "wissen", dass ich hier eine echte Internetadresse ansprechen will?
Dennoch möchte ich nicht auf einem fremden Router DynDNS einrichten.
Meine derzeitige Konfiguration:
RJ45-("LAN")-Kabel (Kabel wegen Speed) aus der Vermieterwohnung in "Internet" Port von Router2
RJ45-Kabel aus Desktop-PC-LAN-Anschluss in "LAN1" Port von Router2
Ziel des Ganzen: Mein privates/geschäftliches LAN vom LAN des Vermieters abgrenzen.
Ich habe auch schon über eine DMZ-Lösung nachgedacht.
Vorschläge aller Art willkommen.
Hi,
also ich hänge am WLAN-_fähigen_ Router meines Vermieters, der wenig Ahnung von Computerei hat. Das Admin-PW habe ich zwar, aber ich möchte aus der Sache ja auch was lernen: nämlich, wie man einen Fremdrouter nutzt, ohne ihn gravierend zu verändern.
Der Router könnte ja in meiner nächsten Wohnung von einer Hausverwaltung sein, die das ganze Haus mit Netz versorgt! Die HV wird dann sicher nicht wollen, dass sich jeder "seinen" Service installiert ; bzw. gerade DynDNS wird dann nur 1x gehen können!
--
Meine ganzen Spielereien (z. B. kabellose Datenübertragung Firmen-Lappi <-> homeoffice PC) möchte ich nach Möglichkeit in meinem WLAN Router (Netgear WGR614 v7) eintragen und den Fremd-Router möglichst in Ruhe lassen und nur Internet von ihm beziehen.
Nur gibt es bei DynDNS ein Problem: DynDNS *WEISS* ja gar nix von irgendwelchen C-Klassen-Adressen! Hinten kommt ja nur 192.168.xx.yy raus...also wie soll DynDNS "wissen", dass ich hier eine echte Internetadresse ansprechen will?
Dennoch möchte ich nicht auf einem fremden Router DynDNS einrichten.
Meine derzeitige Konfiguration:
RJ45-("LAN")-Kabel (Kabel wegen Speed) aus der Vermieterwohnung in "Internet" Port von Router2
RJ45-Kabel aus Desktop-PC-LAN-Anschluss in "LAN1" Port von Router2
Ziel des Ganzen: Mein privates/geschäftliches LAN vom LAN des Vermieters abgrenzen.
Ich habe auch schon über eine DMZ-Lösung nachgedacht.
Vorschläge aller Art willkommen.
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: 70542
Url: https://administrator.de/contentid/70542
Ausgedruckt am: 25.11.2024 um 21:11 Uhr
12 Kommentare
Neuester Kommentar
Hallo,
wenn du die Netze abgrenzen willst, würde ich zunächst einmal intern ein anderes Subnetz nehmen. Würde dann nach "außen" zwangsläufig eine DMZ ergeben ...
Du kannst mit den diversen DDNS-Clients problemlos von hinter deinem Router die DynDNS-Adresse setzen, indem du die IP mit dem Service "web" holst.
Allerdings bleibt dann das Problem, dass der Router deines Vermieters immer noch die benötigten Ports NATten müsste ...
-nik
wenn du die Netze abgrenzen willst, würde ich zunächst einmal intern ein anderes Subnetz nehmen. Würde dann nach "außen" zwangsläufig eine DMZ ergeben ...
Du kannst mit den diversen DDNS-Clients problemlos von hinter deinem Router die DynDNS-Adresse setzen, indem du die IP mit dem Service "web" holst.
Allerdings bleibt dann das Problem, dass der Router deines Vermieters immer noch die benötigten Ports NATten müsste ...
-nik
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...
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...
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.
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.
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....
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....
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.
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.
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
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 ??
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.
"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....
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....
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....
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.
So ist es! :P
Vor lauter Offtopic hab ich jetzt eigentlich immer noch keine Lösung zu meinem Problem - also ich bitte um etwas mehr Konkretisierung ...
Also irgendwer viiiiel weiter oben schrieb doch was dass es eigentlich doch geht dass ich hinten die IP-Adresse rauskriege; und irgendwer anderer auch noch dass es Tools gibt die diese Internet-IP sich holen können.
Also wie geh ich da ran?
Notfalls werd ich halt doch die Sache mit Router 1 absprechen - aber ich lerne eben auch gerne solche Sachen, selbst wenn ich die Möglichkeiten NOCH habe. Irgendwann hab ich die vielleicht nicht mehr, und weiß dann wie ich vorgehen kann: "1x gelernt -> behalten".
Vor lauter Offtopic hab ich jetzt eigentlich immer noch keine Lösung zu meinem Problem - also ich bitte um etwas mehr Konkretisierung ...
Also irgendwer viiiiel weiter oben schrieb doch was dass es eigentlich doch geht dass ich hinten die IP-Adresse rauskriege; und irgendwer anderer auch noch dass es Tools gibt die diese Internet-IP sich holen können.
Also wie geh ich da ran?
Notfalls werd ich halt doch die Sache mit Router 1 absprechen - aber ich lerne eben auch gerne solche Sachen, selbst wenn ich die Möglichkeiten NOCH habe. Irgendwann hab ich die vielleicht nicht mehr, und weiß dann wie ich vorgehen kann: "1x gelernt -> behalten".
Also irgendwer viiiiel weiter oben schrieb
doch was dass es eigentlich doch geht dass
ich hinten die IP-Adresse rauskriege; und
irgendwer anderer auch noch dass es Tools
gibt die diese Internet-IP sich holen
können.
doch was dass es eigentlich doch geht dass
ich hinten die IP-Adresse rauskriege; und
irgendwer anderer auch noch dass es Tools
gibt die diese Internet-IP sich holen
können.
War vielleicht auch ein und dieselbe Person, nämlich ich. aqui hat's dann irgendwie noch umformuliert ...
Also wie geh ich da ran?
Der Trick ist - auch das habe ich bereits geschrieben - einen von den Software-Clients von dyndns.org auf einen PC hinter dem zweiten Router enizusetzen, und nicht den integrierten DDNS-Client auf dem Router. Dann gibt es auch die Option, das Backend web zur Feststellung der Adresse zu benutzen.
-nik
P.S.: An der ganzen Diskussion war rein gar nichts Off-Topic. Es ging genau um dein Problem, nur mussten wir zwei unterschiedliche Ansichten klären.
