Timeout al conexiunii VPN: DNS, transport, negociere sau autentificare

„Conexiunea a expirat” este cea mai puțin specifică eroare pe care un client VPN o poate afișa. Înseamnă că o operațiune și-a ratat termenul, iar fiecare etapă, de la rezolvarea numelui până la răspunsul de autentificare, are un termen. Clienții care arată doar mesajul final fac etapele să pară identice, așa că oamenii măresc timeout-ul, schimbă portul și reinstalează profilul, în această ordine, fără să învețe nimic. Compararea etapelor este mai rapidă: fiecare eșuează într-un loc diferit, iar fiecare eșec lasă un alt tip de dovadă.

Patru etape, patru eșecuri diferite

Secvența este fixă chiar și când clientul o ascunde: numele trebuie rezolvat, trebuie stabilit un transport către adresa rezultată, protocolul trebuie să negocieze parametrii și cheile, iar contul trebuie autentificat. Ghidul de depanare a conectivității al OpenVPN urmează aceeași ordine pentru propriul client, iar celelalte îl urmează îndeaproape. Un timeout la a doua etapă și unul la a patra nu au nimic în comun în afară de cuvântul de pe ecran.

Citiți jurnalul pentru ultima linie care indică progres, nu ultima linie dinaintea erorii. Majoritatea clienților afișează ceva precum o adresă rezolvată, un socket stabilit, un handshake început sau o cerere de autentificare, iar etapa care urmează acelei linii este cea care a expirat.

Rezolvarea numelui eșuează înainte de orice contact

Dacă punctul final nu se rezolvă niciodată, clientul nu are cu ce se conecta și nu s-a făcut nicio muncă de transport. Acel eșec este de obicei instantaneu, nu un timeout complet, iar aceasta este cea mai ieftină cale de a-l distinge de restul. Testați numele cu resolverul sistemului și cu un al doilea resolver, și comparați cele două răspunsuri înainte de a concluziona că serverul este căzut.

O adresă veche copiată dintr-o postare de forum este o cauză comună a unui timeout care pare o problemă de server, pentru că adresa aparține acum altcuiva sau nimănui. Folosiți profilul actual al operatorului în loc să înlocuiți o adresă care funcționa înainte. Absența unui răspuns la ping nu este dovadă în nicio direcție: multe puncte finale renunță la ICMP și totuși deservesc foarte bine.

Configurarea transportului așteaptă un pachet care nu va veni

Când DNS-ul este bun și clientul tot consumă tot timeout-ul, stratul de transport este suspectul. Pe TCP puteți testa portul direct; Test-NetConnection pe Windows sau nc -vz pe Linux vă spune dacă ceva acceptă conexiunea, și asta este mai util decât un ping. Pe UDP nu puteți testa la fel, pentru că în acel strat nu există un handshake de finalizat, iar această asimetrie provoacă multe concluzii greșite.

Ce demonstrează un test TCP este limitat: un serviciu care acceptă portul 443 nu este neapărat ascultătorul VPN, iar un punct final doar cu UDP nu are port TCP ca să accepte ceva. Rescrierea unui profil din UDP în TCP nu creează un ascultător pe cealaltă parte; doar schimbă ceea ce așteaptă clientul. Dacă rețeaua filtrează protocolul, schimbarea produce un timeout diferit în aceeași etapă.

Portalele captive merită o verificare proprie în această etapă. Până când portalul autorizează dispozitivul, traficul de ieșire merge la portal și încercarea tunelului pur și simplu atârnă. Finalizați portalul în browser mai întâi, apoi încercați din nou, și nu schimbați profilul cât timp portalul este încă în așteptare.

Negocierea și autentificarea înseamnă că serverul a răspuns

Odată ce tunelul ajunge la server, clientul începe un handshake și eroarea își schimbă caracterul. O oprire aici ține de compatibilitate, nu de accesibilitate: versiuni de protocol nepotrivite, o setare de cifrare sau de canal de date pe care cealaltă parte nu o va accepta, sau un profil care așteaptă o funcție pe care serverul nu o oferă. OpenVPN și-a mutat valorile implicite de negociere între versiunile majore destul de des încât un profil scris pentru o generație poate ajunge la server și totuși nu se ridică.

Autentificarea este ultima etapă și cea mai ușor de citit greșit. Un refuz explicit este un răspuns, ceea ce înseamnă că traseul funcționează, iar problema este identitatea, certificatul sau starea contului. Un flux de autentificare unică bazat pe browser este al treilea caz: clientul așteaptă o acțiune pe care nu ați făcut-o sau un browser pe care nu îl poate lansa, și nu va veni nimic până nu finalizați acel pas.

Comparați dovezile înainte de a schimba reîncercarea

Țineți dispozitivul și profilul fixe și schimbați câte o singură chestiune, începând cu rețeaua. Dacă același profil se conectează pe un hotspot de telefon și expiră pe Wi-Fi-ul hotelului, variabila este traseul, nu serverul. Dacă eșuează peste tot, variabila este profilul sau punctul final. Dacă eșuează doar la o anumită oră, notați marcajul de timp și comparați-l cu evenimente din partea serverului înainte de a presupune ceva despre încărcare.

Pentru un serviciu pe care îl administrați, comparația decisivă este dacă încercarea ajunge măcar. O conexiune care ajunge la ascultător și apoi se blochează aparține etapei de negociere; una care nu apare niciodată în viziunea ascultătorului este o problemă de transport sau de rezolvare, iar nicio reglare a reîncercărilor nu o va mișca. Jurnalele serverului separă, de asemenea, o autentificare respinsă de o cădere silențioasă, ceea ce este diferența dintre o corectare de identitate și una de firewall.

Notați versiunea clientului, numele profilului, ora încercării cu fusul orar și prima eroare utilă în locul ultimei linii de deconectare. Eliminați cheile și materialul care conține acreditări înainte de a partaja extractul. Apoi faceți o corectare semnificativă și reîncercați, pentru că un termen mai lung ajută doar operațiunea lentă documentată și nu face nimic pentru o adresă greșită sau un port blocat.