Portul 443 răspunde, SSTP tot eșuează: care etapă s-a rupt?

Finalizarea unui handshake TCP către portul 443 în timp ce tunelul nu se construiește niciodată dovedește un lucru, și este un lucru mic. Ceva ascultă și este dispus să accepte o conexiune la acea adresă. Nu identifică serviciul, certificatul pe care îl va prezenta sau ce se întâmplă după primii octeți.

Între acel handshake și un tunel funcțional se află patru etape, iar fiecare produce o eroare diferită.

Un port deschis descrie un singur strat

Acceptarea unei conexiuni TCP înseamnă că un proces deține socketul și că calea permite handshake-ul. Nu spune nimic despre dacă acel proces este un server SSTP, dacă are un certificat valabil pentru numele din profilul dumneavoastră sau dacă vă va autoriza contul. Un server web la aceeași adresă răspunde perfect handshake-ului și apoi răspunde cererii SSTP cu o eroare HTTP. Tot ce se află deasupra acelui handshake rămâne netestat.

Tratați testul portului ca pe cel mai ieftin filtru posibil, nu ca pe o sentință. Valoarea lui este că elimină o întreagă categorie de eșecuri, nu că confirmă tot ce se află deasupra.

Confundarea celor două este motivul pentru care oamenii reinstalează clienții după un test care nu a examinat niciodată problema reală a clientului.

Separați cele patru etape cu dovezi

Etapele sunt accesibilitatea transportului, validarea TLS, schimbul SSTP prin HTTPS și autentificarea PPP în interiorul tunelului. O cale care trece de prima și eșuează la a patra necesită o corectare a acreditărilor; una care eșuează la a doua necesită o corectare a certificatului sau a numelui. Aceste reparații nu au nimic în comun, iar alegerea celei greșite irosește întreruperea.

nc -vz vpn.example.net 443
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief
curl -sS -o /dev/null -w '%{http_code}\n' https://vpn.example.net/

A treia comandă merită citită cu atenție. Un 200 de la o pagină web obișnuită vă spune că există un serviciu web; nu vă spune că cererea SSTP va fi înțeleasă. Un 404 de la aceeași adresă este la fel de neinformativ despre VPN. Doar jurnalul clientului vă spune la care dintre cele patru etape a ajuns.

Observați ce nume a folosit fiecare comandă. Certificatul este ales după numele pe care îl trimiteți, așa că o nepotrivire între profil și test este o nepotrivire pe care ați introdus-o dumneavoastră. Scrierea acelui nume lângă rezultat evită confuzia mai târziu.

Citiți succesul parțial în direcția corectă

Un intermediar poate permite navigarea obișnuită și poate refuza schimbul ulterior, de aceea un proxy care funcționează pentru site-uri web poate eșua pentru un tunel. Același tipar apare când un certificat este valabil pentru un nume de browser dar nu pentru numele configurat în profil: browserul este mulțumit și clientul nu, iar amândoi au dreptate cu privire la ce au verificat.

Păstrați validarea serverului activată în timp ce diagnosticați acest lucru. Dezactivarea ei transformă o nepotrivire de certificat într-un handshake reușit și ascunde singura dovadă care ar fi explicat eșecul.

Dacă același profil funcționează din altă rețea, diferența depinde de cale. Asta restrânge căutarea la intermediari fără a spune care, și este încă un pas util înainte. Notați rețeaua pe care ați folosit-o, pentru că comparația nu valorează nimic fără ea.

Apoi testați aplicația, nu doar sesiunea

Odată ce există o sesiune, verificați ruta dorită, rezolvarea numelor și permisiunea serviciului de la clientul care are nevoie de ele. Un tunel conectat poate avea încă o redirecționare lipsă pe partea îndepărtată sau o rută de întoarcere care nu a existat niciodată, iar acele eșecuri arată exact ca o problemă de aplicație pentru persoana care așteaptă.

Păstrați fiecare concluzie legată de etapa care a produs-o. A numi un port deschis un VPN funcțional este modul în care o verificare de certificat de cinci minute devine o zi de reinstalat software.