A Dev Container nem éri el a csak VPN-en át elérhető gazdagépet: hol keressünk

A privát API megnyílik az asztali böngészőben, és meghiúsul a fejlesztői konténerben. Ez nem ellentmondás, és ritkán maga a VPN az ok. A böngésző kérését és a meghiúsuló kérést különböző folyamatok indították, eltérő feloldókkal, proxykkal és útvonalakkal, gyakran teljesen eltérő hálózati névterekből. A „a laptopomon” jelentheti a Windows gazdagépet, egy WSL-disztribúciót, a Docker Desktop virtuális gépet és egy konténert azon a VM-en belül – négy környezet, amelyek mindegyike másképp válaszolhat ugyanarra a gazdagépnévre. Állapítsa meg, melyiket használja a hibázó folyamat, mielőtt egyetlen beállításhoz hozzányúlna.

Keresse meg a folyamatot, mielőtt beállítást módosít

A konténer-motorral kezdje, ne a VPN-klienssel. Kérdezze meg, melyik környezettel beszél a parancssor, és melyik operációs rendszeren fut az a motor, mert az asztali VM által kezelt Linux konténer más útvonalat jár, mint amelyet helyi daemon kezel:

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

Windowson a wsl -l -v megmondja, fut-e a disztribúció WSL 2 alatt, ami saját virtuális kapcsolója mögé helyezi. Ez a részlet dönti el, hogy a konténer megosztja-e a gazdagép útvonaltábláját, vagy olyan NAT mögött ül, amelynek továbbított portra vagy gazdagépnévre van szüksége a gazdagép eléréséhez.

Tartson egy kérést állandóan, és hasonlítson össze

Válasszon egy ártalmatlan végpontot a privát gazdagépen, és használja minden összehasonlításhoz: a böngészőből, a gazdagép termináljából, a WSL-disztribúcióból és a konténer belsejéből. Minden kísérletnél jegyezzen fel négy dolgot: a feloldott címet, hogy használtak-e proxyt, a hiba osztályát és az eltelt időt. A névfeloldás, a kapcsolat létrehozása, a TLS-ellenőrzés és egy HTTP-állapot négy különböző probléma, és ezeket „nem működik” alá keverni egy délelőttöt pazarol el.

Futtassa az összehasonlítást a hibázó konténer belsejében, időkorláttal, hogy egy csendes tűzfal ne tartsa a terminált percekig. Egy friss konténer újraadja a motor hálózati környezetét, de nem az alkalmazáskonténer névterét, proxyváltozóit vagy feloldóját, ezért a docker exec a valódi konténerbe a mérvadó teszt, a mellékkonténer pedig csak annak elkülönítésére jó, hogy a különbség a motorban vagy a konténerben van-e:

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

Az alpine alapimage busyboxot tartalmaz, curl-t nem, és pontosan ez az a részlet, amelytől egy másolt diagnosztikai blokk elbukik: válasszon klienst tartalmazó image-et, vagy adja hozzá ugyanabban a futásban. A nem kapcsolódó nyilvános oldalakkal való összehasonlítás semmit sem különít el. Ha a https://example.com működik a konténerből, megtanulta, hogy a konténernek van internetelérése, és semmit arról, hogy eléri-e a privát címet az alagúton keresztül. Hasonlóképpen egy új terminál megnyitása csak azt bizonyítja, hogy az új terminál működik, nem azt, hogy közös futásidejű környezetben van a meghiúsult alkalmazással.

A Docker Desktop tud VPN-nel működni

A Docker saját dokumentációja a VPN-ről és a gazdagép-kapcsolatról támogatott beállításként írja le ezt, és az őszinte összefoglaló az, hogy működik, nem pedig automatikusan törött. Ne feltételezze, hogy az asztali VM tervezésénél fogva megkerüli a gazdagép alagútját; sok beállításban a forgalom helyesen követi a gazdagép alagútját, és ezért termel a „Docker figyelmen kívül hagyja a VPN-t” folklór magabiztos és hibás tanácsokat.

Ami továbbra is számít, az a használt backend, az ügyfél split-tunnel szabályzata és az a feloldókonfiguráció, amelyet a VM kapott. Az a VPN-kliens, amely útvonalakat telepít, de DNS-t nem, vagy olyan DNS-kiszolgálót tol, amelyet a VM nem ér el, névre feloldási hibát okoz a konténerben, miközben a gazdagép működik, mert van egy további feloldója vagy gyorsítótárazott válaszra. Ez feloldóprobléma konténerjelmezben. Túléli minden VPN-újracsatlakozást, amelyet megpróbál, mert az alagút már szállítja a forgalmat, amelyet megkért rá.

A címátfedések és az MTU különböző hibák

Két hiba saját diagnózist érdemel, mert gyakran összekeverik őket a hozzáférési szabályzattal. Az első a címátfedés: ha a VPN olyan tartományt tol, amely ütközik egy konténerhálózat alapértelmezett híd-alhálózatával, a konténer útvonala arra a tartományra a helyi hidra mutat, és soha nem éri el az alagutat. Vizsgálja meg a tényleges alhálózatokat, ahelyett hogy találgatna:

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

A második MTU-probléma. Ha a kapcsolat létrejön és a TLS befejeződik, de a nagyobb válaszok elakadnak, packetméret-problémája van, nem engedélyezési problémája, és a DNS-rekordok cseréje soha nem fogja megjavítani. Teszteljen egy kicsi és egy nagy kéréssel, mielőtt bármit módosít, és jegyezze fel mindkét eredményt.

Az átfedés megoldása egy másik konténer-alhálózat vagy egy korlátozott útvonal, amelyet a címterv tulajdonosa választ. Az MTU-elakadás megoldása az alagút vagy interfész MTU-jának szűkítése vagy csökkentése az útvonalat túlélő értékre, az Ön által vezérelt rétegen alkalmazva.

A proxykonfiguráció folyamatonként, nem gépenként érvényes

Egy konténeren belül a localhost az adott konténer saját hálózati környezetét nevezi meg, így a gazdagépen futó proxy ott nem érhető el ezen a néven. A Docker Desktop a gazdagép-eléréshez a host.docker.internal nevet biztosítja, Linuxon pedig kifejezetten a --add-host=host.docker.internal:host-gateway kapcsolóval adja hozzá. Akárhogy is, ez a név útvonalat ad a gazdagéphez; nem hoz létre proxyszolgáltatást, és nem jogosít fel annak használatára.

A tényleges környezethez megadott proxycímet és -portot használja, és ellenőrizze, ki olvassa őket. Az interaktív shellben exportált változók nem konfigurálják automatikusan az összes szerkesztőbővítményt, nyelvi kiszolgálót, build-eszközt és háttér-démont. Az számít, amelyik folyamat a meghiúsult kérést indította, ezért annak a környezetét vizsgálja meg, nem a terminálét.

Végül hagyja, hogy a javítás elmagyarázza magát. Egy hasznos megoldás megnevezi a határt, amely hibás volt, a beállítást, amely megváltoztatta, és a folyamatok halmazát, amelyekre most hatással van. A VPN, a szerkesztő és a motor egymás utáni újraindítása megváltoztathatja a tünetet, de nem hagy maga után semmit, amit a következő ember használhatna.