چگونه بررسی کنیم که یک کلاینت VPN واقعاً از SSTP پشتیبانی می‌کند

نامیدن یک محصول به‌عنوان کلاینت VPN هیچ چیزی دربارهٔ اینکه آیا آن SSTP صحبت می‌کند نمی‌گوید، و پورت 443 در نشانی حتی کمتر چیزی اثبات می‌کند. SSTP ابتدا TLS را روی TCP 443 اجرا می‌کند، سپس یک تبادل کنترل SSTP، سپس PPP برای خود پیوند، و روی آن اعتبارسنجی گواهی و یک روش احراز هویت PPP. کلاینت تنها زمانی از پروتکل پشتیبانی می‌کند که پیاده‌سازی نام‌برده، در نسخهٔ نصب‌شده، هر یک از آن لایه‌ها را مطابق نیازهای سرور شما کامل کند. بررسی‌های زیر را به ترتیب انجام دهید و در نخستین موردی که شکست می‌خورد بایستید، زیرا همان یکی ارزش حل کردن دارد.

پیاده‌سازی، نسخه و سکو را هم‌تراز کنید

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

در ویندوز نوع تونل از سکو می‌آید نه از رابط گرافیکی، پس از سکو بپرسید. Get-VpnConnection -Name 'Work' | Select-Object TunnelType, ServerAddress هنگامی که کلاینت بومی پروتکل را می‌آزماید Sstp را نشان می‌دهد، و مرجع انواع اتصال آن را در میان انواع تونل داخلی فهرست می‌کند. در لینوکس هیچ کلاینت SSTP بومی وجود ندارد، بنابراین پرسش این می‌شود که آیا پیاده‌سازی جداگانه‌ای مانند sstpc از بستهٔ sstp-client نصب و به‌روز است.

پیش از برچسب، قالب نمایه را بخوانید

نمایه‌ها قابل تعویض نیستند و فایلی که به شما داده‌اند معمولاً این پرسش را سریع‌تر از هر فهرست ویژگی حل می‌کند. دستورهای OpenVPN، کلیدهای WireGuard و تنظیمات اتصال SSTP سه پروتکل بی‌ربط را توصیف می‌کنند و هیچ کادر ورود یکی را به دیگری تبدیل نمی‌کند. اشتراک پورت TCP 443 چیزی را ترجمه نمی‌کند، زیرا SSTP، OpenVPN روی TLS و یک سرویس HTTPS ساده می‌توانند همان پورت را بگیرند و چیزی بیش از آن مشترک نداشته باشند.

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

آنچه TLS دربارهٔ استقرار اثبات نمی‌کند

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

سپس روش احراز هویت PPP را تأیید کنید، زیرا استقراری با EAP-TLS به کلاینتی نیاز دارد که بتواند گواهی را درون PPP ارائه دهد، در حالی که روش مبتنی بر گذرواژه به پشتیبانی آن تبادل نیاز دارد. نشانی سرور و یک گذرواژه نیاز واقعی سازمان را توصیف نمی‌کنند، به‌ویژه آنجا که یک عامل دوم یا بررسی دستگاه پیش روی آن قرار دارد. پیش از فرض اینکه کلاینت می‌تواند آن را برآورده کند، بپرسید سرور کدام روش را الزام می‌کند.

نشست را در چهار مرحله دنبال کنید

ببینید اتصال چگونه چهار مرز را می‌گذراند: TCP و TLS به سرور، تبادل کنترل SSTP، مذاکرهٔ PPP، و سپس منبعی که واقعاً به آن نیاز دارید. گزارشی که پس از TLS می‌ایستد عیب متفاوتی را از گزارشی که درون PPP می‌ایستد توصیف می‌کند و آن دو به مسئولان متفاوتی می‌رسند. بارگذاری صفحهٔ وب میزبان در مرورگر تنها اثبات می‌کند که چیزی روی 443 پاسخ داده است، که رایج‌ترین نتیجهٔ مثبت کاذب در این زمینه است. اگر آن صفحه بارگذاری شود در حالی که کلاینت هنوز شکست می‌خورد، مشکل بالاتر از TLS است و کارساز وب مظنون نیست.

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

وقتی پشتیبانی نیست، برنامه را عوض کنید

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

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