Timeout SSTP sau eroare de certificat: cum le deosebești

O conexiune SSTP eșuează în două feluri care arată la fel de pe scaunul utilizatorului, iar reparația fiecăruia stă pe un strat diferit. Un timeout înseamnă că un schimb necesar nu s-a terminat niciodată; o eroare de certificat înseamnă că materialul de identitate a sosit și a fost respins. Tratarea celui de-al doilea ca primul te duce spre firewall-uri și parole care nu au fost niciodată problema. Dovada care le distinge este în jurnalul clientului însuși, dacă îl citești înainte de a schimba ceva.

Două eșecuri, două schimburi diferite

SSTP transportă un tunel într-o sesiune cu formă de HTTPS, de aceea supraviețuiește în rețele care nu permit nimic altceva decât 443. Clientul finalizează un handshake TLS, trimite o cerere HTTP cu o metodă specifică protocolului, iar apoi tunelul rulează în acel flux. Un eșec la oricare dintre acele etape oprește conexiunea, iar doar cele ulterioare implică date de autentificare.

Acea ordine este diagnosticul. Dacă handshake-ul TLS nu se finalizează niciodată, nu a fost trimisă nicio dată de autentificare, deci resetarea parolei nu poate ajuta. Dacă handshake-ul se finalizează și apoi se blochează, identitatea a fost acceptată și ceva din calea cererii a respins-o. Dacă handshake-ul eșuează cu un mesaj de validare, serverul a răspuns, iar clientului nu i-a plăcut ce a auzit. Trei rezultate, trei straturi.

Linia din jurnal spune de obicei în care dintre cele trei ești, de aceea merită capturată înainte de prima schimbare.

Un timeout înseamnă că o etapă nu s-a terminat niciodată

Începe cu rezolvarea numelor și accesibilitatea TCP, pentru că un timeout acolo arată identic cu un timeout mai târziu. Un verificator de porturi care raportează 443 deschis dovedește doar că un ascultător a acceptat o conexiune, și nimic mai mult.

Următorul suspect este calea, nu gazda. Proxy-urile și firewall-urile conștiente de aplicații refuză uneori metoda de cerere pe care o folosește SSTP sau aruncă un flux care rămâne deschis ore întregi, iar ambele comportamente arată ca un timeout din partea clientului. O pagină HTTPS obișnuită servită de aceeași gazdă se încarcă perfect în timp ce metoda tunelului este refuzată, de aceea navigarea la punctul final dovedește atât de puțin. Testează dintr-o rețea fără proxy pentru a separa cele două cazuri.

Test-NetConnection vpn.example.com -Port 443
netsh http show sslcert
Get-WinEvent -LogName 'Microsoft-Windows-RasSstp/Operational' -MaxEvents 20

Un timeout înainte de orice răspuns al celeilalte părți nu spune nimic despre cont, iar schimbarea parolei în acel moment adaugă doar o variabilă.

O eroare de certificat înseamnă că identitatea a fost respinsă

Aici serverul a răspuns într-adevăr, deci rețeaua funcționează și întrebarea trece la identitate. Compară numele cu care clientul formează cu numele pe care certificatul le afirmă cu adevărat, apoi verifică datele de valabilitate și lanțul emitent.

O CA privată în care clientul nu are încredere produce aceeași clasă de eroare ca un certificat expirat, la fel și un ceas care merge cu orele greșit. Formarea adresei brute creează o nouă nepotrivire, pentru că un certificat afirmă nume, nu adrese. Într-o implementare administrată, obține configurația de încredere dorită de la administratorul ei în loc să accepți o rădăcină de înlocuire oferită de o pagină de eroare. Validarea rămâne pornită în timp ce repari cauza.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
w32tm /query /status

Păstrează etapa TLS reușită intactă după ce trece, pentru că anularea ei mai târziu ascunde care schimbare a reparat de fapt tunelul.

Unde cele două se confundă

Ambele eșecuri apar ca o conexiune care nu urcă, și ambele vin după ce utilizatorul a schimbat ceva nelegat. Acea coincidență face reparația greșită să pară plauzibilă o vreme.

Două obiceiuri le țin separate. Capturează jurnalul clientului înainte de a atinge configurația, ca prima stare să rămână. Schimbă un singur strat pe încercare, ca rezultatul următor să aparțină unei variabile cunoscute. Un verificator de porturi și un browser sunt observații parțiale, nu secvența completă, și niciunul nu înlocuiește raportul clientului însuși. Niciunul dintre obiceiuri nu costă nimic, și ambele scurtează investigația.

Problema certificatului și problema accesibilității sunt documentate separat dintr-un motiv.

Testează din nou cu clientul real, apoi mergi spre interior

După ce corecția concretă este la locul ei, încearcă din nou cu clientul SSTP real și profilul adevărat, nu cu o filă de browser.

rasdial "Corp SSTP" /disconnect
rasdial "Corp SSTP" user '*'
Get-VpnConnection -Name "Corp SSTP" | Select-Object ServerAddress, TunnelType, AuthenticationMethod

Dacă sesiunea se conectează și resursele încă eșuează, tunelul nu mai este suspectul: treci la rutare, DNS și acces la servicii. Aceea este o altă investigație cu alte dovezi. Păstrarea etapelor TLS și de autentificare care funcționează împiedică o repetare a primeia. Scrie în tichet etapa care a eșuat, altfel următoarea persoană începe din nou de sus.