Så kontrollerar du om en VPN-klient verkligen stöder SSTP

Att kalla en produkt för VPN-klient säger ingenting om huruvida den talar SSTP, och port 443 i adressen bevisar ännu mindre. SSTP kör TLS över TCP 443, sedan ett SSTP-kontrollutbyte, sedan PPP för själva förbindelsen, med certifikatvalidering och en PPP-autentiseringsmetod ovanpå. En klient stöder protokollet bara när den namngivna implementeringen, i den installerade versionen, slutför vart och ett av dessa lager enligt serverns krav. Arbeta igenom kontrollerna nedan i ordning och stanna vid den första som fallerar, för det är den som är värd att lösa.

Stäm av implementering, version och plattform

Börja med plattformen, programmet och den installerade bygget, för ett tillverkarnamn kan stå över två helt olika implementeringar. Inbyggda VPN-typer och tredjepartsklienter är inte samma sak, och ett plugin kan visa en adapteretikett som inte beskriver protokollet under. Dokumentationen för aktuell utgåva beskriver inte den build som körs på maskinen framför dig. Läs sidan för den specifika versionen och jämför den sedan med vad klienten uppger om sig själv.

I Windows kommer tunneltypen från plattformen och inte från GUI:t, så fråga plattformen. Get-VpnConnection -Name 'Work' | Select-Object TunnelType, ServerAddress visar Sstp när den inbyggda klienten försöker med protokollet, och referensen för anslutningstyper listar den bland de inbyggda tunneltyperna. I Linux finns ingen inbyggd SSTP-klient alls, så frågan blir om en separat implementering som sstpc från paketet sstp-client är installerad och uppdaterad.

Läs profilformatet före etiketten

Profiler är inte utbytbara, och filen du fått avgör vanligtvis frågan snabbare än någon funktionslista. OpenVPN-direktiv, WireGuard-nycklar och SSTP-anslutningsinställningar beskriver tre orelaterade protokoll, och ingen importdialog gör den ena till den andra. Delad TCP-port 443 översätter ingenting, för SSTP, OpenVPN över TLS och en vanlig HTTPS-tjänst kan uppta samma port utan att ha något gemensamt ovanför.

Om filen är en .ovpn eller en WireGuard-konfiguration är svaret redan klart: den klienten ombeds inte tala SSTP. Import till en klient som bara klarar SSTP misslyckas redan i profilsteget, långt innan någon protokollförhandling börjar.

Vad TLS inte bevisar om driftsättningen

En slutförd TLS-handskakning bevisar att servern har ett certifikat, och den bevisar ingenting om huruvida din klient litar på utfärdarkedjan eller om namnet i den stämmer. Valideringen måste lyckas mot den avsedda servern, inklusive varje privat CA som organisationen driver, och en klient som erbjuder att hoppa över certifikatfel har tagit bort kontrollen i stället för att ha fått protokollstöd. Kedjevalidering och namnmatchning är två separata tester, och en stack som klarar det ena kan fortfarande fallera på det andra. Båda hör hemma i acceptanskriterierna, inte i felsökningsbilagan.

Bekräfta sedan PPP-autentiseringsmetoden, för en driftsättning med EAP-TLS behöver en klient som kan lägga fram ett certifikat inne i PPP, medan en lösenordsbaserad metod behöver stöd för det utbytet. En serveradress och ett lösenord beskriver inte organisationens faktiska krav, särskilt inte där en andra faktor eller en enhetskontroll står framför. Fråga vilken metod servern kräver innan du antar att klienten kan uppfylla den.

Följ sessionen genom fyra steg

Se förbindelsen korsa fyra gränser: TCP och TLS till servern, SSTP-kontrollutbytet, PPP-förhandlingen och sedan resursen du faktiskt behöver. En logg som stannar efter TLS beskriver ett annat fel än en som stannar inne i PPP, och de två pekar på olika ansvariga. Att en webbläsare laddar värdens webbsida bevisar bara att något svarade på 443, vilket är den vanligaste falska positiva i området. Om den sidan laddas medan klienten fortfarande misslyckas, sitter problemet ovanför TLS och webbservern är inte den misstänkta.

Avsluta med en verklig privat resurs och en namnsökning, för en session som etableras och inte bär något ser identisk ut med en fungerande i de flesta statusfönster. En enda lyckad begäran mot resursen du behöver avgör en fråga som ikonen inte kan.

När stödet saknas, ändra planen

Om klienten inte kan tala SSTP, skaffa ett godkänt alternativ eller be serverägaren om ett protokoll som båda ändar stöder. Att radera okända alternativ tills en import lyckas ger en profil som inte ansluter till något, vilket är en långsammare väg till samma återvändsgränd. En installationsfil från okänd källa som annonserar universell kompatibilitet lägger till en icke godkänd förtroendeväg på maskinen och ersätter ofta plattformsklienten med något organisationen inte kan uppdatera. Ingen av de två åtgärderna är en reparation, och båda är svårare att ångra än det ursprungliga problemet.

Behandla kompatibilitetsfrågan separat från prestanda och val av ändpunkt, för en närliggande server är värdelös när klienten inte kan tala dess protokoll. Latensjustering reparerar inte ett steg som aldrig slutförs.