مجموعة عناوين VPN لديك ليست نطاق DHCP في الشبكة المحلية: لماذا يتعطل ذلك

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

مخصصان، وفضاء عناوين واحد

خادم DHCP في الشبكة المحلية يعرف العناوين التي أجرها ولأي عنوان MAC، ويدافع عنها عبر ARP. خادم VPN له مجموعته الخاصة ولا يعرف شيئا عن تلك الإيجارات. لا أحد منهما مخطئ؛ لكن لم يعرّف أحدهما الآخر قط.

عنوان من نطاق الشبكة المحلية يمنحه خادم VPN قد يكون مملوكا لطابعة بالفعل. الآن جهازان يطالبان بعنوان واحد على البادئة نفسها، وجدول تمرير المحوّل يقرر أيهما يجيب.

هذا هو الفشل الذي يواجهه الناس أولا: عميل يتصل بنجاح ثم يصل إلى الجهاز الخطأ، أو يصل إلى الجهاز الصحيح بشكل متقطع.

لماذا لا يوزع الموجّه عناوين VPN

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

لذلك يعيّن خادم VPN العنوان بنفسه: مجموعة في إعدادات الخادم، أو عنوان لكل نظير في إعداد WireGuard، أو عنوان تدفعه طبقة المصادقة في نشر IKEv2. هذه الآليات مستقلة عن قاعدة بيانات إيجارات الشبكة المحلية، ولهذا بالضبط تحتاج إلى نطاق خاص بها.

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

التقاطع يظهر كتعارض، لا كشبكة بطيئة

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

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

مسار العودة مشكلة منفصلة

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

اقرأ المسار في الاتجاهين قبل تغيير أي شيء. على البوابة، اسأل أي واجهة سيستخدمها النواة لعنوان عميل؛ وعلى العميل، اسأل أي مسار يستخدمه لعنوان في الشبكة المحلية.

تعرض هذه الأوامر قرار التمرير على البوابة وإدخالات الجوار التي تكشف التكرار:

ip -4 route get 10.8.0.5
ip neigh show dev br-lan | grep 10.8
ip -4 route get 192.168.50.20

إذا أجاب الأمر الأول بواجهة النفق، فمسار العودة موجود. وإذا أجاب بواجهة الشبكة المحلية، فالموجّه يعتقد أن العميل على السلك وسيحاول إرسال ARP له.

تصاميم الجسر موجودة، لكن يجب اختيارها

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

ما لا ينجح هو محاكاة النتيجة بنسخ الأرقام. مجموعة مشتركة بلا جسر تمنحك التعارض بلا الاكتشاف، وهو أسوأ ما في الترتيبين.

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