WireGuard im Netzwerk-Namespace: warum der Socket zurückblieb

Die Schnittstelle ist in dem Namespace aufgeführt, den Sie wollten, die Anwendung ist daran gebunden, und dennoch erscheint kein Tunnelverkehr. Das ist die Signatur eines WireGuard-Geräts im Linux-Kernel, das in einem Namespace erstellt und in einen anderen verschoben wurde: Die Schnittstelle wurde verschoben, ihr verschlüsselter UDP-Socket nicht. Beide müssen am richtigen Ort sein, bevor der innere Verkehr zählt. Die Prüfung ist schnell, sobald man weiß, dass zwei Kontexte statt einem zu betrachten sind.

Das Symptom: richtiger Namespace, keine Pakete

Innerhalb des Namespace sieht der Tunnel gesund aus. Das Gerät existiert, Adressen sind zugewiesen, und die Peer-Konfiguration ist vorhanden. Draußen erscheint der erwartete UDP-Austausch nie auf der Schnittstelle, die Sie beobachtet haben, und die Gegenseite meldet keinen Handshake.

Der Grund ist, dass die inneren Pakete der Anwendung das verschobene Gerät erreichen, und das Gerät versucht, sie über einen Socket zu senden, der zu einem anderen Netzwerkkontext gehört. Die zugrunde liegende Route und jede Firewall-Regel, die darauf zutrifft, sind die in dem Namespace, in dem das Gerät erstellt wurde.

Das ist kein Fehler beim Verschieben und keine Fehlkonfiguration des Peers. So verhält sich die Kernel-Implementierung, und die Namespace-Dokumentation für WireGuard beschreibt die Erstellungsregel direkt.

Warum der Socket einen Geburtsort hat

Ein WireGuard-Gerät besitzt einen UDP-Socket für seinen verschlüsselten Transport, und dieser Socket wird in dem Namespace geöffnet, in dem das Gerät erstellt wird. Das Verschieben der Schnittstelle mit einem Link-Befehl verlagert das sichtbare Gerät, lässt aber den Transport dort, wo er begann. Dann haben die beiden Objekte unterschiedliche Eigentümer.

Die Folge ist leicht zu übersehen, weil die Hälften an verschiedenen Stellen geprüft werden. Die innere Route wird in dem Namespace entschieden, in dem die Anwendung läuft, und die äußere Route wird dort entschieden, wo der Socket lebt. Nur eine davon zu prüfen, führt zu einer sicheren, aber falschen Schlussfolgerung. Beide zu prüfen beendet die Untersuchung meist in einem Durchgang.

Erstellen Sie es dort, wo Sie den Socket wollen

Die Lösung ist, das Gerät im Ziel-Namespace zu erstellen, statt es außerhalb zu erstellen und zu verschieben. Angenommen, ein genehmigter Namespace existiert bereits und der Name ist unbenutzt:

ip netns exec vpn-apps ip link add wg-demo type wireguard
ip netns exec vpn-apps wg show

Jetzt gehören sowohl die Schnittstelle als auch ihr Socket zu diesem Kontext, sodass die zugrunde liegende Route und die geltenden Filterregeln die dort konfigurierten sind. Wenn das Design die Klartextseite woanders braucht, legen Sie zuerst die zugrunde liegende Schnittstelle in den Namespace und erstellen Sie danach den Tunnel. Die Reihenfolge ist Teil des Designs, kein Implementierungsdetail.

Behandeln Sie diese als Netzwerkverwaltungsbefehle, nicht als Rezept. Sie erstellen ein Gerät und zeigen den Zustand; Schlüssel, Peers, Adressen und Routen müssen weiterhin aus einer genehmigten Konfiguration stammen, und eine bestehende Produktionsschnittstelle sollte niemals in ein Beispiel eingesetzt werden.

Lesen Sie beide Seiten des Pfads

Sobald das Gerät am richtigen Ort ist, prüfen Sie die beiden Entscheidungen getrennt. Beginnen Sie mit der inneren Auflösung aus dem Kontext der Anwendung und prüfen Sie dann den äußeren Pfad aus dem Kontext, dem der Socket gehört:

ip netns exec vpn-apps ip route get 10.30.0.9
ip netns exec vpn-apps wg show
tcpdump -ni any udp port 51820

Wenn die innere Auflösung durch den Tunnel erfolgt und die äußere Aufzeichnung den verschlüsselten Austausch zeigt, stimmen beide Hälften überein. Wenn die Aufzeichnung leer ist, liegt der Socket noch woanders, oder die zugrunde liegende Route in seinem Namespace erreicht den Endpunkt nicht.

Eine weitere Prüfung gehört in den Eintrag: wie das Gerät nach einem Neustart erstellt wird. Ein Manager, der die Schnittstelle mit einem anderen Erstellungskontext neu anlegt, ändert den Geburtsort des Sockets. Eine manuelle Verschiebung, die einmal funktioniert hat, ist kein Beleg für den verwalteten Pfad.