Windows-konteneroj kaj VPN: kial loka retado paneas
Windows-kontenero uzas la vojigan tabelon de la gastiganto, do VPN kiu blokas la lokan subreton kunportas ankaŭ la antaŭfiksan prefikson de la kontenero. La Linuxa reĝimo iras alian vojon.
Sur unu tekkomputilo, kun unu konektita VPN-kliento, Linux-konteneroj daŭre interparolas kaj Windows-konteneroj haltas. La bildo ne estas la variablo; la vojo, kiun la pakaĵoj prenas en la gastiganton, estas. Windows-konteneroj en la defaŭlta reto pruntas la vojigan tabelon kaj tradukon de la gastiganto, do politiko, kiu ŝanĝas la vojigon de la gastiganto, ŝanĝas ankaŭ ilin. Konfirmu tion per vojserĉo antaŭ ol reinstali ion ajn.
Kie la pakaĵoj de Windows-kontenero eniras la gastiganton
Kontenero en la defaŭlta nat reto ricevas adreson el prefikso de la servo Host Networking Service, kutime ie ene de 172.16.0.0/12, kaj atingas la gastiganton per virtuala adaptilo. La gastiganto posedas la vojon por tiu prefikso kaj tradukas trafikon al tiu adaptilo, kiu estas aktuala. Ne estas aparta virtuala maŝino meze de tiu vojo.
Ĝuste tiu dezajno faras la fiaskon meĥanika. Kiam la kontenero sendas pakaĵon, la gastiganto faras vojserĉon por la kontenera prefikso. Kiu vojo venkas, tien la pakaĵo iras, kaj la kontenero havas neniun opinion pri tio.
Kion la VPN-kliento ŝanĝas en tiu vojo
Entreprena kliento ofte instalas larĝan aron da vojoj kaj filtrilon, kiu malpermesas aliron al la loka subreto dum la tunelo estas aktiva. La intenco estas defenda: kompromitita loka reto ne devus atingi protektitan maŝinon. La kromefiko estas, ke la vojo de la gastiganto al la kontenera prefikso ne plu estas la loka NAT-reto.
Anstataŭe la serĉo kongruas kun la tunelo kaj la pakaĵo estas transdonita al la pordego, kiu neniam aŭdis pri tiu kontenera adreso. Ping malsukcesas, la aplikaĵo finiĝas pro tempolimo, kaj la kontenero aspektas difektita dum la VPN-ikono brilas. Rigardu la tabelon de la gastiganto dum vi estas konektita, kaj la konkuranta vojo videblas.
| 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 |
Kial Linux-konteneroj kondutas alie
La Linux-motoro funkciigas kontenerojn ene de malpeza virtuala maŝino, kaj elirajn konektojn de tiu maŝino malfermas prokurilo ĉe la gastiganta flanko nome de la kontenero. La gastiganto iniciatas la ingon, do la regulo de la VPN pri la kontenera prefikso ne aplikiĝas al ĝi same, kaj la laborŝarĝo daŭre atingas la reton.
Tiu diferenco ankaŭ klarigas, kial Linux-receptoj ne translokiĝas. Linux-kontenero, kiu bezonas sian propran tunelon, ricevas TUN-aparaton plus la kapablon NET_ADMIN. Windows-konteneroj elmontras neniun interfacon kiel aparaton, do tiu ŝablono havas nenian ekvivalenton ĉe tiu flanko.
Pruvu la vojon, poste elektu dezajnon
Kolektu pruvojn de la gastiganto, ne de la kontenero, ĉar la gastiganto faras la serĉon:
docker network inspect nat --format "{{range .IPAM.Config}}{{.Subnet}}{{end}}"
route print -4
Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like "172.16.*"Rulu la voj-eligan rezulton unufoje antaŭ ol la VPN konektiĝos kaj unufoje poste. Se en la dua eligo la kontenera prefikso montras al la tunela adaptilo, la diagnozo estas kompleta kaj restartigi la kontenerojn ne helpos.
La unua opcio estas politika decido: demandu la retposedanton, ĉu loka LAN-aliro povas esti permesita por ĉi tiu aparato. Pluraj entreprenaj klientoj elmontras tion kiel agordon, sed ĝi malfortigas intencan limon. Petu ĝin kiel dokumentitan escepton kun posedanto kaj revizia dato. Ŝaltilo por unu aparato, al kiu neniu revenas, estas la maniero kiel defenda politiko silente malaperas.
Kie la politiko devas resti, movu la laborŝarĝon anstataŭ batali kontraŭ la vojo. Travidebla reto kun eksplicita subreto kaj pordego metas kontenerojn sur la lokan ligilon, Linux-laborŝarĝo funkcias malantaŭ la prokurilo de la virtuala maŝino, kaj aparta virtuala maŝino kun propra kliento konservas sian propran politikon. Elektu unu intence kaj testu ĝin el la interno de la kontenero, ĉar tie originas la peto de la uzanto.