Dev Container тек VPN арқылы қолжетімді хостқа жетпейді: қайдан қарау керек

Жеке API жұмыс үстеліңіздің браузерінде ашылып, әзірлеу контейнерінде сәтсіз аяқталады. Бұл қайшылық емес және сирек жағдайда себеп VPN-ның өзі болып табылады. Браузер сұранысы мен сәтсіз сұранысты әртүрлі процестер жасаған, олардың resolver, proxy және маршруттары әртүрлі, көбінесе мүлде басқа желілік атау кеңістіктерінен. «Менің ноутбугімде» деген Windows хостын, WSL таратылымын, Docker Desktop виртуалды машинасын және сол VM ішіндегі контейнерді білдіруі мүмкін — бір хост атауына әрқайсысы басқаша жауап бере алатын төрт контекст. Бір параметрге де тимес бұрын сәтсіз процестің қайсысын қолданатынын анықтаңыз.

Параметрді өзгерту алдында процесті табыңыз

VPN клиентінен емес, контейнер қозғалтқышынан бастаңыз. Пәрмен жолы қай контекспен сөйлесіп жатқанын және сол қозғалтқыш қай операциялық жүйеде жұмыс істейтінін сұраңыз, өйткені жұмыс үстелінің VM-і басқаратын Linux контейнері жергілікті демон басқаратын контейнерден өзге жолмен жүреді:

docker context ls
docker info --format '{{.OperatingSystem}} / {{.Name}}'
docker run --rm alpine ip route

Windows-та wsl -l -v таратымның WSL 2 астында жұмыс істейтінін айтады, бұл оны өзінің виртуалды коммутаторының артына қояды. Осы бөлшек контейнердің хосттың маршруттау кестесін бөлісетінін немесе хостқа жету үшін қайта бағытталған порт немесе хост атауы қажет NAT-тың артында тұрғанын шешеді.

Бір сұранысты тұрақты ұстап, салыстырыңыз

Жеке хосттағы бір зиянсыз соңғы нүктені таңдап, оны әрбір салыстыру үшін қолданыңыз: браузерден, хост терминалынан, WSL таратылымынан және контейнердің ішінен. Әрбір әрекет үшін төрт нәрсені жазып алыңыз: шешілген мекенжай, proxy қолданылғаны, қате класы және өткен уақыт. Атауды іздеу, қосылым орнату, TLS тексеру және HTTP күйі — төрт түрлі мәселе, оларды «жұмыс істемейді» деп араластыру жарты күнді ысырап етеді.

Салыстыруды сәтсіз контейнердің ішінде, таймаутпен орындаңыз, сонда үнсіз брандмауэр терминалды минуттарға ұстап тұрмайды. Жаңа контейнер қозғалтқыштың желілік контекстін қалпына келтіреді, бірақ қолданба контейнерінің атау кеңістігін, proxy айнымалыларын немесе resolver-ін емес, сондықтан нақты контейнерге docker exec жасау — беделді тест, ал бүйір контейнер айырмашылық қозғалтқышта ма әлде контейнерде ме екенін оқшаулаудың ғана жолы:

docker exec -it app /bin/sh -c "getent hosts api.internal; curl -v --max-time 8 https://api.internal/ 2>&1 | tail -20"
docker run --rm --network container:app curlimages/curl:latest -sv --max-time 8 https://api.internal/ 2>&1 | tail -20

alpine негізгі бейнесінде busybox бар, curl жоқ, және дәл осындай бөлшек көшірілген диагностикалық блокты сәтсіз етеді: клиенті бар бейнені таңдаңыз немесе оны сол жүргізуге қосыңыз. Байланысы жоқ жария сайттармен салыстыру ештеңені оқшауламайды. Егер контейнерден https://example.com жұмыс істесе, сіз контейнерде интернетке қатынас бар екенін білдіңіз, ал туннель арқылы жеке мекенжайға жететіні туралы ештеңе білмедіңіз. Сол сияқты, жаңа терминал ашу тек жаңа терминалдың жұмыс істейтінін дәлелдейді, оның сәтсіз қолданбамен бір орындау ортасын бөлісетінін емес.

