مهلت زمانی SSTP یا خطای گواهی: چگونه آنها را از هم تشخیص دهیم
پاسخی که نمیآید و هویتی که رد میشود دو تعمیر متفاوت میخواهند. پیش از تغییر هر چیزی، مرحله SSTP را از بررسی گواهی جدا کنید.
اتصال SSTP به دو شیوه شکست میخورد که از دید کاربر یکسان به نظر میرسند، و تعمیر هر یک در لایهای دیگر است. مهلت زمانی یعنی تبادل ضروری هرگز تمام نشد؛ خطای گواهی یعنی ماده هویت رسید و رد شد. اگر دومی را با اولی یکی بگیرید، سر از دیوارهای آتش و گذرواژههایی درمیآورید که هرگز مشکل نبودند. شاهد متمایزکننده در گزارش خودِ کلاینت است، اگر پیش از تغییر هر چیزی آن را بخوانید.
دو شکست، دو تبادل متفاوت
SSTP تونلی را درون نشستی به قالب HTTPS حمل میکند، از این رو در شبکههایی که تنها 443 را اجازه میدهند دوام میآورد. کلاینت دستدادن TLS را کامل میکند، درخواست HTTP را با روشی ویژهٔ پروتکل میفرستد، و سپس تونل درون آن جریان اجرا میشود. شکست در هر یک از این مراحل اتصال را متوقف میکند و تنها مراحل بعدی به اعتبارنامهها مربوطاند.
همین ترتیب، تشخیص است. اگر دستدادن TLS هرگز کامل نشود، هیچ اعتبارنامهای فرستاده نشده، پس بازنشانی گذرواژه کمکی نمیکند. اگر دستدادن کامل شود و سپس گیر کند، هویت پذیرفته شده و چیزی در مسیر درخواست آن را رد کرده است. اگر دستدادن با پیام اعتبارسنجی شکست بخورد، سرور پاسخ داده و کلاینت از شنیدهاش خوشش نیامده است. سه نتیجه، سه لایه.
خط گزارش معمولاً میگوید در کدام یک از این سه هستید، از این رو ارزش دارد پیش از نخستین تغییر آن را ثبت کنید.
مهلت زمانی یعنی یک مرحله هرگز تمام نشد
با تفکیک نام و دسترسپذیری TCP آغاز کنید، زیرا مهلت زمانی در آنجا با مهلت زمانی بعدی یکسان به نظر میرسد. یک بررسیکنندهٔ پورت که 443 را باز گزارش میدهد تنها ثابت میکند شنوندهای اتصالی را پذیرفته و نه چیزی بیشتر.
مشکوک بعدی مسیر است نه میزبان. پروکسیها و دیوارهای آتشی که برنامهها را میشناسند گاهی روش درخواستی را که SSTP به کار میبرد رد میکنند، یا جریانی را میاندازند که ساعتها باز میماند، و هر دو رفتار از دید کلاینت مانند مهلت زمانی است. صفحهٔ HTTPS معمولی که همان میزبان سرو میکند بیعیب بارگذاری میشود در حالی که روش تونل رد میشود، از این رو مرور به نقطهٔ پایانی چیز بسیار کمی را ثابت میکند. برای جدا کردن این دو حالت از شبکهای بدون پروکسی آزمایش کنید.
Test-NetConnection vpn.example.com -Port 443
netsh http show sslcert
Get-WinEvent -LogName 'Microsoft-Windows-RasSstp/Operational' -MaxEvents 20
مهلت زمانی پیش از هر پاسخی از همتا چیزی دربارهٔ حساب نمیگوید، و تغییر گذرواژه در آن لحظه تنها یک متغیر اضافه میکند.
خطای گواهی یعنی هویت رد شد
اینجا سرور واقعاً پاسخ داده، پس شبکه کار میکند و پرسش به هویت منتقل میشود. نامی را که کلاینت میگیرد با نامهایی که گواهی واقعاً ادعا میکند مقایسه کنید، سپس تاریخهای اعتبار و زنجیرهٔ صادرکننده را بررسی کنید.
یک CA خصوصی که کلاینت به آن اعتماد ندارد همان دستهٔ خطا را پدید میآورد که گواهی منقضی میآورد، و همچنین ساعتی که چند ساعت اشتباه است. گرفتن نشانی خام ناسازگاری تازهای میسازد، زیرا گواهی نامها را ادعا میکند نه نشانیها. در استقراری مدیریتشده، پیکربندی اعتماد مورد نظر را از مدیر آن بگیرید بهجای پذیرفتن ریشهٔ جایگزینی که صفحهٔ خطا پیشنهاد میکند. اعتبارسنجی روشن میماند تا زمانی که علت را برطرف کنید.
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
w32tm /query /status
مرحلهٔ موفق TLS را پس از عبور دستنخورده نگه دارید، زیرا بازگرداندنش در ادامه پنهان میکند که کدام تغییر تونل را واقعاً درست کرد.
جایی که این دو اشتباه گرفته میشوند
هر دو شکست به شکل اتصالی که بالا نمیآید ظاهر میشوند، و هر دو پس از آن میآیند که کاربر چیزی بیربط را تغییر داده است. همین تصادف است که تعمیر نادرست را مدتی باورپذیر نشان میدهد.
دو عادت آنها را جدا نگه میدارد. گزارش کلاینت را پیش از دست زدن به پیکربندی ثبت کنید تا نخستین وضعیت حفظ شود. در هر تلاش یک لایه را تغییر دهید تا نتیجهٔ بعدی به متغیری شناختهشده تعلق داشته باشد. بررسیکنندهٔ پورت و مرورگر مشاهدههایی جزئیاند نه توالی کامل، و هیچکدام جای گزارش خود کلاینت را نمیگیرد. هیچیک از این دو عادت هزینهای ندارد و هر دو بررسی را کوتاه میکنند.
پرسش گواهی و پرسش دسترسپذیری به دلیلی جداگانه مستند شدهاند.
با کلاینت واقعی دوباره بیازمایید، سپس به درون حرکت کنید
وقتی اصلاح مشخص در جای خود نشست، با کلاینت واقعی SSTP و نمایهٔ راستین دوباره تلاش کنید، نه با زبانهٔ مرورگر.
rasdial "Corp SSTP" /disconnect
rasdial "Corp SSTP" user '*'
Get-VpnConnection -Name "Corp SSTP" | Select-Object ServerAddress, TunnelType, AuthenticationMethod
اگر نشست متصل شد و منابع هنوز شکست میخورند، تونل دیگر مشکوک نیست: به مسیریابی، DNS و دسترسی به سرویسها بروید. این بررسی دیگری با شواهد دیگر است. نگه داشتن مراحل کارآمد TLS و احراز هویت مانع میشود که به تکرار اولی تبدیل شود. مرحلهای را که شکست خورد در تیکت بنویسید، وگرنه نفر بعدی دوباره از بالا شروع میکند.