App in einem VPN-Namespace ist aus dem LAN nicht erreichbar

Ein Netzwerk-Namespace gibt einem Programm seinen eigenen Tunnel und sein eigenes Loopback. Veröffentlichen Sie nur seinen Port über einen socat-Sprung oder ein veth-Paar statt über den Host.

Ihr Dienst läuft auf der Maschine, der Tunnel steht, und der Browser auf Ihrem Schreibtisch wartet noch immer vergebens. Nichts ist im üblichen Sinne kaputt: Die Anwendung lauscht innerhalb eines Netzwerk-Namespace, und dieser Stack ist für das LAN unsichtbar. Ihr Loopback gehört zum Namespace, also hat ein Client auf einer anderen Maschine keine Adresse, die den Port erreicht. Ein gezielter Sprung oder ein veth-Paar behebt das, ohne den Rest des Hosts zu bewegen.

Warum unter der LAN-Adresse nichts antwortet

Ein Namespace ist ein vollständiger Netzwerk-Stack: Schnittstellen, Routen, Firewall-Regeln und ein privates Loopback. Ein über ip netns exec gestarteter Prozess sieht diesen Stack und nichts anderes, deshalb wird die Adresse, an die er bindet, nur innerhalb des Namespace aufgelöst. Das eigene 127.0.0.1 des Hosts ist ein völlig anderes Loopback.

Deshalb scheitert curl auf dem Host, während derselbe Befehl im Namespace gelingt. Die Anwendung ist gesund; die Adresse existiert im Stack des Hosts einfach nicht.

Einen Port mit einem socat-Sprung veröffentlichen

socat überbrückt die beiden Stacks im Userspace, was ausreicht, wenn ein einzelner TCP-Port übertreten muss. Die Hostseite lauscht im LAN und startet für jede angenommene Verbindung ein zweites socat im Namespace, das sich mit dem Loopback der App verbindet. Der innere Prozess erreicht die Anwendung genau wie ein lokaler Client. An der Weiterleitung des Namespace ändert sich nichts, also nutzt die App den Tunnel weiter als einzigen Ausgang.

socat TCP-LISTEN:9100,reuseaddr,fork EXEC:'ip netns exec vpn socat STDIO tcp-connect:127.0.0.1:9100',nofork

Der äußere Prozess braucht root oder die Fähigkeit, den Namespace zu betreten. Fällt das VPN aus, verliert die App ihren Weg, und der veröffentlichte Port schlägt geschlossen fehl, genau das Verhalten, das Sie von einem Gefängnis wollen.

Ein veth-Paar verwenden, wenn mehr als ein Port übertritt

Ein veth-Paar ist die richtige Antwort, wenn mehrere Ports oder Protokolle übertreten müssen oder wenn andere Hosts Verbindungen aufbauen sollen. Ein Ende bleibt im Host, das andere wandert in den Namespace, und ein kleines /30 gibt beiden Seiten eine stabile Adresse. Eine Host-Route schickt die Namespace-Adresse dann über das Paar.

ip link add veth0 type veth peer name veth1
ip link set veth1 netns vpn
ip addr add 10.77.0.1/30 dev veth0
ip link set veth0 up
ip netns exec vpn ip addr add 10.77.0.2/30 dev veth1
ip netns exec vpn ip link set veth1 up

Fügen Sie keine Standardroute über den Host hinzu, außer Sie wollen das Gefängnis aufbrechen. Der Tunnel soll der Ausgang bleiben, also ist über das Paar nur die veröffentlichte Dienstadresse erreichbar. Geben Sie dem Namespace auch eine eigene Resolver-Datei, denn ip netns exec liest /etc/netns/vpn/resolv.conf, und ohne sie ist die Namensauflösung im Gefängnis leer.

Von einer anderen Maschine testen, nicht vom Host

Führen Sie den Test von einer zweiten Maschine aus, denn der Host erreicht einen lokalen Listener über Wege, die nichts über das LAN aussagen. Prüfen Sie zuerst, woran die Anwendung im Namespace tatsächlich gebunden ist, und verbinden Sie sich dann von außen mit der veröffentlichten Adresse. Das Binden an jede Adresse dort erweitert das Gefängnis nicht, denn der Wildcard gehört weiterhin zum Namespace, und das LAN kann ihn nicht sehen.

ip netns exec vpn ss -lntp

Wenn die Verbindung vom Host funktioniert und die aus dem LAN nicht, fehlt der Sprung oder die Route, nicht die Bindeadresse. Starten Sie OpenVPN im Namespace, statt ein laufendes tun-Gerät hineinzuschieben, denn das Verschieben der Schnittstelle nimmt sie herunter und kann Routen löschen, die Sie danach von außen nicht reparieren können. Halten Sie die Wiederherstellungsbefehle auf der Konsole, nicht im Gefängnis.

Ähnliche Artikel