Windows-containere og VPN: hvorfor lokalt netværk bryder sammen
En Windows-container bruger værtens rutetabel, så en VPN, der blokerer det lokale subnet, tager containerpræfikset med sig. Linux-tilstand går en anden vej.
På én bærbar computer, med én VPN-klient forbundet, bliver Linux-containere ved med at tale sammen, mens Windows-containere stopper. Det er ikke imaget, der er variablen; det er den vej, pakkerne tager ind i værten. Windows-containere på standardnetværket låner værtens rutetabel og oversættelse, så en politik, der ændrer værtens routing, ændrer dem også. Bekræft det med et ruteopslag, før du geninstallerer noget.
Hvor en Windows-containers pakker kommer ind i værten
En container på standardnetværket nat får en adresse fra et præfiks i Host Networking Service, normalt et sted inden for 172.16.0.0/12, og når værten gennem en virtuel adapter. Værten ejer ruten for det præfiks og oversætter trafik mod den adapter, der er aktuel. Der er ingen separat virtuel maskine midt på den vej.
Det design er det, der gør fejlen mekanisk. Når containeren sender en pakke, laver værten et ruteopslag for containerpræfikset. Den rute, der vinder, er der, pakken havner, og containeren har ingen holdning til det.
Hvad VPN-klienten ændrer ved den vej
En virksomhedsklient installerer ofte et bredt sæt ruter og et filter, der nægter adgang til det lokale subnet, mens tunnelen er oppe. Hensigten er defensiv: et kompromitteret lokalt netværk bør ikke nå en beskyttet maskine. Bivirkningen er, at værtens rute til containerpræfikset ikke længere er det lokale NAT-netværk.
I stedet matcher opslaget tunnelen, og pakken overdrages til gatewayen, som aldrig har hørt om den containeradresse. Ping fejler, applikationen løber tør for tid, og containeren ser ødelagt ud, mens VPN-ikonet lyser. Kig på værtens tabel, mens du er forbundet, så er den konkurrerende rute synlig.
| 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 |
Hvorfor Linux-containere opfører sig anderledes
Linux-motoren kører containere inde i en let virtuel maskine, og udgående forbindelser fra den maskine åbnes af en proxy på værtssiden på containerens vegne. Værten starter socketten, så VPN'ens regel om containerpræfikset gælder ikke for den på samme måde, og arbejdsbyrden fortsætter med at nå netværket.
Den forskel forklarer også, hvorfor Linux-opskrifter ikke kan overføres. En Linux-container, der har brug for sin egen tunnel, får en TUN-enhed plus NET_ADMIN-evnen. Windows-containere eksponerer ingen grænseflade som en enhed, så det mønster har ingen ækvivalent på den side.
Bevis ruten, og vælg så et design
Indsaml beviser fra værten, ikke fra containeren, fordi det er værten, der laver opslaget:
docker network inspect nat --format "{{range .IPAM.Config}}{{.Subnet}}{{end}}"
route print -4
Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like "172.16.*"Kør ruteoutputtet én gang, før VPN'en forbinder, og én gang efter. Hvis containerpræfikset i det andet output peger på tunneladapteren, er diagnosen komplet, og genstart af containere vil ikke hjælpe.
Den første mulighed er en politisk beslutning: spørg netværksejeren, om lokal LAN-adgang kan tillades for denne enhed. Flere virksomhedsklienter udstiller det som en indstilling, men den svækker en bevidst grænse. Bed om det som en dokumenteret undtagelse med en ejer og en revisionsdato. En kontakt per enhed, som ingen vender tilbage til, er måden, hvorpå en defensiv politik stille forsvinder.
Hvor politikken skal stå, skal du flytte arbejdsbyrden i stedet for at kæmpe mod ruten. Et gennemsigtigt netværk med et eksplicit subnet og en gateway sætter containere på det lokale link, en Linux-arbejdsbyrde kører bag VM-proxyen, og en separat virtuel maskine med sin egen klient beholder sin egen politik. Vælg én bevidst, og test den indefra containeren, fordi det er der, brugerens anmodning opstår.