Dev Container не стигнува до домаќин достапен само преку VPN: каде да се погледне

Приватниот API се отвора во десктоп браузерот и не успева во развојниот контејнер. Тоа не е противречност и ретко е причина самиот VPN. Барањето од браузерот и барањето што не успева ги направиле различни процеси, со различни resolver-и, proxy-а и рути, и често од сосема различни мрежни именски простори. „На мојот лаптоп“ може да значи Windows домаќин, WSL дистрибуција, виртуелната машина на Docker Desktop и контејнер во таа VM — четири контексти, од кои секој може различно да одговори на истото име на домаќин. Откријте кој го користи процесот што не успева пред да допрете и едно поставување.

Најдете го процесот пред да промените поставување

Започнете со контејнерскиот мотор, а не со VPN клиентот. Прашајте со кој контекст зборува командната линија и на кој оперативен систем работи тој мотор, бидејќи Linux контејнер управуван од десктоп VM оди по различен пат од оној управуван од локален демон:

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 статус се четири различни проблеми, и нивно мешање во „не работи“ троши цело утро.

Изведете ја споредбата во контејнерот што не успева, со тајмаут за тивок firewall да не го држи терминалот со минути. Нов контејнер го репродуцира мрежниот контекст на моторот, но не именскиот простор, 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 на клиентот и resolver конфигурацијата што ја добила VM. VPN клиент што инсталира рути, но не DNS, или што турка DNS сервер до кој VM не може да стигне, создава неуспех при барање на име во контејнерот, додека домаќинот работи затоа што има дополнителен 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, уредувачот и моторот по ред може да го промени симптомот, но не остава ништо што следниот човек би можел да го искористи.