SoftEther VPN Azure: مسیری از راه رله، نه یک پورت باز

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

چه چیزی در مسیر تغییر می‌کند

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

رله به آن سرور نامی در دامنه خودش می‌دهد و کلاینت‌ها برای اتصال به آنجا پیکربندی می‌شوند.

آن نام متعلق به سرویس رله است که Microsoft Azure VPN Gateway نیست، هرچند هر دو Azure چیزی نامیده می‌شوند. رفتار با آن‌ها به‌عنوان قابل‌تبدیل، پیکربندی‌ای می‌سازد که نمی‌تواند کار کند.

کدام پروتکل‌ها از رله عبور می‌کنند

رله پروتکل SoftEther را حمل می‌کند و پروژه SSTP را به عنوان گزینه کلاینت مستند می‌کند، که مفید است چون Windows کلاینت SSTP دارد. اما به حامل عمومی برای هر شنونده روی میزبان تبدیل نمی‌شود: شنونده OpenVPN، پاسخ‌دهنده IPsec و سرویس L2TP هر یک به نقطه پایانی در دسترس خود نیاز دارند و هیچ‌کدام فقط به این دلیل که سرور SoftEther متصل است از رله عبور نمی‌کند.

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

کاری که رله برای شما نمی‌کند

رله یک حامل است. کاربر، هاب مجازی، سیاست دسترسی یا مسیر ایجاد نمی‌کند و هیچ چیزی از شبکه‌های خصوصی پشت سرور شما نمی‌داند. اگر کلاینت‌های راه دور باید به زیرشبکه LAN برسند، سرور هنوز به پیکربندی پل یا مسیریابی، مسیر بازگشت و سیاست دیوار آتش نیاز دارد که آن را ممکن می‌کند. طرح‌های نشانی همپوشان در دو سر نیز برای رله نامرئی است و مشکل شما برای حل باقی می‌ماند.

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

اعتبارسنجی گواهی و احراز هویت کاربر همچنان مسئولیت سرور است و رله هرگز جای هیچ‌یک را نمی‌گیرد.

آن را به‌عنوان یک وابستگی اداره کنید

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

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

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