VPN conectat, dar fără internet? Parcurge cele patru straturi

Clientul spune conectat, browserul se învârte, iar fiecare site se termină într-un timeout. Combinația este obișnuită și nu e o contradicție: conectat înseamnă că tunelul a negociat, și nimic mai mult. Rezolvarea numelor, rutarea și ieșirea proprie a serverului eșuează fiecare în felul său, și fiecare are alt proprietar. Parcurge straturile în ordine și oprește-te la primul care eșuează.

Începe cu rețeaua din care ai venit

Oprește tunelul cu controlul propriu de deconectare al clientului, apoi încearcă două site-uri HTTPS fără legătură, dacă politica permite. Lasă munca sensibilă închisă pe durata testului. Dacă și accesul obișnuit eșuează, VPN-ul nu este primul suspect.

Uită-te la legătura Wi-Fi, la router și la orice pagină de portal care cere autentificare înainte de a atinge tunelul. Un kill switch poate bloca traficul cât timp ești deconectat prin proiectare, așa că urmează procedura de test documentată în loc să concluzionezi că rețeaua este moartă. O altă rețea de încredere este o comparație utilă, iar o ieșire VPN nouă nu va finaliza o autentificare de hotel expirată. Dacă rețeaua deschisă funcționează și tunelul nu, rețeaua este exonerată și următorul strat este al tău.

Decide dacă eșecul este de rezolvare a numelor

Notează textul erorii, pentru că eșecul de rezolvare, timeout-ul și avertismentul de certificat indică fiecare altundeva. Modelul de prins devreme este un nume de gazdă niciodată vizitat care eșuează în timp ce o aplicație cu sesiune deschisă continuă. Acel model privește interogările noi, nu dacă tunelul transportă pachete. O singură interogare arată ce returnează resolverul și durează o secundă. Încearcă și un al doilea nume, ca un răspuns din cache sau o înregistrare stricată să nu decidă diagnosticul.

nslookup example.com

Un IP arbitrar în bara de adrese HTTPS nu este un test DNS, pentru că certificatul și gazda virtuală depind de obicei de nume. Numele interne pot necesita resolverul organizației în locul unui înlocuitor public, iar un browser cu propriul resolver securizat poate răspunde diferit de interogarea sistemului de operare. Unde cele două diferă, resolverul browserului este cel pe care îl trăiește utilizatorul, iar distincția aparține tichetului.

Tunel complet sau doar subrețelele companiei

Unele profiluri există doar pentru a ajunge la câteva subrețele ale companiei; altele sunt construite să transporte tot și au nevoie de o ieșire funcțională în spate. Citește scopul documentat înainte de a presupune că indicatorul acoperă fiecare aplicație și fiecare familie de adrese. Un profil de rețea privată poate funcționa exact cum a fost proiectat, în timp ce browserul, care nu ar fi trebuit să-l folosească niciodată, încă eșuează. Citește tabelul de rutare fără să-l modifici și include IPv6, pentru că o cale IPv4 funcțională nu spune nimic despre cealaltă familie.

O rută mai specifică poate câștiga în timp ce ruta implicită încă există, de aceea tabelul trebuie citit, nu presupus. Adaptoarele virtuale concurente pot deține trafic pe care îl așteptai în altă parte, mai ales după ce un al doilea client VPN a fost instalat și uitat. Nu șterge ruta implicită ca experiment; asta transformă un diagnostic într-o a doua cădere.

Un singur site care eșuează între cele care funcționează este o problemă a acelui site și dovedește și că tunelul transportă trafic. Blocajele care apar doar la transferuri mari indică dimensiunea pachetului, nu accesibilitatea.

Când serverul nu transmite niciodată nimic

Dacă fiecare destinație eșuează pe două dispozitive și două rețele de acces, tunelul este pornit, iar ieșirea nu transmite. Exact această pereche separă o defecțiune de partea serverului de un singur dispozitiv configurat greșit într-un singur loc. Trimite operatorului întrebările despre transmitere, NAT și calea de întoarcere, nu o captură a indicatorului.

Cele trei acoperă majoritatea cauzelor de partea serverului, iar răspunsul este al operatorului. Pagina de depanare a conectivității OpenVPN parcurge aceleași întrebări din partea serverului, așa că trimite-o împreună cu tichetul. O captură a unui indicator verde nu răspunde la niciuna.

Parcurge jurnalul clientului după autentificare pentru eșecuri la aplicarea rutelor, a setărilor DNS sau a adaptorului virtual. Erorile din acea etapă indică dispozitivul, nu serverul. O eroare care nu apare niciodată în jurnal este la fel de informativă, pentru că mută suspiciunea pe partea cealaltă.

Verifică un singur strat o dată

După ce schimbi ceva, reconectează-te și repetă exact aplicația care a eșuat. O singură pagină care se încarcă dovedește mai puțin decât o cale repetabilă către resursele pentru care a fost construit profilul. Două comenzi separă rezolvarea de accesibilitate, iar a doua depinde de gazdă. Rulează linia curl oriunde, apoi comanda de rutare care corespunde gazdei din fața ta.

curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://example.com
route print -4          # Windows
ip -4 route show        # Linux
netstat -rn | head      # macOS

Dacă cererea numerică funcționează și numele nu, rămâi la DNS. Dacă niciuna nu funcționează, compară tabelul de rutare cu implicitul așteptat al tunelului și verifică familia pe care o testezi de fapt. Dacă ruta este corectă și cererea moare în continuare la ieșire, întrebarea rămasă este a operatorului, iar dovezile păstrate sunt tichetul.