Windows контейнер ба VPN: локал сүлжээ яагаад тасардаг вэ
Windows контейнер хостын маршрутын хүснэгтийг ашигладаг тул локал дэд сүлжээг хаадаг VPN контейнерын префиксыг хамт авч явдаг. Linux горим өөр замаар явна.
Нэг зөөврийн компьютер дээр нэг VPN клиент холбогдсон үед Linux контейнерууд хоорондоо ярилсаар байхад Windows контейнерууд зогсдог. Хувьсагч нь дүрс биш, пакетууд хост руу орох зам юм. Өгөгдмөл сүлжээний Windows контейнерууд хостын маршрутын хүснэгт, хөрвүүлэлтийг зээлдэг тул хостын маршрутчлалыг өөрчилдөг бодлого тэднийг ч өөрчилдөг. Ямар нэг зүйлийг дахин суулгахын өмнө үүнийг маршрут хайлтаар баталгаажуулаарай.
Windows контейнерын пакетууд хост руу хаана ордог
Өгөгдмөл nat сүлжээний контейнер Host Networking Service-ийн префиксээс хаяг авдаг, ихэвчлэн 172.16.0.0/12-ийн дотор хаа нэгтээ, виртуал адаптераар дамжин хостод хүрдэг. Хост тухайн префиксын маршрутыг эзэмшиж, одоо идэвхтэй байгаа адаптер руу урсгалыг хөрвүүлдэг. Тухайн замын голд тусдаа виртуал машин байхгүй.
Энэ загвар нь алдааг механик болгодог. Контейнер пакет илгээх үед хост контейнерын префиксын маршрут хайлт хийдэг. Аль маршрут ялснаар пакет тэнд очно, контейнерт үүнд санал байхгүй.
VPN клиент тухайн зам дээр юу өөрчилдөг
Корпорацийн клиент ихэвчлэн маршрутын өргөн багц, туннель идэвхтэй үед локал дэд сүлжээнд хандахыг хориглодог шүүлтүүр суулгадаг. Зорилго нь хамгаалалт: эвдэрсэн локал сүлжээ хамгаалагдсан машин руу хүрэх ёсгүй. Гаж нөлөө нь хостын контейнерын префикс хүртэлх маршрут цаашид локал NAT сүлжээ биш.
Үүний оронд хайлт туннельтэй таарч, пакет тухайн контейнерын хаягийг хэзээ ч сонсоогүй гарц руу шилждэг. Ping бүтэлгүйтэж, програмын хугацаа дуусч, VPN дүрс гялалзах үед контейнер эвдэрсэн мэт харагдана. Холбогдсон үед хостын хүснэгтийг хараарай, өрсөлдөгч маршрут харагдана.
| 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 |
Linux контейнерууд яагаад өөрөөр ажилладаг
Linux хөдөлгүүр контейнеруудыг хөнгөн виртуал машины дотор ажиллуулдаг бөгөөд тухайн машинаас гарах холболтыг контейнерын өмнөөс хост талын прокси нээдэг. Сокетыг хост эхлүүлдэг тул контейнерын префиксын тухай VPN дүрэм түүнд мөн адил үйлчлэхгүй бөгөөд ажлын ачаалал сүлжээнд хүрсээр байна.
Энэ ялгаа нь Linux жорынгууд яагаад шилждэггүйг ч тайлбарладаг. Өөрийн туннель хэрэгтэй Linux контейнерт TUN төхөөрөмж ба NET_ADMIN боломжийг өгдөг. Windows контейнерууд ямар ч интерфейсийг төхөөрөмж болгон ил гаргадаггүй тул энэ загварын тэр талд дүйцэх зүйл байхгүй.
Маршрутыг батал, дараа нь загвар сонго
Нотолгоог контейнерээс биш хостноос цуглуулаарай, учир нь хайлтыг хост хийдэг:
docker network inspect nat --format "{{range .IPAM.Config}}{{.Subnet}}{{end}}"
route print -4
Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like "172.16.*"Маршрутын гаралтыг VPN холбогдохын өмнө нэг удаа, дараа нь нэг удаа ажиллуулаарай. Хоёр дахь гаралтад контейнерын префикс туннелийн адаптер руу зааж байвал оношлогоо дууссан бөгөөд контейнеруудыг дахин эхлүүлэх нь тус болохгүй.
Эхний сонголт бол бодлогын шийдвэр: сүлжээний эзэмшигчээс энэ төхөөрөмжид локал LAN хандалтыг зөвшөөрч болох эсэхийг асуугаарай. Хэд хэдэн корпорацийн клиент үүнийг тохиргоо болгон санал болгодог ч энэ нь санаатай тавьсан хил хязгаарыг сулруулна. Үүнийг эзэмшигч, хяналтын огноотой бичигдсэн үл хамаарах зүйл болгон хүсээрэй. Хэн ч буцаж хардаггүй төхөөрөмж тутмын унтраалга нь хамгаалалтын бодлого чимээгүйгээр алга болох зам юм.
Бодлого тогтох ёстой газарт маршруттай тэмцэхийн оронд ажлын ачааллыг зөө. Тодорхой дэд сүлжээ, гарцтай тунгалаг сүлжээ контейнеруудыг локал холбоос дээр тавьж, Linux ажлын ачаалал виртуал машины проксийн ард ажилладаг ба өөрийн клиенттэй тусдаа виртуал машин өөрийн бодлогыг хадгална. Нэгийг нь санаатайгаар сонгож, контейнерын дотроос шалгаарай, учир нь хэрэглэгчийн хүсэлт тэндээс үүсдэг.