SSTP autentificerer først serveren og derefter brugeren

En SSTP-klient kan fuldføre TLS og alligevel afvise brugeren et sekund senere. Den rækkefølge er ikke en fejl, det er protokolstakken: transportsikkerhed først, brugergodkendelse bagefter. Fordi de to trin fejler med forskellige meddelelser, kræver de også forskellige rettelser. At læse hvilket trin der producerede fejlen er det meste af diagnosen.

Et betroet certifikat beviser endepunktet; det siger intet om kontoen.

Hvad TLS-håndtrykket fastslår

Klienten validerer det certifikat, serveren fremviser, mod sit tillidslager, det ønskede værtsnavn, gyldighedsvinduet og enhver yderligere politik, som platformen anvender. Det beskytter forbindelsen til det tilsigtede endepunkt. Det beviser ikke, at en bestemt konto er aktiveret, ikke udløbet eller har tilladelse til fjernadgang. Det er separate spørgsmål, som stilles senere af en anden komponent.

Derfor er det den forkerte reparation at fjerne certifikatkontroller for at nå loginprompten. Du får en loginprompt på en forbindelse, du ikke kan verificere. En certifikatfejl hører til værtsnavnet, uret, kæden eller tillidskonfigurationen.

Hvad SSTP og PPP tilføjer ovenpå

SSTP kører over HTTPS og bærer PPP indeni, med sin egen kontroludveksling omkring forbindelsen. PPP kører derefter sine link- og autentificeringsfaser, og autentificeringsmetoden afhænger af serverpolitik og klientens evne. PAP, CHAP, MS-CHAPv2 og EAP er alle PPP-autentificeringsmuligheder med meget forskellige egenskaber. VPN'ens brugerkontrol er den PPP-fase, ikke TLS-laget nedenunder.

En brugerafvisning kan derfor betyde legitimationsoplysninger, en kontobegrænsning eller et metodemismatch.

Årsagen på serversiden er langt mere nyttig end at nulstille hver hemmelighed i profilen. En hændelse med deaktiveret konto og en mislykket metodeforhandling ser ens ud på klienten og har intet til fælles på serveren.

Match fejlen til trinnet

Kontroller, om forbindelsen når TLS, derefter SSTP HTTP-udvekslingen, derefter PPP-fasen. Hold logtidsstempler justeret på tværs af forsøg, så en tidligere fejl ikke forveksles med en senere succes. En klient, der logger to forsøg i ét vindue, vil ellers se ud som om den fejlede på det sidste trin, den nåede. Læs den første relevante fejl, ikke den sidste linje.

Den samme justering er vigtig på serversiden, hvor autentificeringsposten og transportloggen ofte er separate filer med separate ure. To minutters skævhed er nok til at få en indlysende årsag til at se umulig ud.

Efter login er autorisation stadig adskilt

Et vellykket login giver ikke adgang til alle private ressourcer. Ruter bestemmer, hvad der kan nås, DNS bestemmer, hvad der opløses, og hver tjeneste anvender stadig sine egne tilladelser. En session, der viser forbundet, er en udtalelse om tunnelen, ikke om fildelingen. Når en bruger kan oprette forbindelse og ikke kan nå én vært, er tunnelefasen allerede afsluttet.

Det er den samme lagdeling, som håndtrykket viste, et niveau højere.

Hold kontogendannelse inden for operatørens understøttede proces i stedet for at ændre transportindstillinger som reaktion på en udtrykkelig brugerafvisning. At ændre transporten for at rette en deaktiveret konto er den slags reparation, der ser ud til at virke, når kontoen genaktiveres af en ikke-relateret grund.