Windows kontejneri i VPN: zašto lokalna mreža puca
Windows kontejner koristi hostovu tablicu ruta, pa VPN koji blokira lokalnu podmrežu nosi sa sobom i prefiks kontejnera. Linux način rada ide drugim putem.
Na jednom laptopu, s jednim povezanim VPN klijentom, Linux kontejneri nastavljaju razgovarati jedan s drugim, a Windows kontejneri se zaustavljaju. Varijabla nije slika, nego put kojim paketi ulaze u host. Windows kontejneri na zadanoj mreži posuđuju hostovu tablicu ruta i prevođenje, pa politika koja mijenja usmjeravanje hosta mijenja i njih. Potvrdite to pretragom rute prije nego što bilo što ponovno instalirate.
Gdje paketi Windows kontejnera ulaze u host
Kontejner na zadanoj nat mreži dobija adresu iz prefiksa servisa Host Networking Service, obično negdje unutar 172.16.0.0/12, i dolazi do hosta preko virtualnog adaptera. Host posjeduje rutu za taj prefiks i prevodi saobraćaj prema adapteru koji je trenutno aktivan. U sredini tog puta nema zasebne virtualne mašine.
Taj dizajn je ono što kvar čini mehaničkim. Kada kontejner pošalje paket, host izvodi pretragu rute za prefiks kontejnera. Koja ruta pobijedi, tamo paket ide, a kontejner o tome nema mišljenje.
Šta VPN klijent mijenja na tom putu
Korporativni klijent često instalira širok skup ruta i filter koji zabranjuje pristup lokalnoj podmreži dok je tunel aktivan. Namjera je odbrambena: kompromitovana lokalna mreža ne smije doći do zaštićene mašine. Nuspojava je da hostova ruta do prefiksa kontejnera više nije lokalna NAT mreža.
Umjesto toga pretraga se poklapa s tunelom i paket se predaje mrežnom prolazu koji nikada nije čuo za tu adresu kontejnera. Ping ne prolazi, aplikacija istječe, a kontejner izgleda pokvareno dok VPN ikona svijetli. Pogledajte hostovu tablicu dok ste povezani i konkurentska ruta je vidljiva.
| 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 |
Zašto se Linux kontejneri ponašaju drugačije
Linux mašina pokreće kontejnere unutar lagane virtualne mašine, a odlazne veze s te mašine otvara proxy na strani hosta u ime kontejnera. Host pokreće socket, pa se VPN pravilo o prefiksu kontejnera ne primjenjuje na njega na isti način i radno opterećenje nastavlja dolaziti do mreže.
Ta razlika objašnjava i zašto se Linux recepti ne prenose. Linux kontejneru kojem treba vlastiti tunel daje se TUN uređaj plus mogućnost NET_ADMIN. Windows kontejneri ne izlažu nijedan interfejs kao uređaj, pa taj obrazac nema ekvivalent na toj strani.
Dokažite rutu, pa odaberite dizajn
Prikupljajte dokaze s hosta, ne iz kontejnera, jer pretragu izvodi host:
docker network inspect nat --format "{{range .IPAM.Config}}{{.Subnet}}{{end}}"
route print -4
Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like "172.16.*"Pokrenite izlaz ruta jednom prije nego se VPN poveže i jednom poslije. Ako u drugom izlazu prefiks kontejnera pokazuje na adapter tunela, dijagnoza je završena i ponovno pokretanje kontejnera neće pomoći.
Prva opcija je odluka o politici: pitajte vlasnika mreže može li se lokalni LAN pristup dopustiti za ovaj uređaj. Nekoliko korporativnih klijenata to izlaže kao postavku, ali ona slabi namjernu granicu. Zatražite to kao dokumentovanu iznimku s vlasnikom i datumom pregleda. Prekidač po uređaju koji nitko više ne pregleda način je na koji odbrambena politika tiho nestaje.
Gdje politika mora ostati, premjestite radno opterećenje umjesto da se borite s rutom. Transparentna mreža s eksplicitnom podmrežom i mrežnim prolazom stavlja kontejnere na lokalnu vezu, Linux radno opterećenje radi iza proxyja virtualne mašine, i zasebna virtualna mašina s vlastitim klijentom zadržava vlastitu politiku. Odaberite jednu namjerno i testirajte je iz unutrašnjosti kontejnera, jer tu korisnički zahtjev nastaje.