Linux-Netzwerk-Namespaces für ein VPN: Was sie nicht isolieren

Starten Sie das VPN in seinem eigenen Namespace, führen Sie dort eine Anwendung aus, und der Verkehr verlässt das System trotzdem über die Host-Route. Nichts ist kaputt: Der Namespace verwaltet nur Prozesse, die in ihn eintreten, und das Leck kam von einem, der das nie tat. Schnittstellen, Adressen, Routen, Firewall-Regeln und Sockets gehören dem Namespace. Dateien, Konten und bereits laufende Dienste nicht, und daher kommen die meisten Überraschungen.

Was der Namespace besitzt und wo der Socket geboren wird

Verschieben Sie eine Schnittstelle in einen Namespace, und der Host verliert sie; bauen Sie darin einen Tunnel, und der Host kann ihn nicht sehen. Das ist der Mechanismus hinter einem namespace-gebundenen VPN: Das Gerät und die Routen darauf leben in einem Kontext, den nur die ausgewählten Prozesse erreichen. Der Host behält seine Standardroute, sodass alles außerhalb unberührt bleibt.

Bei WireGuard zählt der Erstellungskontext ebenso wie der aktuelle Ort: Der UDP-Socket wird in dem Namespace gebunden, in dem die Schnittstelle erstellt wurde, selbst nachdem das Gerät woandershin wandert. Welcher Routingtabelle die verschlüsselten Pakete folgen, hängt von diesem Geburtsort ab. Bleibt der Socket in einem Kontext ohne Route zum Peer, schlägt die Schnittstelle nach und der Handshake geht nie hinaus. Prüfen Sie seinen Geburtsort, dann seinen aktuellen Ort.

Was ein Namespace nicht isoliert

Nichts hier trennt Dateisysteme, Konten oder Geheimnisse, und keine dieser Grenzen entsteht dadurch, dass Sie einen Namespace erstellt haben. Die Resolver-Konfiguration ist eine Datei, also kann ein Prozess darin weiterhin eine Einstellung lesen, die auf den Host-Resolver zeigt, und seine Abfrage über die Route senden, die das impliziert. Eine Anwendung, die die Anfrage an einen bereits laufenden Broker oder Systemdienst übergibt, bezieht einen Prozess in einem völlig anderen Kontext ein. Beides sind Anfragen, die die Grenze nie beantworten sollte.

Die Lösung ist eine Datei pro Namespace unter /etc/netns/<name>/resolv.conf oder ein Bind-Mount einer vorbereiteten Datei, die auf einen von innen erreichbaren Resolver zeigt. /etc/resolv.conf auf dem Host zu bearbeiten ändert nichts von dem, was der Namespace sieht.

Die Prozessplatzierung ist die Steuerung

Die Isolation, die Sie erhalten, ist genau die Isolation der Prozesse, die Sie darin starten. Eine Shell, die über den exec-Helfer des Namespace gestartet wurde, und alles, was sie erzeugt, bleibt drin; eine Desktop-Anwendung, die aus der Host-Sitzung gestartet wird, nicht. Erstellen Sie den Kontext, verschieben Sie das Gerät und beweisen Sie dann beide Seiten:

ip netns add vpn1
ip link set wg0 netns vpn1
ip netns exec vpn1 wg show
wg show

Lesen Sie das erste wg show von innerhalb des Namespace und das zweite vom Host, und erwarten Sie, dass nur eines von beiden den Peer auflistet. Wenn beide es tun, hat sich das Gerät nie bewegt; wenn keines es tut, ist es woandershin gegangen. Wenn der Starter ein Dienstmanager ist, ist die Unit-Datei zu bearbeiten, nicht die Desktop-Verknüpfung. Eine Unit ohne die Namespace-Einstellung startet den Daemon im Host-Kontext und macht das Design stillschweigend zunichte.

Testen Sie aus dem Kontext der Anwendung

Führen Sie die Prüfung mit derselben Binärdatei und demselben Benutzer aus, die die Anwendung verwendet, und zwar im Namespace. Schließen Sie DNS und beide Adressfamilien ein, denn eine IPv6-Route, die Sie nie bedacht haben, ist ein häufiger Ausweg. Ein Test aus Ihrer eigenen Shell beweist nur, dass Ihre Shell isoliert ist.

Führen Sie dann die identische Prüfung auf dem Host aus und bestätigen Sie, dass die Antworten abweichen: Tunneladresse und beabsichtigter Ausgang drinnen, Host-Route und Büro-Ausgang draußen sowie der Resolver nach Namen. Benennen Sie Namespaces nach dem Deployment statt nach dem Protokoll, damit ein Aufräumskript nicht zwei davon verwechselt.

Weiterleitung, Fehlerpolitik und Aufräumen

Für ein Gateway schalten Sie die Weiterleitung bewusst ein und entscheiden, was passieren soll, wenn der Tunnel ausfällt. Ein Namespace blockiert keine Routen, die Sie darin installieren, also wird eine Ausweichroute zum Host genutzt, wenn Sie eine anlegen. Das ist eine politische Entscheidung, und sie sollte niedergeschrieben werden, bevor ein Ausfall sie prüft.

Halten Sie die Namespace-Namen, die Schnittstellen und den Eigentümer der Konfiguration fest, damit das Aufräumen nur entfernt, was das Deployment erstellt hat. Das Zurücksetzen des Host-Netzwerks während eines Rollbacks macht aus einem Aufräumen einen Ausfall. Die network_namespaces(7)-Seite ist kurz und lohnt sich, bevor Sie diesen Weg entwerfen.