الجسر المحلي في SoftEther مقابل SecureNAT: أيّهما تُشغّل

افتح SoftEther Manager، فالقرار الحقيقي الأول بشأن أي محور ليس مربّع اختيار، بل مسألة طوبولوجيا. يربط الجسر المحلي ذلك المحور بمحوّل شبكة فعلي ويتيح للمقطع القائم تزويد العنونة، بينما يمنح SecureNAT المحور موجّهًا افتراضيًا وNAT وDHCP خاصًا به. الاختيار بينهما يغيّر مصدر العناوين والجهاز الذي يجيب عنها. تشغيل الاثنين معًا على أمل أن يفوز أحدهما هو الطريق الذي يحوّل مختبرًا عاملًا إلى سلسلة تذاكر دعم.

ابدأ من المحور الذي تعدّله فعلًا

يعرض Manager شجرة من الخوادم والمحاور، ومن السهل إعداد المحور الافتراضي بينما يتصل العملاء بمحور يحمل اسمًا مختلفًا. انقر على المحور، واقرأ اسمه، وتأكّد من أن الجلسات المدرجة تحته هي العملاء الذين تحاول خدمتهم. هذا الفحص الواحد يمنع معظم الالتباس الذي يُلقى باللوم فيه على البروتوكول.

ثم قرّر ما يحتاجه العميل من الطرف البعيد. سلوك إيثرنت مشترك مع البث وخدمات الشبكة المحلية يشير إلى جسر، والوصول الخاص الموجّه إلى نطاق عناوين صغير يشير إلى SecureNAT، ومخرج الإنترنت قرار توجيه يمكن أن يؤدّيه أي ترتيب بشكل سيئ.

اكتب الجواب قبل أن تنقر أي شيء، لأن الإعدادين غير قابلين للتبادل والتراجع يستغرق وقتًا أطول من القرار. دقيقتان من الكتابة توفّران ساعة من إعادة الاتصال.

ما يفعله الجسر المحلي بالعنونة

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

هذا يعني أيضًا أن الجسر يحتاج محوّلًا حقيقيًا بدعم برنامج تشغيل مناسب، ويحتاج أن يكون المسؤول مخوّلًا بتوسيع ذلك المقطع. تسجيل الدخول إلى VPN يثبت المصادقة، لا الحق في وضع مضيف على شبكة VLAN إنتاجية. تحقّق من أن اسم برنامج التشغيل يطابق المحوّل المقصود، لأن جسر المنفذ الخطأ يُسقط المقطع بسرعة. إذا كانت قائمة المحوّلات فارغة أو أبلغ الجسر عن فشل، فالسبب عادةً متعلّق ببرنامج التشغيل أو الصلاحيات لا بالتشفير.

اقرأ جدول الجسر من سطر الأوامر عندما تكون الشجرة الرسومية غامضة. يُسمّي الناتج المحوّل، وهو ما لا تفعله الشجرة دائمًا.

vpncmd /SERVER localhost /HUB VPN /CMD BridgeList
vpncmd /SERVER localhost /HUB VPN /CMD SessionList

قائمة جسر فارغة مع جلسات متصلة صورة مفيدة: العملاء داخل المحور الافتراضي ولا شيء يمدّه إلى مقطع بعد.

ما يضيفه SecureNAT وما يخفيه

يمنح SecureNAT المحور موجّهًا افتراضيًا ووظيفة NAT وخدمة DHCP، كلها داخل عملية SoftEther. يحصل العملاء على عناوين من نطاق DHCP الافتراضي، ويجيب الموجّه الافتراضي عن البوابة الافتراضية، ويُترجم الترافيك الذي يحتاج إلى الخروج. لا يشارك أي محوّل فعلي، ولهذا يعمل على مضيف ببطاقة شبكة واحدة ودون إعداد مُبدّل.

الثمن أن العناوين الافتراضية تنتمي إلى المحور ولا شيء آخر. لا يمكن لجهاز على شبكة المكتب أن يوجّه إلى عنوان SecureNAT لعميل دون مساعدة، وكل ما يسجّل العناوين المصدرية يرى العنوان المترجم لمضيف SoftEther. إذا كانت قواعد وصولك أو سجل التدقيق يعتمد على العنوان الحقيقي للعميل، فهذا تغيير في التصميم لا تفصيل. وهو يحدّد أيضًا ما إذا كانت قاعدة العنوان المصدر سترى العميل أصلًا.

وهو أيضًا خادم DHCP. تشغيله على مقطع فيه خادم DHCP بالفعل، أو جسر ذلك المقطع في الوقت نفسه، ينتج مجيبين اثنين وإيجارات غير متوقّعة. يتعامل الدليل مع الوظيفتين كخيارين منفصلين لهذا السبب تحديدًا.

افحص ما يخدمه المحور حاليًا قبل أن تُفعّل أي شيء آخر. كل أمر يطبع الحالة الراهنة لا الحالة المقصودة.

vpncmd /SERVER localhost /HUB VPN /CMD SecureNatStatusGet
vpncmd /SERVER localhost /HUB VPN /CMD NatGet
vpncmd /SERVER localhost /HUB VPN /CMD DhcpGet

تشغيل أحدهما دون كسر الآخر

اختر الترتيب، وفعّله، واترك الآخر معطّلًا. محور بجسر وSecureNAT معًا محور له جوابان محتملان للسؤال نفسه، وسيصدّق العميل ما يصل أولًا. عند الانتقال من أحدهما إلى الآخر، عطّل الوظيفة القديمة وأعد اتصال العميل بدلًا من افتراض أن الإعداد الجديد يسري على جلسة قائمة.

رتّب التغيير بحيث لا يتقاطع تجمّع العملاء مع نطاق الشبكة المحلية. الشبكات الفرعية المتقاطعة هي ثاني أكثر الأسباب شيوعًا لنفق يتصل ثم لا يصل إلى شيء، وهي غير مرئية حتى تقارن خطّي العنونة جنبًا إلى جنب.

ثم أعد الاتصال من العميل واقرأ ما تلقّاه، لأن رؤية المحور للجلسة ليست رؤية العميل لشبكته. إعادة الاتصال هي الطريقة الموثوقة الوحيدة لفرض إيجار جديد.

تحقّق من البوابة والمُحلّل على العميل

المصادقة الناجحة تخبرك أن بيانات الاعتماد تعمل وأن المحور قَبِل الجلسة. لا تقول شيئًا عن قدرة العميل على الوصول إلى أي شيء، لأن ذلك يعتمد على العنوان والقناع والبوابة وخادم DNS التي أُعطيت له. اقرأ هذه القيم الأربع على العميل قبل أن تلمس إعداد خادم مرة أخرى.

على Windows تُظهر تفاصيل المحوّل الإيجار والمُحلّل، ويُظهر جدول التوجيه ما إذا كان النفق هو المسار الافتراضي فعلًا.

ipconfig /all
route print -4
nslookup intranet.corp.internal

على عميل Linux تأتي المعلومات نفسها من ملفات العنوان والتوجيه والمُحلّل. المسار الافتراضي هو القيمة التي تحدّد ما إذا كان الترافيك يخرج عبر النفق أصلًا. إذا كانت البوابة تشير إلى موجّه المكتب بينما يتوقّع النفق حمل الترافيك، فالطوبولوجيا مجسورة بالاسم ومكسورة عمليًا. أصلح مصدر العنوان أولًا، ثم أعد اختبار التطبيق، وعندها فقط فكّر في تغيير الوضع الآخر.