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

SSTP bærer PPP inde i en HTTPS-forbindelse, og derfor ligner det webtrafik for alt i midten. TLS og HTTP etablerer den ydre kanal, derefter forbereder SSTP-kontrolmeddelelser tunnelen, og PPP leverer sessionens adfærd. En browser, der indlæser en side på samme adresse har kun gennemført en del af den første fase. At betragte det som en VPN-test er måden, hvorpå en fungerende proxy får skylden for en protokol-uoverensstemmelse.

Gå gennem de fire faser i rækkefølge, og den fejl, du ser, lander i en af dem.

Fase 1: TCP og TLS

Klienten åbner en TCP-forbindelse til port 443 og udfører et TLS-håndtryk. Certifikatkæden skal matche det værtsnavn, klienten blev konfigureret med. En navneforskel her giver en fejl, før nogen SSTP-meddelelse udveksles, og SSTP-specifikationen forudsætter, at denne ydre HTTPS-kanal allerede findes. Intet i de senere faser kan opveje en tillidsfejl her.

En almindelig webserver kan gennemføre denne fase perfekt og alligevel fejle i den næste. TLS-succes er bevis om certifikatet, ikke om protokollen bag det.

Fase 2: HTTPS-anmodningen

SSTP sender sin anmodning med en bestemt metode, SSTP_DUPLEX_POST, og holder udvekslingen åben i stedet for at returnere et dokument. En server eller proxy, der er konfigureret til almindelige sideanmodninger, kan acceptere forbindelsen og derefter afvise metoden. Den afvisning er det kompatibilitetsproblem, som folk normalt beskriver som, at port 443 er blokeret.

Læs svarkoden og metoden i serverloggen. En afvisning i denne fase er et andet problem end en TCP-timeout, og de to fører til forskellige rettelser.

Fase 3: kontrolmeddelelser

Når anmodningen er accepteret, udveksler SSTP kontrolmeddelelser, der forhandler og forbereder tunnelen. Det er protokolmeddelelser inde i HTTPS-bodyen og ikke HTTP-anmodninger, så en proxy, der inspicerer og omskriver bodies, kan ødelægge dem, mens sideanmodninger forbliver urørte.

Det er her, en dybdeinspektions-middlebox tjener sit ry. Hvis sider indlæses, og VPN fejler, så tjek, om bodyen ændres, i stedet for om porten er åben.

Fase 4: PPP overtager

PPP leverer derefter sessionens adfærd: linkforhandling, godkendelse og den netværkslagskonfiguration, der følger. PPP-godkendelse er adskilt fra den TLS-kontrol, klienten allerede har bestået. Et servercertifikat, klienten accepterer, siger intet om, hvorvidt brugerens legitimationsoplysninger er gyldige, eller om kontoen er autoriseret.

Et accepteret certifikat og et afvist login er ikke modstridende. De er på hinanden følgende faser med uafhængige resultater.

Godkendelse har flere roller

Klienten validerer TLS-serverens identitet mod sit tillidslager og det konfigurerede navn. Derefter godkender PPP brugeren eller maskinen afhængigt af udrulningen. Serveren kan tilføje sin egen politik om, hvem der må forbinde, og hvad de må nå. Hold værtsnavnet i overensstemmelse med certifikatets identitet, fordi en rå adresse i stedet gør en fungerende opsætning til en navnekontrolfejl.

Skriv ned, hvilken fase der rapporterede fejlen. Certifikat, metode, kontrolmeddelelse, PPP-godkendelse, derefter ruter: fem steder, fem rettelser.

Hvad en browsertest kan og ikke kan vise

At indlæse en side på adressen beviser DNS-opløsning, TCP-rækkevidde og at noget lytter, som taler HTTP. Det beviser ikke, at metoden accepteres, at kontroludvekslingen overlever, eller at PPP-godkendelse er konfigureret. Brug en klient, der implementerer SSTP, i stedet for at konvertere en anden profil ved at ændre porten.

Når sessionen er oppe, afgør ruter, DNS og videresendelse på serversiden stadig, hvad brugeren kan nå. Tunnelen er en vej, ikke en autorisation.