SSTP eșuează acolo unde HTTPS din browser reușește: de ce
SSTP rulează în interiorul TLS pe portul 443, dar nu este o cerere web. Testați TCP, identitatea TLS, schimbul SSTP și autentificarea PPP ca etape separate.
Browserul deschide numele de gazdă al VPN prin HTTPS fără nicio obiecție, iar clientul SSTP continuă să refuze conectarea. Nimic din această pereche nu este contradictoriu. SSTP folosește TLS ca transport exterior și apoi execută propria cerere și sarcina utilă PPP în acea conexiune, deci o încărcare reușită a paginii demonstrează doar un lucru îngust: gazda răspunde la un GET pe portul 443. Clientul pune o altă întrebare, iar serverul poate răspunde prost.
Pagina se încarcă, iar tunelul nu
Oamenii apelează la testul din browser pentru că este rapid, apoi iau rezultatul drept dovadă că serverul este accesibil și configurat. Este o dovadă despre un GET către calea deschisă de bara de adrese, nimic mai mult. Conversația VPN începe după același handshake TLS, dar trimite o metodă și o cale pe care o pagină web nu le folosește niciodată. Așadar, un răspuns 200 pentru browser nu spune nimic despre existența punctului final SSTP.
Separați cele două observații și căutarea se scurtează. Transportul și lanțul de certificate funcționează, iar ceva din schimbul de protocol de deasupra lor nu funcționează. Este o investigație diferită de cea a unui port defect sau a unui certificat expirat și cere alte dovezi.
Ce trimite de fapt clientul SSTP
Clientul trimite o cerere HTTP cu metoda SSTP_DUPLEX_POST către calea /sra_{GUID}/, apoi ține corpul conexiunii deschis ca un flux bidirecțional care transportă cadre PPP. Un server conform răspunde HTTP/1.1 200 și încetează să se comporte ca un server web. Orice altceva este o semnătură: 405 sau 404 înseamnă că punctul final nu există, 301 sau 302 înseamnă că ceva redirecționează cererea, iar un FIN imediat înseamnă că un proxy sau server a închis fluxul.
De aceea ținta trebuie să fie un server SSTP, nu un server web cu un certificat TLS înșurubat. Metoda, calea și corpul de lungă durată sunt cerințe ale protocolului, așa că un proxy invers nu le poate adăuga doar prin configurație. Un proxy care redirecționează perfect HTTPS obișnuit poate totuși refuza o metodă pe care nu o recunoaște.
Unde un proxy sau server web rupe fluxul
Un intermediar inspectează linia cererii HTTP înainte de a redirecționa ceva, iar o metodă personalizată cu o cale neobișnuită poate eșua la regulile lui. Unele dispozitive servesc o pagină normală în timp ce resping sau întrerup tunelul, așa că clientul raportează o conexiune care pornește și apoi moare, în loc de un refuz curat. Altele acceptă cererea, apoi aplică un timeout de corp sau de inactivitate pe care keepalive-urile PPP nu îl supraviețuiesc. Ambele arată la fel din partea clientului, de aceea etapa care a eșuat contează mai mult decât textul erorii.
Partajarea portului 443 între un site web și SSTP este o alegere de rutare, nu o promisiune că fiecare hop tratează cele două conversații la fel. Dacă pe traseu se află un balansator de încărcare, un firewall sau un terminator TLS, adăugați-l pe lista suspecților înainte de a atinge configurația VPN.
Testați etapele separat
Rulați verificările în ordine și opriți-vă la prima eșuare, pentru că fiecare etapă exclude un alt strat. Sonda TLS de mai jos separă identitatea certificatului de tot ce face SSTP. Înlocuiți numele de gazdă cu punctul final propriu și citiți subject-ul și lanțul pe care le afișează.
openssl s_client -connect vpn.example.com:443 -servername vpn.example.comApoi mapați dovezile rămase pe etape în loc să ghiciți din eroarea clientului. Tabelul de mai jos este lista de verificare de citat în tichet, cu semnătura care separă o eșuare de următoarea.
| Stage | What it proves | Failure signature |
|---|---|---|
| TCP to 443 | A listener exists and the path is open | Timeout or connection refused |
| TLS with SNI | The certificate matches the name you use | Name mismatch or untrusted chain |
| SSTP_DUPLEX_POST exchange | The endpoint is an SSTP server | 405, 404, 301 or an early FIN |
| PPP authentication | The user credential was accepted | Auth failure after a 200 response |
| Inner routing | A permitted destination is reachable | Tunnel up, no reply from the target |
Notați în tichet ultima etapă care a reușit în loc să scrieți "nu se poate conecta". Specificația MS-SSTP documentează cererea și schimbul PPP care urmează după handshake-ul TLS și este referința pentru de ce un test în browser nu poate înlocui niciuna dintre ele.
Mai întâi identitatea, apoi PPP
Identitatea TLS și autentificarea PPP sunt secvențiale, nu alternative, iar confundarea lor duce oamenii la setarea greșită a serverului. Clientul validează mai întâi certificatul serverului și scopul său prevăzut, apoi PPP negociază propria stare și autentifică utilizatorul cu o metodă challenge-response sau EAP. O problemă de certificat produce o eroare diferită de o parolă respinsă, iar niciuna dintre erori nu descrie etapa pe care o acoperă cealaltă.
Înlocuirea numelui de gazdă cu o adresă, sau clicarea dincolo de avertismentul de certificat, elimină verificarea care ar fi identificat etapa eșuată în loc să o repare. Păstrați avertismentul și citiți-l. De asemenea, nu resetați o parolă PPP când schimbul HTTP nu a ajuns niciodată la comportamentul SSTP, pentru că acreditările nu au fost niciodată cerute.