/ Linux - dyndns, loopback umgehen

[entropie]

Tach alle,

Ich wusste nicht so recht den titel zu formulieren.
Ich habe ein dyndns account der zum hauseigenen linux router weiterleitet. Port 80 zum beispiel, wird dann wiederum lokal zu meiner workstation weitergeleitet.

wenn ich jetzt host.dyndns.org/~mit/foo (lokal) in den browser eingebe, funktioniert die NAT weiterleitung nicht, ich bekomme einen 404 weil /~mit auf dem router kein Userdir ist. das selbe bei ssh und so weiter.

Kann ich irgendwie umgehen?

Sozusagen habe ich keinerlei möglichkeiten die firewall, oder sonst irgendetwas zu testen.. Ein wenig blöd.

Mfg entropie

[Sven Rautenberg]

Moin!

wenn ich jetzt host.dyndns.org/~mit/foo (lokal) in den browser eingebe, funktioniert die NAT weiterleitung nicht, ich bekomme einen 404 weil /~mit auf dem router kein Userdir ist. das selbe bei ssh und so weiter.

Kann ich irgendwie umgehen?

Dein Router kriegt es nicht hin, dich von intern wieder zurück nach intern zu leiten.

Empfehlung: Lege einen Eintrag in deiner jeweiligen hosts-Datei an, der den Dyndns-Domainnamen mit der internen IP verbindet. Dann umgehst du den Router - kannst aber auch nicht mehr unterschiedliche Dienste (auf unterschiedlichen Ports) auf unterschiedlichen Servern ansprechen, sondern nur noch einen einzigen Server.

Sozusagen habe ich keinerlei möglichkeiten die firewall, oder sonst irgendetwas zu testen.. Ein wenig blöd.

Die Firewall kannst du von intern sowieso nicht wirklich testen (ich würde solchen Ergebnissen sowieso mißtrauen, man weiß nicht wirklich, ob da nicht doch irgendein Faktor für Durchlaß sorgt, weil "intern ist ja wohl erlaubt" - oder was auch immer sich die Firewall so denkt).

- Sven Rautenberg

[entropie]

Moin!

Dein Router kriegt es nicht hin, dich von intern wieder zurück nach intern zu leiten.

Empfehlung: Lege einen Eintrag in deiner jeweiligen hosts-Datei an, der den Dyndns-Domainnamen mit der internen IP verbindet. Dann umgehst du den Router - kannst aber auch nicht mehr unterschiedliche Dienste (auf unterschiedlichen Ports) auf unterschiedlichen Servern ansprechen, sondern nur noch einen einzigen Server.

Hm, da hätte ich natürlich auch selbst draufkommen können. Die nervigsten dinge sind so schon gelöst.
Danke sehr.

Mfg entropie

[Christian Seiler]

Hallo entropie,

Ich wusste nicht so recht den titel zu formulieren.
Ich habe ein dyndns account der zum hauseigenen linux router weiterleitet. Port 80 zum beispiel, wird dann wiederum lokal zu meiner workstation weitergeleitet.

wenn ich jetzt host.dyndns.org/~mit/foo (lokal) in den browser eingebe, funktioniert die NAT weiterleitung nicht, ich bekomme einen 404 weil /~mit auf dem router kein Userdir ist. das selbe bei ssh und so weiter.

Das Problem ist folgendes: Du machst ja sicherlich sowas wie:

iptables -t nat -A PREROUTING -p tcp -s 0/0 -d $EXTERNE_IP --dport 80 -j DNAT --to-destination $IP_DES_ZIELRECHNERS:80 -i $EXTERNES_INTERFACE

[$EXTERNE_IP == Die IP, die Du gerade im Internet hast]
[$EXTERNES_INTERFACE == Das Interface für Deine Internetverbindung, z.B. ppp0]
[$IP_DES_ZIELRECHNERS == Die interne IP von Deiner Workstation]

Wenn Du das -i $EXTERNES_INTERFACE drin lässt, dann hast Du das Problem, dass nur Pakete, die über das externe Interface hineinkommen, diese Weiterleitung erfahren. Wenn Du aber ein Paket von Workstation -> dyndns.org-Adresse schickst, dann kommt das ja von *intern* an den Router rein. Konsequenz: Der Router ändert das Ziel nicht, sondern lässt es so, wie's ist. Ergo: Das von Dir beschriebene passiert.

Lösung? -i $EXTRNES_INTERFACE weglassen. Das geht natürlich nur, wenn Du das -d $EXTERNE_IP auf jeden Fall drin hast, sonst wird *jedes* Paket an Port 80 an Deinen Rechner umgeschrieben - auch nicht schön. Nachteil: Du musst beim Aufbau/Abbau der Internetverbindung (z.B. in ip-up/ip-down-Scripts) die iptables-Regeln erzeugen und kannst sie nicht schon beim Booten anlegen, enn die externe IP ist natürlich erst hinterher bekannt. Vorteil: Damit leitet Dein Router schonmal die Pakete von Deinem internen Rechner an ihn zurück.

