Internetul funcționează doar cu aplicația VPN pornită? Verificați patru straturi

Încercați un client VPN gratuit sau o extensie de browser pentru o săptămână, îl opriți, iar internetul se oprește. Pictograma Wi-Fi arată în continuare o conexiune, celelalte dispozitive din același router funcționează, iar singurele lucruri care readuc navigarea sunt repornirea aplicației sau dezinstalarea ei. Acest tipar nu este criptarea care creează o dependență. Este configurația pe care aplicația a scris-o undeva unde tunelul nu o deține.

Clientul modifică setări pe care tunelul nu le deține

Un client de confidențialitate pe Windows sau macOS atinge de obicei trei locuri deodată. Setează proxy-ul HTTP de sistem, același câmp pe care îl expune Opțiuni internet. Instalează un adaptor virtual, adesea un driver TAP, ca să poată captura pachete. Și rescrie lista de resolvere, în timp ce doar tunelul dispare când apăsați deconectare.

O extensie de browser este un lucru mai îngust. De obicei își schimbă propriul profil sau proxy-ul pe care îl urmează un singur browser. De aceea un singur browser poate eșua în timp ce instrumentele din linia de comandă funcționează, sau invers: extensia nu a avut niciodată autoritatea de a atinge celelalte straturi. Stratul pe care l-a modificat decide ce instrumente se strică.

În orice caz, decizia rămasă în urmă a fost luată de un software care nu avea niciun motiv să o anuleze. Tunelul era partea vizibilă și era și singura parte cu o cale de oprire curată. Restul este o setare într-un depozit care supraviețuiește procesului, așa că eliminarea aplicației este singurul pas care le inversează pe toate trei deodată. Citirea acestor depozite înainte de a reinstala orice este ceea ce transformă simptomul în diagnostic.

Trei rămășițe, trei defecțiuni diferite

Prima rămășiță este un proxy care nu duce nicăieri: caseta proxy-ului LAN încă bifată, sau un URL de script de configurare îndreptat spre un port localhost unde nu mai ascultă niciun proces. Browserul trimite fiecare cerere către acel port mort și se blochează până când expirarea pare o rețea moartă. A doua este un adaptor care încă deține o rută implicită, pentru că un dispozitiv TAP-Windows sau un driver de rutare al furnizorului rămâne o interfață reală după dezinstalare. Își păstrează ruta primită, iar traficul dispare într-un tunel care nu există. Nicio rămășiță nu se anunță singură; ambele arată exact ca o pană.

A treia este DNS, și eșuează mai devreme decât celelalte două. Dacă lista de resolvere conține doar servere accesibile prin tunel, fiecare căutare expiră înainte de a fi cerută o singură pagină, așa că browserul raportează un site inaccesibil, nu un proxy mort. Oricare ar fi, niciuna nu este o pană în sensul rețelei. Fiecare este o rămășiță pe care nimeni nu a revocat-o și fiecare se repară într-un loc diferit.

Parcurgeți cele patru straturi

Începeți cel mai aproape de aplicație și coborâți, pentru că straturile eșuează în acea ordine a vizibilității. Schimbați un singur strat per test și retestați după fiecare. Resetarea tuturor deodată readuce de obicei navigarea și vă lasă incapabil să spuneți care rămășiță a cauzat-o, așa că următoarea instalare recreează același puzzle. Ordinea este proxy, adaptoare, rute, resolvere.

Pe Windows fiecare verificare este o singură comandă care vine cu sistemul de operare, așa că nu trebuie instalat nimic. Rulați-le în ordine și păstrați rezultatul împreună, pentru că cele patru răspunsuri au sens doar alăturate. Ele raportează proxy-ul, adaptoarele, rutele IPv4 și lista de resolvere, în această ordine:

netsh winhttp show proxy
Get-NetAdapter
route print -4
Get-DnsClientServerAddress

Linux și macOS au nevoie de comenzile lor, și nu sunt interschimbabile. Pe Linux rutele vin de la ip route, iar resolverul de la resolvectl status acolo unde systemd-resolved îl deține, cu revenire la cat /etc/resolv.conf. Pe macOS rutele vin de la netstat -rn, resolverii de la scutil --dns, iar proxy-ul de sistem de la scutil --proxy. Un cititor macOS care rulează ip route primește command not found, iar /etc/resolv.conf de acolo este un stub generat, nu configurația autoritativă. Verificați platforma înainte de a verifica stratul, altfel prima comandă devine constatarea.

Pentru fiecare strat puneți o singură întrebare: această valoare mai indică ceva ce există în timp ce aplicația este închisă? Un proxy la un port mort, un adaptor fără tunel, o rută implicită printr-o interfață căzută și un resolver în interiorul tunelului răspund toate nu. Orice singur nu este suficient pentru a explica simptomul, de aceea contează o singură schimbare per test.

Un proxy nu este un tunel

Un proxy acceptă o cerere, o preia în altă parte și returnează răspunsul, ceea ce înseamnă că știe destinația și vede tot ce site-ul nu a criptat singur. Nu transportă alte protocoale. Nu protejează calea decât dacă destinația folosește deja TLS. Și poate fi schimbat de orice l-a instalat, fără implicarea dumneavoastră.

Această distincție schimbă întrebarea care merită pusă. Când rămâne un proxy, aflați ce program vă mai dirijează browserul, nu dacă tunelul este pornit. Tunelul poate fi perfect sănătos și complet irelevant pentru defecțiune.

Dacă vreți să știți ce a făcut de fapt un astfel de client, observați-l în loc să citiți tabloul de bord. Process Monitor înregistrează ce chei de registru și fișiere atinge, iar o captură de pachete arată unde s-a dus traficul. Ambele sunt instrumente obișnuite și ambele răspund mai bine la întrebarea despre rămășiță decât orice led de stare. Niciuna nu cere ca aplicația să ruleze încă.

Eliminați componenta, nu dovada

Remedierea durabilă este să eliminați lucrul care a scris setarea. Dezinstalați aplicația, ștergeți adaptorul virtual pe care l-a adăugat, curățați proxy-ul și lista de resolvere, apoi reporniți și testați cu aplicația încă dezinstalată. Dacă navigarea funcționează în acel moment, ați găsit cauza, nu o soluție de ocolire. Notați care strat era învechit, pentru că același furnizor tinde să livreze aceeași greșeală de două ori.

Dacă simptomul revine după ce instalați următorul client, parcurgeți din nou cele patru straturi înainte de a decide că serviciul a stricat ceva. Dovada este de obicei încă acolo, în unul dintre cele patru locuri. O a doua aplicație nu creează un al cincilea strat; ea modifică unul dintre cele patru.

Reinstalarea resetează proxy-ul, dar nu un adaptor învechit, și poate lăsa două resolvere în listă. Această asimetrie este motivul pentru care dezinstalare-apoi-test bate un buton de resetare totală. Vă oferă și o linie de bază pentru comparație data viitoare când conexiunea cade.