Kill-Switch für einen VPN-Sidecar: Datenverkehr blockieren, wenn er beendet wird

Ein Anwendungscontainer, der den Netzwerk-Namespace eines VPN-Containers teilt, hat keine eigene Schnittstelle, daher liegt die Annahme nahe, dass er nichts senden kann, wenn der Tunnel ausfällt. Diese Annahme ist im entscheidenden Fehlerfall falsch. Stirbt der VPN-Prozess, während der Namespace weiterlebt, behält die Anwendung ihre Sockets und der Namespace behält seine Routen, und der Datenverkehr läuft auf dem Pfad weiter, der noch installiert ist. Ein echter Kill-Switch besteht aus einer expliziten Filterrichtlinie plus Tests des Laufzeit-Lebenszyklus, nicht aus einer Startabhängigkeit.

Warum geteilter Namespace kein Kill-Switch ist

Ein Namespace zu teilen bedeutet, dass die App die Schnittstellen, Adressen und die Routentabelle des VPN-Containers nutzt. Das beseitigt den eigenständigen Weg der App ins Netzwerk, solange der geteilte Namespace intakt ist, und es sagt nichts darüber aus, was dieser Namespace tut, wenn der Tunnel verschwindet.

Abhängigkeitsbedingungen in Compose können den Start einer App verzögern, bis eine Abhängigkeit gesund ist. Das deckt einen einzigen Zeitpunkt ab und keinen späteren Ausfall, es ist also ein Werkzeug für die Startreihenfolge und keine dauerhafte Egress-Firewall.

Was tatsächlich passiert, wenn der Container beendet wird

Unterscheiden Sie drei Ereignisse. Der VPN-Prozess im Container kann sterben, während der Container weiterläuft. Der Container kann gestoppt oder entfernt werden, was den Namespace zerstört. Der Container kann neu erstellt werden, was einen neuen Namespace und neue Regeln erzeugt.

Im ersten Fall besteht der Namespace fort, die Standardroute kann weiterhin auf die physische Schnittstelle zeigen, und die Anwendung sendet weiterhin direkt. Im zweiten Fall verliert die abhängige App in der Regel die Verbindung vollständig, weil ihr Namespace verschwunden ist. Im dritten Fall kann die App sich mit einem frischen Namespace verbinden, bevor der Tunnel bereit ist. Jeder Fall braucht einen anderen Test, und ein Entwurf, der nur die geordnete Trennung abdeckt, deckt den uninteressantesten ab.

Eine explizite Egress-Richtlinie aufbauen

Schreiben Sie die Richtlinie in den geteilten Namespace, damit sie für die Pakete der Anwendung gilt. Die Form ist ein Standard-Drop mit engen Ausnahmen: Loopback, die Tunnelschnittstelle und die konkrete Endpunktadresse und der Port, die der Tunneltransport benötigt.

Die Endpunkt-Ausnahme muss stehen, bevor der Tunnel hochkommt, sonst erreicht der VPN-Client seinen Server nicht. Deshalb erlaubt das Regelwerk den äußeren Transport ausdrücklich, statt die physische Schnittstelle pauschal zuzulassen. Fügen Sie auch IPv6-Regeln hinzu, wenn der Namespace IPv6-Konnektivität hat, denn eine reine IPv4-Richtlinie lässt die andere Adressfamilie offen.

DNS gehört ebenfalls in die Richtlinie. Löst die App Namen über einen Resolver auf, der nur im Tunnel erreichbar ist, bricht die Drop-Regel die Auflösung, wenn der Tunnel unten ist, und das ist für einen Kill-Switch das richtige Verhalten. Entscheiden Sie bewusst, ob Sie das wollen.

Den Lebenszyklus testen, nicht nur die Trennung

Senden Sie eine frische harmlose Anfrage, solange der Tunnel gesund ist, töten Sie dann den VPN-Prozess und senden Sie eine weitere. Wiederholen Sie das nach einem Containerstopp, nach einem Neustart und nach einer Neuerstellung. Eine frische Anfrage ist wichtig, weil eine bestehende Verbindung eine Regeländerung überleben kann, die neue blockiert.

Verlassen Sie sich nicht auf einen Health-Check oder eine Exit-IP-Abfrage als Blockiermechanismus. Ein Check beobachtet den Zustand und meldet ihn; eine Richtlinie steuert den Verkehr. Beides gehört in dieselbe Bereitstellung, und sie ersetzen einander nicht.

Die Regeln festhalten, damit der Test ein Update übersteht

Schreiben Sie das erwartete Ergebnis für jeden Fehlerfall zusammen mit den umsetzenden Regeln in die Bereitstellungsdokumentation. Diese Aufzeichnung erlaubt denselben Test nach einem Image-Update oder einem Laufzeit-Upgrade, wenn sich Namespace-Verhalten oder Standardrouten ändern können, ohne dass jemand die Compose-Datei bearbeitet.

Halten Sie den erforderlichen äußeren Pfad des VPN-Endpunkts getrennt vom uneingeschränkten Egress der Anwendung und halten Sie DNS und IPv6 innerhalb der beabsichtigten Abdeckung. Erlaubt die Richtlinie aus Bequemlichkeit die gesamte physische Schnittstelle, ist der Kill-Switch weg. Die Docker-Netzwerkdokumentation beschreibt die Anordnung des geteilten Namespace, auf der die Richtlinie aufbaut, und sie ist die Referenz, die zu prüfen ist, wenn das Verhalten der Laufzeit fraglich ist.