Na jednom notebooku s jedným pripojeným klientom VPN pokračujú kontajnery Linux vo vzájomnej komunikácii a kontajnery Windows sa zastavia. Premennou nie je obraz, ale cesta, ktorou pakety vstupujú do hostiteľa. Kontajnery Windows na predvolenej sieti si požičiavajú smerovaciu tabuľku a preklad hostiteľa, takže zásada, ktorá zmení smerovanie hostiteľa, zmení aj ich. Overte to vyhľadaním trasy skôr, než čokoľvek preinštalujete.

Kadiaľ pakety kontajnera Windows vstupujú do hostiteľa

Kontajner na predvolenej sieti nat dostane adresu z prefixu služby Host Networking Service, zvyčajne niekde v 172.16.0.0/12, a dosiahne hostiteľa cez virtuálny adaptér. Hostiteľ vlastní trasu pre tento prefix a prekladá prevádzku k adaptéru, ktorý je práve aktívny. V strede tejto cesty nie je žiadny samostatný virtuálny stroj.

Práve tento návrh robí poruchu mechanickou. Keď kontajner odošle paket, hostiteľ vykoná vyhľadanie trasy pre prefix kontajnera. Ktorá trasa zvíťazí, tam paket ide, a kontajner do toho nemá čo hovoriť.

Čo klient VPN na tejto ceste mení

Firemný klient často nainštaluje širokú sadu trás a filter, ktorý počas aktívneho tunela zakazuje prístup k miestnej podsieti. Zámer je obranný: napadnutá miestna sieť by sa nemala dostať k chránenému stroju. Vedľajším účinkom je, že trasa hostiteľa k prefixu kontajnera už nie je miestna sieť NAT.

Namiesto toho sa vyhľadanie zhoduje s tunelom a paket sa odovzdá bráne, ktorá o tejto adrese kontajnera nikdy nepočula. Ping zlyhá, aplikácia vyprší a kontajner vyzerá pokazený, zatiaľ čo ikona VPN svieti. Pozrite sa na tabuľku hostiteľa počas pripojenia a konkurenčná trasa je viditeľná.

Container modeOutbound pathTypical result behind the VPN
Windows, default natHost routes and translates container trafficContainer prefix follows the tunnel and fails
Windows, transparentContainer sits on the physical linkDepends on the local subnet being allowed
Linux engine on Docker DesktopVM egress proxied by a host processOften keeps working

Prečo sa kontajnery Linux správajú inak

Linuxový engine spúšťa kontajnery vnútri odľahčeného virtuálneho stroja a odchádzajúce spojenia z tohto stroja otvára proxy na strane hostiteľa v mene kontajnera. Socket iniciuje hostiteľ, takže pravidlo VPN o prefixe kontajnera naň neplatí rovnako a záťaž sa naďalej dostáva do siete.

Tento rozdiel tiež vysvetľuje, prečo sa linuxové recepty neprenášajú. Kontajner Linux, ktorý potrebuje vlastný tunel, dostane zariadenie TUN plus schopnosť NET_ADMIN. Kontajnery Windows neposkytujú žiadne rozhranie ako zariadenie, takže tento vzor na tej strane nemá ekvivalent.

Dokážte trasu a potom zvoľte návrh

Zbierajte dôkazy z hostiteľa, nie z kontajnera, pretože vyhľadanie vykonáva hostiteľ:

docker network inspect nat --format "{{range .IPAM.Config}}{{.Subnet}}{{end}}"
route print -4
Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like "172.16.*"

Spustite výstup trás raz pred pripojením VPN a raz potom. Ak v druhom výstupe prefix kontajnera ukazuje na adaptér tunela, diagnóza je hotová a reštart kontajnerov nepomôže.

Prvá možnosť je rozhodnutie o zásade: opýtajte sa vlastníka siete, či možno pre toto zariadenie povoliť prístup k miestnej LAN. Niekoľko firemných klientov to ponúka ako nastavenie, ale oslabuje to zámernú hranicu. Žiadajte to ako zdokumentovanú výnimku s vlastníkom a dátumom revízie. Prepínač pre jednotlivé zariadenie, ku ktorému sa nikto nevracia, je spôsob, akým obranná zásada ticho zmizne.

Tam, kde zásada musí zostať, presuňte záťaž namiesto boja s trasou. Transparentná sieť s explicitnou podsietou a bránou postaví kontajnery na miestne spojenie, linuxová záťaž beží za proxy virtuálneho stroja a samostatný virtuálny stroj s vlastným klientom si zachováva vlastnú zásadu. Vyberte jednu zámerne a otestujte ju zvnútra kontajnera, pretože práve tam požiadavka používateľa vzniká.

Súvisiace články