Windows konteineriai ir VPN: kodėl vietinis tinklas lūžta
Windows konteineris naudoja pagrindinio kompiuterio maršrutų lentelę, todėl vietinį potinklį blokuojantis VPN pasiima ir konteinerio priešdėlį. Linux režimas pasirenka kitą kelią.
Viename nešiojamajame kompiuteryje, su vienu prijungtu VPN klientu, Linux konteineriai toliau bendrauja tarpusavyje, o Windows konteineriai sustoja. Kintamasis yra ne atvaizdas, o kelias, kuriuo paketai patenka į pagrindinį kompiuterį. Windows konteineriai numatytajame tinkle skolinasi pagrindinio kompiuterio maršrutų lentelę ir vertimą, todėl politika, keičianti pagrindinio kompiuterio maršrutizavimą, keičia ir juos. Patvirtinkite tai maršruto paieška prieš ką nors perinstaliuodami.
Kur Windows konteinerio paketai patenka į pagrindinį kompiuterį
Numatytajame nat tinkle esantis konteineris gauna adresą iš Host Networking Service priešdėlio, dažniausiai kažkur 172.16.0.0/12 viduje, ir pasiekia pagrindinį kompiuterį per virtualų adapterį. Pagrindinis kompiuteris valdo to priešdėlio maršrutą ir verčia srautą link to adapterio, kuris šiuo metu aktyvus. To kelio viduryje nėra atskiros virtualios mašinos.
Būtent ši konstrukcija daro gedimą mechaniniu. Kai konteineris siunčia paketą, pagrindinis kompiuteris atlieka maršruto paiešką konteinerio priešdėliui. Kuris maršrutas laimi, ten paketas ir eina, o konteineris tam neturi nuomonės.
Ką VPN klientas pakeičia tame kelyje
Įmonės klientas dažnai įdiegia platų maršrutų rinkinį ir filtrą, kuris, kol tunelis aktyvus, atsisako prieigos prie vietinio potinklio. Tikslas gynybinis: pažeistas vietinis tinklas neturėtų pasiekti apsaugoto kompiuterio. Šalutinis poveikis tas, kad pagrindinio kompiuterio maršrutas į konteinerio priešdėlį nebėra vietinis NAT tinklas.
Vietoje to paieška atitinka tunelį, o paketas perduodamas šliuzui, kuris niekada negirdėjo apie tą konteinerio adresą. Ping nepavyksta, programa baigia laukti, o konteineris atrodo sugedęs, kol VPN piktograma šviečia. Pažiūrėkite pagrindinio kompiuterio lentelę būdami prisijungę – konkuruojantis maršrutas matomas.
| 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 |
Kodėl Linux konteineriai elgiasi kitaip
Linux variklis vykdo konteinerius lengvoje virtualioje mašinoje, o išeinančias jungtis iš tos mašinos atidaro pagrindinio kompiuterio pusėje esantis tarpininkas konteinerio vardu. Lizdą inicijuoja pagrindinis kompiuteris, todėl VPN taisyklė apie konteinerio priešdėlį jam netaikoma taip pat, ir darbo krūvis toliau pasiekia tinklą.
Šis skirtumas paaiškina ir kodėl Linux receptai nepersikelia. Linux konteineriui, kuriam reikia savo tunelio, suteikiamas TUN įrenginys ir NET_ADMIN galimybė. Windows konteineriai neeksponuoja jokios sąsajos kaip įrenginio, todėl šis modelis toje pusėje atitikmens neturi.
Įrodykite maršrutą, tada pasirinkite konstrukciją
Rinkite įrodymus iš pagrindinio kompiuterio, o ne iš konteinerio, nes paiešką atlieka pagrindinis kompiuteris:
docker network inspect nat --format "{{range .IPAM.Config}}{{.Subnet}}{{end}}"
route print -4
Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like "172.16.*"Paleiskite maršrutų išvestį vieną kartą prieš VPN prisijungiant ir vieną kartą po to. Jei antroje išvestyje konteinerio priešdėlis rodo į tunelio adapterį, diagnozė baigta, o konteinerių paleidimas iš naujo nepadės.
Pirmasis variantas yra politikos sprendimas: paklauskite tinklo savininko, ar šiam įrenginiui galima leisti vietinę LAN prieigą. Keli įmonės klientai tai siūlo kaip nustatymą, bet tai silpnina sąmoningai nustatytą ribą. Prašykite to kaip dokumentuotos išimties su savininku ir peržiūros data. Kiekvieno įrenginio jungiklis, prie kurio niekas negrįžta, yra būdas, kuriuo gynybinė politika tyliai išnyksta.
Ten, kur politika turi išsilaikyti, perkelkite darbo krūvį, o ne kovokite su maršrutu. Skaidrus tinklas su aiškiu potinkliu ir šliuzu padeda konteinerius į vietinę jungtį, Linux darbo krūvis veikia už virtualios mašinos tarpininko, ir atskira virtuali mašina su savo klientu išsaugo savo politiką. Pasirinkite vieną sąmoningai ir išbandykite ją konteinerio viduje, nes būtent ten kyla naudotojo užklausa.