Slik kontrollerer du om en VPN-klient faktisk støtter SSTP

Å kalle et produkt en VPN-klient sier ingenting om hvorvidt det snakker SSTP, og port 443 i adressen beviser enda mindre. SSTP kjører TLS over TCP 443, deretter en SSTP-kontrollutveksling, deretter PPP for selve forbindelsen, med sertifikatvalidering og en PPP-autentiseringsmetode på toppen. En klient støtter bare protokollen når den navngitte implementasjonen, i den installerte versjonen, fullfører hvert av disse lagene mot serverens krav. Gå gjennom kontrollene nedenfor i rekkefølge og stopp ved den første som feiler, for det er den som er verdt å løse.

Avstem implementasjon, versjon og plattform

Begynn med plattformen, programmet og den installerte byggen, for ett produsentnavn kan stå over to helt forskjellige implementasjoner. Innebygde VPN-typer og tredjepartsklienter er ikke det samme, og en plugin kan vise en adapteretikett som ikke beskriver protokollen under. Dokumentasjonen for gjeldende utgave beskriver ikke den byggen som kjører på maskinen foran deg. Les siden for den aktuelle versjonen, og sammenlign den med det klienten oppgir om seg selv.

På Windows kommer tunneltypen fra plattformen og ikke fra GUI-et, så spør plattformen. Get-VpnConnection -Name 'Work' | Select-Object TunnelType, ServerAddress viser Sstp når den innebygde klienten vil forsøke protokollen, og referansen for tilkoblingstyper fører den opp blant de innebygde tunneltypene. På Linux finnes det ingen innebygd SSTP-klient i det hele tatt, så spørsmålet blir om en separat implementasjon som sstpc fra sstp-client-pakken er installert og oppdatert.

Les profilformatet før etiketten

Profiler kan ikke byttes om hverandre, og filen du har fått, avgjør vanligvis spørsmålet raskere enn noen funksjonsliste. OpenVPN-direktiver, WireGuard-nøkler og SSTP-tilkoblingsinnstillinger beskriver tre ubeslektede protokoller, og ingen importdialog gjør den ene om til den andre. Delt TCP-port 443 oversetter ingenting, for SSTP, OpenVPN over TLS og en vanlig HTTPS-tjeneste kan oppta samme port uten å ha noe til felles over den.

Hvis filen er en .ovpn eller en WireGuard-konfigurasjon, er svaret allerede klart: den klienten blir ikke bedt om å snakke SSTP. Import til en klient som bare kan SSTP feiler på profiltrinnet, lenge før noen protokollforhandling begynner.

Hva TLS ikke beviser om utrullingen

Et fullført TLS-håndtrykk beviser at serveren har et sertifikat, og det beviser ingenting om hvorvidt klienten din stoler på utstedelseskjeden eller om navnet i den stemmer. Valideringen må lykkes mot den tiltenkte serveren, inkludert enhver privat CA organisasjonen driver, og en klient som tilbyr å hoppe over sertifikatfeil har fjernet kontrollen i stedet for å ha fått protokollstøtte. Kjedepåvising og navnematch er to separate tester, og en stabel som består den ene, kan fortsatt feile på den andre. Begge hører hjemme i akseptkriteriene, ikke i feilsøkingsvedlegget.

Bekreft deretter PPP-autentiseringsmetoden, for en utrullering med EAP-TLS trenger en klient som kan legge fram et sertifikat inne i PPP, mens en passordbasert metode trenger støtte for den utvekslingen. En serveradresse og et passord beskriver ikke organisasjonens faktiske krav, særlig der en andre faktor eller en enhetskontroll står foran. Spør hvilken metode serveren krever, før du antar at klienten kan oppfylle den.

Følg økten gjennom fire trinn

Se forbindelsen krysse fire grenser: TCP og TLS til serveren, SSTP-kontrollutvekslingen, PPP-forhandlingen og deretter ressursen du faktisk trenger. En logg som stopper etter TLS, beskriver en annen feil enn en som stopper inne i PPP, og de to peker på ulike eiere. At en nettleser laster vertens nettside, beviser bare at noe svarte på 443, som er den vanligste falske positive i dette feltet. Hvis den siden lastes mens klienten fortsatt feiler, sitter problemet over TLS og webserveren er ikke den mistenkte.

Avslutt med en ekte privat ressurs og et navneoppslag, for en økt som etableres og ikke bærer noe, ser identisk ut med en fungerende i de fleste statusvinduer. Én vellykket forespørsel mot ressursen du trenger, avgjør et spørsmål ikonet ikke kan.

Når støtten mangler, endre planen

Hvis klienten ikke kan snakke SSTP, skaff et godkjent alternativ eller be servereieren om en protokoll begge ender støtter. Å slette ukjente valg til en import lykkes, gir en profil som ikke kobler til noe, og det er en langsommere vei til samme blindgate. En installasjonsfil fra ukjent kilde som reklamerer med universell kompatibilitet, legger til en ikke-godkjent tillitsvei på maskinen og erstatter ofte plattformklienten med noe organisasjonen ikke kan oppdatere. Ingen av de to grepene er en reparasjon, og begge er vanskeligere å reversere enn det opprinnelige problemet.

Behandle kompatibilitetsspørsmålet atskilt fra ytelse og valg av endepunkt, for en nærliggende server er ubrukelig når klienten ikke kan snakke protokollen dens. Finjustering av latenstid reparerer ikke et trinn som aldri fullføres.