Hogyan ellenőrizze, hogy egy VPN-kliens valóban támogatja-e az SSTP-t

Egy terméket VPN-kliensnek nevezni semmit sem mond arról, hogy beszél-e SSTP-t, a címben szereplő 443-as port pedig még kevesebbet bizonyít. Az SSTP TLS-t futtat TCP 443 felett, majd SSTP-vezérlőcserét, majd PPP-t magához a kapcsolathoz, efölött pedig tanúsítvány-ellenőrzés és egy PPP-hitelesítési módszer. Egy kliens csak akkor támogatja a protokollt, ha a megnevezett megvalósítás a telepített verzióban a szerver követelményei szerint mindegyik réteget teljesíti. Hajtsa végre az alábbi ellenőrzéseket sorrendben, és álljon meg az elsőnél, amelyik elbukik, mert az az, amit érdemes megoldani.

Hangolja össze a megvalósítást, a verziót és a platformot

Kezdje a platformmal, az alkalmazással és a telepített builddel, mert egyetlen gyártónév két teljesen különböző megvalósítás fölött állhat. A beépített VPN-típusok és a harmadik féltől származó kliensek nem ugyanazok, és egy bővítmény olyan adaptercímkét jeleníthet meg, amely nem írja le az alatta lévő protokollt. Az aktuális kiadás dokumentációja nem azt a buildet írja le, amely az Ön előtti gépen fut. Olvassa el a verzióspecifikus oldalt, majd hasonlítsa össze azzal, amit a kliens önmagáról közöl.

Windowson az alagút típusa a platformtól származik, nem a grafikus felülettől, ezért a platformot kérdezze. Get-VpnConnection -Name 'Work' | Select-Object TunnelType, ServerAddress azt mutatja, hogy Sstp, amikor a natív kliens megpróbálja a protokollt, a kapcsolattípus-referencia pedig a beépített alagúttípusok között sorolja fel. Linuxon egyáltalán nincs natív SSTP-kliens, így a kérdés az, hogy egy külön megvalósítás, például az sstp-client csomag sstpc-je telepítve és naprakész-e.

Előbb a profilformátum, aztán a címke

A profilok nem csereszabatosak, és a kapott fájl általában gyorsabban eldönti a kérdést, mint bármely funkciólista. Az OpenVPN-direktívák, a WireGuard-kulcsok és az SSTP-kapcsolat beállításai három, egymástól független protokollt írnak le, és egyetlen importálási párbeszéd sem alakítja át az egyiket a másikká. A közös TCP 443-as port semmit sem fordít le, mert az SSTP, a TLS fölötti OpenVPN és egy egyszerű HTTPS-szolgáltatás ugyanazt a portot foglalhatja el, és semmi közös nincs fölötte.

Ha a fájl .ovpn vagy WireGuard-konfiguráció, a válasz már világos: ettől a klienstől nem kérik az SSTP-t. Egy csak SSTP-t tudó kliensbe importálva már a profil szakaszban elbukik, jóval azelőtt, hogy bármilyen protokoll-tárgyalás elkezdődne.

Amit a TLS nem bizonyít a telepítésről

Egy befejezett TLS-kézfogás bizonyítja, hogy a szerver rendelkezik tanúsítvánnyal, és semmit sem bizonyít arról, hogy az Ön kliense megbízik-e a kibocsátó láncban, vagy hogy egyezik-e a benne lévő név. Az ellenőrzésnek a szándékolt szerverrel szemben kell sikerülnie, beleértve a szervezet által üzemeltetett magán-CA-t is, és a tanúsítványhibák átugrását kínáló kliens inkább eltávolította az ellenőrzést, mintsem protokolltámogatást szerzett volna. A lánc ellenőrzése és a névegyezés két külön teszt, és egy vermet, amelyik az egyiken átmegy, a másikon elbukhat. Mindkettő az elfogadási kritériumokba tartozik, nem a hibaelhárítási függelékbe.

Ezután erősítse meg a PPP-hitelesítési módszert, mert az EAP-TLS-t használó telepítéshez olyan kliens kell, amely a PPP-n belül tanúsítványt tud bemutatni, míg a jelszóalapú módszerhez e csere támogatása szükséges. A szervercím és egy jelszó nem írja le a szervezet tényleges követelményét, különösen ott, ahol második tényező vagy eszközellenőrzés áll előtte. Kérdezze meg, melyik módszert kényszeríti ki a szerver, mielőtt feltételezné, hogy a kliens teljesíteni tudja.

Kövesse végig a munkamenetet négy szakaszon

Figyelje, hogyan lép át a kapcsolat négy határon: TCP és TLS a szerver felé, az SSTP-vezérlőcsere, a PPP-tárgyalás, majd az az erőforrás, amelyre valóban szüksége van. A TLS után megálló napló más hibát ír le, mint a PPP-n belül megálló, és a kettő különböző felelősökhöz vezet. Az, hogy egy böngésző betölti a gazdagép weboldalát, csak azt bizonyítja, hogy valami válaszolt a 443-on, ami ezen a területen a leggyakoribb téves pozitív eredmény. Ha az az oldal betöltődik, miközben a kliens továbbra is elbukik, a probléma a TLS fölött van, és a webszerver nem gyanús.

Fejezze be egy valódi privát erőforrással és egy névfeloldással, mert a létrejövő, de semmit nem szállító munkamenet a legtöbb állapotablakban ugyanúgy néz ki, mint egy működő. Egyetlen sikeres kérés a szükséges erőforrás felé eldönti azt a kérdést, amelyet az ikon nem tud.

Ha nincs támogatás, változtasson a terven

Ha a kliens nem tud SSTP-t beszélni, szerezzen jóváhagyott alternatívát, vagy kérjen a szerver tulajdonosától olyan protokollt, amelyet mindkét fél támogat. Az ismeretlen opciók törlése addig, amíg egy importálás sikerül, olyan profilt eredményez, amely semmihez sem kapcsolódik, ami lassabb út ugyanahhoz a zsákutcához. Egy ismeretlen forrásból származó telepítő, amely univerzális kompatibilitást hirdet, nem jóváhagyott bizalmi útvonalat ad a géphez, és gyakran olyasmivel helyettesíti a platformklienst, amit a szervezet nem tud frissíteni. Egyik lépés sem javítás, és mindkettő nehezebben visszafordítható, mint az eredeti probléma.

A kompatibilitás kérdését kezelje külön a teljesítménytől és a végpont kiválasztásától, mert egy közeli szerver haszontalan, ha a kliens nem tudja beszélni a protokollját. A késleltetés hangolása nem javít meg egy soha be nem fejeződő szakaszt.