Windows-containrar och VPN: varför lokalt nätverk bryts
En Windows-container använder värdens routingtabell, så en VPN som blockerar det lokala subnätet tar containerprefixet med sig. Linux-läget tar en annan väg.
På en enda laptop, med en enda ansluten VPN-klient, fortsätter Linux-containrar att prata med varandra medan Windows-containrar stannar. Variabeln är inte imagen, utan vägen som paketen tar in i värden. Windows-containrar på standardnätet lånar värdens routingtabell och översättning, så en policy som ändrar värdens routing ändrar också dem. Bekräfta det med en ruteuppslagning innan du installerar om något.
Var en Windows-containers paket kommer in i värden
En container på standardnätet nat får en adress från ett prefix i Host Networking Service, vanligtvis någonstans inom 172.16.0.0/12, och når värden genom en virtuell adapter. Värden äger rutten för det prefixet och översätter trafik mot den adapter som är aktiv. Det finns ingen separat virtuell maskin mitt på den vägen.
Det är den konstruktionen som gör felet mekaniskt. När containern skickar ett paket gör värden en ruteuppslagning för containerprefixet. Den rutt som vinner är dit paketet går, och containern har ingen åsikt om det.
Vad VPN-klienten ändrar på den vägen
En företagsklient installerar ofta en bred uppsättning rutter och ett filter som nekar åtkomst till det lokala subnätet medan tunneln är uppe. Avsikten är defensiv: ett komprometterat lokalt nätverk ska inte nå en skyddad maskin. Bieffekten är att värdens rutt till containerprefixet inte längre är det lokala NAT-nätet.
I stället matchar uppslagningen tunneln och paketet lämnas till gatewayen, som aldrig har hört talas om den containeradressen. Ping misslyckas, programmet får timeout och containern ser trasig ut medan VPN-ikonen lyser. Titta på värdens tabell medan du är ansluten och den konkurrerande rutten syns.
| 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 |
Varför Linux-containrar beter sig annorlunda
Linux-motorn kör containrar inuti en lättvikts virtuell maskin, och utgående anslutningar från den maskinen öppnas av en proxy på värdsidan för containerns räkning. Det är värden som initierar socketen, så VPN:ens regel om containerprefixet gäller inte för den på samma sätt, och arbetsbelastningen fortsätter att nå nätverket.
Den skillnaden förklarar också varför Linux-recept inte kan flyttas över. En Linux-container som behöver sin egen tunnel får en TUN-enhet plus NET_ADMIN-förmågan. Windows-containrar exponerar inget gränssnitt som enhet, så det mönstret har ingen motsvarighet på den sidan.
Bevisa rutten och välj sedan en konstruktion
Samla bevis från värden, inte från containern, eftersom det är värden som gör uppslagningen:
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 ruttutskriften en gång innan VPN ansluter och en gång efter. Om containerprefixet i den andra utskriften pekar på tunneladaptern är diagnosen klar och att starta om containrar hjälper inte.
Det första alternativet är ett policybeslut: fråga nätverkets ägare om lokal LAN-åtkomst kan tillåtas för den här enheten. Flera företagsklienter erbjuder det som en inställning, men det försvagar en medveten gräns. Begär det som ett dokumenterat undantag med ägare och granskningsdatum. En växel per enhet som ingen går tillbaka till är hur en defensiv policy tyst försvinner.
Där policyn måste stå kvar, flytta arbetsbelastningen i stället för att kämpa mot rutten. Ett transparent nätverk med ett uttryckligt subnät och en gateway sätter containrar på den lokala länken, en Linux-arbetsbelastning körs bakom VM-proxyn, och en separat virtuell maskin med sin egen klient behåller sin egen policy. Välj en medvetet och testa den inifrån containern, för det är där användarens begäran uppstår.