SSTP epäonnistuu siellä, missä selaimen HTTPS onnistuu: miksi

Selain avaa VPN-isäntänimen HTTPS:n kautta valittamatta, ja SSTP-asiakasohjelma silti kieltäytyy yhdistämästä. Tuossa parissa ei ole mitään ristiriitaista. SSTP käyttää TLS:ää ulompana siirtotienä ja ajaa sitten oman pyyntönsä ja PPP-hyötykuormansa kyseisen yhteyden sisällä, joten onnistunut sivun lataus todistaa vain yhden kapean asian: isäntä vastaa GET-pyyntöön portissa 443. Asiakasohjelma esittää toisen kysymyksen, ja palvelin voi vastata siihen huonosti.

Sivu latautuu, mutta tunneli ei

Ihmiset turvautuvat selaintestiin, koska se on nopea, ja pitävät sitten tulosta todisteena siitä, että palvelin on saavutettavissa ja määritetty. Se on todiste GET-pyynnöstä polkuun, jonka osoitepalkki avasi, ei muuta. VPN-keskustelu alkaa saman TLS-kättelyn jälkeen, mutta lähettää menetelmän ja polun, jota verkkosivu ei koskaan käytä. Niinpä vastaus 200 selaimelle ei kerro mitään siitä, onko SSTP-päätepiste olemassa.

Erottele kaksi havaintoa, niin etsinnästä tulee lyhyempi. Siirto ja varmenneketju toimivat, ja jokin niiden yläpuolisessa protokollavaihdossa ei toimi. Se on eri tutkimus kuin rikkinäinen portti tai vanhentunut varmenne, ja se vaatii erilaisia todisteita.

Mitä SSTP-asiakasohjelma todella lähettää

Asiakasohjelma lähettää HTTP-pyynnön menetelmällä SSTP_DUPLEX_POST polkuun /sra_{GUID}/ ja pitää sitten yhteyden rungon avoinna kaksisuuntaisena virtana, joka kuljettaa PPP-kehyksiä. Vaatimustenmukainen palvelin vastaa HTTP/1.1 200 ja lakkaa käyttäytymästä verkkopalvelimena. Kaikki muu on allekirjoitus: 405 tai 404 tarkoittaa, ettei päätepistettä ole, 301 tai 302 tarkoittaa, että jokin uudelleenohjaa pyyntöä, ja välitön FIN tarkoittaa, että välityspalvelin tai palvelin sulki virran.

Siksi kohteen on oltava SSTP-palvelin eikä verkkopalvelin, johon on ruuvattu TLS-varmenne. Menetelmä, polku ja pitkäikäinen runko ovat protokollavaatimuksia, joten käänteinen välityspalvelin ei voi lisätä niitä pelkällä kokoonpanolla. Välityspalvelin, joka välittää tavallisen HTTPS:n täydellisesti, voi silti hylätä menetelmän, jota se ei tunnista.

Missä välityspalvelin tai verkkopalvelin katkaisee virran

Välittäjä tarkistaa HTTP-pyyntörivin ennen kuin välittää mitään, ja mukautettu menetelmä epätavallisella polulla voi rikkoa sen säännöt. Jotkin laitteet tarjoilevat normaalin sivun samalla kun ne hylkäävät tai keskeyttävät tunnelin, joten asiakasohjelma raportoi yhteydestä, joka alkaa ja sitten kuolee, puhtaan hylkäyksen sijaan. Toiset hyväksyvät pyynnön ja soveltavat sitten runko- tai joutoaikakatkaisun, jota PPP-keepalivet eivät kestä. Molemmat näyttävät samalta asiakkaan puolelta, siksi epäonnistunut vaihe on tärkeämpi kuin virheteksti.

Portin 443 jakaminen verkkosivuston ja SSTP:n kesken on reititysvalinta, ei lupaus siitä, että jokainen hyppy käsittelee molemmat keskustelut samalla tavalla. Jos polulla on kuormantasaaja, palomuuri tai TLS-päättäjä, lisää se epäiltyjen luetteloon ennen kuin kosket VPN-kokoonpanoon.

Testaa vaiheet erikseen

Suorita tarkistukset järjestyksessä ja pysähdy ensimmäiseen epäonnistumiseen, koska jokainen vaihe sulkee pois eri kerroksen. Alla oleva TLS-koetin erottaa varmenteen identiteetin kaikesta, mitä SSTP tekee. Korvaa isäntänimi päätepisteelläsi ja lue subject ja ketju, jonka se tulostaa.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com

Yhdistä sitten jäljellä olevat todisteet vaiheisiin sen sijaan, että arvaisit asiakasohjelman virheestä. Alla oleva taulukko on tiketissä siteerattava tarkistuslista, ja allekirjoitus erottaa yhden epäonnistumisen seuraavasta.

Kirjaa tikettiin viimeinen onnistunut vaihe sen sijaan, että kirjoittaisit "yhteys ei onnistu". MS-SSTP-määritys dokumentoi pyynnön ja PPP-vaihdon, jotka seuraavat TLS-kättelyä, ja on viite siihen, miksi selaintesti ei voi korvata kumpaakaan niistä.

Ensin identiteetti, sitten PPP

TLS-identiteetti ja PPP-todennus ovat peräkkäisiä, eivät vaihtoehtoisia, ja niiden sekoittaminen ohjaa ihmiset väärään palvelinasetukseen. Asiakasohjelma validoi ensin palvelimen varmenteen ja sen käyttötarkoituksen, sitten PPP neuvottelee oman tilansa ja todentaa käyttäjän haaste-vastaus-menetelmällä tai EAP:lla. Varmenneongelma tuottaa eri virheen kuin hylätty salasana, eikä kumpikaan virhe kuvaa vaihetta, jonka toinen kattaa.

Isäntänimen korvaaminen osoitteella tai varoituksen ohittaminen poistaa tarkistuksen, joka olisi tunnistanut epäonnistuvan vaiheen, sen korjaamisen sijaan. Pidä varoitus ja lue se. Älä myöskään nollaa PPP-salasanaa, kun HTTP-vaihto ei koskaan saavuttanut SSTP-käyttäytymistä, koska tunnistetietoja ei koskaan kysytty.