Vsebniki Windows in VPN: zakaj se lokalno omrežje zlomi
Vsebnik Windows uporablja usmerjevalno tabelo gostitelja, zato VPN, ki blokira lokalno podomrežje, vzame s seboj tudi predpono vsebnika. Način Linux gre po drugi poti.
Na enem prenosniku, z enim povezanim odjemalcem VPN, vsebniki Linux še naprej govorijo med seboj, vsebniki Windows pa se ustavijo. Spremenljivka ni slika, ampak pot, po kateri paketi vstopajo v gostitelja. Vsebniki Windows v privzetem omrežju si izposodijo usmerjevalno tabelo in prevajanje gostitelja, zato politika, ki spremeni usmerjanje gostitelja, spremeni tudi njih. Potrdite to z iskanjem poti, preden karkoli znova namestite.
Kje paketi vsebnika Windows vstopijo v gostitelja
Vsebnik v privzetem omrežju nat dobi naslov iz predpone storitve Host Networking Service, običajno nekje znotraj 172.16.0.0/12, in doseže gostitelja prek navideznega vmesnika. Gostitelj ima v lasti pot za to predpono in pretvarja promet proti vmesniku, ki je trenutno dejaven. Sredi te poti ni ločenega navideznega stroja.
Prav ta zasnova naredi okvaro mehansko. Ko vsebnik pošlje paket, gostitelj izvede iskanje poti za predpono vsebnika. Katera pot zmaga, tja gre paket, in vsebnik o tem nima mnenja.
Kaj odjemalec VPN spremeni na tej poti
Podjetniški odjemalec pogosto namesti širok nabor poti in filter, ki med delovanjem tunela zavrača dostop do lokalnega podomrežja. Namen je obramben: ogroženo lokalno omrežje ne sme doseči zaščitenega stroja. Stranski učinek je, da pot gostitelja do predpone vsebnika ni več lokalno omrežje NAT.
Namesto tega se iskanje ujema s tunelom in paket se preda prehodu, ki o tem naslovu vsebnika ni nikoli slišal. Ping spodleti, aplikacija poteče in vsebnik je videti pokvarjen, medtem ko ikona VPN sveti. Poglejte tabelo gostitelja, ko ste povezani, in konkurenčna pot je vidna.
| 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 |
Zakaj se vsebniki Linux obnašajo drugače
Pogon Linux izvaja vsebnike znotraj lahkega navideznega stroja, odhodne povezave iz tega stroja pa odpre posrednik na strani gostitelja v imenu vsebnika. Vtičnico začne gostitelj, zato pravilo VPN o predponi vsebnika zanj ne velja na enak način, in delovna obremenitev še naprej dosega omrežje.
Ta razlika pojasnjuje tudi, zakaj se recepti Linux ne prenesejo. Vsebnik Linux, ki potrebuje svoj tunel, dobi napravo TUN in zmožnost NET_ADMIN. Vsebniki Windows ne izpostavijo nobenega vmesnika kot naprave, zato ta vzorec na tisti strani nima enakovredne rešitve.
Dokažite pot in nato izberite zasnovo
Zbirajte dokaze z gostitelja, ne iz vsebnika, ker iskanje izvede gostitelj:
docker network inspect nat --format "{{range .IPAM.Config}}{{.Subnet}}{{end}}"
route print -4
Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like "172.16.*"Zaženite izpis poti enkrat pred povezavo VPN in enkrat po njej. Če v drugem izpisu predpona vsebnika kaže na vmesnik tunela, je diagnoza popolna in ponovni zagon vsebnikov ne bo pomagal.
Prva možnost je odločitev o politiki: vprašajte lastnika omrežja, ali je za to napravo mogoče dovoliti dostop do lokalnega omrežja LAN. Več podjetniških odjemalcev to ponuja kot nastavitev, vendar to oslabi namerno mejo. Zahtevajte to kot dokumentirano izjemo z lastnikom in datumom pregleda. Stikalo za posamezno napravo, h kateremu se nihče ne vrne, je način, kako obrambna politika tiho izgine.
Kjer mora politika ostati, premaknite delovno obremenitev namesto boja s potjo. Pregledno omrežje z izrecnim podomrežjem in prehodom postavi vsebnike na lokalno povezavo, delovna obremenitev Linux teče za posrednikom navideznega stroja, in ločen navidezni stroj z lastnim odjemalcem ohrani svojo politiko. Izberite enega namerno in ga preizkusite znotraj vsebnika, ker tam nastane zahteva uporabnika.