SSTP zataji tamo gdje HTTPS u pregledniku uspije: zašto
SSTP radi unutar TLS-a na portu 443, ali to nije web zahtjev. Testirajte TCP, TLS identitet, SSTP razmjenu i PPP autentifikaciju kao odvojene faze.
Preglednik otvara VPN ime hosta preko HTTPS-a bez prigovora, a SSTP klijent ipak odbija uspostaviti vezu. Ništa u tom paru nije proturječno. SSTP rabi TLS kao vanjski prijevoz, a zatim unutar te veze izvodi vlastiti zahtjev i PPP teret, pa uspješno učitavanje stranice dokazuje samo jednu usku stvar: host odgovara na GET na portu 443. Klijent postavlja drugo pitanje, a poslužitelj mu može odgovoriti loše.
Stranica se učita, a tunel ne
Ljudi posežu za testom u pregledniku jer je brz, a zatim rezultat uzimaju kao dokaz da je poslužitelj dostupan i konfiguriran. To je dokaz o GET-u na putanju koju je otvorila adresna traka, ništa više. VPN razgovor počinje nakon istog TLS rukovanja, ali šalje metodu i putanju koju web stranica nikada ne rabi. Zato odgovor 200 za preglednik ne govori ništa o tome postoji li SSTP završna točka.
Odvojite dva zapažanja i potraga postaje kraća. Prijevoz i lanac certifikata rade, a nešto u razmjeni protokola iznad njih ne radi. To je druga istraga od pokvarenog porta ili istekao certifikata i traži drukčije dokaze.
Što SSTP klijent zapravo šalje
Klijent šalje HTTP zahtjev metodom SSTP_DUPLEX_POST na putanju /sra_{GUID}/, a zatim drži tijelo veze otvorenim kao dvosmjerni tok koji nosi PPP okvire. Ispravan poslužitelj odgovara HTTP/1.1 200 i prestaje se ponašati kao web poslužitelj. Bilo što drugo je potpis: 405 ili 404 znači da završne točke nema, 301 ili 302 znači da nešto preusmjerava zahtjev, a trenutačni FIN znači da je proxy ili poslužitelj zatvorio tok.
Zato meta mora biti SSTP poslužitelj, a ne web poslužitelj s pričvršćenim TLS certifikatom. Metoda, putanja i dugotrajno tijelo zahtjevi su protokola, pa obrnuti proxy ne može ih dodati samo konfiguracijom. Proxy koji savršeno prosljeđuje običan HTTPS ipak može odbiti metodu koju ne prepoznaje.
Gdje proxy ili web poslužitelj prekida tok
Posrednik pregledava red HTTP zahtjeva prije nego što bilo što proslijedi, a prilagođena metoda s neobičnom putanjom može pasti na njegovim pravilima. Neki uređaji poslužuju normalnu stranicu dok odbijaju ili prekidaju tunel, pa klijent prijavljuje vezu koja počne i zatim umre umjesto čistog odbijanja. Drugi prihvate zahtjev pa primijene vremensko ograničenje tijela ili mirovanja koje PPP keepalive poruke ne mogu preživjeti. Oboje izgleda isto s klijentove strane, zato je faza koja je pala važnija od teksta pogreške.
Dijeljenje porta 443 između web stranice i SSTP-a odluka je o usmjeravanju, a ne obećanje da svaki skok obrađuje oba razgovora na isti način. Ako je na putu balanser opterećenja, vatrozid ili TLS termininator, dodajte ga na popis sumnjivaca prije nego dirnete VPN konfiguraciju.
Testirajte faze odvojeno
Izvršite provjere redom i zaustavite se na prvom neuspjehu, jer svaka faza isključuje drugi sloj. TLS sonda u nastavku odvaja identitet certifikata od svega što SSTP radi. Zamijenite ime hosta svojom završnom točkom i pročitajte subject i lanac koji ispisuje.
openssl s_client -connect vpn.example.com:443 -servername vpn.example.comZatim preslikajte preostale dokaze na faze umjesto da nagađate iz pogreške klijenta. Tablica u nastavku kontrolni je popis za tiket, s potpisom koji odvaja jedan neuspjeh od sljedećega.
| 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 |
U tiket zapišite posljednju fazu koja je uspjela umjesto da pišete "nema veze". MS-SSTP specifikacija dokumentira zahtjev i PPP razmjenu koji slijede nakon TLS rukovanja i referenca je za to zašto test u pregledniku ne može zamijeniti nijedno od toga.
Prvo identitet, zatim PPP
TLS identitet i PPP autentifikacija uzastopni su, ne alternativni, a njihovo miješanje vodi ljude na pogrešnu postavku poslužitelja. Klijent prvo provjeri certifikat poslužitelja i njegovu namjenu, zatim PPP pregovara vlastito stanje i autentificira korisnika metodom izazov-odgovor ili EAP. Problem s certifikatom daje drukčiju pogrešku od odbijene lozinke i nijedna pogreška ne opisuje fazu koju pokriva ona druga.
Zamjena imena hosta adresom ili preskakanje upozorenja o certifikatu uklanja provjeru koja bi identificirala neuspjelu fazu umjesto da je popravi. Zadržite upozorenje i pročitajte ga. Nemojte resetirati PPP lozinku kad HTTP razmjena nikada nije stigla do SSTP ponašanja, jer podaci za prijavu nikada nisu zatraženi.