Неліктен Docker контейнерлері VPN-нің DNS шешушісін елемейді

VPN қосылып тұр, браузер ішкі сайттарға жетеді, ал контейнер сол аттарды әлі шеше алмайды. Пакетті орнату EAI_AGAIN сияқты ат шешу қатесімен өледі, немесе қолданба хост машинасы шағымсыз шешетін дерекқор хостын таба алмайды. Контейнер VPN орнатқан шешушіні пайдаланбайды. Docker контейнер жасалған кезде хосттың шешуші конфигурациясын көшірді, ал одан кейін оны ешнәрсе қайта көшірмеді.

Бір машинадағы шешушінің екі көрінісі

Linux-та Docker жасау сәтінде әр контейнерге хосттың шешуші конфигурациясының көшірмесін береді, loopback мекенжайларын сүзеді және 127.0.0.11 мекенжайында сұрауларды сыртқа жіберетін кіріктірілген DNS серверін іске қосады. Контейнер іске қосылғаннан кейін /etc/resolv.conf файлын қайта жазатын VPN клиенті оның ішінде ештеңе өзгертпейді. Контейнерді қайта іске қосу тек сол сәтте хост шешушісі кездейсоқ дұрыс болса ғана көмектеседі.

macOS немесе Windows-тағы Docker Desktop бір қабат қосады, өйткені демон виртуалды машинада тұрады. Хосттың VPN шешушісі сол VM-ге ешқашан көрінбеуі мүмкін, сондықтан қайта іске қосу ештеңе өзгертпейді. Түзетуді таңдамас бұрын екі көріністі салыстырыңыз: хосттың шешушілер тізімінің жанында docker exec mycontainer cat /etc/resolv.conf.

Хост ішкі шешушіні тізімдеп тұрғанда контейнер жалпыға ортақ шешушіні тізімдесе, ол жалпыға ортақ аттарды шешіп, ішкілерде сәтсіздікке ұшырайды. Осы бөліну — бұл мәселенің қолтаңбасы.

A нұсқасы: туннель шешушісін әр контейнерге беру

Docker әр контейнер үшін DNS параметрлерін қабылдайды, және бұл жұмыс істейтін ең кіші өзгеріс. Алдымен VPN-нің шешуші мекенжайларын оқыңыз: macOS-та scutil --dns, Linux-та resolvectl status немесе клиенттің өз күй шығысы. Содан кейін контейнерді солармен іске қосыңыз, мысалы docker run --dns 192.168.2.1 --dns 192.168.123.1 myimage. Compose-те сол параметр қызметтің астындағы тізім, онда ол біреудің shell тарихында емес, нұсқа бақылауында тұрады.

/etc/docker/daemon.json ішіндегі dns массиві әр жаңа контейнерге қолданылады, бұл ұқыптырақ естіледі, бірақ олай емес. Туннель өшіп тұрғанда да қолданылады, сонда тек VPN арқылы қол жетімді шешуші қарапайым образ тартуды бұзады. Контейнер бойынша параметрлерді негіздеу де, кері қайтару да оңай.

B нұсқасы: контейнер хост желісін бөліссін

Хост желісі көшірмеден толық айналып өтеді, өйткені контейнер хосттың шешушісін және хосттың туннелін пайдаланады. Ол сондай-ақ сіз күткен желілік оқшаулауды жояды және Docker Desktop астында бірдей әрекет етпейді. Linux-та бұл ішкі аттарды шешуі керек бір реттік құрал үшін прагматикалық таңдау.

Build-тер үшін екі нұсқаның ешқайсысы қолданылмайды, өйткені build қадамдары орындалу уақытының жалаушаларын мұрагерлікке алмайды. Платформа рұқсат еткен жерде хост желісімен build жасаңыз, немесе тәуелділіктерді орнатуды туннель қажет етпейтін кезеңде ұстаңыз.

Екі нұсқаның ешқайсысы түзетпейтіні

Егер контейнердің оған маршруты болмаса, DNS мекенжайы пайдасыз. VPN шешушісі әдетте туннельдің мекенжай кеңістігінде отырады, сондықтан контейнерге сол префикске жол керек. Docker-дің әдепкі көпірі әдетте хост арқылы сыртқа маршруттайды, және хостта туннель маршруты болып, қайта бағыттау қосылғанда бұл жеткілікті. Өз мекенжай пулдары бар теңшелген көпір желілері VPN ішкі желісімен соқтығысуы мүмкін, сонда сұраулар мүлдем басқа жерге кетеді.

Шешушіні өзін жөндеуге кіріспес бұрын Docker желісінің ішкі желісін VPN ішкі желісімен салыстырыңыз. Қабаттасу дәл бұзылған DNS серверіне ұқсайтын ақау туғызады.

Контейнер ішінде тексеріңіз

Браузер немесе тілдік орындалу ортасының орнына контейнер ішінде getent hosts db.internal арқылы сынаңыз, өйткені олар өздерінің DNS саясатын және өз кэшін қолданады. Егер getent атты шешіп, қолданба әлі де сәтсіз болса, шешуші енді дұрыс және қалған мәселе қолданба деңгейінде. Егер ол шешпесе, DNS қадамы аяқталмаған.

DNS параметрлерін өзгерткеннен кейін контейнерді қайта жасаңыз. Жұмыс істеп тұрған контейнер ішінде /etc/resolv.conf өңдеу онымен бірге жоғалады және конфигурация мәселесін біреу оны қайта іске қосқанша жасырады.