Бир ноутбукта, бир туташкан VPN кардары менен, Linux контейнерлери бири-бири менен сүйлөшүүнү улантат, ал эми Windows контейнерлери токтойт. Өзгөрмө сүрөт эмес, пакеттердин хостко кирген жолу. Демейки тармактагы Windows контейнерлери хосттун маршруттоо таблицасын жана котормосун карызга алат, ошондуктан хосттун маршруттоосун өзгөрткөн саясат аларды да өзгөртөт. Бирон нерсени кайра орнотуудан мурун муну маршрут издөө менен ырастаңыз.

Windows контейнеринин пакеттери хостко кайдан кирет

Демейки nat тармагындагы контейнер Host Networking Service префиксинен дарек алат, адатта 172.16.0.0/12 ичинде бир жерден, жана виртуалдык адаптер аркылуу хостко жетет. Хост ошол префикстин маршрутуна ээ жана трафикти азыр активдүү адаптерге карай которот. Ошол жолдун ортосунда өзүнчө виртуалдык машина жок.

Ушул дизайн бузулууну механикалык кылат. Контейнер пакет жөнөткөндө, хост контейнер префикси үчүн маршрут издөөсүн аткарат. Кайсы маршрут жеңишке жетсе, пакет ошол жакка кетет, ал эми контейнердин буга пикири жок.

VPN кардары бул жолдо эмнени өзгөртөт

Корпоративдик кардар көбүнчө маршруттардын кенен жыйындысын жана туннель күйүп турганда жергиликтүү субнетке кирүүнү четке каккан чыпканы орнотот. Ниет коргонуу: бузулган жергиликтүү тармак корголгон машинага жетпеши керек. Жанама таасир — хосттун контейнер префиксине болгон маршруту эми жергиликтүү NAT тармагы эмес.

Анын ордуна издөө туннелге дал келет жана пакет ошол контейнер дареги жөнүндө эч качан укпаган дарбазага берилет. Ping ишке ашпайт, колдонмо убакыты бүтөт жана VPN белгиси жаркырап турганда контейнер сынгандай көрүнөт. Туташкан кезде хосттун таблицасын караңыз, атаандаш маршрут көрүнөт.

Container modeOutbound pathTypical result behind the VPN
Windows, default natHost routes and translates container trafficContainer prefix follows the tunnel and fails
Windows, transparentContainer sits on the physical linkDepends on the local subnet being allowed
Linux engine on Docker DesktopVM egress proxied by a host processOften 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 жүгү виртуалдык машинанын проксисинин артында иштейт жана өз кардары бар өзүнчө виртуалдык машина өз саясатын сактайт. Бирөөнү атайын тандап, аны контейнердин ичинен сынап көрүңүз, анткени колдонуучунун суроосу так ошол жерде жаралат.

Тектеш макалалар