SSTP în spatele unui proxy care inspectează TLS: unde se rupe sesiunea

Browserul încarcă intranetul companiei, certificatul proxy-ului este de încredere și totuși clientul SSTP cade aproape de finalul conexiunii. Acest model indică diferența dintre o cerere web și o sesiune tunelată, nu o parolă greșită. Parcurgeți conexiunea de la TCP în sus și notați prima etapă care eșuează. Etapa, nu codul de eroare, vă spune dacă proxy-ul este cauza.

Începeți acolo unde se oprește clientul

Clientul trece printr-o secvență fixă: conexiune TCP la portul 443, handshake TLS, validarea certificatului, schimbul HTTP al SSTP, negocierea și autentificarea PPP, apoi configurarea IP. O defecțiune în fiecare etapă lasă o urmă diferită, iar confundarea lor vă duce la pagina de configurare greșită.

O defecțiune TCP este un timeout sau un reset înainte să apară vreun byte TLS. O defecțiune TLS este o alertă sau un timeout al handshake-ului. O defecțiune de certificat produce un avertisment despre lanț sau nume. O defecțiune HTTP vine după un handshake reușit, adesea ca cod de stare sau închidere imediată. O defecțiune PPP vine după ce tunelul este stabilit tehnic, de aceea pare o problemă de autentificare.

Citiți jurnalul clientului pentru ultima etapă reușită, nu pentru prima linie de eroare. Linia de eroare raportează de obicei consecința, în timp ce granița etapei numește componenta care a refuzat.

Ce cere SSTP rețelei să transporte

SSTP rulează peste TLS pe TCP 443 și apoi trimite o cerere HTTP numită SSTP_DUPLEX_POST, definită în specificația SSTP, către o cale de forma /sra_{GUID}/. Cererea declară o lungime de conținut practic nelimitată și ține fluxul deschis în ambele direcții pe toată durata sesiunii. Cadrele PPP călătoresc în interiorul acelui flux.

De aceea un proxy care tratează navigarea obișnuită poate totuși eșua. Un GET sau un POST cu corp finit poate fi tamponat, inspectat și forwardat; un flux duplex cu un corp care nu se termină niciodată nu poate. Un proxy care așteaptă terminarea corpului așteaptă la nesfârșit, iar clientul ajunge în final la timeout.

Filtrarea metodelor și autentificarea adaugă propriile moduri de eșec. Dacă proxy-ul cere credențiale pentru cerere, clientul VPN poate să nu răspundă, deși browserul ar răspunde. Dacă elimină sau rescrie metoda, gateway-ul respinge cererea înainte de a începe PPP.

De ce inspecția schimbă identitatea

Un proxy care inspectează TLS termină conexiunea TLS a clientului și deschide una separată către gateway. Prin urmare, clientul validează certificatul proxy-ului, nu pe cel al gateway-ului, iar gateway-ul vede proxy-ul ca partener al său. Când organizația distribuie propria rădăcină, atât browserul, cât și clientul VPN pot accepta acel lanț, așa că handshake-ul reușește și problema trece la etapa următoare.

O validare reușită nu înseamnă că proxy-ul poate transporta sesiunea. El trebuie în continuare să retransmită un POST bidirecțional nelimitat fără tamponare și să țină ambele conexiuni în viață ore întregi. Multe produse de inspecție sunt construite pentru trafic cerere-răspuns și tratează acest caz prost sau deloc.

De aceea adăugarea unei rădăcini necunoscute sau dezactivarea verificării este reparația greșită. Schimbă ce certificat acceptă clientul; nu face nimic în privința tratării fluxului care a rupt de fapt sesiunea.

Identificați emitentul înainte de a schimba setări

Întrebați punctul final ce certificat prezintă și cine l-a semnat. Comenzile de mai jos arată lanțul și emitentul fără a porni o sesiune VPN:

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts
curl -vI https://vpn.example.com/

Dacă emitentul este o CA publică, conexiunea probabil nu este interceptată pentru acest host și defecțiunea este în altă parte. Dacă emitentul este CA-ul companiei, inspecția este activă și gateway-ul este atins printr-un proxy. Comparați amprenta cu cea pe care o așteaptă echipa de rețea înainte de a trage concluzii doar din nume.

Un test de browser către același host dovedește doar că proxy-ul acceptă un GET. Nu spune nimic despre metoda SSTP, URI-ul cererii sau durata de viață a corpului, așa că nu luați o pagină de intranet funcțională drept dovadă că traseul tunelului este suportat.

Alegeți traseul suportat

Puneți proprietarului rețelei o întrebare concretă: proxy-ul permite un POST duplex fără tamponare către acest gateway pe portul 443? Un da duce la o excepție în proxy sau la o ocolire documentată pentru hostul VPN. Un nu înseamnă că traseul inspectat nu poate transporta SSTP, iar soluția suportată este alt traseu sau protocol, nu o ajustare a clientului.

Opțiunile includ de obicei o ieșire neinspectată pentru gateway-ul VPN, un proiect de tunel divizat care trimite doar traficul companiei prin proxy, sau un protocol alternativ pe care organizația îl suportă pe alt port. Fiecare aparține proiectării rețelei și fiecare ar trebui testat cu același dispozitiv și profil, ca comparația să izoleze traseul.

Documentați rezultatul: emitent, etapă eșuată, regulă de proxy și traseu ales. Următoarea persoană care vede aceeași oprire la 98 la sută va putea verifica un singur fapt în loc să repete întregul parcurs.