SSTP не працуе там, дзе HTTPS у браўзеры працуе: чаму
SSTP працуе ўнутры TLS на порце 443, але гэта не вэб-запыт. Правярайце TCP, ідэнтычнасць TLS, абмен SSTP і аўтэнтыфікацыю PPP як асобныя этапы.
Браўзер адкрывае імя хоста VPN праз HTTPS без нараканняў, а кліент SSTP усё роўна адмаўляецца падключацца. У гэтай пары няма нічога супярэчлівага. SSTP выкарыстоўвае TLS як знешні транспарт, а затым запускае свой запыт і карысную нагрузку PPP унутры гэтага злучэння, таму паспяховая загрузка старонкі даказвае толькі адно вузкае: хост адказвае на GET на порце 443. Кліент задае іншае пытанне, і сервер можа адказаць на яго дрэнна.
Старонка загружаецца, а тунель не
Людзі бяруцца за тэст у браўзеры, бо ён хуткі, а потым успрымаюць вынік як доказ таго, што сервер дасяжны і наладжаны. Гэта доказ пра GET да таго шляху, які адкрыў адрасны радок, і не больш. Размова VPN пачынаецца пасля таго ж рукапоціску TLS, але дасылае метад і шлях, якія вэб-старонка ніколі не выкарыстоўвае. Таму адказ 200 для браўзера нічога не кажа пра тое, ці існуе канчатковы пункт SSTP.
Аддзяліце два назіранні, і пошук стане карацейшым. Транспарт і ланцуг сертыфікатаў працуюць, а нешта ў абмене пратакола над імі не. Гэта іншае расследаванне, чым зламаны порт або скончаны сертыфікат, і яно патрабуе іншых доказаў.
Што насамрэч дасылае кліент SSTP
Кліент дасылае HTTP-запыт метадам SSTP_DUPLEX_POST на шлях /sra_{GUID}/, а затым трымае цела злучэння адкрытым як двухбаковы паток, што нясе кадры PPP. Сумленны сервер адказвае HTTP/1.1 200 і перастае паводзіць сябе як вэб-сервер. Любое іншае гэта подпіс: 405 або 404 азначае, што канчатковага пункта няма, 301 або 302 што нешта перанакіроўвае запыт, а імгненны FIN што праксі або сервер закрыў паток.
Вось чаму мэтай павінен быць сервер SSTP, а не вэб-сервер з прымацаваным сертыфікатам TLS. Метад, шлях і доўгае цела гэта патрабаванні пратакола, таму зваротны праксі не можа дадаць іх адной толькі канфігурацыяй. Праксі, які бездакорна перасылае звычайны HTTPS, усё роўна можа адмовіць у метадзе, якога не пазнае.
Дзе праксі або вэб-сервер ламае паток
Пасрэднік правярае радок HTTP-запыту перш чым нешта пераслаць, і нестандартны метад з незвычайным шляхам можа не прайсці яго правілы. Некаторыя прылады падаюць звычайную старонку, а тунель адхіляюць або перарываюць, таму кліент паведамляе пра злучэнне, якое пачынаецца і потым памірае, а не пра чыстую адмову. Іншыя прымаюць запыт, а потым ужываюць тайм-аут цела або прастою, якога PPP-запыты не перажывуць. Абодва выглядаюць аднолькава з боку кліента, таму этап, які зламаўся, важнейшы за тэкст памылкі.
Сумеснае выкарыстанне порта 443 паміж вэб-сайтам і SSTP гэта рашэнне аб маршрутызацыі, а не абяцанне, што кожны крок аднолькава апрацуе абедзве размовы. Калі ў шляху стаіць балансіроўшчык нагрузкі, файрвол або тэрмінатар TLS, дадайце яго ў спіс падазроных, перш чым кранаць канфігурацыю VPN.
Правярайце этапы асобна
Выконвайце праверкі па парадку і спыніцеся на першай няўдачы, бо кожны этап выключае іншы пласт. TLS-зонд ніжэй аддзяляе ідэнтычнасць сертыфіката ад усяго, што робіць SSTP. Замяніце імя хоста на свой канчатковы пункт і прачытайце суб'ект і ланцуг, якія ён друкуе.
openssl s_client -connect vpn.example.com:443 -servername vpn.example.comЗатым суаднясіце астатнія доказы з этапамі, а не ўгадвайце па памылцы кліента. Табліца ніжэй гэта кантрольны спіс для тікета з подпісам, які аддзяляе адну няўдачу ад наступнай.
| 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 |
Запішыце ў тікет апошні этап, які ўдаўся, замест таго каб пісаць "немагчыма падключыцца". Спецыфікацыя MS-SSTP дакументуе запыт і абмен PPP, якія ідуць пасля рукапоціску TLS, і менавіта на яе спасылаюцца, калі тлумачаць, чаму тэст у браўзеры не можа замяніць ні адно, ні другое.
Спачатку ідэнтычнасць, потым PPP
Ідэнтычнасць TLS і аўтэнтыфікацыя PPP ідуць паслядоўна, а не як альтэрнатывы, і блытаніна паміж імі вядзе людзей да няправільнай налады сервера. Кліент спачатку правярае сертыфікат сервера і яго мэтавае прызначэнне, потым PPP узгадняе свой стан і аўтэнтыфікуе карыстальніка метадам выклік-адказ або EAP. Праблема з сертыфікатам дае іншую памылку, чым адхілены пароль, і ні адна з памылак не апісвае этап, які пакрывае іншая.
Замена імя хоста на адрас або пераход праз папярэджанне пра сертыфікат выдаляе праверку, якая вызначыла б этап збою, замест таго каб выправіць яго. Пакіньце папярэджанне і прачытайце яго. Не скідвайце пароль PPP, калі HTTP-абмен так і не дасягнуў паводзін SSTP, бо ўліковыя даныя ніколі не запытваліся.