Az SSTP ott bukik el, ahol a böngésző HTTPS-e sikerül: miért
Az SSTP TLS-en belül fut a 443-as porton, de nem webes kérés. Tesztelje a TCP-t, a TLS-identitást, az SSTP-cserét és a PPP-hitelesítést külön szakaszként.
A böngésző panasz nélkül nyitja meg a VPN-gazdagépnevet HTTPS-en, és az SSTP-kliens mégis megtagadja a kapcsolódást. Ebben a párban semmi sem ellentmondásos. Az SSTP a TLS-t külső szállítási rétegként használja, majd saját kérését és PPP-terhelését ezen a kapcsolaton belül futtatja, ezért egy sikeres oldalbetöltés csak egy szűk dolgot bizonyít: a gazdagép válaszol egy GET-re a 443-as porton. A kliens más kérdést tesz fel, és a kiszolgáló esetleg rosszul válaszol rá.
Az oldal betöltődik, az alagút nem
Az emberek a böngészős teszthez fordulnak, mert gyors, majd az eredményt annak bizonyítékaként kezelik, hogy a kiszolgáló elérhető és konfigurált. Ez egy GET-re vonatkozó bizonyíték arra az útvonalra, amelyet a címsor megnyitott, semmi több. A VPN-beszélgetés ugyanazon TLS-kézfogás után kezdődik, de elküld egy metódust és egy útvonalat, amelyet egy weboldal soha nem használ. Ezért a 200-as válasz a böngészőnek semmit sem mond arról, létezik-e az SSTP-végpont.
Válassza szét a két megfigyelést, és a keresés rövidebb lesz. A szállítás és a tanúsítványlánc működik, és valami a felettük lévő protokollcserében nem. Ez más vizsgálat, mint egy törött port vagy egy lejárt tanúsítvány, és más bizonyítékokat igényel.
Mit küld valójában az SSTP-kliens
A kliens HTTP-kérést küld az SSTP_DUPLEX_POST metódussal a /sra_{GUID}/ útvonalra, majd a kapcsolat törzsét nyitva tartja kétirányú adatfolyamként, amely PPP-kereteket szállít. A megfelelő kiszolgáló HTTP/1.1 200-zal válaszol, és felhagy a webszerver-viselkedéssel. Bármi más egy aláírás: a 405 vagy 404 azt jelenti, hogy nincs ott a végpont, a 301 vagy 302 azt, hogy valami átirányítja a kérést, az azonnali FIN pedig azt, hogy egy proxy vagy kiszolgáló lezárta az adatfolyamot.
Ezért a célpontnak SSTP-kiszolgálónak kell lennie, nem pedig egy webkiszolgálónak rácsavarozott TLS-tanúsítvánnyal. A metódus, az útvonal és a hosszú életű törzs protokollkövetelmény, ezért egy fordított proxy nem tudja őket pusztán konfigurációval hozzáadni. Egy proxy, amely a közönséges HTTPS-t tökéletesen továbbítja, még mindig elutasíthat egy általa nem ismert metódust.
Hol töri meg az adatfolyamot egy proxy vagy webkiszolgáló
Egy közvetítő megvizsgálja a HTTP-kérés sort, mielőtt bármit továbbítana, és egy szokatlan útvonalú egyedi metódus megbukhat a szabályain. Egyes eszközök normál oldalt szolgálnak ki, miközben elutasítják vagy megszakítják az alagutat, ezért a kliens olyan kapcsolatot jelent, amely elindul, majd meghal, nem pedig tiszta elutasítást. Mások elfogadják a kérést, majd olyan törzs- vagy tétlenségi időkorlátot alkalmaznak, amelyet a PPP-keepalive-ok nem élnek túl. Mindkettő ugyanúgy néz ki a kliens oldaláról, ezért a hibát szenvedett szakasz fontosabb, mint a hibaüzenet szövege.
A 443-as port megosztása egy webhely és az SSTP között útválasztási döntés, nem ígéret arra, hogy minden ugrás ugyanúgy kezeli a két beszélgetést. Ha terheléselosztó, tűzfal vagy TLS-terminátor van az útvonalon, tegye fel a gyanúsítottak listájára, mielőtt a VPN-konfigurációhoz nyúl.
Tesztelje a szakaszokat külön
Futtassa a ellenőrzéseket sorrendben, és álljon meg az első hibánál, mert minden szakasz más réteget zár ki. Az alábbi TLS-szonda elválasztja a tanúsítvány identitását mindattól, amit az SSTP tesz. Cserélje ki a gazdagépnevet a saját végpontjára, és olvassa el a kiírt subjectet és láncot.
openssl s_client -connect vpn.example.com:443 -servername vpn.example.comEzután rendelje a fennmaradó bizonyítékokat a szakaszokhoz, ahelyett hogy a klienshibából találgatna. Az alábbi táblázat a jegyzékben idézhető ellenőrzőlista, azzal az aláírással, amely elválaszt egy hibát a következőtől.
| Stage | What it proves | Failure signature |
|---|---|---|
| TCP to 443 | A listener exists and the path is open | Timeout or connection refused |
| TLS with SNI | The certificate matches the name you use | Name mismatch or untrusted chain |
| SSTP_DUPLEX_POST exchange | The endpoint is an SSTP server | 405, 404, 301 or an early FIN |
| PPP authentication | The user credential was accepted | Auth failure after a 200 response |
| Inner routing | A permitted destination is reachable | Tunnel up, no reply from the target |
A jegyzékben az utolsó sikeres szakaszt rögzítse, ahelyett hogy azt írná: "nem lehet csatlakozni". Az MS-SSTP specifikáció dokumentálja a TLS-kézfogást követő kérést és PPP-cserét, és ez a hivatkozás arra, miért nem helyettesítheti a böngészős teszt egyiket sem.
Először az identitás, aztán a PPP
A TLS-identitás és a PPP-hitelesítés egymás után következik, nem alternatívák, és összekeverésük rossz kiszolgálóbeállításhoz vezeti az embereket. A kliens először a kiszolgáló tanúsítványát és annak szándékolt célját validálja, majd a PPP megtárgyalja a saját állapotát, és kihívás-válasz módszerrel vagy EAP-pal hitelesíti a felhasználót. A tanúsítványprobléma más hibát ad, mint egy elutasított jelszó, és egyik hiba sem írja le azt a szakaszt, amelyet a másik lefed.
A gazdagépnév címre cserélése vagy a tanúsítványfigyelmeztetés átkattintása eltávolítja azt az ellenőrzést, amely azonosította volna a hibás szakaszt, ahelyett hogy kijavítaná. Tartsa meg a figyelmeztetést, és olvassa el. Ne állítsa vissza a PPP-jelszót sem, amikor a HTTP-csere soha nem érte el az SSTP-viselkedést, mert a hitelesítő adatokat soha nem kérték.