SSTP iza proksija koji pregleda TLS: gdje se sesija prekida

Vaš preglednik učitava korporativni intranet, sertifikat proksija je pouzdan, a SSTP klijent se ipak prekida blizu kraja veze. Taj obrazac upućuje na razliku između web zahtjeva i sesije u tunelu, a ne na pogrešnu lozinku. Prođite vezu od TCP-a prema gore i zabilježite prvu fazu koja ne uspije. Faza, a ne kod greške, kaže vam je li proksi uzrok.

Počnite tamo gdje se klijent zaustavlja

Klijent prolazi fiksni slijed: TCP veza na port 443, TLS rukovanje, provjera sertifikata, SSTP HTTP razmjena, PPP pregovaranje i autentifikacija, zatim IP konfiguracija. Neuspjeh u svakoj fazi ostavlja drugačiji potpis, a njihovo miješanje vodi vas na pogrešnu stranicu postavki.

TCP neuspjeh je istek vremena ili reset prije nego se pojavi i jedan TLS bajt. TLS neuspjeh je upozorenje ili istek vremena rukovanja. Neuspjeh sertifikata daje upozorenje o lancu ili imenu. HTTP neuspjeh dolazi nakon uspješnog rukovanja, često kao statusni kod ili trenutno zatvaranje. PPP neuspjeh dolazi nakon što je tunel tehnički uspostavljen, zato izgleda kao problem autentifikacije.

Čitajte klijentski dnevnik za posljednju uspješnu fazu, a ne prvi red greške. Red greške obično prenosi posljedicu, dok granica faze imenuje komponentu koja je odbila.

Šta SSTP traži da mreža nosi

SSTP radi preko TLS-a na TCP 443 i zatim šalje HTTP zahtjev SSTP_DUPLEX_POST, definiran u specifikaciji SSTP-a, na putanju oblika /sra_{GUID}/. Zahtjev objavljuje praktično neograničenu dužinu sadržaja i drži tok otvorenim u oba smjera tokom cijele sesije. PPP okviri putuju unutar tog toka.

Zato proksi koji obrađuje obično pregledanje ipak može zakazati. GET ili POST s konačnim tijelom može se baferovati, pregledati i proslijediti; dupleksni tok s tijelom koje nikad ne završava ne može. Proksi koji čeka da se tijelo završi čeka zauvijek, a klijent na kraju dobije istek vremena.

Filtriranje metoda i autentifikacija dodaju svoje načine neuspjeha. Ako proksi traži akreditive za zahtjev, VPN klijent možda neće odgovoriti iako bi preglednik odgovorio. Ako ukloni ili prepiše metodu, pristupnik odbija zahtjev prije nego PPP počne.

Zašto pregled mijenja identitet

Proksi koji pregleda TLS prekida klijentovu TLS vezu i otvara odvojenu vezu prema pristupniku. Zato klijent provjerava sertifikat proksija, a ne pristupnika, i pristupnik vidi proksi kao svog partnera. Kada organizacija dijeli vlastiti korijen, preglednik i VPN klijent mogu oba prihvatiti taj lanac, pa rukovanje uspije i problem se seli u sljedeću fazu.

Uspješna provjera ne znači da proksi može nositi sesiju. On još mora prosljeđivati neograničeni dvosmjerni POST bez baferovanja i držati obje veze živima satima. Mnogi proizvodi za pregled napravljeni su za saobraćaj zahtjev-odgovor i ovaj slučaj obrađuju loše ili nikako.

Zato je dodavanje nepoznatog korijena ili isključivanje provjere pogrešna popravka. To mijenja koji sertifikat klijent prihvata; ne radi ništa s obradom toka koja je stvarno slomila sesiju.

Utvrdite izdavaoca prije promjene postavki

Pitajte krajnju tačku koji sertifikat predstavlja i ko ga je potpisao. Naredbe ispod prikazuju lanac i izdavaoca bez pokretanja VPN sesije:

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

Ako je izdavalac javni CA, veza vjerovatno nije presretana za ovaj host i neuspjeh je negdje drugdje. Ako je izdavalac vlastiti CA organizacije, pregled je aktivan i pristupnik se dostiže kroz proksi. Uporedite otisak s onim koji mrežni tim očekuje prije nego zaključite samo na osnovu imena.

Test preglednika prema istom hostu dokazuje samo da proksi prihvata GET. Ne govori ništa o SSTP metodi, URI-ju zahtjeva ili životnom vijeku tijela, pa nemojte radnu intranet stranicu smatrati dokazom da je putanja tunela podržana.

Odaberite podržanu putanju

Postavite vlasniku mreže jedno konkretno pitanje: dopušta li proksi nebaferovani dupleksni POST prema ovom pristupniku na portu 443? „Da“ vodi do izuzetka u proksiju ili dokumentovanog zaobilaženja za VPN host. „Ne“ znači da pregledana putanja ne može nositi SSTP, a podržana popravka je druga putanja ili protokol, a ne dotjerivanje klijenta.

Opcije obično uključuju nepregledani izlaz za VPN pristupnik, dizajn podijeljenog tunela koji samo korporativni saobraćaj šalje kroz proksi, ili alternativni protokol koji organizacija podržava na drugom portu. Svaka pripada mrežnom dizajnu i svaku treba testirati s istim uređajem i profilom kako bi poređenje izolovalo putanju.

Dokumentujte ishod: izdavalac, neuspjela faza, proksi pravilo i odabrana putanja. Sljedeća osoba koja vidi isto zastoj na 98 posto može provjeriti jednu činjenicu umjesto da ponavlja cijeli prolaz.