SSTP پشت پروکسی‌ای که TLS را بررسی می‌کند: نشست کجا می‌شکند

مرورگر شما اینترانت شرکت را بارگذاری می‌کند، گواهی پروکسی معتبر است، و با این حال کلاینت SSTP نزدیک پایان اتصال قطع می‌شود. این الگو به تفاوت میان یک درخواست وب و یک نشست تونل‌شده اشاره دارد، نه به رمز عبور اشتباه. اتصال را از TCP به بالا طی کنید و اولین مرحله‌ای را که شکست می‌خورد یادداشت کنید. مرحله، نه کد خطا، به شما می‌گوید آیا پروکسی علت است.

از جایی شروع کنید که کلاینت متوقف می‌شود

کلاینت از یک توالی ثابت می‌گذرد: اتصال TCP به پورت 443، دست‌دادن TLS، اعتبارسنجی گواهی، تبادل HTTP مربوط به SSTP، مذاکره و احراز هویت PPP، و سپس پیکربندی IP. شکست در هر مرحله اثر متفاوتی بر جای می‌گذارد، و اشتباه گرفتن آن‌ها شما را به صفحه پیکربندی نادرست می‌فرستد.

شکست TCP یک پایان مهلت یا بازنشانی است پیش از آنکه حتی یک بایت TLS ظاهر شود. شکست TLS یک هشدار یا پایان مهلت دست‌دادن است. شکست گواهی هشداری درباره زنجیره یا نام تولید می‌کند. شکست HTTP پس از دست‌دادن موفق می‌آید، اغلب به شکل کد وضعیت یا بسته شدن فوری. شکست PPP پس از آن می‌آید که تونل از نظر فنی برقرار شده است، به همین دلیل شبیه مشکل احراز هویت به نظر می‌رسد.

گزارش کلاینت را برای آخرین مرحله موفق بخوانید، نه اولین خط خطا. خط خطا معمولاً پیامد را گزارش می‌کند، در حالی که مرز مرحله نام مؤلفه‌ای را می‌آورد که رد کرده است.

SSTP از شبکه چه می‌خواهد که حمل کند

SSTP روی TLS روی TCP 443 اجرا می‌شود و سپس یک درخواست HTTP به نام SSTP_DUPLEX_POST، که در مشخصات SSTP تعریف شده است، به مسیری به شکل /sra_{GUID}/ می‌فرستد. درخواست طول محتوای عملاً نامحدود اعلام می‌کند و جریان را در طول عمر نشست در هر دو جهت باز نگه می‌دارد. قاب‌های PPP درون همان جریان حرکت می‌کنند.

به همین دلیل پروکسی‌ای که مرور عادی را مدیریت می‌کند باز هم می‌تواند شکست بخورد. GET یا POST با بدنه محدود را می‌توان بافر، بررسی و ارسال کرد؛ اما جریان دوطرفه با بدنه‌ای که هرگز تمام نمی‌شود را نمی‌توان. پروکسی‌ای که منتظر کامل شدن بدنه می‌ماند تا ابد منتظر می‌ماند و کلاینت در نهایت به پایان مهلت می‌رسد.

فیلتر کردن متدها و احراز هویت حالت‌های شکست خود را اضافه می‌کنند. اگر پروکسی برای درخواست اعتبارنامه بخواهد، ممکن است کلاینت VPN پاسخ ندهد، هرچند مرورگر پاسخ می‌داد. اگر متد را حذف یا بازنویسی کند، دروازه درخواست را پیش از شروع PPP رد می‌کند.

چرا بررسی، هویت را تغییر می‌دهد

پروکسی‌ای که TLS را بررسی می‌کند اتصال TLS کلاینت را پایان می‌دهد و اتصال جداگانه‌ای به دروازه باز می‌کند. بنابراین کلاینت گواهی پروکسی را اعتبارسنجی می‌کند، نه گواهی دروازه را، و دروازه پروکسی را همتای خود می‌بیند. وقتی سازمان ریشه خود را توزیع می‌کند، مرورگر و کلاینت VPN هر دو می‌توانند آن زنجیره را بپذیرند، پس دست‌دادن موفق می‌شود و مشکل به مرحله بعد می‌رود.

اعتبارسنجی موفق به این معنا نیست که پروکسی می‌تواند نشست را حمل کند. هنوز باید یک POST دوطرفه نامحدود را بدون بافر عبور دهد و هر دو اتصال را ساعت‌ها زنده نگه دارد. بسیاری از محصولات بررسی برای ترافیک درخواست-پاسخ ساخته شده‌اند و این حالت را ضعیف یا اصلاً مدیریت نمی‌کنند.

به همین دلیل افزودن یک ریشه ناشناخته یا غیرفعال کردن اعتبارسنجی تعمیر اشتباه است. این کار تغییر می‌دهد کلاینت کدام گواهی را می‌پذیرد؛ اما هیچ کاری با مدیریت جریانی که واقعاً نشست را شکسته است نمی‌کند.

پیش از تغییر تنظیمات، صادرکننده را مشخص کنید

از نقطه پایانی بپرسید چه گواهی‌ای ارائه می‌دهد و چه کسی آن را امضا کرده است. دستورهای زیر زنجیره و صادرکننده را بدون شروع نشست VPN نشان می‌دهند:

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts
curl -vI https://vpn.example.com/

اگر صادرکننده یک CA عمومی باشد، احتمالاً اتصال برای این میزبان رهگیری نمی‌شود و شکست جای دیگری است. اگر صادرکننده CA خود سازمان باشد، بررسی فعال است و دروازه از طریق پروکسی می‌رسد. اثر انگشت را با آنچه تیم شبکه انتظار دارد مقایسه کنید، پیش از آنکه تنها بر پایه نام نتیجه بگیرید.

آزمایش مرورگر به همان میزبان فقط ثابت می‌کند که پروکسی یک GET را می‌پذیرد. چیزی درباره متد SSTP، URI درخواست یا عمر بدنه نمی‌گوید، پس یک صفحه اینترانتِ کارکننده را شاهد پشتیبانی از مسیر تونل ندانید.

مسیر پشتیبانی‌شده را انتخاب کنید

از مالک شبکه یک پرسش مشخص بپرسید: آیا پروکسی یک POST دوطرفه بدون بافر به این دروازه روی پورت 443 را مجاز می‌داند؟ پاسخ بله به یک استثنا در پروکسی یا یک دور زدن مستند برای میزبان VPN می‌رسد. پاسخ خیر یعنی مسیر بررسی‌شده نمی‌تواند SSTP را حمل کند، و اصلاح پشتیبانی‌شده مسیر یا پروتکل دیگری است، نه دستکاری کلاینت.

گزینه‌ها معمولاً شامل خروجی بدون بررسی برای دروازه VPN، طراحی تونل تقسیم‌شده که تنها ترافیک شرکت را از پروکسی می‌فرستد، یا پروتکل جایگزینی است که سازمان روی پورت دیگری پشتیبانی می‌کند. هر کدام به طراحی شبکه تعلق دارد و هر کدام باید با همان دستگاه و پروفایل آزمایش شود تا مقایسه مسیر را جدا کند.

نتیجه را مستند کنید: صادرکننده، مرحله شکست، قاعده پروکسی و مسیر انتخاب‌شده. نفر بعدی که همان توقف 98 درصدی را می‌بیند می‌تواند یک واقعیت را بررسی کند، به جای تکرار کل مسیر.