SSTP už TLS tikrinančio tarpinio serverio: kur sesija nutrūksta

Jūsų naršyklė įkelia įmonės intranetą, tarpinio serverio sertifikatas yra patikimas, o SSTP klientas vis tiek nutrūksta netoli ryšio pabaigos. Šis modelis rodo skirtumą tarp žiniatinklio užklausos ir tunelio sesijos, o ne neteisingą slaptažodį. Pereikite ryšį nuo TCP aukštyn ir pažymėkite pirmąjį etapą, kuris nepavyksta. Būtent etapas, o ne klaidos kodas, pasako, ar tarpinis serveris yra priežastis.

Pradėkite ten, kur sustoja klientas

Klientas praeina fiksuotą seką: TCP ryšys prie 443 prievado, TLS rankos paspaudimas, sertifikato tikrinimas, SSTP HTTP mainai, PPP derybos ir autentifikavimas, tada IP konfigūracija. Kiekvieno etapo gedimas palieka skirtingą pėdsaką, o juos sumaišius patenkama į neteisingą konfigūracijos puslapį.

TCP gedimas yra skirtasis laikas arba atstatymas prieš pasirodant bet kuriam TLS baitui. TLS gedimas yra įspėjimas arba rankos paspaudimo skirtasis laikas. Sertifikato gedimas sukuria įspėjimą apie grandinę arba pavadinimą. HTTP gedimas ateina po sėkmingo rankos paspaudimo, dažnai kaip būsenos kodas arba tiesioginis užsidarymas. PPP gedimas ateina po to, kai tunelis techniškai sukurtas, todėl jis atrodo kaip autentifikavimo problema.

Skaitykite kliento žurnalą ieškodami paskutinio sėkmingo etapo, o ne pirmos klaidos eilutės. Klaidos eilutė paprastai praneša pasekmę, o etapo riba įvardija komponentą, kuris atsisakė.

Ko SSTP prašo tinklo perduoti

SSTP veikia per TLS TCP 443 prievade ir tada siunčia HTTP užklausą pavadinimu SSTP_DUPLEX_POST, apibrėžtą SSTP specifikacijoje, į kelio formą /sra_{GUID}/. Užklausa deklaruoja praktiškai neribotą turinio ilgį ir visą sesijos laiką laiko srautą atvirą abiem kryptimis. PPP kadrai keliauja tame sraute.

Štai kodėl tarpinis serveris, tvarkantis įprastą naršymą, vis tiek gali nepavykti. GET arba POST su baigtiniu turiniu galima buferizuoti, patikrinti ir persiųsti; dvipusio srauto su turiniu, kuris niekada nesibaigia, ne. Tarpinis serveris, laukiantis turinio pabaigos, laukia amžinai, ir klientas galiausiai gauna skirtąjį laiką.

Metodų filtravimas ir autentifikavimas prideda savo gedimo režimus. Jei tarpinis serveris reikalauja užklausos prisijungimo duomenų, VPN klientas gali neatsakyti, nors naršyklė atsakytų. Jei jis pašalina arba perrašo metodą, šliuzas atmeta užklausą prieš prasidedant PPP.

Kodėl tikrinimas keičia tapatybę

TLS tikrinantis tarpinis serveris užbaigia kliento TLS ryšį ir atidaro atskirą ryšį į šliuzą. Todėl klientas tikrina tarpinio serverio, o ne šliuzo sertifikatą, ir šliuzas mato tarpinį serverį kaip savo partnerį. Kai organizacija platina savo šaknį, ir naršyklė, ir VPN klientas gali priimti tą grandinę, todėl rankos paspaudimas pavyksta, o problema persikelia į kitą etapą.

Sėkmingas tikrinimas nereiškia, kad tarpinis serveris gali perduoti sesiją. Jam vis tiek reikia persiųsti neribotą dvikryptį POST be buferizavimo ir išlaikyti abu ryšius gyvus valandas. Daugelis tikrinimo produktų sukurti užklausos-atsakymo srautui ir šį atvejį tvarko prastai arba visai netvarko.

Štai kodėl nežinomos šaknies pridėjimas arba tikrinimo išjungimas yra neteisingas taisymas. Tai keičia, kurį sertifikatą klientas priima; tai nieko nedaro su srauto apdorojimu, kuris iš tikrųjų nutraukė sesiją.

Nustatykite išdavėją prieš keisdami nustatymus

Paklauskite galinio taško, kurį sertifikatą jis pateikia ir kas jį pasirašė. Toliau pateiktos komandos rodo grandinę ir išdavėją nepradedant VPN sesijos:

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

Jei išdavėjas yra viešoji CA, šio hosto ryšys greičiausiai neperimamas, o gedimas yra kitur. Jei išdavėjas yra pačios organizacijos CA, tikrinimas aktyvus ir šliuzas pasiekiamas per tarpinį serverį. Palyginkite pirštų atspaudą su tuo, kurio tikisi tinklo komanda, prieš darydami išvadą vien iš pavadinimo.

Naršyklės testas į tą patį hostą įrodo tik tai, kad tarpinis serveris priima GET. Jis nieko nesako apie SSTP metodą, užklausos URI ar turinio gyvavimo laiką, todėl nepriimkite veikiančio intraneto puslapio kaip įrodymo, kad tunelio kelias palaikomas.

Pasirinkite palaikomą kelią

Užduokite tinklo savininkui vieną konkretų klausimą: ar tarpinis serveris leidžia nebuferizuotą dvipusį POST į šį šliuzą 443 prievade? Taip veda prie tarpinio serverio išimties arba dokumentuoto apėjimo VPN hostui. Ne reiškia, kad tikrinamas kelias negali perduoti SSTP, o palaikomas sprendimas yra kitas kelias arba protokolas, o ne kliento koregavimas.

Parinktys paprastai apima netikrinamą išėjimą VPN šliuzui, suskaidyto tunelio dizainą, kuris per tarpinį serverį siunčia tik įmonės srautą, arba alternatyvų protokolą, kurį organizacija palaiko kitame prievade. Kiekviena priklauso tinklo dizainui, ir kiekvieną reikėtų išbandyti su tuo pačiu įrenginiu ir profiliu, kad palyginimas išskirtų kelią.

Dokumentuokite rezultatą: išdavėjas, nepavykęs etapas, tarpinio serverio taisyklė ir pasirinktas kelias. Kitas žmogus, pamatęs tą patį 98 procentų sustojimą, galės patikrinti vieną faktą, o ne kartoti visą ėjimą.