Windows-containere og VPN: hvorfor lokalt nettverk bryter sammen
En Windows-container bruker vertens rutetabell, så en VPN som blokkerer det lokale subnettet tar containerprefikset med seg. Linux-modus går en annen vei.
På én bærbar PC, med én tilkoblet VPN-klient, fortsetter Linux-containere å snakke sammen mens Windows-containere stopper. Variabelen er ikke imaget, men veien pakkene tar inn i verten. Windows-containere på standardnettet låner vertens rutetabell og oversettelse, så en policy som endrer vertens ruting endrer dem også. Bekreft det med et ruteoppslag før du reinstalerer noe.
Hvor pakkene til en Windows-container kommer inn i verten
En container på standardnettet nat får en adresse fra et prefiks i Host Networking Service, vanligvis et sted innenfor 172.16.0.0/12, og når verten gjennom en virtuell adapter. Verten eier ruten for dette prefikset og oversetter trafikk mot den adapteren som er aktiv. Det er ingen egen virtuell maskin midt i den veien.
Det er denne utformingen som gjør feilen mekanisk. Når containeren sender en pakke, gjør verten et ruteoppslag for containerprefikset. Den ruten som vinner, er der pakken går, og containeren har ingen mening om det.
Hva VPN-klienten endrer på den veien
En bedriftsklient installerer ofte et bredt sett med ruter og et filter som nekter tilgang til det lokale subnettet mens tunnelen er oppe. Hensikten er defensiv: et kompromittert lokalt nettverk skal ikke nå en beskyttet maskin. Bivirkningen er at vertens rute til containerprefikset ikke lenger er det lokale NAT-nettet.
I stedet treffer oppslaget tunnelen, og pakken overleveres til gatewayen, som aldri har hørt om den containeradressen. Ping feiler, applikasjonen går ut på tid, og containeren ser ødelagt ut mens VPN-ikonet lyser. Se på vertens tabell mens du er tilkoblet, så er den konkurrerende ruten 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 oppfører seg annerledes
Linux-motoren kjører containere inne i en lett virtuell maskin, og utgående forbindelser fra den maskinen åpnes av en proxy på vertssiden på containerens vegne. Verten starter socketen, så VPN-ens regel om containerprefikset gjelder ikke for den på samme måte, og arbeidsbelastningen fortsetter å nå nettet.
Den forskjellen forklarer også hvorfor Linux-oppskrifter ikke kan overføres. En Linux-container som trenger sin egen tunnel, får en TUN-enhet pluss NET_ADMIN-evnen. Windows-containere eksponerer ingen grensesnitt som enhet, så det mønsteret har ingen ekvivalent på den siden.
Bevis ruten, og velg deretter en utforming
Samle bevis fra verten, ikke fra containeren, fordi det er verten som gjør oppslaget:
docker network inspect nat --format "{{range .IPAM.Config}}{{.Subnet}}{{end}}"
route print -4
Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like "172.16.*"Kjør ruteutskriften én gang før VPN-en kobler til og én gang etterpå. Hvis containerprefikset i den andre utskriften peker på tunneladapteren, er diagnosen komplett, og omstart av containere vil ikke hjelpe.
Det første alternativet er en policybeslutning: spør nettverkseieren om lokal LAN-tilgang kan tillates for denne enheten. Flere bedriftsklienter tilbyr det som en innstilling, men det svekker en bevisst grense. Be om det som et dokumentert unntak med eier og revisjonsdato. En bryter per enhet som ingen går tilbake til, er måten en defensiv policy stille forsvinner på.
Der policyen må stå, flytt arbeidsbelastningen i stedet for å kjempe mot ruten. Et gjennomsiktig nettverk med eksplisitt subnett og gateway setter containere på den lokale lenken, en Linux-arbeidsbelastning kjører bak VM-proxyen, og en egen virtuell maskin med sin egen klient beholder sin egen policy. Velg én bevisst, og test den fra innsiden av containeren, fordi det er der brukerens forespørsel oppstår.