VPN pornit și localhost nu mai funcționează: nume, proxy sau bind?

Serverul tău de dezvoltare a răspuns acum un minut, iar acum că tunelul este activ cererea expiră cu un nume de gazdă pe care nu l-ai tastat niciodată. Aproape fiecare caz este explicat de două mecanisme, iar din exterior par identice. Un sufix de căutare transformă un nume scurt într-unul corporativ, în timp ce un proxy trimite traficul loopback către o gazdă care nu îl poate atinge. Separarea celor două costă o interogare și economisește regula de firewall pe care erai pe punctul de a o scrie.

Când localhost se rezolvă în zona corporativă

Verifică în ce se rezolvă numele cât timp tunelul este activ, apoi rulează aceeași interogare cu tunelul oprit și compară cele două răspunsuri. Indiciul este o adresă din intervalul corporativ acolo unde te așteptai la 127.0.0.1. O înregistrare precum localhost.mycompany.corp învinge intrarea loopback imediat ce clientul adaugă acel sufix în lista de căutare, iar cererea călătorește către o gazdă privată unde nimic nu ascultă pe acel port. Citește lista de căutare în loc să o ghicești, pentru că un client poate adăuga mai mult de un domeniu, iar ordinea decide care candidat este încercat primul:

getent hosts localhost
resolvectl domain
ss -ltnp | grep 8080

Înlocuiește numele gazdei cu adresa literală în aplicație, în clientul bazei de date sau în URL-ul caietului, apoi repetă cererea. Dacă eroarea dispare, ai avut o problemă de denumire, iar tunelul a fost doar declanșatorul. Dacă persistă, ascultătorul sau ruta este următorul suspect, iar numele a fost doar o pistă falsă.

Setări de proxy care captează loopback

Un proxy de sistem aplicat când tunelul urcă va accepta o cerere către 127.0.0.1 și o va trimite mai departe unui proxy îndepărtat care nu are idee ce ai vrut să spui. O listă de excepții goală transformă o cerere locală într-una îndepărtată, iar mesajul de eroare spune rar acest lucru. Adaugă adresele loopback în lista de excepții pentru întreaga sesiune și nu pentru o singură comandă, apoi confirmă că instrumentul le respectă înainte de a trage vreo concluzie despre rețea.

Framework-urile de aplicație citesc propriile variabile de mediu și uneori propriul fișier de configurare, așa că o excepție care funcționează pentru un instrument nu dovedește nimic pentru următorul. Browserele adaugă o nuanță: browserele bazate pe Chromium ocolesc implicit proxy-ul pentru loopback, iar un token de excepție poate elimina acest comportament. Verifică decizia efectivă a proxy-ului în loc să presupui că setarea sistemului de operare este toată povestea. Două comenzi rezolvă acest lucru pentru orice este lansat dintr-un shell:

curl --noproxy '*' http://127.0.0.1:8080/health
NO_PROXY=localhost,127.0.0.1,::1 your-tool

Adresa de bind decide cine se poate conecta

Un server pornit pe 127.0.0.1 acceptă conexiuni doar de pe acea mașină, ceea ce este de obicei valoarea implicită corectă pentru dezvoltare. Un server pe 0.0.0.0 răspunde pe fiecare interfață, inclusiv adaptorul VPN, ceea ce este mai multă expunere decât intenționează majoritatea oamenilor. Când adresa literală loopback eșuează, verifică bind-ul înainte de orice altceva.

Uită-te la socket-ul care ascultă și notează adresa de care este legat, nu doar portul. Dacă un alt dispozitiv sau un container trebuie să atingă serviciul prin tunel, leagă-l de interfața specifică pe care o va folosi și permite acel port în mod deliberat. Dacă doar mașina ta are nevoie de el, păstrează bind-ul îngust și corectează clientul în loc să lărgești serverul. Un port forwarding sau un strat de tuneluri poate uni cele două, dar fiecare adaugă o componentă care va avea nevoie de propria depanare mai târziu.

Unde un instrument de depanare așteaptă LAN-ul

Instrumentele de depanare poartă presupuneri pe care un tunel le rupe în tăcere. Un bridge de depanare pentru telefon își pierde dispozitivul când VPN-ul captează subrețeaua dispozitivului, așa că reconectarea prin adresa LAN sau un cablu evită conflictul. Un hub de automatizare a browserului expiră când hub-ul este accesibil doar prin proxy, sau când un firewall local îi aruncă portul de control. Un debugger la distanță poate cere elevare și o adresă loopback acolo unde clientul a rescris ruta.

Identifică portul de control și portul de date separat, pentru că des unul supraviețuiește în timp ce celălalt nu. Apoi decide dacă remedierea aparține configurației instrumentului, unei rute pentru acea subrețea sau unei reguli de tunelare divizată. Editarea unui fișier hosts pe fiecare mașină de dezvoltator scalează cel mai prost și este uitată prima. Preferă setarea care trăiește cu profilul și poate fi revizuită de oricine deține tunelul.

Oprește-te la prima etapă care eșuează

Coboară prin trei etape: rezolvă numele, deschide un socket către adresa literală, apoi lasă instrumentul să își facă propria conexiune. Fiecare etapă elimină un strat, așa că primul eșec numește stratul de corectat, iar tot ce urmează rămâne netestat. Notează rezultatul înainte de a schimba ceva, pentru că o remediere aplicată înainte de măsurare nu se poate distinge de noroc. Dacă prima încercare eșuează și o repetare funcționează, tunelul probabil nu era gata când instrumentul a pornit.

Înlocuiește așteptarea fixă cu o verificare de disponibilitate limitată care așteaptă ruta, și păstrează etapa care eșuează în jurnal ca următoarea persoană să vadă unde s-a oprit. Un instrument care se repară singur nu este reparat, este norocos, iar norocul se termină pe mașina altcuiva. Schimbă tunelul ultimul, și doar pentru etapa care a eșuat cu adevărat. Acea ordine este și cea mai scurtă cale înapoi la o construcție funcțională, pentru că te oprește să reconstruiești o componentă care nu a fost niciodată implicată.