SSTP er PPP over HTTPS, ikkje ei nettside på port 443

SSTP ber PPP inne i ein HTTPS-tilkopling, og difor ser det ut som webtrafikk for alt i midten. TLS og HTTP etablerer den ytre kanalen, deretter førebur SSTP-kontrollmeldingar tunnelen, og PPP leverer åtferda til økta. Ein nettlesar som lastar ei side på same adresse har berre fullført ein del av det første trinnet. Å handsame det som ein VPN-test er måten ein fungerande proxy får skulda for eit protokollavvik.

Gå gjennom dei fire trinna i rekkjefølgje, og feilen du ser landar i eitt av dei.

Trinn 1: TCP og TLS

Klienten opnar ein TCP-tilkopling til port 443 og utfører eit TLS-handtrykk. Sertifikatkjeda må samsvare med vertsnamnet klienten vart konfigurert med. Eit namneavvik her gir ein feil før noka SSTP-melding vert utveksla, og SSTP-spesifikasjonen føreset at denne ytre HTTPS-kanalen alt finst. Ingenting i dei seinare trinna kan kompensere for ein tillitsfeil her.

Ein vanleg webserver kan fullføre dette trinnet perfekt og likevel feile i det neste. TLS-suksess er prov om sertifikatet, ikkje om protokollen bak det.

Trinn 2: HTTPS-førespurnaden

SSTP sender førespurnaden sin med ein bestemd metode, SSTP_DUPLEX_POST, og held utvekslinga open i staden for å returnere eit dokument. Ein server eller proxy konfigurert for vanlege sideførespurnader kan godta tilkoplinga og deretter avvise metoden. Den avvisinga er kompatibilitetsproblemet folk vanlegvis skildrar som at port 443 er blokkert.

Les svarkoden og metoden i serverloggen. Ei avvising i dette trinnet er eit anna problem enn ein TCP-tidsavbrot, og dei to fører til ulike rettingar.

Trinn 3: kontrollmeldingar

Når førespurnaden er godteken, utvekslar SSTP kontrollmeldingar som forhandlar og førebur tunnelen. Dette er protokollmeldingar inne i HTTPS-bodyen, ikkje HTTP-førespurnader, så ein proxy som granskar og skriv om bodyar kan øydeleggje dei medan sideførespurnader held seg urørte.

Det er her ein djupneinspeksjons-middlebox tenest gjer seg rykte. Viss sider lastar og VPN feilar, sjekk om bodyen vert endra i staden for om porten er open.

Trinn 4: PPP tek over

PPP leverer deretter åtferda til økta: lenkeforhandling, autentisering og nettverkslagskonfigurasjonen som følgjer. PPP-autentisering er skild frå TLS-kontrollen klienten alt har bestått. Eit serversertifikat klienten godtek seier ingenting om korvidt påloggingsdataa til brukaren er gyldige eller kontoen er autorisert.

Eit godteke sertifikat og ei avvist pålogging er ikkje motstridande. Dei er påfølgjande trinn med uavhengige utfall.

Autentisering har fleire roller

Klienten validerer identiteten til TLS-serveren mot tillitslageret sitt og det konfigurerte namnet. Deretter autentiserer PPP brukaren eller maskina, avhengig av utrullinga. Serveren kan leggje til si eiga retningslinje for kven som får kople til og kva dei får nå. Hald vertsnamnet i samsvar med identiteten til sertifikatet, fordi ei rå adresse i staden gjer eit fungerande oppsett til ein namnekontrollfeil.

Skriv ned kva trinn som rapporterte feilen. Sertifikat, metode, kontrollmelding, PPP-autentisering, deretter ruter: fem stader, fem rettingar.

Kva ein nettlesartest kan og ikkje kan vise

Å laste ei side på adressa beviser DNS-oppslag, TCP-tilgjenge og at noko lyttar og snakkar HTTP. Det beviser ikkje at metoden vert godteken, at kontrollutvekslinga overlever eller at PPP-autentisering er konfigurert. Bruk ein klient som implementerer SSTP i staden for å konvertere ein annan profil ved å endre porten.

Når økta er oppe, avgjer ruter, DNS og vidaresending på serversida framleis kva brukaren kan nå. Tunnelen er ein veg, ikkje ein autorisasjon.