Zwei VPNs auf einer Linux-Maschine: jeden testen, ohne Ergebnisse zu vermischen

Zwei grüne Verbindungssymbole sehen nach einem Vergleich aus und sind meistens ein Zufall. Konnte die Testanfrage beide Tunnel nutzen, beschreibt das Ergebnis bestenfalls einen von ihnen und schlimmstenfalls keinen. Gib jeder Beobachtung einen Netzwerkkontext, ein beabsichtigtes Ziel und eine Erwartung, die vor dem Testlauf niedergeschrieben ist. Auf einer selbst verwalteten Linux-Maschine sind benannte Netzwerk-Namespaces der billigste Weg, diese Trennung zu kaufen.

Zwei grüne Lichter sind kein Vergleich

Ein Namespace trennt Routingtabellen, Schnittstellen und den Zustand des Netzwerk-Stacks, sodass eine Anfrage, die in einem gestartet wurde, nicht stillschweigend den Tunnel eines anderen ausleihen kann. Was er nicht trennt, sind eine CPU, ein physischer Uplink oder der Resolver-Daemon auf dem Host. Genau in dieser letzten Lücke scheitern die meisten dieser Tests, ohne dass es jemand merkt. Eine Abfrage, die den Namespace verlässt und den Host-Resolver fragt, liefert eine Antwort ohne jede Beziehung zum getesteten Tunnel.

Dieses Verfahren setzt zwei bereits bereitgestellte, freigegebene Test-Namespaces mit funktionierender äußerer Konnektivität und unterstützten Clients voraus. Es erzeugt nichts, trägt nichts ein und ersetzt keine Konfiguration. Getrennte virtuelle Maschinen bleiben die ehrliche Wahl, wenn ein Client eine vollständige Desktop-Sitzung braucht oder sich weigert, außerhalb einer solchen zu laufen.

Erwartung vor dem ersten Lauf festlegen

Lege je Kontext fest, wie Erfolg aussieht: der Resolver, der Dienstname, die erwartete Adresse und das Verhalten, das beim Abbruch des Tunnels erforderlich ist. Halte diese geplanten Werte in ihrer eigenen Spalte, denn ein Protokoll, das Plan und Beobachtung mischt, ist Fiktion mit Zeitstempel. Die Liste unten ist die Form, die das Protokoll braucht, und jede Zeile muss vor der ersten Verbindung ausfüllbar sein.

Die Resolver-Verdrahtung braucht ihre eigene Zeile in diesem Protokoll, denn sie ist das Feld, das am ehesten lügt. Namespace-gebundene Dateien wie /etc/netns/vpn-a/resolv.conf erscheinen an ihren gewohnten Pfaden, wenn ein Befehl innerhalb des Namespace läuft, wie es die iproute2-Referenz zu Namespaces beschreibt, aber die Konfiguration des Namensdienst-Umschaltens und jeder lokale Resolver, den sie startet, können eine Abfrage immer noch zurück zum Host ziehen.

Ein Tunnel nach dem anderen, der andere getrennt

Verbinde A über seinen bestehenden Eigentümer, während B unten bleibt, und prüfe dann Richtlinie, Routen und den gewählten Pfad aus dem Administrationskontext. Drei der Befehle unten lesen Zustand; nur der letzte kontaktiert einen Namensdienst, und keiner von ihnen sendet eine Anwendungsanfrage.

sudo ip -n vpn-a -4 rule show
sudo ip -n vpn-a -4 route show table all
sudo ip -n vpn-a -4 route get 10.55.10.20
sudo ip netns exec vpn-a getent ahostsv4 svc-a.lab.internal

Eine Routensuche beantwortet eine hypothetische Frage zu einem Ziel, kann also nicht zeigen, dass der Dienst Verkehr annimmt. Halte diese beiden Beweisarten in getrennten Spalten, denn eine gesunde Route neben einer abgelehnten Verbindung ist ein reales und häufiges Ergebnis. Sende dann eine harmlose autorisierte Anfrage mit der echten Anwendung, gestartet im Kontext von A als ihr normaler unprivilegierter Benutzer, mit intakter Zertifikatsprüfung und Anwendungsauthentifizierung, und protokolliere das Ergebnis zusammen mit der Quelladresse, die der Dienst gesehen hat. Trenne A über seinen Eigentümer und wiederhole die gesamte Grundlinie für B, wobei du jede Konfigurationsänderung notierst, sonst sind die beiden Grundlinien nicht mehr vergleichbar.

Beide oben, dann einer nach dem anderen runter

Der Dauerzustand ist der leichte Teil. Mit beiden verbundenen Tunneln wiederhole Abfrage und Anwendungsanfrage jedes Kontexts, dann brich einen Tunnel ab und prüfe den anderen. Verbinde in umgekehrter Reihenfolge neu, wenn die Verbindungsreihenfolge selbst die Frage ist.

sudo ip netns exec vpn-a tcpdump -ni any port 443 -c 5
sudo ip netns exec vpn-b getent ahostsv4 svc-b.lab.internal
sudo ip -n vpn-b -4 route get 10.55.20.20

Der Mitschnitt entscheidet Streitfragen, die ein Anwendungsergebnis nicht entscheiden kann: er zeigt, ob die Anfrage über die erwartete Schnittstelle hinausging oder über etwas völlig anderes. Für jeden Übergang protokolliere die Aktion des Eigentümers, den Zeitstempel, das Routenergebnis, das Namensergebnis und das Anwendungsergebnis. Prüfe dann die Anforderung des sicheren Schließens innerhalb des betroffenen Namespace, denn Isolierung ist kein Kill-Switch. Ein Namespace hält zwei Tunnel auseinander; er hindert keinen von beiden daran, Verkehr zu tragen, wenn sein Profil sagt, dass der Verkehr stoppen muss.

Was dieses Protokoll behaupten kann und was nicht

Ein Bestehen beweist diese Beobachtungen für diese Anordnung, auf diesem Host, zu diesem Zeitpunkt. Es sagt nichts über zwei Clients, die sich eine Desktop-Routingtabelle teilen, und nichts über den Durchsatz, während beide Tunnel Last tragen. Das sind getrennte Fragen mit getrennten Tests, und ein Vergleich ist nur so gut wie der Kontext, der an jeder Zeile hängt.

Halte die Fehlschläge im Protokoll neben den Erfolgen, beschriftet damit, welcher Tunnel damals oben war. Eine saubere Seite, die den Zustand bei der Messung verbirgt, ist schlechter als eine hässliche, die ihn zeigt. Was das Protokoll später wiederverwendbar macht, ist der Kontext, nicht die Punktzahl.

Zwei Tunnel auf einer Maschine lassen sich ehrlich vergleichen, aber nur in so vielen Kontexten, wie du tatsächlich kontrolliert hast. Alles darüber hinaus ist ein Wunsch mit einem grünen Symbol daneben.