SSTP TLS-i kontrolliva puhverserveri taga: kus seanss katkeb

Teie brauser laeb ettevõtte intraneti, puhverserveri sertifikaat on usaldusväärne, ja ometi katkeb SSTP klient ühenduse lõpu lähedal. See muster viitab veebipäringu ja tunneliseansi erinevusele, mitte vale paroolile. Käige ühendus TCP-st ülespoole läbi ja märkige esimene aste, mis ebaõnnestub. Just aste, mitte veakood, ütleb, kas puhverserver on põhjus.

Alustage sealt, kus klient peatub

Klient läbib kindla järjestuse: TCP-ühendus pordile 443, TLS-kätlus, sertifikaadi valideerimine, SSTP HTTP-vahetus, PPP läbirääkimine ja autentimine ning seejärel IP-konfiguratsioon. Iga astme tõrge jätab erineva jälje ja nende segamini ajamine viib teid vale seadistuslehele.

TCP tõrge on aegumine või lähtestamine enne, kui ilmub ükski TLS-i bait. TLS-i tõrge on hoiatus või kätluse aegumine. Sertifikaadi tõrge tekitab hoiatuse ahela või nime kohta. HTTP tõrge saabub pärast edukat kätlust, sageli olekukoodina või kohese sulgemisena. PPP tõrge saabub pärast seda, kui tunnel on tehniliselt loodud, mistõttu see näeb välja nagu autentimisprobleem.

Lugege kliendi logist viimast edukat astet, mitte esimest vearida. Vearida teatab tavaliselt tagajärje, samas kui astme piir nimetab komponendi, mis keeldus.

Mida SSTP võrgust kannab

SSTP töötab TLS-i peal TCP 443-l ja saadab seejärel HTTP-päringu nimega SSTP_DUPLEX_POST, mis on määratletud SSTP spetsifikatsioonis, teele kujul /sra_{GUID}/. Päring deklareerib praktiliselt piiramatu sisupikkuse ja hoiab voogu kogu seansi vältel mõlemas suunas avatuna. PPP kaadrid liiguvad selle voo sees.

Seepärast võib tavapärast veebilehitsemist käsitlev puhverserver siiski ebaõnnestuda. Lõpliku kehaga GET või POST on võimalik puhverdada, kontrollida ja edasi saata; lõputu kehaga dupleksvoogu aga mitte. Puhverserver, mis ootab keha lõppu, ootab igavesti ja klient jookseb lõpuks aegumisele.

Meetodite filtreerimine ja autentimine lisavad omad tõrkerežiimid. Kui puhverserver nõuab päringult volitusi, ei pruugi VPN-klient vastata, kuigi brauser vastaks. Kui see meetodi eemaldab või ümber kirjutab, lükkab lüüs päringu tagasi enne PPP algust.

Miks kontrollimine identiteeti muudab

TLS-i kontrolliv puhverserver lõpetab kliendi TLS-ühenduse ja avab lüüsiga eraldi ühenduse. Seetõttu valideerib klient puhverserveri, mitte lüüsi sertifikaati, ja lüüs näeb puhverserverit oma partnerina. Kui organisatsioon jagab oma juurt, võivad brauser ja VPN-klient mõlemad selle ahela vastu võtta, nii et kätlus õnnestub ja probleem liigub järgmisele astmele.

Edukas valideerimine ei tähenda, et puhverserver suudab seanssi kanda. See peab endiselt edastama piiramatut kahesuunalist POST-i ilma puhverdamiseta ja hoidma mõlemat ühendust tunde elus. Paljud kontrollitooted on ehitatud päring-vastus liiklusele ja käsitlevad seda juhtumit halvasti või üldse mitte.

Seepärast on tundmatu juure lisamine või valideerimise väljalülitamine vale parandus. See muudab, millist sertifikaati klient vastu võtab; see ei tee midagi voo käsitlemisega, mis seansi tegelikult murdis.

Tehke väljaandja kindlaks enne seadete muutmist

Küsige lõpp-punktilt, millist sertifikaati see esitab ja kes selle allkirjastas. Allolevad käsud näitavad ahelat ja väljaandjat ilma VPN-seanssi alustamata:

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

Kui väljaandja on avalik CA, ei püüta seda hosti jaoks tõenäoliselt kinni ja tõrge on mujal. Kui väljaandja on organisatsiooni enda CA, on kontrollimine aktiivne ja lüüsi juurde jõutakse puhverserveri kaudu. Võrrelge sõrmejälge sellega, mida võrgu meeskond ootab, enne kui teete järelduse ainult nime põhjal.

Brauseri test samale hostile tõestab ainult seda, et puhverserver võtab GET-i vastu. See ei ütle midagi SSTP meetodi, päringu URI ega keha eluea kohta, seega ärge pidage töötavat intranetilehte tõendiks, et tunnelitee on toetatud.

Valige toetatud tee

Esitage võrgu omanikule üks konkreetne küsimus: kas puhverserver lubab puhverdamata dupleksset POST-i sellele lüüsile pordil 443? Jah viib puhverserveri erandini või dokumenteeritud möödaviiguni VPN-hostile. Ei tähendab, et kontrollitud tee ei suuda SSTP-d kanda, ja toetatud parandus on teine tee või protokoll, mitte kliendi nokitsemine.

Valikute hulka kuuluvad tavaliselt kontrollimata väljapääs VPN-lüüsile, jagatud tunneli disain, mis saadab puhverserveri kaudu ainult ettevõtte liiklust, või alternatiivne protokoll, mida organisatsioon toetab teisel pordil. Igaüks kuulub võrgu disaini juurde ja igaüht tuleks testida sama seadme ja profiiliga, et võrdlus isoleeriks tee.

Dokumenteerige tulemus: väljaandja, ebaõnnestunud aste, puhverserveri reegel ja valitud tee. Järgmine inimene, kes näeb sama 98-protsendilist tõkestust, saab kontrollida üht fakti, selle asemel et kogu käik uuesti läbi teha.