Ce protocoale oferă de fapt acest nod VPN public?
Faptul că software-ul serverului acceptă un protocol nu înseamnă că acest nod l-a activat. Verificați punctul final, profilul și etapa care eșuează de fapt.
Software-ul îl acceptă, deci nodul îl oferă. Această deducție e greșită suficient de des încât să fie o regulă: o implementare SoftEther poate activa orice submulțime a metodelor sale de conectare compatibile, iar un nod public este o implementare cu un proprietar și o configurație. Cu ce vă puteți conecta depinde de acel nod, nu de lista de funcții a proiectului pe care îl rulează. Exact în decalajul dintre cele două trăiesc de fapt majoritatea tichetelor „protocolul e stricat”.
Ce promite de fapt lista proiectului
Funcțiile de protocol ale proiectului descriu ce poate face serverul. Un anumit nod activează unii dintre acești ascultători și nu alții, iar operatorul poate schimba acea mulțime fără să atingă versiunea software-ului. De aceea două noduri din aceeași compilare se comportă diferit, iar un profil care funcționează împotriva unuia nu demonstrează nimic despre următoarea țintă. Lista nodului însuși cântărește mai mult decât pagina proiectului atunci când alegeți unde să vă conectați.
Citiți lista ca cinci câmpuri, nu ca un meniu: punct final, port, transport, familie de protocoale și metodă de autentificare. Un nod public care anunță SSTP v-a spus despre un ascultător pe un port; nu v-a spus ce certificat prezintă sau dacă contul dumneavoastră funcționează acolo. Compararea acestor cinci câmpuri cu profilul dumneavoastră este mai rapidă decât orice cantitate de reinstalare a clientului și produce o așteptare scrisă pe care o puteți testa mai târziu.
Potriviți profilul cu punctul final pe care îl numește
O intrare SoftEther nativă nu este automat o configurație OpenVPN, chiar și atunci când ambele apar pe o pagină de furnizor sub un singur titlu. Când un nod publică atât un ascultător TCP, cât și unul UDP pentru OpenVPN, tratați-le ca două puncte finale: un profil editat de la unul la celălalt indică un ascultător pe care nimeni nu l-a activat. Eticheta de transport din fișier face parte din adresă, nu este o setare cosmetică.
Faptul că clientul acceptă un fișier importat stabilește că fișierul se parsează. Nu spune nimic despre dacă un ascultător aflat la distanță așteaptă la celălalt capăt, de aceea prima încercare de conectare este testul real. Comparați linia remote a profilului cu gazda și portul anunțate ale nodului înainte de a da vina pe protocol.
Sondați etapa care eșuează
O gazdă care răspunde la traficul web poate totuși să nu aibă serviciul VPN dorit, iar o gazdă care refuză un protocol nu este neapărat căzută pentru toate. Aceste două greșeli trimit oamenii în direcții opuse în aceeași după-amiază. Unul urmărește un firewall care este în regulă; celălalt reinstalează un client care nu a fost niciodată problema. Sondați fiecare cale separat, astfel încât răspunsul să descrie un ascultător și nu întreaga gazdă.
Aceste cinci verificări acoperă metodele obișnuite ale nodurilor publice. Rulați-le din aceeași rețea pe care o folosește clientul, pentru că un port filtrat arată identic cu un ascultător lipsă de la distanță.
nc -vz node.example 1194
nc -vz node.example 443
openvpn --config client.ovpn --verb 4
nmap -sU -p 500,4500 node.example
openssl s_client -connect node.example:443 -servername node.example| Rezultat | Etapă | Ce exclude |
|---|---|---|
| Conexiune refuzată sau timp expirat | Transport | Ascultător lipsă, filtrat sau port greșit |
| Eroare de strângere de mână TLS sau de identitate | Certificat | Disponibilitatea protocolului; ascultătorul a răspuns |
| AUTH_FAILED sau respingerea contului | Autentificare | Punctul final; problema sunt acreditările |
| UDP 500 și 4500 tăcute | Negocierea IPsec | ESP și L2TP sunt blocate înainte de autentificare |
Asociați fiecare eroare observată cu rândul ei înainte de a schimba ceva. O eroare de identitate TLS dovedește că ascultătorul există, așa că rescrierea profilului către alt protocol ar arunca o dovadă funcțională. O conexiune refuzată dovedește doar că acest port nu a răspuns, ceea ce este o afirmație mult mai îngustă decât „nodul nu acceptă OpenVPN”.
Păstrați eroarea înainte de a schimba ceva
Notați rezultatul exact: un timp expirat, o eroare de identitate a certificatului, o respingere a contului și o refuzare la nivel de aplicație sunt patru rezultate diferite. Doar primul privește un protocol indisponibil, iar doar ultimul privește permisiunea după o conexiune reușită. Resetarea clientului sau schimbarea protocoalelor distruge acea distincție, pentru că următoarea eroare vine cu alt istoric și fără o linie de bază pentru comparație.
Nu slăbiți verificarea pentru a face un profil incompatibil să pară că funcționează. O verificare a certificatului dezactivată transformă o eroare clară de identitate într-o conexiune la ceva la care nu intenționați să ajungeți, iar succesul rezultat este mai rău decât eroarea originală pentru că ascunde care etapă era greșită.
Verificați din nou pentru fiecare nod, de fiecare dată
Opțiunile native SSL, OpenVPN, L2TP/IPsec și SSTP dintr-o listă de nod public descriu configurația acelui nod în acel moment. Același software în altă parte poate prezenta un set diferit, iar un furnizor poate retrage un ascultător între semnul de carte și următoarea încercare. Notele vechi descriu implementări vechi.
Înregistrați profilul verificat cu punctul lui final și metoda, apoi repetați sondajul când nodul se schimbă sau conexiunea începe să eșueze. Specificația protocolului SoftEther este referința pentru ce poate face software-ul; lista nodului însuși este referința pentru ce face el. Țineți cele două documente separate și diagnosticul devine mai scurt.