Kontejneri i zhvillimit nuk arrin një host vetëm me VPN: ku të shikoni

API privat hapet në shfletuesin e desktopit tuaj dhe dështon në kontejnerin e zhvillimit. Ky nuk është kontradiktë dhe rrallë është vetë VPN-ja. Kërkesa e shfletuesit dhe kërkesa që dështon u bënë nga procese të ndryshme, me rezolues, proxy dhe rrugë të ndryshme, dhe shpesh nga hapësira rrjeti krejtësisht të ndryshme. Shprehja "në laptopin tim" mund të nënkuptojë hostin Windows, një shpërndarje WSL, makinën virtuale Docker Desktop dhe një kontejner brenda asaj VM-je, katër kontekste që secili mund t'i përgjigjet ndryshe të njëjtit emër hosti. Zbuloni se cilin prej tyre përdor procesi që dështon përpara se të prekni një cilësim të vetëm.

Gjeni procesin përpara se të ndryshoni një cilësim

Filloni me motorin e kontejnerëve, jo me klientin VPN. Pyetni me cilin kontekst po flet rreshti i komandave dhe cilin sistem operativ ekzekuton ai motor, sepse një kontejner Linux i menaxhuar nga një VM desktopi është një rrugë e ndryshme nga ai i menaxhuar nga një daemon lokal:

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

Në Windows, wsl -l -v ju tregon nëse shpërndarja po ekzekutohet nën WSL 2, gjë që e vendos pas një ndërprerësi virtual të vetin. Ky detaj vendos nëse kontejneri ndan tabelën e rrugëzimit të hostit ose qëndron pas një NAT që kërkon një port të përcjellë ose një emër hosti për të arritur hostin.

Mbani një kërkesë konstante dhe krahasoni

Zgjidhni një pikë fundore të padëmshme në hostin privat dhe përdoreni atë për çdo krahasim, nga shfletuesi, nga një terminal i hostit, nga shpërndarja WSL dhe nga brenda kontejnerit. Regjistroni katër gjëra për çdo provë: adresën e rezolvuar, nëse u përdor një proxy, klasën e dështimit dhe kohën e kaluar. Kërkimi i emrit, vendosja e lidhjes, validimi TLS dhe një status HTTP janë katër probleme të ndryshme, dhe përzierja e tyre në "nuk funksionon" harxhon një mëngjes.

Kryeni krahasimin brenda kontejnerit që dështon, me një afat kohor, që një firewall i heshtur të mos e mbajë terminalin për minuta. Një kontejner i ri riprodhon kontekstin e rrjetit të motorit, por jo hapësirën e emrave, variablat e proxy-t ose rezoluesin e kontejnerit të aplikacionit, prandaj docker exec në atë të vërtetë është testi përfundimtar dhe një kontejner ndihmës është vetëm një mënyrë për të izoluar nëse ndryshimi është motori apo kontejneri:

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

Imazhi bazë alpine përmban busybox dhe nuk ka curl, dhe pikërisht ky lloj detaji e bën të dështojë një bllok diagnostik i kopjuar: zgjidhni një imazh që e ka klientin ose shtojeni brenda të njëjtit ekzekutim. Krahasimi me faqe publike të palidhura nuk izolon asgjë. Nëse https://example.com funksionon nga kontejneri, keni mësuar se kontejneri ka akses në internet dhe asgjë për atë nëse mund të arrijë një adresë private përmes tunelit. Po ashtu, hapja e një terminali të ri vërteton vetëm se terminali i ri funksionon, jo se ndan një mjedis ekzekutimi me aplikacionin që dështoi.

Docker Desktop mund të funksionojë me një VPN

Dokumentacioni i vetë Docker-it për VPN-në dhe lidhshmërinë me hostin e përshkruan këtë si një konfigurim të mbështetur, dhe përmbledhja e ndershme është se funksionon, nuk është automatikisht i prishur. Mos supozoni se VM-ja e desktopit e anashkalon tunelin e hostit si çështje dizajni; në shumë konfigurime trafiku ndjek saktë tunelin e hostit, prandaj folklori "Docker e injoron VPN-në" prodhon këshilla të sigurta dhe të gabuara.

Ajo që ende ka rëndësi është backend-i në përdorim, politika e tunelit të ndarë e klientit dhe konfigurimi i rezoluesit që mori VM-ja. Një klient VPN që instalon rrugë por jo DNS, ose që shtyn një server DNS që VM-ja nuk mund ta arrijë, prodhon një dështim të kërkimit të emrit brenda kontejnerit, ndërsa hosti funksionon sepse ka një rezolues shtesë ose një përgjigje të ruajtur në cache. Ky është një problem rezoluesi me kostum kontejneri. I mbijeton çdo rilidhjeje VPN që provoni, sepse tuneli tashmë po e transporton trafikun që i kërkuat.

Mbivendosjet e adresave dhe MTU janë dështime të ndryshme

Dy dështime meritojnë diagnozën e tyre, sepse shpesh ngatërrohen me politikën e aksesit. I pari është një mbivendosje adresash: nëse VPN-ja shtyn një interval që përplaset me nënrrjetin e urës së parazgjedhur të një rrjeti kontejneri, rruga e kontejnerit për atë interval tregon urën lokale dhe nuk arrin kurrë tunelin. Inspektoni nënrrjetet aktuale në vend që të hamendësoni:

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

I dyti është një problem MTU-je. Nëse lidhja vendoset dhe TLS përfundon, por përgjigjet më të mëdha ngecin, keni një çështje madhësie pakete, jo një çështje autorizimi, dhe zëvendësimi i të dhënave DNS nuk do ta rregullojë kurrë. Testoni me një kërkesë të vogël dhe një të madhe përpara se të ndryshoni ndonjë gjë dhe regjistroni të dyja rezultatet.

Rregullimi për një mbivendosje është një nënrrjet tjetër kontejneri ose një rrugë e kufizuar, e zgjedhur nga ai që zotëron planin e adresave. Rregullimi për një ngecje MTU-je është kufizimi ose zvogëlimi i MTU-së së tunelit ose të ndërfaqes në një vlerë që i mbijeton rrugës, i aplikuar në shtresën që ju kontrolloni.

Konfigurimi i proxy-t është për proces, jo për makinë

Brenda një kontejneri, localhost emërton kontekstin e rrjetit të vetë atij kontejneri, kështu që një proxy që ekzekutohet në host nuk arrihet atje me atë emër. Docker Desktop ofron host.docker.internal për aksesin në host, dhe në Linux e shtoni shprehimisht me --add-host=host.docker.internal:host-gateway. Në të dyja rastet, ai emër ju jep një rrugë drejt hostit; nuk krijon një shërbim proxy dhe nuk ju autorizon ta përdorni.

Përdorni adresën dhe portin e proxy-t të dhëna për mjedisin aktual dhe kontrolloni kush po e lexon. Variablat e eksportuara në një shell interaktiv nuk konfigurojnë automatikisht çdo shtojcë editori, server gjuhe, mjet ndërtimi dhe daemon në sfond. Ai që ka rëndësi është procesi që bëri kërkesën që dështon, prandaj inspektoni mjedisin e tij, jo atë të terminalit tuaj.

Së fundi, bëni që rregullimi të shpjegohet vetë. Një zgjidhje e dobishme emërton kufirin që ishte i gabuar, cilësimin që e ndryshoi dhe grupin e proceseve që prek tani. Rinisja e VPN-së, e editorit dhe e motorit me radhë mund ta ndryshojë simptomën, por nuk lë asgjë pas që personi tjetër mund ta përdorë.