Sådan kontrollerer du, om en VPN-klient reelt understøtter SSTP
En importknap og port 443 beviser intet. Kontrollér den navngivne implementering, profilformatet, certifikatet og PPP-godkendelsen, og verificér derefter hvert trin.
At kalde et produkt for en VPN-klient siger intet om, hvorvidt det taler SSTP, og port 443 i adressen beviser endnu mindre. SSTP kører TLS over TCP 443, derefter en SSTP-kontroludveksling, derefter PPP for selve forbindelsen, med certifikatvalidering og en PPP-godkendelsesmetode ovenpå. En klient understøtter kun protokollen, når den navngivne implementering i den installerede version gennemfører hvert af disse lag i forhold til din servers krav. Gå gennem kontrollen nedenfor i rækkefølge, og stop ved den første, der fejler, for det er den, der er værd at løse.
Afstem implementering, version og platform
Begynd med platformen, programmet og den installerede build, for ét producentnavn kan dække over to helt forskellige implementeringer. Indbyggede VPN-typer og tredjepartsklienter er ikke det samme, og et plugin kan vise en adapteretikette, der ikke beskriver protokollen nedenunder. Dokumentationen for den aktuelle udgivelse beskriver ikke den build, der kører på maskinen foran dig. Læs siden for den specifikke version, og sammenlign den med det, klienten oplyser om sig selv.
På Windows kommer tunneltypen fra platformen og ikke fra GUI'et, så spørg platformen. Get-VpnConnection -Name 'Work' | Select-Object TunnelType, ServerAddress viser Sstp, når den indbyggede klient vil forsøge protokollen, og referencen for forbindelsestyper nævner den blandt de indbyggede tunneltyper. På Linux findes der slet ingen indbygget SSTP-klient, så spørgsmålet bliver, om en separat implementering som sstpc fra sstp-client-pakken er installeret og opdateret.
Læs profilformatet før etiketten
Profiler kan ikke udskiftes, og den fil, du har fået, afgør normalt spørgsmålet hurtigere end enhver funktionsliste. OpenVPN-direktiver, WireGuard-nøgler og SSTP-forbindelsesindstillinger beskriver tre ubeslægtede protokoller, og ingen importdialog omdanner den ene til den anden. Delt TCP-port 443 oversætter intet, for SSTP, OpenVPN over TLS og en almindelig HTTPS-tjeneste kan optage den samme port uden at have noget til fælles ovenover.
Hvis filen er en .ovpn eller en WireGuard-konfiguration, er svaret allerede givet: den klient bedes ikke om at tale SSTP. Import i en klient, der kun kan SSTP, fejler på profilstadiet, længe før nogen protokolforhandling begynder.
Hvad TLS ikke beviser om udrulningen
Et fuldført TLS-håndtryk beviser, at serveren har et certifikat, og det beviser intet om, hvorvidt din klient stoler på udstedelseskæden eller matcher navnet i den. Valideringen skal lykkes mod den tilsigtede server, inklusive enhver privat CA, som organisationen driver, og en klient, der tilbyder at springe certifikatfejl over, har fjernet kontrollen i stedet for at få protokolunderstøttelse. Kædevalidering og navnematch er to separate test, og en stak, der består den ene, kan stadig fejle den anden. Begge hører i acceptkriterierne, ikke i fejlfindingsbilaget.
Bekræft derefter PPP-godkendelsesmetoden, for en udrulning med EAP-TLS kræver en klient, der kan fremvise et certifikat inde i PPP, mens en adgangskodebaseret metode kræver understøttelse af den udveksling. En serveradresse og en adgangskode beskriver ikke organisationens faktiske krav, især hvor en anden faktor eller en enhedskontrol står foran. Spørg, hvilken metode serveren kræver, før du antager, at klienten kan opfylde den.
Følg sessionen gennem fire trin
Se forbindelsen krydse fire grænser: TCP og TLS til serveren, SSTP-kontroludvekslingen, PPP-forhandling og derefter den ressource, du faktisk har brug for. En log, der stopper efter TLS, beskriver en anden fejl end en, der stopper inde i PPP, og de to peger på forskellige ejere. At en browser indlæser værtens webside beviser kun, at noget svarede på 443, hvilket er den mest almindelige falske positiv i dette område. Hvis den side indlæses, mens klienten stadig fejler, sidder problemet over TLS og webserveren er ikke den mistænkte.
Slut af med en rigtig privat ressource og et navneopslag, for en session, der etableres og ikke bærer noget, ser identisk ud med en fungerende i de fleste statusvinduer. Én vellykket anmodning til den ressource, du har brug for, afgør et spørgsmål, som ikonet ikke kan.
Når understøttelsen mangler, skal du ændre planen
Hvis klienten ikke kan tale SSTP, skaf et godkendt alternativ, eller bed serverejeren om en protokol, som begge ender understøtter. At slette ukendte valgmuligheder, indtil importen lykkes, giver en profil, der ikke forbinder til noget, hvilket er en langsommere vej til den samme blindgyde. En installationsfil fra en ukendt kilde, der reklamerer med universel kompatibilitet, tilføjer en ikke-godkendt tillidsvej til maskinen og erstatter ofte platformsklienten med noget, organisationen ikke kan opdatere. Ingen af de to træk er en løsning, og begge er sværere at rulle tilbage end det oprindelige problem.
Behandl kompatibilitetsspørgsmålet adskilt fra ydeevne og valg af endepunkt, for en nærliggende server er ubrugelig, når klienten ikke kan tale dens protokol. Finjustering af latenstid reparerer ikke et trin, der aldrig fuldføres.