Kontenery Windows i VPN: dlaczego lokalna sieć się psuje
Kontener Windows korzysta z tablicy routingu hosta, więc VPN blokujący lokalną podsieć zabiera ze sobą również prefiks kontenera. Tryb Linux idzie inną drogą.
Na jednym laptopie, z jednym podłączonym klientem VPN, kontenery Linux nadal rozmawiają ze sobą, a kontenery Windows zatrzymują się. Zmienną nie jest obraz, lecz ścieżka, którą pakiety wchodzą do hosta. Kontenery Windows w sieci domyślnej pożyczają tablicę routingu i translację hosta, więc polityka zmieniająca routing hosta zmienia także je. Potwierdź to wyszukaniem trasy, zanim cokolwiek przeinstalujesz.
Gdzie pakiety kontenera Windows wchodzą do hosta
Kontener w sieci domyślnej nat otrzymuje adres z prefiksu usługi Host Networking Service, zwykle gdzieś w 172.16.0.0/12, i dociera do hosta przez wirtualny adapter. Host posiada trasę dla tego prefiksu i tłumaczy ruch w stronę adaptera, który jest aktualnie aktywny. W środku tej ścieżki nie ma osobnej maszyny wirtualnej.
To właśnie ten projekt czyni awarię mechaniczną. Gdy kontener wysyła pakiet, host wykonuje wyszukiwanie trasy dla prefiksu kontenera. Która trasa wygra, tam trafia pakiet, a kontener nie ma nic do powiedzenia.
Co klient VPN zmienia na tej ścieżce
Klient korporacyjny często instaluje szeroki zestaw tras i filtr, który odmawia dostępu do lokalnej podsieci, dopóki tunel jest aktywny. Zamiar jest obronny: przejęta sieć lokalna nie powinna docierać do chronionej maszyny. Skutkiem ubocznym jest to, że trasa hosta do prefiksu kontenera nie jest już lokalną siecią NAT.
Zamiast tego wyszukiwanie pasuje do tunelu, a pakiet trafia do bramy, która nigdy nie słyszała o tym adresie kontenera. Ping zawodzi, aplikacja kończy się przekroczeniem czasu, a kontener wygląda na zepsuty, podczas gdy ikona VPN świeci. Spójrz na tablicę hosta przy połączeniu, a konkurencyjna trasa jest widoczna.
| 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 |
Dlaczego kontenery Linux zachowują się inaczej
Silnik Linux uruchamia kontenery wewnątrz lekkiej maszyny wirtualnej, a połączenia wychodzące z tej maszyny otwiera proxy po stronie hosta w imieniu kontenera. To host inicjuje gniazdo, więc reguła VPN dotycząca prefiksu kontenera nie stosuje się do niego w ten sam sposób, a obciążenie nadal dociera do sieci.
Ta różnica wyjaśnia też, dlaczego przepisy dla Linux nie przenoszą się dalej. Kontener Linux, który potrzebuje własnego tunelu, dostaje urządzenie TUN oraz zdolność NET_ADMIN. Kontenery Windows nie wystawiają żadnego interfejsu jako urządzenia, więc ten wzorzec nie ma odpowiednika po tamtej stronie.
Udowodnij trasę, potem wybierz projekt
Zbieraj dowody z hosta, nie z kontenera, bo to host wykonuje wyszukiwanie:
docker network inspect nat --format "{{range .IPAM.Config}}{{.Subnet}}{{end}}"
route print -4
Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like "172.16.*"Uruchom wynik tras raz przed połączeniem VPN i raz po nim. Jeśli w drugim wyniku prefiks kontenera wskazuje adapter tunelu, diagnoza jest kompletna i restart kontenerów nie pomoże.
Pierwsza opcja to decyzja polityczna: zapytaj właściciela sieci, czy dostęp do lokalnej sieci LAN można zezwolić dla tego urządzenia. Kilku klientów korporacyjnych udostępnia to jako ustawienie, ale osłabia ono świadomie postawioną granicę. Poproś o to jako udokumentowany wyjątek z właścicielem i datą przeglądu. Przełącznik dla każdego urządzenia, do którego nikt nie wraca, to sposób, w jaki polityka obronna po cichu znika.
Tam, gdzie polityka musi się utrzymać, przenieś obciążenie zamiast walczyć z trasą. Przezroczysta sieć z jawną podsiecią i bramą umieszcza kontenery na łączu lokalnym, obciążenie Linux działa za proxy maszyny wirtualnej, a osobna maszyna wirtualna z własnym klientem zachowuje własną politykę. Wybierz jedną świadomie i przetestuj ją od wewnątrz kontenera, bo tam powstaje żądanie użytkownika.