Эмнеге Docker контейнери VPN артындагы хостторго жете албайт

Корпоративдик VPN артында эч нерсеге жете албаган контейнер адатта туннелден башка тармактык аталыш мейкиндигинде жашайт. Хост кардарынын маршруттары, DNS серверлери жана брандмауэр белгилери хосттун стегине таандык; көпүрө тармагынын контейнеринин өз стеги бар. Ушул бир факт платформа тобуна келген отчеттордун көбүн түшүндүрөт жана «VPN бузулган» менен «Docker VPNди айланып өтөт» дегендин экөө тең бир убакта туура эмес болушу мүмкүн экенин түшүндүрөт. Бир симптомдун артында эки такыр башка конфигурация жашынган, ошондуктан кандайдыр бир жөндөөнү өзгөртүүдөн мурун кайсынысы сизде экенин аныктаңыз.

Туннель кимдин аталыш мейкиндигине таандык экенин аныктаңыз

macOS же Windows үчүн Docker Desktop'то контейнерлер Linux виртуалдык машинасынын ичинде иштейт. Жумуш столуна орнотулган VPN кардары жумуш столунун операциялык системасында туннель түзөт, ал эми виртуалдык машина аны эч качан көрбөйт. Эч бир контейнер конфигурациясы муну оңдобойт, анткени контейнерге керектүү интерфейс анын тармактык аталыш мейкиндигинде такыр жок.

Linux хостто туннель хосттун аталыш мейкиндигинде жашайт, ал эми көпүрө контейнерлери ага адатта чыгууда баштапкы NAT колдонулган хосттун маршруттоо таблицасы аркылуу жетет. Бул жол иштен чыкканда, себеби адатта жок маршрут эмес, кайра багыттоо саясаты, тескери жол фильтри же кабатташкан ички тармак болот. Андан ары окуудан мурун эки дүйнөнүн кайсынысында экениңизди ырастаңыз:

docker info --format '{{.OperatingSystem}}'
docker run --rm --net=host alpine ip route | head -5
docker run --rm alpine ip route | head -5

Бул эки маршруттоо таблицасынын айырмасы — бир экрандагы бүт көйгөй. Эгер хост көрүнүшүндө туннель интерфейси бар, көпүрө көрүнүшүндө жок болсо, сиз аталыш мейкиндигинин обочолонуусун көрүп жатасыз, ал эми калганынын баары андан кантип өтүү тууралуу тандоо.

Хост тармагы — сыноо, дизайн эмес

Контейнерди хост тармагы менен иштетүү, аны Docker хосттун тармактык аталыш мейкиндигин бөлүшүү деп документтештирет, ага туннель интерфейсин жана анын маршруттарын түздөн-түз мурастоо менен берет. Эгер ошол эле суроо андан кийин ийгиликтүү болсо, маршрут теориясы ырасталат жана бузулуу — аталыш мейкиндигинин обочолонуусу, ал эми эсептик маалыматтар, DNS же кирүү эрежеси эмес.

docker run --rm --net=host curl -sS -o /dev/null -w '%{http_code}\n' https://api.internal/health

Аны диагностика катары кармаңыз. Хост тармагы порт жарыялоодон жана контейнерден күткөн обочолонуунун көп бөлүгүнөн баш тартат, ал эми Docker Desktop'то «host» виртуалдык машинаны билдирет, жумуш столун эмес, ошондуктан кайсы хостко кайрылганыңызды унутуп калсаңыз, ал жердеги ийгилик же ийгиликсиздик сизди адаштырышы мүмкүн.

tun түзмөгү жана аны менен келген артыкчылыктар

Контейнердин ичиндеги VPN кардарына туннель түзмөгү жана аны конфигурациялоого уруксат керек. Көнүмүш кыска жол — --privileged, ал бардык түзмөктү берет жана бүт контейнерде коопсуздук саясатын бошотот. Бул бул иш талап кылгандан алда канча көп жана кароодо актоо кыйын.

sudo modprobe tun
docker run --rm -it --device /dev/net/tun --cap-add NET_ADMIN myvpn-client

Тар форма жалгыз түзмөк түйүнүн салыштырат жана тармактык администрациялоо жөндөмүн гана кошот. Түйүн болушу үчүн адегенде модулду хостко жүктөңүз. Эгер контейнер иштеп, кардар туннель түзмөгүн ача албай турганын билдирсе, профилге шектенүүдөн мурун салыштырууну текшериңиз, анткени бул ката адатта сөзмө-сөз.

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

Көпүрө NAT'ы VPN көргөн булакты өзгөртөт

Демейки көпүрөдө контейнердин чыккан трафиги хосттун дарегине которулат. Ошондуктан VPN артында корпоративдик тарап контейнердин эмес, хосттун туннель дарегин көрөт, булакка байланыштуу кирүү эрежелери суроону хост жөнөткөндөй иштейт, ал эми эки контейнер VPN сервери үчүн айырмаланбайт.

macvlan же ipvlan анын ордуна контейнерге LAN дарегин берет, бул LAN'да табууга жардам берет жана контейнерди сегментте тең укуктуу катары көрсөтөт. Ал ошондой эле хосттун туннелин толугу менен айланып өтөт, ошондуктан мындай контейнер VPN-гана префикстерине жетпейт, эгер VPN ошол LAN'дан да жеткиликтүү болбосо.

Эки форма тең мыйзамдуу; алар ар башка талаптарга жооп берет. Эгер талап «бул контейнер VPN-гана кызматына жетиши керек» болсо, сиз хост аркылуу маршруттоо менен контейнердин ичинде туннелди аяктоонун ортосунда тандайсыз. Бул тандоону жайылтууга чейин жазыңыз, биринчи ийгиликсиз суроодон кийин эмес. Эмнени тандасаңыз да, алыскы тарап көрө турган булак дарегин жазып алыңыз, анткени анын кирүү эрежелери жана журналдары дал ошону көрсөтөт. Бул даректи атай албаган дизайн бүтпөгөн.

DNS демонду ээрчийт, туннелди эмес

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

Чечүүчүнү кызмат үчүн ачык орнотуңуз же туннель аркылуу жеткиликтүү ички чечүүчүгө багыттаңыз. Жеке атты коомдук дарекке чечкен контейнер адатта коомдук чечүүчүнү колдонот, бузулган маршруттан жапа чекпейт, ал эми оңдоо compose файлына же демон конфигурациясына таандык.

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

Билетти жабуудан мурунку текшерүү тизмеси: туннелге ээ аталыш мейкиндигин аныктаңыз, жолду хост тармагы менен далилдеңиз, керектүү tun түзмөгүн гана салыштырыңыз, NAT'тан кийинки булак дарегин эстеп калыңыз, чечүүчүнү ачык орнотуңуз жана ар бир контейнердин чыгуу даректерин желек эмес, архитектуралык чечим катары караңыз.