SSTP er PPP over HTTPS, ikke en nettside på port 443

SSTP bærer PPP inne i en HTTPS-tilkobling, og derfor ser det ut som webtrafikk for alt i midten. TLS og HTTP etablerer den ytre kanalen, deretter forbereder SSTP-kontrollmeldinger tunnelen, og PPP leverer øktens oppførsel. En nettleser som laster en side på samme adresse har bare fullført en del av det første trinnet. Å behandle det som en VPN-test er måten en fungerende proxy får skylden for et protokollavvik.

Gå gjennom de fire trinnene i rekkefølge, og feilen du ser lander i ett av dem.

Trinn 1: TCP og TLS

Klienten åpner en TCP-tilkobling til port 443 og utfører et TLS-håndtrykk. Sertifikatkjeden må samsvare med vertsnavnet klienten ble konfigurert med. Et navneavvik her gir en feil før noen SSTP-melding utveksles, og SSTP-spesifikasjonen forutsetter at denne ytre HTTPS-kanalen allerede finnes. Ingenting i de senere trinnene kan kompensere for en tillitsfeil her.

En vanlig webserver kan fullføre dette trinnet perfekt og likevel feile i det neste. TLS-suksess er bevis om sertifikatet, ikke om protokollen bak det.

Trinn 2: HTTPS-forespørselen

SSTP sender forespørselen sin med en bestemt metode, SSTP_DUPLEX_POST, og holder utvekslingen åpen i stedet for å returnere et dokument. En server eller proxy konfigurert for vanlige sideforespørsler kan godta tilkoblingen og deretter avvise metoden. Den avvisningen er kompatibilitetsproblemet folk vanligvis beskriver som at port 443 er blokkert.

Les svarkoden og metoden i serverloggen. En avvisning i dette trinnet er et annet problem enn en TCP-tidsavbrudd, og de to fører til ulike rettelser.

Trinn 3: kontrollmeldinger

Når forespørselen er godtatt, utveksler SSTP kontrollmeldinger som forhandler og forbereder tunnelen. Dette er protokollmeldinger inne i HTTPS-bodyen, ikke HTTP-forespørsler, så en proxy som inspiserer og skriver om bodyer kan ødelegge dem mens sideforespørsler forblir urørt.

Det er her en dybdeinspeksjons-middlebox tjener sitt rykte. Hvis sider lastes og VPN feiler, sjekk om bodyen endres i stedet for om porten er åpen.

Trinn 4: PPP overtar

PPP leverer deretter øktens oppførsel: lenkeforhandling, autentisering og nettverkslagskonfigurasjonen som følger. PPP-autentisering er atskilt fra TLS-kontrollen klienten allerede har bestått. Et serversertifikat klienten godtar sier ingenting om hvorvidt brukerens påloggingsopplysninger er gyldige eller kontoen er autorisert.

Et godtatt sertifikat og en avvist pålogging er ikke motstridende. De er påfølgende trinn med uavhengige utfall.

Autentisering har flere roller

Klienten validerer TLS-serverens identitet mot sitt tillitslager og det konfigurerte navnet. Deretter autentiserer PPP brukeren eller maskinen, avhengig av utrullingen. Serveren kan legge til sin egen policy for hvem som får koble til og hva de får nå. Hold vertsnavnet i samsvar med sertifikatets identitet, fordi en rå adresse i stedet gjør et fungerende oppsett til en navnekontrollfeil.

Skriv ned hvilket trinn som rapporterte feilen. Sertifikat, metode, kontrollmelding, PPP-autentisering, deretter ruter: fem steder, fem rettelser.

Hva en nettlesertest kan og ikke kan vise

Å laste en side på adressen beviser DNS-oppslag, TCP-tilgjengelighet og at noe lytter og snakker HTTP. Det beviser ikke at metoden godtas, at kontrollutvekslingen overlever eller at PPP-autentisering er konfigurert. Bruk en klient som implementerer SSTP i stedet for å konvertere en annen profil ved å endre porten.

Når økten er oppe, avgjør ruter, DNS og videresending på serversiden fortsatt hva brukeren kan nå. Tunnelen er en vei, ikke en autorisasjon.