Funktioniert das dann bereits? Nein. Warum nicht? Schauen wir uns mal ein Paket an: Deine Workstation hat z.B. die IP 192.168.0.2, Dein Router die IP 192.168.0.1; die externe IP wäre 300.0.0.1 (ja, die gibt's natürlich nicht, aber ich will keine gültige IP angeben ;-)). Jetzt baut Dein Browser eine Verbindung zu 300.0.0.1 Port 80 auf. Der Source-Port wird wie immer zufällig gewählt. Damit erhält das Paket folgende Angaben:

Quelle: 192.168.0.2:4321
Ziel: 300.0.0.1:80

Das Paket kommt nun bei Deinem Router an und durchläuft die PREROUTING-Table. Was passiert? Die Ziel-Adresse wird umgeschrieben:

Quelle: 192.168.0.2:4321
Ziel: 192.168.0.2:80

Das Paket kommt nun wieder bei Deinem Rechner an. Der antwortet dann auch darauf. Also schickt Dein Rechner ein Antwortpaket los:

Quelle: 192.168.0.2:80
Ziel: 192.168.0.2:4321

Doch was passiert nun? Das Antwortpaket kommt gar nicht erst zu Deinem Router durch und der kann das DNAT nicht wieder rückgängig machen, denn Dein Rechner bemerkt, dass er das Paket selbst behandeln kann (bzw. analog für andere Adressen im eigenen Netz: die wandern auch nicht über den Router). Jetzt erhält Dein Rechner jedoch ein Paket (von sich selbst) an 192.168.0.2:4321, Absender ist jedoch 192.168.0.2. Er wartet aber auf Pakete von 300.0.0.1:80 und nicht 192.168.0.2:80 - das Paket verwirft er. Auf der anderen Seite wartet Dein Rechner nun ewig auf die Antwort auf das Paket, das er an 300.0.0.1:80 geschickt hat - das wird nie ankommen.

Nun könnte man meinen, es wäre hier Schluss, es geht einfach nicht. Falsch: Es geht doch. Allerdings muss man dabei etwas "tricksen". Und zwar kannst Du nicht nur die Ziel-, sondern auch die Absender-Adresse austauschen, wenn Du Port Forwarding betreibst. Dazu sei $INTERNES_INTERFACE das Interface an dem das lokale Netzwerk von Dir hängt (z.B. eth0), $INTERNES_NETZ sei Dein lokales Netz inklusive Netzmaske (z.B. 192.168.0.0/24 wenn wir unserem Beispiel wieter folgen). Dann kannst Du über:

iptables -t nat -A POSTROUTING -p tcp -s $INTERNES_NETZ -d $IP_DES_ZIELRECHNERS --dport 80 -o $INTERNES_INTERFACE -j SNAT --to $INTERNE_IP

Was macht diese Zeile? Wann immer Dein Router ein Paket, das von Deinem internen Netz kommt an den Zielrechner mit dem entsprechenden Port aus dem Internen Netz schicken will, tut er so, als ob er der Absender wäre. Dazu mehrere Erläuterungen:

Zum einen: Reine interne Netzwerkkommunikation läuft defaultmäßig sowieso nicht über den Router (die Rechner sehen sich ja auf Link-Ebene direkt), d.h. die Regel greift dort *nicht* ein. Bei normalem Betrieb (ohne Adressumschreibung vorher) dürfte die Regel eigentlich nie erfüllt werden, weil von Deinem internen Netz *nie* etwas über Deinen Router weiter ins gleiche interne Netz geleitet werden dürfte.

Zum anderen: Wenn wir nun das obige Beispiel uns nochmal durchdenken: Rechner sendet folgendes Paket:

Quelle: 192.168.0.2:4321
Ziel: 300.0.0.1:80

Das kommt am Router an. Im ersten Schritt (_PRE_ROUTING) macht der DNAT, d.h.

Quelle: 192.168.0.2:4321
Ziel: 192.168.0.2:80

Im zweiten Schritt (_POST_ROUTING) macht er jetzt die neue SNAT-Regel:

Quelle: 192.168.0.1:5678
Ziel: 192.168.0.2:80

Das Paket kommt an Deinem Rechner an. Der sendet nun ein Antwortpaket dazu. Das hat die Angaben:

Quelle: 192.168.0.2:80
Ziel: 192.168.0.1:5678

Das kommt jetzt beim Router an. Der macht jetzt das SNAT rückgängig:

Quelle: 192.168.0.2:80
Ziel: 192.168.0.2:4321

Und als nächstes das DNAT rückgängig:

Quelle: 300.0.0.1:80
Ziel: 192.168.0.2:4321

Dein Rechner erhält also als Antwort auf seine Anfrage das korrekte (!) Antwortpaket, das er nicht verwirft. Somit kann eine Kommunikation zwischen Deinem Rechner und sich selbst stattfinden.

Hat den kleinen Nachteil, dass nur noch die IP des Routers in Deinen Logs auftaucht, wenn jemand von innen auf Deinen Rechner zugreifen wollte. Von außen steht dagegen weiterhin die korrekte externe Adresse in den Logs.

Die Alternative dazu, nämlich eigene Einträge ins die /etc/hosts (oder wo auch immer unter Deinem Betriebsystem die Datei auch liegen mag) zu schreiben, hat Sven Dir ja schon genannt. Die /etc/hosts hat 3 Nachteile: Zum einen geht's nicht mit der Angabe von ausschließlich der IP, zum anderen musst Du bei *jedem* Rechner die /etc/hosts modifizieren. Ferner kannst Du unterschiedliche Ports dann nicht mehr auf unterschiedliche Rechner leiten, wenn Du intern auf *alle* dieser Ports zugreifen willst. Dafür gibt's 2 Vorteile: In den Logs steht immer die richtige Quell-IP und die Einrichtung ist einfacher als die iptabes-Methode.

Alternativ könntest Du natürlich Deinem DNS-Server auf dem Router (sofern der nicht ausschließlich ein Cache ist) beibringen, dass für die dyndns.org-Adresse immer die interne IP angeben soll. Nachteil gegenüber der /etc/hosts-Methode: Komplizierter einzurichten; Vorteil: /etc/hosts muss nicht mehr auf jedem Rechner modifiziert werden.

Viele Grüße,
Christian