Docker Desktop VPN-мен жұмыс істей алады

Docker-дың өз VPN және хост қосылымы туралы құжаттамасы мұны қолдау көрсетілетін конфигурация ретінде сипаттайды, ал адал қорытынды — ол автоматты түрде бұзылмайды, жұмыс істейді. Жұмыс үстелінің VM-і хост туннелін дизайн бойынша айналып өтеді деп ойламаңыз; көптеген конфигурацияларда трафик хост туннелінен дұрыс өтеді, сондықтан «Docker VPN-ды елемейді» деген аңыз сенімді әрі қате кеңес береді.

Бұрын да маңыздысы — қолданылатын backend, клиенттің split-tunnel саясаты және VM алған resolver конфигурациясы. Маршруттарды орнататын, бірақ DNS орнатпайтын немесе VM жете алмайтын DNS серверін итеретін VPN клиенті контейнер ішіндегі атауды іздеу қатесін тудырады, ал хост жұмыс істейді, өйткені оның қосымша resolver-і немесе кэштегі жауабы бар. Бұл контейнер киімін киген resolver мәселесі. Ол VPN-ның сіз байқаған әрбір қайта қосылуынан аман қалады, өйткені туннель сіз сұраған трафикті әлдеқашан тасымалдап жүр.

Мекенжай қабаттасуы мен MTU — әртүрлі ақаулар

Екі ақау жеке диагностикаға лайық, өйткені оларды жиі қатынас саясаты деп шатастырады. Біріншісі — мекенжай қабаттасуы: егер VPN контейнерлік желінің әдепкі көпір ішкі желісімен соқтығысатын диапазонды итерсе, сол диапазон үшін контейнер маршруты жергілікті көпірге сілтейді және туннельге ешқашан жетпейді. Болжаудың орнына нақты ішкі желілерді тексеріңіз:

docker network inspect bridge --format '{{range .IPAM.Config}}{{.Subnet}}{{end}}'
ip route get 10.20.30.40

Екіншісі — MTU мәселесі. Қосылым орнап, TLS аяқталса да үлкенірек жауаптар тұрып қалса, сізде пакет өлшемінің мәселесі бар, рұқсат мәселесі емес, және DNS жазбаларын ауыстыру оны ешқашан түзетпейді. Бірдеңені өзгерту алдында кіші және үлкен сұраныспен сынап көріңіз және екі нәтижені де жазып алыңыз.

Қабаттасудың шешімі — мекенжай жоспарының иесі таңдайтын басқа контейнер ішкі желісі немесе шектелген маршрут. MTU тұрып қалуының шешімі — туннельдің немесе интерфейстің MTU-ын жолдан өтетін мәнге қысу немесе азайту, оны өзіңіз басқаратын қабатта қолдану.

Proxy конфигурациясы машина бойынша емес, процесс бойынша

Контейнердің ішінде localhost сол контейнердің өз желілік контекстін атайды, сондықтан хостта жұмыс істейтін proxy ол жерде бұл атаумен қолжетімсіз. Docker Desktop хостқа қатынас үшін host.docker.internal ұсынады, ал Linux-та оны --add-host=host.docker.internal:host-gateway арқылы анық қосасыз. Қалай болғанда да, бұл атау сізге хостқа маршрут береді; ол proxy қызметін жасамайды және оны пайдалануға рұқсат та бермейді.

Нақты орта үшін берілген proxy мекенжайы мен портын қолданыңыз және оларды кім оқитынын тексеріңіз. Интерактивті shell-де экспортталған айнымалылар әрбір редактор кеңейтімдерін, тіл серверін, build құралын және фондық демонды автоматты түрде конфигурацияламайды. Маңыздысы — сәтсіз сұранысты жасаған процесс, сондықтан оның ортасын тексеріңіз, өз терминалыңыздың емес.

Соңында, түзету өзін түсіндірсін. Пайдалы шешім қате болған шекараны, оны өзгерткен параметрді және қазір оған әсер ететін процестер жиынтығын атайды. VPN-ды, редакторды және қозғалтқышты ретімен қайта іске қосу симптомды өзгертуі мүмкін, бірақ келесі адамға керек ештеңе қалдырмайды.