Kako preveriti, ali odjemalec VPN resnično podpira SSTP

Imenovati izdelek odjemalec VPN ne pove ničesar o tem, ali govori SSTP, vrata 443 v naslovu pa dokazujejo še manj. SSTP poganja TLS prek TCP 443, nato izmenjavo nadzora SSTP, nato PPP za samo povezavo, na vrhu pa preverjanje potrdila in metoda preverjanja PPP. Odjemalec protokol podpira le, ko navedena izvedba v nameščeni različici dokonča vsako od teh plasti skladno z zahtevami vašega strežnika. Izvedite spodnja preverjanja po vrsti in ustavite se pri prvem neuspešnem, ker je vredno rešiti prav tega.

Uskladite izvedbo, različico in platformo

Začnite s platformo, aplikacijo in nameščeno gradnjo, ker je eno ime proizvajalca lahko nad dvema popolnoma različnima izvedbama. Vgrajene vrste VPN in odjemalci tretjih oseb niso isto, vtičnik pa lahko prikaže oznako vmesnika, ki ne opisuje protokola pod njo. Dokumentacija trenutne izdaje ne opisuje gradnje, ki teče na stroju pred vami. Preberite stran, specifično za različico, in jo primerjajte s tem, kar odjemalec sporoča o sebi.

V sistemu Windows vrsta tunela prihaja s platforme in ne iz grafičnega vmesnika, zato vprašajte platformo. Get-VpnConnection -Name 'Work' | Select-Object TunnelType, ServerAddress prikaže Sstp, ko bo izvorni odjemalec poskusil protokol, in referenca vrst povezav ga navaja med vgrajenimi vrstami tunela. V sistemu Linux izvornega odjemalca SSTP sploh ni, zato je vprašanje, ali je ločena izvedba, kot je sstpc iz paketa sstp-client, nameščena in ažurna.

Pred oznako preberite obliko profila

Profili niso zamenljivi in datoteka, ki ste jo dobili, običajno vprašanje razreši hitreje kot kateri koli seznam funkcij. Direktive OpenVPN, ključi WireGuard in nastavitve povezave SSTP opisujejo tri nepovezane protokole in nobeno uvozno okno enega ne spremeni v drugega. Skupna vrata TCP 443 ne prevedejo ničesar, ker lahko SSTP, OpenVPN prek TLS in običajna storitev HTTPS zasedejo ista vrata in nad njimi nimajo nič skupnega.

Če je datoteka .ovpn ali konfiguracija WireGuard, je odgovor že jasen: od tega odjemalca se ne zahteva, da govori SSTP. Uvoz v odjemalca, ki zmore samo SSTP, spodleti že v stopnji profila, veliko preden se začne kakršno koli pogajanje o protokolu.

Česa TLS ne dokaže o uvajanju

Dokončano rokovanje TLS dokaže, da ima strežnik potrdilo, in ničesar ne dokaže o tem, ali vaš odjemalec zaupa izdajateljski verigi ali se ime v njej ujema. Preverjanje mora uspeti proti predvidenemu strežniku, vključno z vsakim zasebnim CA, ki ga upravlja organizacija, odjemalec, ki ponuja preskok napak potrdila, pa je preverjanje odstranil, namesto da bi pridobil podporo za protokol. Preverjanje verige in ujemanje imena sta dva ločena testa in sklad, ki prestane enega, lahko spodleti na drugem. Oba sodita med merila sprejemljivosti, ne v prilogo za odpravljanje težav.

Nato potrdite metodo preverjanja PPP, ker uvajanje z EAP-TLS potrebuje odjemalca, ki lahko predloži potrdilo znotraj PPP, medtem ko metoda z geslom potrebuje podporo za to izmenjavo. Naslov strežnika in geslo ne opisujeta dejanske zahteve organizacije, še posebej kadar je pred njima drugi dejavnik ali preverjanje naprave. Vprašajte, katero metodo strežnik zahteva, preden domnevate, da jo odjemalec lahko izpolni.

Spremljajte sejo skozi štiri stopnje

Opazujte, kako povezava prečka štiri meje: TCP in TLS do strežnika, izmenjava nadzora SSTP, pogajanje PPP in nato vir, ki ga resnično potrebujete. Dnevnik, ki se ustavi po TLS, opisuje drugačno okvaro kot tisti, ki se ustavi znotraj PPP, in oba vodita do različnih odgovornih. Nalaganje spletne strani gostitelja v brskalniku dokaže le, da je na 443 nekaj odgovorilo, kar je najpogostejši lažni pozitiv na tem področju. Če se ta stran naloži, odjemalec pa še vedno spodleti, je težava nad TLS in spletni strežnik ni osumljenec.

Končajte z resničnim zasebnim virom in poizvedbo imena, ker je seja, ki se vzpostavi in ničesar ne prenaša, v večini statusnih oken videti enako kot delujoča. Ena uspešna zahteva do vira, ki ga potrebujete, razreši vprašanje, na katero ikona ne more odgovoriti.

Ko podpore ni, spremenite načrt

Če odjemalec ne more govoriti SSTP, si priskrbite odobreno alternativo ali prosite lastnika strežnika za protokol, ki ga podpirata oba konca. Brisanje neznanih možnosti, dokler uvoz ne uspe, ustvari profil, ki se nikamor ne poveže, kar je počasnejša pot v isto slepo ulico. Namestitveni program iz neznanega vira, ki oglašuje univerzalno združljivost, doda stroju neodobreno pot zaupanja in pogosto nadomesti odjemalca platforme z nečim, česar organizacija ne more posodobiti. Nobena od obeh potez ni popravilo in obe je težje razveljaviti kot prvotno težavo.

Vprašanje združljivosti obravnavajte ločeno od zmogljivosti in izbire končne točke, ker je bližnji strežnik neuporaben, ko odjemalec ne more govoriti njegovega protokola. Nastavljanje zakasnitve ne popravi stopnje, ki se nikoli ne konča.