Windows-konténerek és VPN: miért szakad meg a helyi hálózat
A Windows-konténer a gazdagép útvonaltábláját használja, ezért a helyi alhálózatot blokkoló VPN magával viszi a konténer előtagját is. A Linux mód más utat választ.
Egyetlen laptopon, egy csatlakoztatott VPN-klienssel a Linux-konténerek tovább beszélnek egymással, a Windows-konténerek pedig leállnak. A változó nem az image, hanem az az útvonal, amelyen a csomagok a gazdagépbe jutnak. Az alapértelmezett hálózaton lévő Windows-konténerek kölcsönveszik a gazdagép útvonaltábláját és fordítását, ezért a gazdagép útválasztását megváltoztató házirend őket is megváltoztatja. Erősítse meg ezt egy útvonalkereséssel, mielőtt bármit újratelepítene.
Hol lépnek be a Windows-konténer csomagjai a gazdagépbe
Az alapértelmezett nat hálózaton lévő konténer címet kap a Host Networking Service egyik előtagjából, általában valahol a 172.16.0.0/12 tartományon belül, és virtuális adapteren keresztül éri el a gazdagépet. A gazdagép birtokolja az adott előtag útvonalát, és a forgalmat az éppen aktív adapter felé fordítja. Ennek az útvonalnak a közepén nincs külön virtuális gép.
Ez a felépítés teszi mechanikussá a hibát. Amikor a konténer csomagot küld, a gazdagép útvonalkeresést végez a konténer előtagjára. Amelyik útvonal nyer, oda megy a csomag, és a konténernek ehhez nincs véleménye.
Mit változtat a VPN-kliens ezen az útvonalon
A vállalati kliens gyakran útvonalak széles készletét és egy szűrőt telepít, amely az alagút fennállása alatt megtagadja a helyi alhálózathoz való hozzáférést. A szándék védelmi jellegű: egy kompromittált helyi hálózat nem érhet el védett gépet. A mellékhatás az, hogy a gazdagép útvonala a konténer előtagjához már nem a helyi NAT-hálózat.
Ehelyett a keresés az alagútra illeszkedik, és a csomag átadódik az átjárónak, amely soha nem hallott erről a konténer-címről. A Ping meghiúsul, az alkalmazás időtúllépésbe fut, és a konténer töröttnek látszik, miközben a VPN ikon világít. Nézze meg a gazdagép táblázatát csatlakozva, és a versengő útvonal látható.
| 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 |
Miért viselkednek másként a Linux-konténerek
A Linux motor konténereket futtat egy könnyű virtuális gépen belül, és az abból a gépből kimenő kapcsolatokat a gazdagép oldali proxy nyitja meg a konténer nevében. A gazdagép indítja a socketet, ezért a VPN-nek a konténer előtagjára vonatkozó szabálya nem ugyanúgy érvényes rá, és a munkaterhelés továbbra is eléri a hálózatot.
Ez a különbség azt is megmagyarázza, miért nem ültethetők át a Linux-receptek. Az olyan Linux-konténer, amelynek saját alagútra van szüksége, TUN-eszközt és NET_ADMIN képességet kap. A Windows-konténerek nem tárnak fel egyetlen interfészt sem eszközként, ezért ennek a mintának nincs megfelelője azon az oldalon.
Bizonyítsa az útvonalat, majd válasszon felépítést
A bizonyítékokat a gazdagépről gyűjtse, ne a konténerből, mert a keresést a gazdagép végzi:
docker network inspect nat --format "{{range .IPAM.Config}}{{.Subnet}}{{end}}"
route print -4
Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like "172.16.*"Futtassa az útvonalak kimenetét egyszer, mielőtt a VPN csatlakozik, és egyszer utána. Ha a második kimenetben a konténer előtagja az alagút adapterére mutat, a diagnózis teljes, és a konténerek újraindítása nem segít.
Az első lehetőség házirend-döntés: kérdezze meg a hálózat tulajdonosát, engedélyezhető-e a helyi LAN-hozzáférés ehhez az eszközhöz. Több vállalati kliens beállításként kínálja, de ez gyengít egy szándékos határt. Kérje dokumentált kivételként, tulajdonossal és felülvizsgálati dátummal. Az eszközönkénti kapcsoló, amelyhez senki nem tér vissza, az a mód, ahogy egy védelmi házirend csendben eltűnik.
Ahol a házirendnek fenn kell maradnia, helyezze át a munkaterhelést, ahelyett hogy az útvonallal harcolna. Egy kifejezett alhálózatú és átjárójú átlátszó hálózat a helyi kapcsolatra teszi a konténereket, egy Linux-munkaterhelés a virtuális gép proxyja mögött fut, és egy külön virtuális gép saját klienssel megtartja a saját házirendjét. Válasszon egyet szándékosan, és tesztelje a konténer belsejéből, mert a felhasználó kérése ott keletkezik.