De ce eșuează unele site-uri doar când VPN-ul este pornit?

Un singur site care eșuează în timp ce restul se încarcă delimitează repede defectul. Citește eroarea, testează rezolvarea numelor, apoi măsoară dimensiunea pachetelor înainte de a atinge clientul.

Faptul că un singur site eșuează în timp ce restul se încarcă dovedește că tunelul transportă trafic, ceea ce restrânge problema mai mult decât se așteaptă majoritatea. Trei observații sortează restul: dacă ai primit deloc un răspuns HTTP, dacă numele gazdă s-a rezolvat într-o adresă și dacă cererile mici trec în timp ce cele mari se blochează. Ghiceala la VPN înainte de a avea acele răspunsuri mută de obicei defectul în loc să-l rezolve.

Parcurge observațiile în ordine, fiindcă un site care a răspuns nu poate fi eșuat și la rezolvare. Dacă nu se încarcă absolut nimic, ești în ramura greșită și se aplică verificările pentru conectat dar fără internet.

Lasă mesajul de eroare să aleagă ramura

Un refuz, o provocare antibot sau o pagină de eroare înseamnă că serviciul a răspuns, deci pachetele au ajuns la o aplicație și s-au întors. Asta mută întrebarea la politica de acces a site-ului, care poate cântări adresa de ieșire, contul sau tipare de cereri pe care nu le publică. Un defect de rezolvare a numelor nu a ajuns deloc la site, iar adresa este primul lucru de inspectat. Un timp de așteptare stă între cele două: s-a trimis ceva și nimic nu l-a confirmat.

Avertismentele de certificat aparțin unei a patra ramuri. Ele înseamnă că conexiunea a fost răspunsă de ceva a cărui identitate browserul nu a putut-o verifica, fie un proxy de partea ta, fie o nepotrivire reală prin care nu ar trebui să dai clic. Tratează asta ca o chestiune de încredere, nu de rutare.

Un site care răspunde nu a dovedit un tunel stricat

Când răspunsul este o pagină de blocare, compară aceeași pagină printr-o a doua ieșire păstrând browserul și mașina neschimbate. Dacă rezultatul urmează adresa de ieșire, site-ul tratează altfel acea adresă, și nicio configurație de client nu-l va face să se răzgândească. Dacă blocarea urmează în schimb browserul tău, cauza stă într-o extensie, un proxy salvat sau o setare a resolverului. Două rulări separă aceste explicații ieftin.

Defectele doar din browser sunt destul de frecvente pentru a fi testate devreme. O pagină care se încarcă într-un browser acceptat și eșuează în altul indică starea profilului, un blocant de conținut sau DNS criptat configurat în interiorul browserului însuși. Indicațiile Chrome despre DNS sigur arată unde se află acea setare, iar schimbarea ei prin controlul acceptat bate resetarea dispozitivului.

Când se blochează doar transferurile mari, uită-te la dimensiunea pachetelor

O pagină care își desenează antetul și apoi se blochează are o semnătură diferită de o pagină care nu pornește niciodată. Răspunsurile mici pot trece în timp ce o încărcătură de dimensiune completă este aruncată undeva care nu poate semnala expeditorului, și așa arată un defect de MTU de cale văzut din browser. Compară o cerere minusculă și una mare către aceeași gazdă înainte de a teoretiza despre filtrare. Descoperirea MTU de cale ar trebui să învețe cea mai mică dimensiune de legătură de-a lungul căii, și depinde de răspunsuri ICMP pe care rețelele filtrate le aruncă în mod obișnuit.

Testează această ipoteză cu o baleiere de dimensiuni în loc de un singur ping. Un defect care începe la o dimensiune constantă a încărcăturii este o dovadă puternică, în timp ce unul care se mută nu este.

Confirmă remedierea pe cererea care a eșuat

Retestează operația originală, nu pagina de start, fiindcă o coajă din cache se poate desena în timp ce apelul API din spatele unei autentificări încă eșuează. Comenzile de mai jos separă rezolvarea numelor, o cerere mică și una mare către aceeași gazdă. Înlocuiește numele gazdă și calea cu cele din cererea care s-a stricat cu adevărat.

dig +short www.example.com
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://www.example.com/
curl -sS -o /dev/null -w '%{http_code} %{size_download}\n' https://www.example.com/assets/app.js
ping -M do -s 1400 -c 3 203.0.113.20

Dacă răspunsul dig diferă de cel pe care l-a folosit browserul, resolverul este variabila, iar setarea DNS a browserului este locul unde să te uiți. Dacă cererea mică returnează un status în timp ce cea mare se blochează, lucrează ramura dimensiunii pachetelor. Dacă ambele expiră, calea de ieșire și modul în care site-ul tratează acea adresă revin pe masă.

Păstrează schimbarea care a făcut să reușească cererea originală și anulează restul. O grămadă de modificări simultane la browser, resolver și client te lasă incapabil să spui care a contat.

Articole similare