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، لأن التفويض وعضوية المحور وتعيين العناوين ومسارات العودة تبقى مسؤوليتك في كل الأحوال.

دوّن اسم المضيف والبروتوكول وإعدادات الميزة والنقل الملاحظ. ذلك السجل الرباعي هو ما يتيح للشخص التالي إعادة إنتاج اتصال عامل.