Windows-containers en VPN: waarom lokaal netwerken breekt
Een Windows-container gebruikt de routetabel van de host, dus een VPN die het lokale subnet blokkeert neemt het containerprefix mee. Linux-modus neemt een andere route.
Op één laptop, met één verbonden VPN-client, blijven Linux-containers met elkaar praten en stoppen Windows-containers. De variabele is niet de image, maar het pad dat de pakketten naar de host nemen. Windows-containers op het standaardnetwerk lenen de routetabel en vertaling van de host, dus een beleid dat de routing van de host verandert, verandert hen ook. Bevestig dat met een routeopzoeking voordat u iets herinstalleert.
Waar de pakketten van een Windows-container de host binnenkomen
Een container op het standaardnetwerk nat krijgt een adres uit een prefix van de Host Networking Service, meestal ergens binnen 172.16.0.0/12, en bereikt de host via een virtuele adapter. De host bezit de route voor dat prefix en vertaalt verkeer naar de adapter die op dat moment actief is. Er zit geen aparte virtuele machine midden in dat pad.
Dat ontwerp maakt de storing mechanisch. Wanneer de container een pakket verstuurt, doet de host een routeopzoeking voor het containerprefix. Welke route wint, daar gaat het pakket heen, en de container heeft daar geen mening over.
Wat de VPN-client aan dat pad verandert
Een bedrijfsclient installeert vaak een brede set routes en een filter dat de toegang tot het lokale subnet weigert zolang de tunnel actief is. De bedoeling is defensief: een gecompromitteerd lokaal netwerk mag een beschermde machine niet bereiken. Het neveneffect is dat de route van de host naar het containerprefix niet langer het lokale NAT-netwerk is.
In plaats daarvan past de opzoeking bij de tunnel en wordt het pakket aan de gateway overhandigd, die nog nooit van dat containeradres heeft gehoord. Ping mislukt, de toepassing loopt in een time-out en de container lijkt stuk terwijl het VPN-pictogram gloeit. Kijk naar de tabel van de host terwijl u verbonden bent en de concurrerende route is zichtbaar.
| 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 |
Waarom Linux-containers zich anders gedragen
De Linux-engine draait containers in een lichte virtuele machine, en uitgaande verbindingen van die machine worden geopend door een proxy aan de hostzijde namens de container. De host start de socket, dus de regel van de VPN over het containerprefix geldt er niet op dezelfde manier voor, en de werkbelasting blijft het netwerk bereiken.
Dat verschil verklaart ook waarom Linux-recepten niet overgaan. Een Linux-container die een eigen tunnel nodig heeft, krijgt een TUN-apparaat plus de NET_ADMIN-mogelijkheid. Windows-containers stellen geen interface als apparaat beschikbaar, dus dat patroon heeft aan die kant geen equivalent.
Bewijs de route en kies dan een ontwerp
Verzamel bewijs van de host, niet uit de container, want de host doet de opzoeking:
docker network inspect nat --format "{{range .IPAM.Config}}{{.Subnet}}{{end}}"
route print -4
Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like "172.16.*"Voer de route-uitvoer één keer uit voordat de VPN verbindt en één keer daarna. Als het containerprefix in de tweede uitvoer naar de tunneladapter wijst, is de diagnose compleet en helpt het herstarten van containers niet.
De eerste optie is een beleidsbeslissing: vraag de netwerkeigenaar of lokale LAN-toegang voor dit apparaat kan worden toegestaan. Verschillende bedrijfsclients bieden dat als instelling aan, maar het verzwakt een bewuste grens. Vraag erom als gedocumenteerde uitzondering met een eigenaar en een herzieningsdatum. Een schakelaar per apparaat waar niemand naar terugkeert, is de manier waarop een defensief beleid stil verdwijnt.
Waar het beleid moet blijven staan, verplaats de werkbelasting in plaats van tegen de route te vechten. Een transparant netwerk met een expliciet subnet en gateway zet containers op de lokale link, een Linux-werkbelasting draait achter de VM-proxy, en een aparte virtuele machine met een eigen client houdt zijn eigen beleid. Kies er bewust één en test het van binnenuit de container, want daar ontstaat de aanvraag van de gebruiker.