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-тан кейінгі бастапқы мекенжайды есте сақтаңыз, шешушіні анық орнатыңыз және әр контейнердің шығу мекенжайларын жалауша емес, сәулеттік шешім ретінде қарастырыңыз.