Dev Container ne doseže gostitelja, dostopnega samo prek VPN: kam pogledati

Zasebni API se odpre v namiznem brskalniku in ne uspe v razvojnem vsebniku. To ni protislovje in redko je kriva sama VPN. Zahtevo brskalnika in zahtevo, ki ne uspe, so poslali različni procesi, z različnimi resolverji, proxyji in potmi, pogosto pa iz povsem različnih omrežnih imenskih prostorov. „Na mojem prenosniku“ lahko pomeni gostitelja Windows, distribucijo WSL, virtualni stroj Docker Desktop in vsebnik znotraj te VM – štirje konteksti, od katerih lahko vsak na isto ime gostitelja odgovori drugače. Ugotovite, katerega uporablja proces, ki ne uspe, preden se dotaknete ene same nastavitve.

Poiščite proces, preden spremenite nastavitev

Začnite s pogonom za vsebnike, ne s odjemalcem VPN. Vprašajte, s katerim kontekstom govori ukazna vrstica in na katerem operacijskem sistemu teče ta pogon, ker vsebnik Linux, ki ga upravlja namizni VM, gre po drugi poti kot tisti, ki ga upravlja lokalni demon:

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

V Windows wsl -l -v pove, ali distribucija teče pod WSL 2, kar jo postavi za lastno virtualno stikalo. Ta podrobnost odloči, ali si vsebnik deli usmerjevalno tabelo gostitelja ali sedi za NAT, ki potrebuje posredovana vrata ali ime gostitelja, da doseže gostitelja.

Ohranite eno zahtevo nespremenjeno in primerjajte

Izberite eno neškodljivo končno točko na zasebnem gostitelju in jo uporabite za vsako primerjavo: iz brskalnika, iz terminala gostitelja, iz distribucije WSL in od znotraj vsebnika. Zapišite štiri stvari za vsak poskus: razrešen naslov, ali je bil uporabljen proxy, razred napake in pretečeni čas. Iskanje imena, vzpostavitev povezave, preverjanje TLS in status HTTP so štirje različni problemi, njihovo zlivanje v „ne deluje“ pa zapravi dopoldne.

Primerjavo izvedite znotraj vsebnika, ki ne uspe, s časovno omejitvijo, da tiha požarna pregrada ne zadrži terminala za minute. Nov vsebnik poustvari omrežni kontekst pogona, ne pa imenskega prostora, proxy spremenljivk ali resolverja aplikacijskega vsebnika, zato je docker exec v pravi vsebnik merodajni test, stranski vsebnik pa je le način, da izoliramo, ali je razlika v pogonu ali v vsebniku:

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

Osnovna slika alpine vsebuje busybox in nima curl, in prav takšna podrobnost povzroči, da kopiran diagnostični blok ne uspe: izberite sliko s klientom ali ga dodajte v istem zagonu. Primerjava z nepovezanimi javnimi stranmi ne izolira ničesar. Če https://example.com deluje iz vsebnika, ste izvedeli, da ima vsebnik dostop do interneta, in nič o tem, ali doseže zasebni naslov skozi tunel. Prav tako odpiranje novega terminala dokaže le, da novi terminal deluje, ne pa da si deli izvajalno okolje z aplikacijo, ki ni uspela.

Docker Desktop lahko deluje z VPN

Lastna dokumentacija Dockerja o VPN in povezljivosti z gostiteljem to opisuje kot podprto nastavitev, pošten povzetek pa je, da deluje, namesto da bi bilo samodejno pokvarjeno. Ne domnevajte, da namizni VM obide tunel gostitelja že po zasnovi; v mnogih nastavitvah promet pravilno sledi tunelu gostitelja, zato folklora „Docker ignorira VPN“ daje samozavestne in napačne nasvete.

Kar je še vedno pomembno, je uporabljeni backend, politika razdeljenega tunela odjemalca in konfiguracija resolverja, ki jo je prejel VM. Odjemalec VPN, ki namesti poti, ne pa DNS, ali potisne strežnik DNS, ki ga VM ne more doseči, ustvari napako pri iskanju imena v vsebniku, medtem ko gostitelj deluje, ker ima dodaten resolver ali predpomnjen odgovor. To je problem resolverja v kostumu vsebnika. Preživi vsako ponovno povezavo VPN, ki jo poskusite, ker tunel že prenaša promet, ki ste ga zahtevali.

Prekrivanja naslovov in MTU so različne okvare

Dve okvari si zaslužita lastno diagnostiko, ker ju pogosto zamenjujemo s politiko dostopa. Prva je prekrivanje naslovov: če VPN potisne obseg, ki se zaleti v privzeto podomrežje mostu vsebniškega omrežja, pot vsebnika za ta obseg kaže na lokalni most in nikoli ne doseže tunela. Preglejte dejanska podomrežja, namesto da ugibate:

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

Druga je težava z MTU. Če se povezava vzpostavi in TLS zaključi, vendar se večji odgovori ustavijo, imate težavo z velikostjo paketa, ne z avtorizacijo, in zamenjava zapisov DNS tega nikoli ne bo odpravila. Preizkusite z majhno in veliko zahtevo, preden karkoli spremenite, in zapišite oba izida.

Rešitev za prekrivanje je drugo vsebniško podomrežje ali omejena pot, ki jo izbere lastnik načrta naslovov. Rešitev za zastoj MTU je stiskanje ali zmanjšanje MTU tunela ali vmesnika na vrednost, ki preživi pot, uporabljeno na plasti, ki jo nadzorujete.

Konfiguracija proxyja je na proces, ne na stroj

Znotraj vsebnika localhost poimenuje lastni omrežni kontekst tega vsebnika, zato proxy, ki teče na gostitelju, tam pod tem imenom ni dosegljiv. Docker Desktop ponuja host.docker.internal za dostop do gostitelja, v Linuxu pa ga dodate izrecno z --add-host=host.docker.internal:host-gateway. Kakor koli, to ime vam daje pot do gostitelja; ne ustvari storitve proxy in vas ne pooblašča za uporabo ene.

Uporabite naslov in vrata proxyja, ki so dana za dejansko okolje, in preverite, kdo jih bere. Spremenljivke, izvožene v interaktivni lupini, ne nastavijo samodejno vsake razširitve urejevalnika, jezikovnega strežnika, orodja za gradnjo in ozadnjega demona. Pomemben je proces, ki je poslal zahtevo, ki ni uspela, zato preglejte njegovo okolje in ne okolja svojega terminala.

Nazadnje, pustite popravku, da se pojasni sam. Uporabna rešitev poimenuje mejo, ki je bila napačna, nastavitev, ki jo je spremenila, in množico procesov, na katere zdaj vpliva. Ponovni zagon VPN, urejevalnika in pogona po vrsti lahko spremeni simptom, a ne pusti ničesar, kar bi naslednja oseba lahko uporabila.