VPN-Routing in Namensräumen testen, ohne Host-Routen anzufassen

Zwei Labs können dieselbe VPN-Topologie modellieren und auf völlig unterschiedliche Weise scheitern: Das eine lebt in Netzwerk-Namespaces, das andere in den eigenen Routen des Hosts. Die Namespace-Variante hält jede Schnittstelle, jede Route und jeden Socket in einem Kontext, den du löschen kannst, während die Host-Variante schneller startet und Zustand hinterlässt. Dieser zurückgebliebene Zustand ist der Grund, warum das zweite Lab einen Monat später schwer zu wiederholen ist. Vergleiche zuerst das Aufräumen, denn es entscheidet, ob du das Experiment zweimal laufen lassen kannst.

Zwei Wege, dasselbe Lab zu bauen, und wann jeder gewinnt

In einem Host-Routen-Lab fügst du der Maschine, an der du arbeitest, eine Tunnelschnittstelle und Routen hinzu, sodass das Experiment das Schicksal mit deiner Shell, deinem Paketmanager und jeder anderen Verbindung teilt. In einem Namespace-Lab bekommt jede Rolle ihren eigenen Stapel aus Schnittstellen, Adressen, Routen und Sockets, und das Löschen des Namespace entfernt all das. Keines der beiden Modelle ist korrekter, weil sie unterschiedliche Fragen beantworten. Wähle Namespaces, wenn es um Routing und Weiterleitung geht, und ein Host-Lab, wenn es darum geht, wie sich ein Desktop-Client integriert.

Die beiden zu vermischen ist der übliche Fehler: ein Namespace-Lab, das gegen einen reinen Host-Client getestet wird beweist nichts über die eine oder die andere Anordnung. Entscheide, welche Frage du stellst, bevor du den ersten Link erstellst.

Ein Kontext pro Rolle, bewusst verbunden

Erstelle einen Namespace pro Rolle und verschiebe jedes Ende jedes veth-Paars in den Kontext, dem es gehört. Die ersten vier Befehle reichen, um die Form zu erkennen:

ip netns add client
ip netns add gateway
ip link add veth-c type veth peer name veth-g
ip link set veth-c netns client

Gib dem Lab Bereiche, die sich mit nichts auf dem Host überschneiden, und notiere vor dem Start, welcher Namespace welche Adresse besitzt. Ein funktionierendes Lab braucht zwei getrennte Pfade: einen äußeren, damit der VPN-Endpunkt seinen Peer erreicht, und einen Rückweg für die Ressource, die geschützt wird. Modelliere sie als zwei Entscheidungen, denn ein Lab, das nur die ausgehende Hälfte baut, besteht einen Handshake-Test und scheitert an einem Anwendungstest.

Die Weiterleitungsrolle ist der Punkt, an dem Labs interessant werden

Eine Rolle muss weiterleiten, was bedeutet, die Weiterleitung in diesem Namespace zu aktivieren und die Regel hinzuzufügen, die das Design braucht. Der Weiterleitungszustand gilt pro Namespace, daher ist die Host-Einstellung für das Lab irrelevant und die Lab-Einstellung sickert nicht nach außen, wie die Dokumentation zu Netzwerk-Namespaces beschreibt. WireGuard dokumentiert, dass eine Schnittstelle und ihr äußerer Socket in verschiedenen Namespaces leben können, was ein nützlicher Trick und eine hervorragende Methode ist, sich selbst zu verwirren. Gehe nicht davon aus, dass das Verschieben einer Schnittstelle jeden Teil der Verbindung gleichermaßen verschiebt.

Prüfe den Weiterleitungszähler nach einem Testpaket, denn eine Regel, die nie gepasst hat, und eine Regel, die verworfen hat, sehen in der Routentabelle identisch aus. Nur die Zähler unterscheiden sie.

Eine Baseline aufzeichnen, dann eine Route kaputt machen

Beginne damit, aufzuzeichnen, was existiert, mit dem Kontext neben jeder Zeile. Lies die Namespaces, dann die Route, die ein Testziel innerhalb eines davon nehmen würde, dann die Zähler auf dem Link, der sie trägt:

ip netns list
ip -n client route get 10.0.0.5
ip -n gateway -s link show veth-g

Der dritte Befehl ist der, den Leute überspringen, und dort liegen die Beweise: Die Zähler für verworfene Pakete und Fehler sagen dir, ob ein Paket die Weiterleitungsrolle überhaupt erreicht hat. Erfasse dieselben drei Ansichten nach einer Änderung, und lass den Diff der Beweis sein statt deiner Erinnerung daran. Dann brich genau eine Sache, entweder indem du eine Route löschst oder eine Verweigerungsregel auf dem Weiterleitungspfad hinzufügst, und bestätige das vorhergesagte Symptom: ein abgeschlossener Handshake ohne Antwort oder ein Auflösungsfehler statt einer Zeitüberschreitung. Ein Lab, das nur Erfolg zeigt, lehrt sehr wenig.

Aufräumen macht den nächsten Lauf wiederholbar

Halte das Aufräumen auf die Ressourcen beschränkt, die du benannt hast, denn ein pauschaler Firewall-Reset oder das Entfernen einer Host-Route ist keine Reproduzierbarkeit, sondern ein zweiter Vorfall. Speichere die Topologie, die genauen Befehle und die erwarteten Beobachtungen, damit der nächste Lauf denselben Fehler reproduziert, statt zu raten, welcher Kontext den vorherigen Zustand hielt. Ohne diese Aufzeichnung ist das Lab eine Geschichte statt einer Prozedur.

Verwende lokal erzeugte Zugangsdaten für das Lab und halte Produktionskonten aus geteilten Beispielen heraus. Lösche dann jeden Namespace und bestätige, dass die Host-Ansicht unverändert ist, was der ganze Grund für die Wahl dieses Modells ist. Ein Lab, das du nicht sauber entfernen kannst, ist eine Host-Änderung mit zusätzlichen Schritten.