شکست 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 را بررسی می‌کند، و یک روش سفارشی با مسیر غیرمعمول ممکن است قواعد آن را رد نکند. برخی دستگاه‌ها صفحه‌ای عادی سرو می‌کنند در حالی که تونل را رد یا قطع می‌کنند، بنابراین کلاینت اتصالی را گزارش می‌دهد که شروع می‌شود و سپس می‌میرد، نه یک رد تمیز. دستگاه‌های دیگر درخواست را می‌پذیرند و سپس مهلت بدنه یا بی‌کاری اعمال می‌کنند که keepaliveهای PPP از آن جان سالم به در نمی‌برند. هر دو از سمت کلاینت یکسان به نظر می‌رسند، به همین دلیل مرحله‌ای که شکست خورده از متن خطا مهم‌تر است.
اشتراک پورت 443 میان یک وب‌سایت و SSTP یک انتخاب مسیریابی است، نه وعده‌ای که هر گام هر دو گفت‌وگو را یکسان مدیریت کند. اگر متعادل‌کننده بار، دیوار آتش یا پایانه TLS در مسیر باشد، پیش از دست زدن به پیکربندی VPN آن را به فهرست مظنونان اضافه کنید.
مراحل را جداگانه آزمایش کنید
بررسی‌ها را به ترتیب اجرا کنید و در نخستین شکست بایستید، چون هر مرحله لایه متفاوتی را کنار می‌گذارد. کاوشگر TLS پایین هویت گواهی را از هر چیزی که SSTP انجام می‌دهد جدا می‌کند. نام میزبان را با نقطه پایانی خود جایگزین کنید و subject و زنجیره‌ای را که چاپ می‌شود بخوانید.
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 احراز هویت می‌کند. مشکل گواهی خطای متفاوتی از رمز عبور ردشده تولید می‌کند و هیچ‌یک از دو خطا مرحله‌ای را که دیگری پوشش می‌دهد توصیف نمی‌کند.
جایگزینی نام میزبان با یک نشانی، یا کلیک کردن فراتر از هشدار گواهی، بررسی‌ای را که مرحله شکست‌خورده را شناسایی می‌کرد حذف می‌کند، نه اینکه آن را درست کند. هشدار را نگه دارید و آن را بخوانید. همچنین وقتی تبادل HTTP هرگز به رفتار SSTP نرسید، رمز PPP را بازنشانی نکنید، زیرا اعتبارنامه هرگز خواسته نشد.