Windows-Container und VPN: Warum das lokale Netzwerk bricht
Ein Windows-Container nutzt die Routing-Tabelle des Hosts, daher nimmt ein VPN, das das lokale Subnetz sperrt, das Container-Präfix mit. Der Linux-Modus nimmt einen anderen Weg.
Auf einem einzigen Laptop, mit einem verbundenen VPN-Client, sprechen Linux-Container weiter miteinander, während Windows-Container aufhören. Die Variable ist nicht das Image, sondern der Weg, den die Pakete in den Host nehmen. Windows-Container im Standardnetz leihen sich die Routing-Tabelle und die Übersetzung des Hosts, daher ändert eine Richtlinie, die das Host-Routing ändert, auch sie. Bestätigen Sie das mit einer Routenabfrage, bevor Sie irgendetwas neu installieren.
Wo die Pakete eines Windows-Containers in den Host eintreten
Ein Container im Standardnetz nat erhält eine Adresse aus einem Präfix des Host Networking Service, meist irgendwo innerhalb von 172.16.0.0/12, und erreicht den Host über einen virtuellen Adapter. Der Host besitzt die Route für dieses Präfix und übersetzt den Datenverkehr zu dem Adapter, der gerade aktiv ist. Auf diesem Weg liegt keine eigene virtuelle Maschine.
Genau dieses Design macht den Fehler mechanisch. Wenn der Container ein Paket sendet, führt der Host eine Routenabfrage für das Container-Präfix durch. Welche Route gewinnt, dorthin geht das Paket, und der Container hat dazu keine Meinung.
Was der VPN-Client an diesem Weg ändert
Ein Unternehmensclient installiert oft einen breiten Satz von Routen und einen Filter, der den Zugriff auf das lokale Subnetz verweigert, solange der Tunnel aktiv ist. Die Absicht ist defensiv: Ein kompromittiertes lokales Netz soll eine geschützte Maschine nicht erreichen. Der Nebeneffekt ist, dass die Route des Hosts zum Container-Präfix nicht mehr das lokale NAT-Netz ist.
Stattdessen passt die Abfrage auf den Tunnel, und das Paket wird an das Gateway übergeben, das von dieser Containeradresse noch nie gehört hat. Ping schlägt fehl, die Anwendung läuft in eine Zeitüberschreitung, und der Container wirkt kaputt, während das VPN-Symbol leuchtet. Sehen Sie sich die Tabelle des Hosts im verbundenen Zustand an, dann ist die konkurrierende Route sichtbar.
| Container mode | Outbound path | Typical result behind the VPN |
|---|---|---|
| Windows, default nat | Host routes and translates container traffic | Container prefix follows the tunnel and fails |
| Windows, transparent | Container sits on the physical link | Depends on the local subnet being allowed |
| Linux engine on Docker Desktop | VM egress proxied by a host process | Often keeps working |
Warum sich Linux-Container anders verhalten
Die Linux-Engine führt Container in einer schlanken virtuellen Maschine aus, und ausgehende Verbindungen dieser Maschine werden von einem Proxy auf der Hostseite im Namen des Containers geöffnet. Der Host eröffnet den Socket, daher gilt die VPN-Regel zum Container-Präfix für ihn nicht in gleicher Weise, und die Arbeitslast erreicht das Netz weiterhin.
Dieser Unterschied erklärt auch, warum sich Linux-Rezepte nicht übertragen lassen. Ein Linux-Container, der einen eigenen Tunnel braucht, bekommt ein TUN-Gerät plus die Fähigkeit NET_ADMIN. Windows-Container stellen keine Schnittstelle als Gerät bereit, daher hat dieses Muster auf jener Seite kein Äquivalent.
Beweisen Sie die Route, dann wählen Sie ein Design
Sammeln Sie Belege vom Host, nicht aus dem Container, denn der Host führt die Abfrage aus:
docker network inspect nat --format "{{range .IPAM.Config}}{{.Subnet}}{{end}}"
route print -4
Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like "172.16.*"Führen Sie die Routenausgabe einmal aus, bevor sich das VPN verbindet, und einmal danach. Zeigt das Container-Präfix in der zweiten Ausgabe auf den Tunneladapter, ist die Diagnose vollständig, und ein Neustart der Container hilft nicht.
Die erste Option ist eine Richtlinienentscheidung: Fragen Sie den Netzwerkeigentümer, ob lokaler LAN-Zugriff für dieses Gerät erlaubt werden kann. Mehrere Unternehmensclients bieten das als Einstellung an, doch sie schwächt eine bewusste Grenze. Fordern Sie es als dokumentierte Ausnahme mit Eigentümer und Prüfdatum. Ein Schalter pro Gerät, zu dem niemand zurückkehrt, ist der Weg, auf dem eine defensive Richtlinie still verschwindet.
Wo die Richtlinie bestehen muss, verlagern Sie die Arbeitslast, statt gegen die Route zu kämpfen. Ein transparentes Netz mit ausdrücklichem Subnetz und Gateway setzt Container auf den lokalen Link, eine Linux-Arbeitslast läuft hinter dem VM-Proxy, und eine eigene virtuelle Maschine mit eigenem Client behält ihre eigene Richtlinie. Wählen Sie eine bewusst und testen Sie sie aus dem Container heraus, denn dort entsteht die Anfrage des Nutzers.