SSTP este PPP peste HTTPS, nu o pagină web pe portul 443

SSTP transportă PPP în interiorul unei conexiuni HTTPS, de aceea pare trafic web pentru orice se află la mijloc. TLS și HTTP stabilesc canalul exterior, apoi mesajele de control SSTP pregătesc tunelul, iar PPP oferă comportamentul sesiunii. Un browser care încarcă o pagină la aceeași adresă a finalizat doar o parte din prima etapă. A trata asta ca test VPN este modul în care un proxy funcțional este învinuit pentru o nepotrivire de protocol.

Parcurgeți cele patru etape în ordine, iar defecțiunea pe care o vedeți va cădea într-una dintre ele.

Etapa 1: TCP și TLS

Clientul deschide o conexiune TCP către portul 443 și efectuează un handshake TLS. Lanțul de certificate trebuie să corespundă numelui de gazdă cu care a fost configurat clientul. O nepotrivire de nume aici produce o defecțiune înainte de a se schimba vreun mesaj SSTP, iar specificația SSTP presupune că acest canal HTTPS exterior există deja. Nimic din etapele ulterioare nu poate compensa o defecțiune de încredere aici.

Un server web obișnuit poate finaliza perfect această etapă și totuși poate eșua la următoarea. Succesul TLS este o dovadă despre certificat, nu despre protocolul din spatele lui.

Etapa 2: cererea HTTPS

SSTP își face cererea cu o metodă specifică, SSTP_DUPLEX_POST, și ține schimbul deschis în loc să returneze un document. Un server sau proxy configurat pentru cereri obișnuite de pagină poate accepta conexiunea și apoi respinge metoda. Acea respingere este problema de compatibilitate pe care oamenii o descriu de obicei ca port 443 blocat.

Citiți codul de răspuns și metoda în jurnalul serverului. O respingere în această etapă este o problemă diferită de un timeout TCP, iar ambele duc la remedieri diferite.

Etapa 3: mesaje de control

După ce cererea este acceptată, SSTP schimbă mesaje de control care negociază și pregătesc tunelul. Acestea sunt mesaje de protocol în interiorul corpului HTTPS, nu cereri HTTP, așa că un proxy care inspectează și rescrie corpuri le poate rupe, lăsând cererile de pagină neatinse.

Aici un echipament de inspecție profundă își câștigă reputația. Dacă paginile se încarcă, dar VPN-ul eșuează, verificați dacă corpul este modificat, nu dacă portul este deschis.

Etapa 4: PPP preia controlul

PPP oferă apoi comportamentul sesiunii: negocierea legăturii, autentificarea și configurația stratului de rețea care urmează. Autentificarea PPP este separată de verificarea TLS pe care clientul a trecut-o deja. Un certificat de server pe care clientul îl acceptă nu spune nimic despre dacă acreditările utilizatorului sunt valide sau dacă contul este autorizat.

Un certificat acceptat și o autentificare respinsă nu sunt contradictorii. Sunt etape consecutive cu rezultate independente.

Autentificarea are mai multe roluri

Clientul validează identitatea serverului TLS față de magazinul său de încredere și numele configurat. Apoi PPP autentifică utilizatorul sau mașina, în funcție de implementare. Serverul poate adăuga propria politică despre cine se poate conecta și la ce poate ajunge. Păstrați numele de gazdă consecvent cu identitatea certificatului, pentru că înlocuirea cu o adresă brută transformă o configurație funcțională într-o defecțiune de verificare a numelui.

Notați ce etapă a raportat defecțiunea. Certificat, metodă, mesaj de control, autentificare PPP, apoi rute: cinci locuri, cinci remedieri.

Ce poate și ce nu poate arăta un test în browser

Încărcarea unei pagini la adresă dovedește rezolvarea DNS, accesibilitatea TCP și că ceva ascultă și vorbește HTTP. Nu dovedește că metoda este acceptată, că schimbul de control supraviețuiește sau că autentificarea PPP este configurată. Folosiți un client care implementează SSTP în loc să convertiți alt profil schimbând portul.

După ce sesiunea este ridicată, rutele, DNS-ul și redirecționarea din partea serverului încă decid la ce poate ajunge utilizatorul. Tunelul este o cale, nu o autorizare.