SSTP za posrednikom, ki pregleduje TLS: kje se seja pretrga

Vaš brskalnik naloži poslovni intranet, potrdilo posrednika je zaupanja vredno, pa vendar odjemalec SSTP pade blizu konca povezave. Ta vzorec kaže na razliko med spletno zahtevo in sejo v tunelu, ne pa na napačno geslo. Prehodite povezavo od TCP navzgor in zapišite prvo fazo, ki ne uspe. Faza, ne koda napake, vam pove, ali je posrednik vzrok.

Začnite tam, kjer se odjemalec ustavi

Odjemalec prehodi fiksno zaporedje: povezava TCP na vrata 443, rokovanje TLS, preverjanje potrdila, izmenjava HTTP SSTP, pogajanje in preverjanje pristnosti PPP, nato konfiguracija IP. Napaka v vsaki fazi pusti drugačen odtis, njihovo mešanje pa vas pripelje na napačno stran z nastavitvami.

Napaka TCP je časovna omejitev ali ponastavitev, preden se pojavi kateri koli bajt TLS. Napaka TLS je opozorilo ali časovna omejitev rokovanja. Napaka potrdila ustvari opozorilo o verigi ali imenu. Napaka HTTP pride po uspešnem rokovanju, pogosto kot statusna koda ali takojšnje zaprtje. Napaka PPP pride po tem, ko je tunel tehnično vzpostavljen, zato je videti kot težava s preverjanjem pristnosti.

V dnevniku odjemalca berite zadnjo uspešno fazo, ne prve vrstice napake. Vrstica napake običajno poroča posledico, meja faze pa imenuje komponento, ki je zavrnila.

Kaj SSTP zahteva od omrežja, da prenaša

SSTP teče prek TLS na TCP 443 in nato pošlje zahtevo HTTP z imenom SSTP_DUPLEX_POST, definirano v specifikaciji SSTP, na pot oblike /sra_{GUID}/. Zahteva razglasi praktično neomejeno dolžino vsebine in ohranja tok odprt v obe smeri ves čas seje. Okviri PPP potujejo znotraj tega toka.

Zato lahko posrednik, ki obdeluje običajno brskanje, vseeno ne uspe. GET ali POST s končnim telesom je mogoče medpomniti, pregledati in posredovati; dvosmernega toka s telesom, ki se nikoli ne konča, ni mogoče. Posrednik, ki čaka na dokončanje telesa, čaka večno, odjemalec pa na koncu doživi časovno omejitev.

Filtriranje metod in preverjanje pristnosti dodajata svoje načine odpovedi. Če posrednik za zahtevo zahteva poverilnice, odjemalec VPN morda ne bo odgovoril, čeprav bi brskalnik odgovoril. Če metodo odstrani ali prepiše, prehod zavrne zahtevo, preden se začne PPP.

Zakaj pregled spremeni identiteto

Posrednik, ki pregleduje TLS, konča odjemalčevo povezavo TLS in odpre ločeno povezavo do prehoda. Odjemalec zato preveri potrdilo posrednika, ne prehoda, in prehod vidi posrednika kot svojega partnerja. Ko organizacija razširi svoj koren, lahko brskalnik in odjemalec VPN sprejmeta to verigo, zato rokovanje uspe in težava se premakne v naslednjo fazo.

Uspešno preverjanje ne pomeni, da lahko posrednik nosi sejo. Še vedno mora posredovati neomejen dvosmerni POST brez medpomnjenja in ohraniti obe povezavi živi ure in ure. Veliko izdelkov za pregledovanje je zgrajenih za promet zahteva-odgovor in ta primer obravnavajo slabo ali sploh ne.

Zato je dodajanje neznanega korena ali izklop preverjanja napačno popravilo. Spremeni, katero potrdilo odjemalec sprejme; glede obdelave toka, ki je sejo dejansko zlomila, ne naredi ničesar.

Pred spremembo nastavitev ugotovite izdajatelja

Vprašajte končno točko, katero potrdilo predstavi in kdo ga je podpisal. Spodnji ukazi prikažejo verigo in izdajatelja, ne da bi začeli sejo VPN:

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

Če je izdajatelj javni CA, povezava za tega gostitelja verjetno ni prestrežena in napaka je drugje. Če je izdajatelj lastni CA organizacije, je pregledovanje aktivno in prehod je dosežen prek posrednika. Primerjajte prstni odtis s tistim, ki ga pričakuje omrežna ekipa, preden sklepate samo po imenu.

Preizkus brskalnika na istega gostitelja dokaže le, da posrednik sprejme GET. Ne pove ničesar o metodi SSTP, URI zahteve ali življenjski dobi telesa, zato delujoče intranetne strani ne jemljite kot dokaz, da je pot tunela podprta.

Izberite podprto pot

Vprašajte lastnika omrežja eno konkretno vprašanje: ali posrednik dovoli ne-medpomnjen dvosmerni POST do tega prehoda na vratih 443? Da vodi do izjeme v posredniku ali do dokumentiranega obhoda za gostitelja VPN. Ne pomeni, da pregledana pot ne more nositi SSTP, in podprta rešitev je druga pot ali protokol, ne prilagajanje odjemalca.

Možnosti običajno vključujejo nepregledan izhod za prehod VPN, zasnovo razdeljenega tunela, ki skozi posrednik pošilja le poslovni promet, ali alternativni protokol, ki ga organizacija podpira na drugih vratih. Vsaka spada v zasnovo omrežja in vsako bi bilo treba preizkusiti z isto napravo in profilom, da primerjava izolira pot.

Dokumentirajte izid: izdajatelj, neuspešna faza, pravilo posrednika in izbrana pot. Naslednja oseba, ki bo videla enako zaustavitev pri 98 odstotkih, bo lahko preverila eno dejstvo, namesto da bi ponovila celoten sprehod.