Dev kontejner ne doseže host dostupan samo putem VPN-a: gdje tražiti

Privatni API se otvara u vašem desktop browseru, a pada u razvojnom kontejneru. To nije proturječje i rijetko je uzrok sam VPN. Zahtjev iz browsera i zahtjev koji pada uputili su različiti procesi, s različitim resolverima, proxyjima i rutama, a često i iz potpuno različitih mrežnih imenskih prostora. „Na mom laptopu“ može značiti Windows host, WSL distribuciju, virtualnu mašinu Docker Desktopa i kontejner unutar te VM — četiri konteksta od kojih svaki može dati drugačiji odgovor na isto ime hosta. Otkrijte koji od njih koristi proces koji pada prije nego dotaknete i jednu postavku.

Locirajte proces prije nego promijenite postavku

Počnite s kontejnerskim engineom, a ne s VPN klijentom. Pitajte s kojim kontekstom razgovara komandna linija i na kojem operativnom sistemu taj engine radi, jer Linux kontejner kojim upravlja desktop VM ide drugim putem od onog kojim upravlja lokalni daemon:

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

Na Windowsu wsl -l -v kaže radi li distribucija pod WSL 2, što je stavlja iza vlastitog virtualnog switcha. Taj detalj odlučuje dijeli li kontejner hostovu routing tabelu ili sjedi iza NAT-a kojem treba proslijeđeni port ili ime hosta da bi dosegao host.

Držite jedan zahtjev konstantnim i uporedite

Odaberite jednu bezopasnu krajnju točku na privatnom hostu i koristite je za svako poređenje: iz browsera, iz host terminala, iz WSL distribucije i iz unutrašnjosti kontejnera. Zabilježite četiri stvari za svaki pokušaj: razriješenu adresu, je li korišten proxy, klasu kvara i proteklo vrijeme. Traženje imena, uspostavljanje veze, TLS validacija i HTTP status su četiri različita problema, a njihovo stapanje u „ne radi“ troši cijelo jutro.

Pokrenite poređenje unutar kontejnera koji pada, s timeoutom da tihi firewall ne drži terminal minutama. Novi kontejner reprodukuje mrežni kontekst enginea, ali ne imenski prostor aplikacijskog kontejnera, proxy varijable ili resolver, pa je docker exec u pravi kontejner autoritativni test, a sidecar je samo način da izolujete je li razlika u engineu ili u kontejneru:

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 bazna slika nosi busybox i nema curl, a to je upravo vrsta detalja zbog koje kopirani dijagnostički blok pada: odaberite sliku s klijentom ili ga dodajte unutar istog pokretanja. Poređenje s nepovezanim javnim stranicama ne izoluje ništa. Ako https://example.com radi iz kontejnera, naučili ste da kontejner ima internetski pristup, a ništa o tome doseže li privatnu adresu kroz tunel. Isto tako, otvaranje novog terminala dokazuje samo da novi terminal radi, ne da dijeli runtime s aplikacijom koja je pala.

Docker Desktop može raditi s VPN-om

Dockerova vlastita dokumentacija o VPN-u i povezivanju s hostom opisuje to kao podržanu postavku, a iskren sažetak je da radi, a ne da je automatski pokvaren. Ne pretpostavljajte da desktop VM zaobilazi hostov tunel po dizajnu; u mnogim postavkama promet ispravno slijedi hostov tunel, i zato folklor „Docker ignorira VPN“ daje samouvjerene i pogrešne savjete.

Ono što je i dalje važno jest backend koji se koristi, klijentova politika podijeljenog tunela i konfiguracija resolvera koju je VM dobio. VPN klijent koji instalira rute ali ne DNS, ili gura DNS server koji VM ne može dosegnuti, proizvodi kvar traženja imena unutar kontejnera dok host radi jer ima dodatni resolver ili keširan odgovor. To je problem resolvera u kontejnerskom kostimu. Preživljava svako VPN ponovno povezivanje koje pokušate, jer tunel već nosi promet koji ste tražili da nosi.

Preklapanje adresa i MTU su različiti kvarovi

Dva kvara zaslužuju vlastitu dijagnozu jer se često brkaju s politikom pristupa. Prvi je preklapanje adresa: ako VPN gura raspon koji se sudara s podmrežom zadane mreže mosta kontejnera, ruta kontejnera za taj raspon pokazuje na lokalni most i nikada ne doseže tunel. Pregledajte stvarne podmreže umjesto da nagađate:

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

Drugi je MTU problem. Ako se veza uspostavi i TLS završi, ali veći odgovori zastaju, imate problem veličine paketa, a ne autorizacije, i zamjena DNS zapisa to nikada neće popraviti. Testirajte malim zahtjevom i velikim prije nego bilo šta promijenite i zabilježite oba ishoda.

Rješenje za preklapanje je druga kontejnerska podmreža ili ograničena ruta, koju bira onaj koji posjeduje plan adresa. Rješenje za MTU zastoj je stezanje ili smanjenje MTU tunela ili interfejsa na vrijednost koja preživljava put, primijenjeno na sloju koji kontrolišete.

Proxy konfiguracija je po procesu, ne po mašini

Unutar kontejnera localhost označava vlastiti mrežni kontekst tog kontejnera, pa proxy koji radi na hostu tamo nije dostupan pod tim imenom. Docker Desktop pruža host.docker.internal za pristup hostu, a na Linuxu ga dodajete izričito s --add-host=host.docker.internal:host-gateway. U svakom slučaju to ime vam daje rutu do hosta; ono ne stvara proxy servis niti vas ovlašćuje da ga koristite.

Koristite proxy adresu i port koji su dati za stvarno okruženje i provjerite ko ih čita. Varijable izvezene u interaktivnom shellu ne konfigurišu automatski svako proširenje editora, jezički server, alat za build i pozadinski daemon. Važan je proces koji je uputio zahtjev koji pada, pa pregledajte njegovo okruženje, a ne okruženje svog terminala.

Na kraju, neka popravka objasni sama sebe. Korisno rješenje imenuje granicu koja je bila pogrešna, postavku koja ju je promijenila i skup procesa na koje sada utiče. Redoslijedno restartovanje VPN-a, editora i enginea može promijeniti simptom, ali ne ostavlja ništa što sljedeća osoba može iskoristiti.