Kontejnery Windows a VPN: proč místní síť přestane fungovat
Kontejner Windows využívá směrovací tabulku hostitele, takže VPN, která blokuje místní podsíť, si vezme s sebou i prefix kontejneru. Režim Linux jde jinou cestou.
Na jednom notebooku s jedním připojeným klientem VPN pokračují kontejnery Linux ve vzájemné komunikaci a kontejnery Windows se zastaví. Proměnnou není image, ale cesta, kterou pakety vstupují do hostitele. Kontejnery Windows na výchozí síti si půjčují směrovací tabulku a překlad hostitele, takže zásada, která změní směrování hostitele, změní i je. Ověřte to vyhledáním trasy dřív, než cokoli přeinstalujete.
Kudy pakety kontejneru Windows vstupují do hostitele
Kontejner na výchozí síti nat dostane adresu z prefixu služby Host Networking Service, obvykle někde uvnitř 172.16.0.0/12, a dosáhne hostitele přes virtuální adaptér. Hostitel vlastní trasu pro tento prefix a překládá provoz k adaptéru, který je právě aktivní. Uprostřed této cesty není žádný samostatný virtuální stroj.
Právě tento návrh dělá poruchu mechanickou. Když kontejner odešle paket, hostitel provede vyhledání trasy pro prefix kontejneru. Která trasa vyhraje, tam paket jde, a kontejner do toho nemá co mluvit.
Co klient VPN na této cestě mění
Firemní klient často nainstaluje širokou sadu tras a filtr, který po dobu aktivního tunelu zakazuje přístup k místní podsíti. Záměr je obranný: napadená místní síť by se neměla dostat k chráněnému stroji. Vedlejším účinkem je, že trasa hostitele k prefixu kontejneru už není místní síť NAT.
Místo toho se vyhledání shoduje s tunelem a paket se předá bráně, která o této adrese kontejneru nikdy neslyšela. Ping selže, aplikace vyprší a kontejner vypadá rozbitý, zatímco ikona VPN svítí. Podívejte se na tabulku hostitele během připojení a konkurenční trasa je vidět.
| 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 |
Proč se kontejnery Linux chovají jinak
Linuxový engine spouští kontejnery uvnitř odlehčeného virtuálního stroje a odchozí spojení z tohoto stroje otevírá proxy na straně hostitele jménem kontejneru. Socket iniciuje hostitel, takže pravidlo VPN o prefixu kontejneru na něj neplatí stejně a zátěž se nadále dostává do sítě.
Tento rozdíl také vysvětluje, proč se linuxové recepty nepřenášejí. Kontejner Linux, který potřebuje vlastní tunel, dostane zařízení TUN plus schopnost NET_ADMIN. Kontejnery Windows neposkytují žádné rozhraní jako zařízení, takže tento vzor na oné straně nemá ekvivalent.
Dokažte trasu a pak zvolte návrh
Sbírejte důkazy z hostitele, ne z kontejneru, protože vyhledání provádí hostitel:
docker network inspect nat --format "{{range .IPAM.Config}}{{.Subnet}}{{end}}"
route print -4
Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like "172.16.*"Spusťte výstup tras jednou před připojením VPN a jednou potom. Pokud ve druhém výstupu prefix kontejneru ukazuje na adaptér tunelu, diagnóza je hotová a restart kontejnerů nepomůže.
První možnost je rozhodnutí o zásadě: zeptejte se vlastníka sítě, zda lze pro toto zařízení povolit přístup k místní LAN. Několik firemních klientů to nabízí jako nastavení, ale oslabuje to záměrnou hranici. Žádejte to jako zdokumentovanou výjimku s vlastníkem a datem revize. Přepínač pro jednotlivé zařízení, ke kterému se nikdo nevrací, je způsob, jak obranná zásada tiše zmizí.
Tam, kde zásada musí zůstat, přesuňte zátěž místo boje s trasou. Transparentní síť s explicitní podsítí a bránou postaví kontejnery na místní spoj, linuxová zátěž běží za proxy virtuálního stroje a samostatný virtuální stroj s vlastním klientem si zachovává vlastní zásadu. Vyberte jednu záměrně a otestujte ji zevnitř kontejneru, protože právě tam požadavek uživatele vzniká.