SSTP zlyháva tam, kde HTTPS v prehliadači funguje: prečo
SSTP beží vnútri TLS na porte 443, ale nie je to webová požiadavka. Testujte TCP, identitu TLS, výmenu SSTP a autentifikáciu PPP ako samostatné fázy.
Prehliadač otvorí názov hostiteľa VPN cez HTTPS bez sťažnosti a klient SSTP stále odmieta pripojenie. Na tejto dvojici nie je nič protirečivé. SSTP používa TLS ako vonkajší transport a potom v tomto spojení vykonáva vlastnú požiadavku a užitočné zaťaženie PPP, takže úspešné načítanie stránky dokazuje len jednu úzku vec: hostiteľ odpovedá na GET na porte 443. Klient sa pýta na inú otázku a server na ňu môže odpovedať zle.
Stránka sa načíta a tunel nie
Ľudia siahnu po teste v prehliadači, pretože je rýchly, a výsledok potom berú ako dôkaz, že server je dostupný a nakonfigurovaný. Je to dôkaz o GET na cestu, ktorú otvoril adresný riadok, nič viac. VPN rozhovor sa začína po rovnakom TLS podaní rúk, ale posiela metódu a cestu, ktoré webová stránka nikdy nepoužíva. Preto odpoveď 200 pre prehliadač nehovorí nič o tom, či koncový bod SSTP existuje.
Oddeľte dve pozorovania a hľadanie sa skráti. Transport a reťazec certifikátov fungujú a niečo vo výmene protokolu nad nimi nie. To je iné vyšetrovanie než pokazený port alebo exspirovaný certifikát a vyžaduje iné dôkazy.
Čo klient SSTP skutočne posiela
Klient posiela HTTP požiadavku metódou SSTP_DUPLEX_POST na cestu /sra_{GUID}/ a potom drží telo spojenia otvorené ako obojsmerný tok nesúci rámce PPP. Vyhovujúci server odpovie HTTP/1.1 200 a prestane sa správať ako webový server. Čokoľvek iné je podpis: 405 alebo 404 znamená, že koncový bod nie je, 301 alebo 302 znamená, že niečo požiadavku presmerúva, a okamžitý FIN znamená, že proxy alebo server tok uzavrel.
Preto musí byť cieľom server SSTP, a nie webový server s priskrutkovaným TLS certifikátom. Metóda, cesta a dlho otvorené telo sú požiadavky protokolu, takže reverzná proxy ich nemôže pridať iba konfiguráciou. Proxy, ktorá dokonale preposiela bežný HTTPS, môže stále odmietnuť metódu, ktorú nepozná.
Kde proxy alebo webový server preruší tok
Sprostredkovateľ skontroluje riadok HTTP požiadavky, než čokoľvek prepošle, a vlastná metóda s neobvyklou cestou môže zlyhať na jeho pravidlách. Niektoré zariadenia obsluhujú normálnu stránku, zatiaľ čo tunel odmietajú alebo prerušujú, takže klient hlási spojenie, ktoré sa začne a potom zomrie, namiesto čistého odmietnutia. Iné požiadavku prijmú a potom uplatnia časový limit tela alebo nečinnosti, ktorý keepalive PPP neprežijú. Obe vyzerajú z pohľadu klienta rovnako, preto je fáza, ktorá zlyhala, dôležitejšia ako text chyby.
Zdieľanie portu 443 medzi webom a SSTP je voľba smerovania, nie sľub, že každý skok zvládne oba rozhovory rovnako. Ak je v ceste vyvažovač záťaže, firewall alebo TLS terminátor, pridajte ho na zoznam podozrivých, než sa dotknete konfigurácie VPN.
Testujte fázy oddelene
Vykonajte kontroly v poradí a zastavte sa pri prvom zlyhaní, pretože každá fáza vylučuje inú vrstvu. TLS sonda nižšie oddeľuje identitu certifikátu od všetkého, čo SSTP robí. Nahraďte názov hostiteľa svojím koncovým bodom a prečítajte subject a reťazec, ktorý vypíše.
openssl s_client -connect vpn.example.com:443 -servername vpn.example.comPotom priraďte zostávajúce dôkazy k fázam, namiesto toho aby ste hádali z chyby klienta. Tabuľka nižšie je kontrolný zoznam na citovanie v tikete, s podpisom, ktorý oddeľuje jedno zlyhanie od ďalšieho.
| 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 |
Do tiketu zapíšte poslednú úspešnú fázu, namiesto toho aby ste písali "nedá sa pripojiť". Špecifikácia MS-SSTP dokumentuje požiadavku a výmenu PPP, ktoré nasledujú po TLS podaní rúk, a je referenciou pre to, prečo test v prehliadači nemôže nahradiť ani jedno z nich.
Najprv identita, potom PPP
Identita TLS a autentifikácia PPP sú postupné, nie alternatívne, a ich zámena posiela ľudí k nesprávnemu nastaveniu servera. Klient najprv overí certifikát servera a jeho zamýšľaný účel, potom PPP vyjedná svoj stav a autentifikuje používateľa metódou výzva-odpoveď alebo EAP. Problém s certifikátom dáva inú chybu než odmietnuté heslo a ani jedna chyba neopisuje fázu, ktorú pokrýva tá druhá.
Nahradenie názvu hostiteľa adresou alebo prekliknutie varovania o certifikáte odstráni kontrolu, ktorá by identifikovala zlyhávajúcu fázu, namiesto toho aby ju opravilo. Varovanie si nechajte a prečítajte ho. Neresetujte ani heslo PPP, keď výmena HTTP nikdy nedosiahla správanie SSTP, pretože prihlasovacie údaje neboli nikdy vyžiadané.