Mga container ng Windows at VPN: bakit nasisira ang lokal na networking
Gumagamit ang container ng Windows ng routing table ng host, kaya dinadala ng VPN na humaharang sa lokal na subnet ang prefix ng container. Iba ang landas ng Linux mode.
Sa isang laptop, na may isang konektadong VPN client, patuloy na nag-uusap ang mga container ng Linux habang humihinto ang mga container ng Windows. Ang variable ay hindi ang image kundi ang landas na tinatahak ng mga packet papasok sa host. Humihiram ang mga container ng Windows sa default na network ng routing table at pagsasalin ng host, kaya binabago rin sila ng patakarang nagbabago sa routing ng host. Kumpirmahin iyon sa pamamagitan ng paghahanap ng ruta bago mag-install muli ng kahit ano.
Saan pumapasok ang mga packet ng container ng Windows sa host
Ang container sa default na network nat ay nakakakuha ng address mula sa prefix ng serbisyong Host Networking Service, karaniwang sa isang lugar sa loob ng 172.16.0.0/12, at naaabot ang host sa pamamagitan ng virtual adapter. Pag-aari ng host ang ruta para sa prefix na iyon at isinasalin ang trapiko patungo sa adapter na aktibo sa sandaling iyon. Walang hiwalay na virtual machine sa gitna ng landas na iyon.
Ang disenyong ito ang gumagawa ng pagkasira na mekanikal. Kapag nagpadala ang container ng packet, gumagawa ang host ng paghahanap ng ruta para sa prefix ng container. Kung aling ruta ang manalo, doon pupunta ang packet, at walang opinyon ang container tungkol doon.
Ano ang binabago ng VPN client sa landas na iyon
Ang corporate client ay madalas na nag-i-install ng malawak na hanay ng mga ruta at isang filter na tumatanggi sa pag-access sa lokal na subnet habang aktibo ang tunnel. Ang layunin ay pagtatanggol: hindi dapat makarating ang kompromisong lokal na network sa protektadong makina. Ang side effect ay ang ruta ng host patungo sa prefix ng container ay hindi na ang lokal na NAT network.
Sa halip, tumutugma ang paghahanap sa tunnel at ang packet ay ibinibigay sa gateway, na hindi kailanman nakarinig tungkol sa address ng container na iyon. Nabibigo ang Ping, nauubos ang oras ng application, at mukhang sira ang container habang nagniningning ang icon ng VPN. Tingnan ang table ng host habang konektado at makikita ang katunggaling ruta.
| 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 |
Bakit iba ang kilos ng mga container ng Linux
Pinapatakbo ng Linux engine ang mga container sa loob ng magaan na virtual machine, at ang mga palabas na koneksyon mula sa machine na iyon ay binubuksan ng proxy sa gilid ng host sa ngalan ng container. Ang host ang nagpapasimula ng socket, kaya ang patakaran ng VPN tungkol sa prefix ng container ay hindi nalalapat dito sa parehong paraan, at patuloy na naaabot ng workload ang network.
Ipinapaliwanag din ng pagkakaibang iyon kung bakit hindi naililipat ang mga recipe ng Linux. Ang container ng Linux na nangangailangan ng sariling tunnel ay binibigyan ng TUN device kasama ang kakayahang NET_ADMIN. Hindi inilalantad ng mga container ng Windows ang anumang interface bilang device, kaya walang katumbas ang pattern na iyon sa ganoong panig.
Patunayan ang ruta, pagkatapos pumili ng disenyo
Mangolekta ng ebidensya mula sa host, hindi mula sa container, dahil ang host ang gumagawa ng paghahanap:
docker network inspect nat --format "{{range .IPAM.Config}}{{.Subnet}}{{end}}"
route print -4
Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like "172.16.*"Patakbuhin ang output ng ruta isang beses bago kumonekta ang VPN at isang beses pagkatapos. Kung sa ikalawang output ay itinuturo ng prefix ng container ang adapter ng tunnel, kumpleto na ang diagnosis at hindi makakatulong ang pag-restart ng mga container.
Ang unang opsyon ay desisyon sa patakaran: tanungin ang may-ari ng network kung maaaring payagan ang lokal na LAN access para sa device na ito. Ipinapakita ito ng ilang corporate client bilang setting, ngunit pinapahina nito ang sadyang hangganan. Hilingin ito bilang dokumentadong pagbubukod na may may-ari at petsa ng pagsusuri. Ang toggle sa bawat device na walang bumabalik ay ang paraan kung paano tahimik na nawawala ang isang defensive na patakaran.
Kung saan dapat manatili ang patakaran, ilipat ang workload sa halip na labanan ang ruta. Ang transparent na network na may malinaw na subnet at gateway ay naglalagay ng mga container sa lokal na link, tumatakbo ang Linux workload sa likod ng proxy ng virtual machine, at isang hiwalay na virtual machine na may sariling client pinapanatili ang sariling patakaran. Pumili ng isa nang sadyang at subukan ito mula sa loob ng container, dahil doon nagmumula ang kahilingan ng user.