SSTP TLS:ää tarkastavan välityspalvelimen takana: missä istunto katkeaa

Selaimesi lataa yrityksen intranetin, välityspalvelimen varmenne on luotettu, ja silti SSTP-asiakas katkeaa lähellä yhteyden loppua. Kuvio viittaa verkkopyynnön ja tunneloidun istunnon eroon, ei väärään salasanaan. Käy yhteys läpi TCP:stä ylöspäin ja merkitse ensimmäinen vaihe, joka epäonnistuu. Vaihe, ei virhekoodi, kertoo, onko välityspalvelin syy.

Aloita siitä, mihin asiakas pysähtyy

Asiakas kulkee kiinteän järjestyksen läpi: TCP-yhteys porttiin 443, TLS-kättely, varmenteen validointi, SSTP:n HTTP-vaihto, PPP-neuvottelu ja -todennus sekä lopuksi IP-määritys. Jokaisen vaiheen epäonnistuminen jättää erilaisen jäljen, ja niiden sekoittaminen vie sinut väärälle määrityssivulle.

TCP-virhe on aikakatkaisu tai nollaus ennen kuin yhtään TLS-tavua ilmestyy. TLS-virhe on hälytys tai kättelyn aikakatkaisu. Varmennevirhe tuottaa varoituksen ketjusta tai nimestä. HTTP-virhe saapuu onnistuneen kättelyn jälkeen, usein tilakoodina tai välittömänä sulkemisena. PPP-virhe saapuu sen jälkeen, kun tunneli on teknisesti muodostettu, minkä vuoksi se näyttää todennusongelmalta.

Lue asiakasloki viimeisen onnistuneen vaiheen varalta, älä ensimmäisen virherivin. Virherivi kertoo yleensä seurauksen, kun taas vaiheen raja nimeää komponentin, joka kieltäytyi.

Mitä SSTP vaatii verkolta kannettavaksi

SSTP toimii TLS:n päällä TCP 443:ssa ja lähettää sitten HTTP-pyynnön nimeltä SSTP_DUPLEX_POST, joka on määritelty SSTP-määrityksessä, polulle muotoa /sra_{GUID}/. Pyyntö ilmoittaa käytännössä rajattoman sisältöpituuden ja pitää virran auki molempiin suuntiin koko istunnon ajan. PPP-kehykset kulkevat virran sisällä.

Siksi tavallista selailua käsittelevä välityspalvelin voi silti epäonnistua. GET tai POST, jolla on rajallinen runko, voidaan puskuroida, tarkastaa ja välittää; duplexvirtaa, jonka runko ei lopu koskaan, ei voida. Välityspalvelin, joka odottaa rungon valmistumista, odottaa ikuisesti, ja asiakas aikakatkaisee lopulta.

Menetelmien suodatus ja todennus lisäävät omat epäonnistumistilansa. Jos välityspalvelin vaatii pyynnöltä tunnistetietoja, VPN-asiakas ei ehkä vastaa, vaikka selain vastaisi. Jos se poistaa tai kirjoittaa menetelmän uudelleen, yhdyskäytävä hylkää pyynnön ennen kuin PPP alkaa.

Miksi tarkastus muuttaa identiteettiä

TLS:ää tarkastava välityspalvelin päättää asiakkaan TLS-yhteyden ja avaa erillisen yhteyden yhdyskäytävään. Siksi asiakas validoi välityspalvelimen varmenteen, ei yhdyskäytävän, ja yhdyskäytävä näkee välityspalvelimen vertaisenaan. Kun organisaatio jakaa oman juurensa, sekä selain että VPN-asiakas voivat hyväksyä kyseisen ketjun, joten kättely onnistuu ja ongelma siirtyy seuraavaan vaiheeseen.

Onnistunut validointi ei tarkoita, että välityspalvelin pystyy kantamaan istunnon. Sen on edelleen välitettävä rajoittamaton kaksisuuntainen POST ilman puskurointia ja pidettävä molemmat yhteydet elossa tunteja. Monet tarkastustuotteet on rakennettu pyyntö-vastaus-liikenteelle ja käsittelevät tämän tapauksen huonosti tai eivät lainkaan.

Siksi tuntemattoman juuren lisääminen tai validoinnin poistaminen käytöstä on väärä korjaus. Se muuttaa, minkä varmenteen asiakas hyväksyy; se ei tee mitään virran käsittelylle, joka todella rikkoi istunnon.

Tunnista myöntäjä ennen asetusten muuttamista

Kysy päätepisteeltä, minkä varmenteen se esittää ja kuka sen allekirjoitti. Alla olevat komennot näyttävät ketjun ja myöntäjän aloittamatta VPN-istuntoa:

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

Jos myöntäjä on julkinen CA, yhteyttä ei todennäköisesti siepata tälle isännälle ja virhe on muualla. Jos myöntäjä on organisaation oma CA, tarkastus on käytössä ja yhdyskäytävään päästään välityspalvelimen kautta. Vertaa sormenjälkeä siihen, jota verkkotiimi odottaa, ennen kuin päättelet pelkän nimen perusteella.

Selaintesti samaan isäntään todistaa vain, että välityspalvelin hyväksyy GET-pyynnön. Se ei kerro mitään SSTP-menetelmästä, pyynnön URI:sta tai rungon eliniästä, joten älä pidä toimivaa intranetsivua todisteena siitä, että tunnelipolku on tuettu.

Valitse tuettu polku

Kysy verkon omistajalta yksi konkreettinen kysymys: salliiko välityspalvelin puskuroimattoman duplex-POSTin tähän yhdyskäytävään portissa 443? Kyllä johtaa välityspalvelimen poikkeukseen tai dokumentoituun ohitukseen VPN-isännälle. Ei tarkoittaa, että tarkastettu polku ei voi kantaa SSTP:tä, ja tuettu korjaus on toinen polku tai protokolla, ei asiakkaan viilaus.

Vaihtoehtoihin kuuluvat yleensä tarkastamaton uloskäynti VPN-yhdyskäytävälle, jaetun tunnelin suunnittelu, joka lähettää välityspalvelimen kautta vain yrityksen liikennettä, tai vaihtoehtoinen protokolla, jota organisaatio tukee toisessa portissa. Kukin kuuluu verkkosuunnitteluun, ja kukin tulisi testata samalla laitteella ja profiililla, jotta vertailu eristää polun.

Dokumentoi tulos: myöntäjä, epäonnistunut vaihe, välityspalvelimen sääntö ja valittu polku. Seuraava henkilö, joka näkee saman 98 prosentin pysähdyksen, voi tarkistaa yhden tosiasian sen sijaan, että toistaisi koko kierroksen.