SoftEther پشت NAT: عبور مستقیم یا رله VPN Azure؟

سرور SoftEther شما پشت روتر ارائه‌دهنده‌ای است که نمی‌توانید تغییرش دهید، و کلاینت‌ها همچنان متصل می‌شوند، پس فرض می‌کنید رله همه‌چیز را حمل می‌کند. اینکه این درست باشد به این بستگی دارد که کدام سازوکار کار را انجام داده است: یک نام DNS، یک مسیر UDP هماهنگ‌شده یا یک تونل خروجی به رله. هر سه می‌توانند کلاینت متصل بسازند و در شرایط متفاوت شکست می‌خورند. پیش از دست زدن به کاربران یا هاب‌ها تصمیم بگیرید کدام مسیر را می‌خرید.

سه سازوکار، سه وعده متفاوت

DNS پویا نام‌گذاری است. نام میزبان را به نشانی در حال تغییر نشانه می‌رود تا مردم دنبال عدد نروند، و کار دیگری نمی‌کند. عبور بومی NAT هماهنگی است: دو نقطه پایانی SoftEther اطلاعات مبادله می‌کنند و می‌کوشند از میان دستگاه‌های ترجمه میان خود یک مسیر UDP قابل استفاده باز کنند. VPN Azure یک رله است: سرور به سرویس شماره می‌گیرد و کلاینت‌ها از طریق نام میزبان روی زیرساخت رله می‌رسند.

این سه مکمل یکدیگرند نه نسخه‌های یک قابلیت. یک استقرار می‌تواند نام‌گذاری را به کار ببرد در حالی که اتصالش در واقع به عبور یا به رله وابسته است.

از کلاینت و شبکه تصمیم بگیرید

انتخاب از کلاینت آغاز می‌شود، چون عبور فقط در سازوکار اتصال بومی SoftEther وجود دارد. OpenVPN، L2TP/IPsec و شنودگرهای SSTP روی همان سرور آن را به ارث نمی‌برند، هرچند یک میزبان را شریک‌اند. ببینید کاربر چه چیزی اجرا می‌کند، سپس شبکه چه چیزی اجازه می‌دهد. شبکه سازمانی که فقط TCP 443 را مجاز می‌داند شما را به رله‌ای روی همان درگاه سوق می‌دهد، در حالی که شبکه‌ای که درگاه‌های UDP موردنیاز عبور را عبور می‌دهد می‌تواند مسیر مستقیم را بیازماید؛ هر دو را با سیاست خروج واقعی بسنجید.

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

تأیید کنید نشست کدام انتقال را برگزیده است

وضعیت اتصال تنها منبع صادق برای مسیر در استفاده است. آن را روی سرور بخوانید و نام میزبانی را که کلاینت گرفته حل کنید.

vpncmd /SERVER localhost /HUB VPN /CMD:SessionList
vpncmd /SERVER localhost /HUB VPN /CMD:SessionGet <session-name>
nslookup alice.vpnazure.net

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

برای آنچه مسیر انتخابی به آن وابسته است برنامه بریزید

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

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