Az SSTP PPP HTTPS felett, nem weboldal a 443-as porton

SSTP PPP-t szállít egy HTTPS-kapcsolatban, ezért minden köztes eszköznek webbox forgalomnak látszik. A TLS és a HTTP állítja fel a külső csatornát, utána az SSTP vezérlőüzenetei készítik elő az alagutat, és a PPP adja a munkamenet viselkedését. Egy böngésző, amely ugyanazon a címen tölt be egy oldalt csak az első szakasz egy részét teljesítette. Ha ezt VPN-tesztnek tekintjük, egy működő proxy kapja a hibát egy protokoll-eltérésért.

Járja végig a négy szakaszt sorrendben, és a látott hiba valamelyikükbe esik.

1. szakasz: TCP és TLS

A kliens TCP-kapcsolatot nyit a 443-as portra, és TLS-kézfogást végez. A tanúsítványláncnak meg kell felelnie annak a hosztnévnek, amellyel a klienst beállították. A névegyezés hiánya itt hibát okoz, mielőtt bármelyik SSTP-üzenet kicserélődne, és a SSTP-specifikáció feltételezi, hogy ez a külső HTTPS-csatorna már létezik. A későbbi szakaszokban semmi nem tudja kompenzálni az itteni bizalmi hibát.

Egy közönséges webszerver tökéletesen teljesítheti ezt a szakaszt, és mégis elbukhat a következőn. A TLS sikere a tanúsítványról szól, nem a mögötte lévő protokollról.

2. szakasz: a HTTPS-kérés

Az SSTP egy meghatározott módszerrel, az SSTP_DUPLEX_POST-tal küldi a kérését, és nyitva tartja a cserét ahelyett, hogy dokumentumot adna vissza. Egy hétköznapi oldalkérésekre beállított szerver vagy proxy elfogadhatja a kapcsolatot, majd elutasíthatja a módszert. Ez az elutasítás az a kompatibilitási probléma, amelyet az emberek általában a 443-as port blokkolásaként írnak le.

Olvassa el a válaszkódot és a módszert a szerver naplójában. Az e szakaszban történő elutasítás más probléma, mint egy TCP-időtúllépés, és a kettő különböző javításokhoz vezet.

3. szakasz: vezérlőüzenetek

Miután a kérés elfogadásra kerül, az SSTP olyan vezérlőüzeneteket cserél, amelyek egyeztetik és előkészítik az alagutat. Ezek protokollüzenetek a HTTPS törzsén belül, nem HTTP-kérések, ezért egy törzseket vizsgáló és átíró proxy eltörheti őket, miközben az oldalkérések érintetlenek maradnak.

Itt szerzi meg hírnevét egy mélyvizsgáló köztes eszköz. Ha az oldalak betöltődnek, de a VPN elbukik, azt ellenőrizze, hogy a törzs módosul-e, ne azt, hogy a port nyitva van-e.

4. szakasz: a PPP átveszi

Ezután a PPP adja a munkamenet viselkedését: kapcsolat-egyeztetés, hitelesítés és az ezt követő hálózati réteg beállítása. A PPP-hitelesítés különálló attól a TLS-ellenőrzéstől, amelyen a kliens már átment. Egy szervertanúsítvány elfogadása semmit nem mond arról, hogy a felhasználó hitelesítő adatai érvényesek-e, vagy hogy a fiók jogosult-e.

Az elfogadott tanúsítvány és az elutasított bejelentkezés nem mond ellent egymásnak. Ezek egymást követő szakaszok, független eredményekkel.

A hitelesítésnek több szerepe van

A kliens a TLS-szerver identitását a saját bizalmi tárolójához és a beállított névhez méri. Ezután a PPP hitelesíti a felhasználót vagy a gépet, a telepítéstől függően. A szerver saját szabályt adhat hozzá arról, ki kapcsolódhat és mit érhet el. Tartsa a hosztnevet összhangban a tanúsítvány identitásával, mert a nyers címre cserélés egy működő beállítást névellenőrzési hibává tesz.

Jegyezze fel, melyik szakasz jelentette a hibát. Tanúsítvány, módszer, vezérlőüzenet, PPP-hitelesítés, majd útvonalak: öt hely, öt javítás.

Mit mutathat meg egy böngészős teszt, és mit nem

Egy oldal betöltése a címen bizonyítja a DNS-feloldást, a TCP elérhetőségét és azt, hogy valami hallgat, ami HTTP-t beszél. Nem bizonyítja, hogy a módszert elfogadják, a vezérlőcsere túlél, vagy a PPP-hitelesítés be van állítva. Olyan klienst használjon, amely megvalósítja az SSTP-t, ahelyett hogy egy másik profilt a port módosításával alakítana át.

Amikor a munkamenet feláll, az útvonalak, a DNS és a kiszolgálóoldali továbbítás dönti el továbbra is, mit érhet el a felhasználó. Az alagút egy útvonal, nem egy engedély.