SSTP on PPP HTTPS:n yli, ei verkkosivu portissa 443

SSTP kuljettaa PPP:tä HTTPS-yhteyden sisällä, siksi se näyttää verkkoliikenteeltä kaikelle välissä olevalle. TLS ja HTTP pystyttävät ulomman kanavan, sitten SSTP-ohjausviestit valmistelevat tunnelin ja PPP tarjoaa istunnon käyttäytymisen. Selain, joka lataa sivun samasta osoitteesta on suorittanut vain osan ensimmäisestä vaiheesta. Sen pitäminen VPN-testinä on tapa, jolla toimiva välityspalvelin saa syyn protokollan eroavaisuudesta.

Käy neljä vaihetta järjestyksessä läpi, ja näkemäsi vika osuu yhteen niistä.

Vaihe 1: TCP ja TLS

Asiakas avaa TCP-yhteyden porttiin 443 ja tekee TLS-kättelyn. Varmenneketjun on vastattava isäntänimeä, jolla asiakas määritettiin. Nimen eroavuus tuottaa tässä vian ennen kuin yhtään SSTP-viestiä vaihdetaan, ja SSTP-määritys olettaa, että tämä ulompi HTTPS-kanava on jo olemassa. Mikään myöhemmissä vaiheissa ei voi korvata luottamusvian tässä.

Tavallinen verkkopalvelin voi suorittaa tämän vaiheen täydellisesti ja silti epäonnistua seuraavassa. TLS:n onnistuminen on todiste varmenteesta, ei sen takana olevasta protokollasta.

Vaihe 2: HTTPS-pyyntö

SSTP tekee pyyntönsä tietyllä menetelmällä, SSTP_DUPLEX_POST, ja pitää vaihdon avoimena palauttamatta asiakirjaa. Tavallisiin sivupyyntöihin määritetty palvelin tai välityspalvelin voi hyväksyä yhteyden ja hylätä sitten menetelmän. Tämä hylkäys on yhteensopivuusongelma, jota ihmiset yleensä kuvaavat portin 443 estämiseksi.

Lue vastauskoodi ja menetelmä palvelimen lokista. Hylkäys tässä vaiheessa on eri ongelma kuin TCP-aikakatkaisu, ja molemmat johtavat erilaisiin korjauksiin.

Vaihe 3: ohjausviestit

Kun pyyntö on hyväksytty, SSTP vaihtaa ohjausviestejä, jotka neuvottelevat ja valmistelevat tunnelin. Ne ovat protokollaviestejä HTTPS-rungon sisällä eivätkä HTTP-pyyntöjä, joten runkoja tarkastava ja uudelleenkirjoittava välityspalvelin voi rikkoa ne sivupyyntöjen jäädessä koskemattomiksi.

Tässä syvätarkastuksen välilaite ansaitsee maineensa. Jos sivut latautuvat ja VPN epäonnistuu, tarkista muutetaanko runkoa sen sijaan, onko portti auki.

Vaihe 4: PPP ottaa vallan

Sitten PPP tarjoaa istunnon käyttäytymisen: linkin neuvottelu, todennus ja sitä seuraava verkkokerroksen määritys. PPP-todennus on erillinen TLS-tarkistuksesta, jonka asiakas on jo läpäissyt. Palvelinvarmenteen hyväksyminen ei kerro mitään siitä, ovatko käyttäjän tunnistetiedot voimassa tai onko tili valtuutettu.

Hyväksytty varmenne ja hylätty kirjautuminen eivät ole ristiriidassa. Ne ovat peräkkäisiä vaiheita, joilla on riippumattomat tulokset.

Todennuksella on useita rooleja

Asiakas validoi TLS-palvelimen identiteetin luottamusvarastoaan ja määritettyä nimeä vasten. Sitten PPP todentaa käyttäjän tai koneen käyttöönotosta riippuen. Palvelin voi lisätä oman käytäntönsä siitä, kuka saa yhdistää ja mihin saa päästä. Pidä isäntänimi yhdenmukaisena varmenteen identiteetin kanssa, koska raakan osoitteen käyttäminen tekee toimivasta asetuksesta nimistarkistuksen vian.

Kirjoita muistiin, mikä vaihe raportoi vian. Varmenne, menetelmä, ohjausviesti, PPP-todennus, sitten reitit: viisi kohtaa, viisi korjausta.

Mitä selaintesti voi ja mitä ei voi näyttää

Sivun lataaminen osoitteessa todistaa DNS-selvityksen, TCP-tavoitettavuuden ja sen, että jokin kuuntelee ja puhuu HTTP:tä. Se ei todista, että menetelmä hyväksytään, että ohjausvaihto kestää tai että PPP-todennus on määritetty. Käytä asiakasta, joka toteuttaa SSTP:n, sen sijaan että muuntaisit toisen profiilin porttia muuttamalla.

Kun istunto on pystyssä, reitit, DNS ja palvelinpuolen edelleenvälitys päättävät edelleen, mihin käyttäjä pääsee. Tunneli on polku, ei valtuutus.