Dev Container nu ajunge la un host disponibil doar prin VPN: unde să te uiți

API-ul privat se deschide în browserul de pe desktop și eșuează în containerul de dezvoltare. Nu este o contradicție și rareori VPN-ul însuși este cauza. Cererea browserului și cererea care eșuează au fost făcute de procese diferite, cu resolveri, proxy-uri și rute diferite, și adesea din spații de nume de rețea complet diferite. „Pe laptopul meu” poate însemna gazda Windows, o distribuție WSL, mașina virtuală Docker Desktop și un container în interiorul acelei VM — patru contexte care pot răspunde diferit la același nume de gazdă. Află pe care îl folosește procesul care eșuează înainte de a atinge o singură setare.

Găsește procesul înainte de a schimba o setare

Începe cu motorul de containere, nu cu clientul VPN. Întreabă cu ce context vorbește linia de comandă și pe ce sistem de operare rulează acel motor, pentru că un container Linux administrat de o VM de desktop merge pe altă cale decât unul administrat de un daemon local:

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

Pe Windows, wsl -l -v îți spune dacă distribuția rulează sub WSL 2, ceea ce o pune în spatele propriului comutator virtual. Acest detaliu decide dacă containerul partajează tabela de rutare a gazdei sau stă în spatele unui NAT care are nevoie de un port redirecționat sau de un nume de gazdă pentru a ajunge la gazdă.

Păstrează o cerere constantă și compară

Alege un endpoint inofensiv pe gazda privată și folosește-l pentru fiecare comparație: din browser, dintr-un terminal al gazdei, din distribuția WSL și din interiorul containerului. Notează patru lucruri pentru fiecare încercare: adresa rezolvată, dacă s-a folosit un proxy, clasa de eșec și timpul scurs. Căutarea numelui, stabilirea conexiunii, validarea TLS și un status HTTP sunt patru probleme diferite, iar amestecarea lor în „nu funcționează” irosește o dimineață.

Rulează comparația în interiorul containerului care eșuează, cu un timeout ca un firewall tăcut să nu țină terminalul minute în șir. Un container nou reproduce contextul de rețea al motorului, dar nu spațiul de nume, variabilele de proxy sau resolverul containerului aplicației, așa că docker exec în containerul real este testul autoritativ, iar un container lateral este doar o modalitate de a izola dacă diferența este în motor sau în container:

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

Imaginea de bază alpine conține busybox și nu conține curl, iar acesta este exact tipul de detaliu care face un bloc de diagnostic copiat să eșueze: alege o imagine cu clientul sau adaugă-l în aceeași rulare. O comparație cu site-uri publice fără legătură nu izolează nimic. Dacă https://example.com funcționează din container, ai aflat că containerul are acces la internet și nimic despre dacă ajunge la o adresă privată prin tunel. La fel, deschiderea unui terminal nou dovedește doar că terminalul nou funcționează, nu că împarte un runtime cu aplicația care a eșuat.

Docker Desktop poate funcționa cu un VPN

Propria documentație a Docker despre VPN și conectivitatea cu gazda descrie acest lucru ca o configurație acceptată, iar rezumatul onest este că funcționează în loc să fie stricat automat. Nu presupune că VM-ul de desktop ocolește tunelul gazdei prin proiectare; în multe configurații traficul urmează corect tunelul gazdei, și de aceea legenda „Docker ignoră VPN-ul” produce sfaturi încrezătoare și greșite.

Ce mai contează este backend-ul folosit, politica de split-tunnel a clientului și configurația resolverului pe care a primit-o VM-ul. Un client VPN care instalează rute dar nu DNS, sau care împinge un server DNS la care VM-ul nu poate ajunge, produce o eroare de căutare a numelui în container, în timp ce gazda funcționează pentru că are un resolver suplimentar sau un răspuns din cache. Este o problemă de resolver în costum de container. Supraviețuiește fiecărei reconectări VPN pe care o încerci, pentru că tunelul transportă deja traficul pe care i l-ai cerut.

Suprapunerile de adrese și MTU sunt eșecuri diferite

Două eșecuri merită diagnostic propriu pentru că sunt adesea confundate cu politica de acces. Primul este o suprapunere de adrese: dacă VPN-ul împinge un interval care se ciocnește cu subrețeaua podului implicit al unei rețele de containere, ruta containerului pentru acel interval indică podul local și nu ajunge niciodată la tunel. Inspectează subrețelele reale în loc să ghicești:

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

Al doilea este o problemă de MTU. Dacă conexiunea se stabilește și TLS se finalizează, dar răspunsurile mai mari se blochează, ai o problemă de dimensiune a pachetului, nu de autorizare, iar înlocuirea înregistrărilor DNS nu o va rezolva niciodată. Testează cu o cerere mică și una mare înainte de a schimba ceva, și notează ambele rezultate.

Soluția pentru o suprapunere este o altă subrețea de container sau o rută limitată, aleasă de cel care deține planul de adrese. Soluția pentru un blocaj de MTU este strângerea sau reducerea MTU a tunelului sau interfeței la o valoare care supraviețuiește căii, aplicată la nivelul pe care îl controlezi.

Configurația proxy este pe proces, nu pe mașină

În interiorul unui container, localhost numește contextul de rețea propriu al containerului, așa că un proxy care rulează pe gazdă nu este accesibil acolo sub acel nume. Docker Desktop oferă host.docker.internal pentru accesul la gazdă, iar pe Linux îl adaugi explicit cu --add-host=host.docker.internal:host-gateway. În orice caz, acel nume îți dă o rută către gazdă; nu creează un serviciu de proxy și nu te autorizează să folosești unul.

Folosește adresa și portul de proxy furnizate pentru mediul real și verifică cine le citește. Variabilele exportate într-un shell interactiv nu configurează automat fiecare extensie de editor, server de limbaj, instrument de build și daemon din fundal. Contează procesul care a făcut cererea eșuată, așa că inspectează mediul acestuia, nu pe cel al terminalului tău.

În final, lasă corectura să se explice singură. O soluție utilă numește granița care era greșită, setarea care a schimbat-o și setul de procese afectate acum. Repornirea VPN-ului, a editorului și a motorului în succesiune poate schimba simptomul, dar nu lasă nimic pe care următoarea persoană să îl poată folosi.