Windowsi konteinerid ja VPN: miks kohalik võrk katkeb
Windowsi konteiner kasutab hosti marsruutimistabelit, seega VPN, mis blokeerib kohaliku alamvõrgu, võtab konteineri prefiksi endaga kaasa. Linuxi režiim läheb teist teed.
Ühel sülearvutil, ühe ühendatud VPN-kliendiga, jätkavad Linuxi konteinerid omavahelist suhtlust ja Windowsi konteinerid lakkavad töötamast. Muutuja ei ole pilt, vaid tee, mida pidi paketid hosti jõuavad. Windowsi konteinerid vaikimisi võrgus laenavad hosti marsruutimistabelit ja tõlget, seega hosti marsruutimist muutev poliitika muudab ka neid. Kinnitage seda marsruudiotsinguga enne, kui midagi uuesti paigaldate.
Kuhu Windowsi konteineri paketid hosti sisenevad
Vaikimisi nat võrgus olev konteiner saab aadressi Host Networking Service'i prefiksist, tavaliselt kuskil 172.16.0.0/12 sees, ja jõuab hostini virtuaaladapteri kaudu. Host omab selle prefiksi marsruuti ja tõlgib liiklust sinna adapterisse, mis parasjagu aktiivne on. Selle tee keskel ei ole eraldi virtuaalmasinat.
Just see disain teebki rikke mehaaniliseks. Kui konteiner saadab paketi, teeb host konteineri prefiksi jaoks marsruudiotsingu. Milline marsruut võidab, sinna pakett läheb, ja konteineril ei ole selle kohta arvamust.
Mida VPN-klient sellel teel muudab
Ettevõtte klient paigaldab sageli laia marsruudikomplekti ja filtri, mis keelab tunnelil olles juurdepääsu kohalikule alamvõrgule. Kavatsus on kaitseline: rikutud kohalik võrk ei tohiks jõuda kaitstud masinani. Kõrvalmõju on see, et hosti marsruut konteineri prefiksini ei ole enam kohalik NAT-võrk.
Selle asemel sobib otsing tunneliga ja pakett antakse üle lüüsile, kes ei ole sellest konteineri aadressist kunagi kuulnud. Ping ebaõnnestub, rakendus jookseb ajast välja ja konteiner näeb katkine välja, samal ajal kui VPN-i ikoon hõõgub. Vaadake hosti tabelit ühendatud olekus ja konkureeriv marsruut on nähtav.
| 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 |
Miks Linuxi konteinerid käituvad teisiti
Linuxi mootor jooksutab konteinereid kerges virtuaalmasinas ja selle masina väljuvad ühendused avab hostipoolne puhverserver konteineri nimel. Socketi algatab host, seega VPN-i reegel konteineri prefiksi kohta ei kehti selle kohta samamoodi ja töökoormus jõuab võrku edasi.
See erinevus selgitab ka, miks Linuxi retseptid ei kandu üle. Linuxi konteiner, mis vajab oma tunnelit, saab TUN-seadme ja võimekuse NET_ADMIN. Windowsi konteinerid ei eksponeeri ühtegi liidest seadmena, seega sellel mustril ei ole sellel poolel vasteid.
Tõestage marsruut ja valige siis disain
Koguge tõendeid hostist, mitte konteinerist, sest otsingu teeb host:
docker network inspect nat --format "{{range .IPAM.Config}}{{.Subnet}}{{end}}"
route print -4
Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like "172.16.*"Käivitage marsruudiväljund üks kord enne VPN-i ühendumist ja üks kord pärast. Kui teises väljundis osutab konteineri prefiks tunneladapterile, on diagnoos täielik ja konteinerite taaskäivitamine ei aita.
Esimene valik on poliitika otsus: küsige võrguomanikult, kas selle seadme jaoks tohib kohalikku LAN-juurdepääsu lubada. Mitmed ettevõtte kliendid pakuvad seda seadistusena, kuid see nõrgendab tahtlikku piiri. Küsige seda dokumenteeritud erandina, millel on omanik ja ülevaatamise kuupäev. Seadmepõhine lüliti, mille juurde keegi ei naase, on viis, kuidas kaitseline poliitika vaikselt kaob.
Kus poliitika peab püsima, liigutage töökoormus selle asemel, et marsruudiga võidelda. Selge alamvõrgu ja lüüsiga läbipaistev võrk paneb konteinerid kohalikule lingile, Linuxi töökoormus jookseb virtuaalmasina puhverserveri taga ja eraldi virtuaalmasin oma kliendiga hoiab oma poliitikat. Valige üks teadlikult ja testige seda konteineri seest, sest seal tekib kasutaja päring.