لماذا يرسل مضيف LAN طلب ARP لعنوان عميل OpenVPN

غالبًا ما تعود مشكلات الوصول بين مضيف في الشبكة المحلية وعميل VPN إلى خطة العناوين نفسها. أعطِ ذلك المضيف واجهة على 10.0.100.0/22 وسيعامل كل عنوان من 10.0.100.0 حتى 10.0.103.255 كمتصل مباشرة، بما في ذلك تجمع عملاء موضوع بهدوء على 10.0.101.0/24. لا تذهب الاستجابة أبدًا إلى موجه، لأنه من وجهة نظر المضيف لا يشارك أي موجه. تُوجَّه الحزمة إلى جار ويُطلب منه على السلك.

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

البادئة /22 التي تبتلع /24

اقرأ البادئة كنطاق، لا كسلسلة. تحتوي البادئة /22 على 1024 عنوانًا، وتمتد 10.0.100.0/22 من 10.0.100.0 إلى 10.0.103.255، لذا يقع تجمع على 10.0.101.0/24 بالكامل داخلها. تنجو الخطأ من المراجعة لأن أوكتيتات التجمع الأولى تبدو مختلفة عن أوكتيتات الشبكة المحلية الأولى، ولا يكشف سوى الأوكتيت الثالث عن الاحتواء. اكتب كلا النطاقين رقميًا قبل أن تعلنهما منفصلين.

قد يظهر الاحتواء نفسه بالعكس. قد يقع تجمع يبدو حرًا لأن لا شيء يستخدمه حاليًا داخل بادئة يعلنها موجه موقع ما، وخطة العناوين هي الوثيقة الوحيدة التي تُظهر ذلك.

الاتصال المباشر يعني ARP لا التوجيه

عندما يرسل مضيف بواجهة /22 إلى 10.0.101.25، يقارن النواة الوجهة ببادئة الواجهة ويجد تطابقًا. تتحول الحزمة إلى بحث عن جار بدلًا من حزمة موجهة، وعلى Ethernet يكون البحث عن الجار طلب ARP لذلك العنوان. إذا كان العنوان ينتمي إلى عميل VPN خلف بوابة موجهة، فلا يملك أي مضيف في الشبكة المحلية ذلك العنوان، لذا يبقى الطلب بلا إجابة وتُسقط الحزم. النفق ليس المسؤول، ولا يرى العميل الحركة أبدًا.

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

TUN وTAP وما يحمله كل منهما

يحمل جهاز TUN حزم IP، ويحمل جهاز TAP إطارات Ethernet. لا يحتاج ارتباط TUN الموجه إلى حمل ARP لتقديم إمكانية الوصول إلى IP، ولهذا بالضبط يُتوقع الطلب غير المجاب أعلاه ولا يُعد عطلًا. يمكن لـ TAP مع جسر متعمد أن يوسع نطاق البث ويجعل ARP يعمل، لكنه يغير ما يمكن للعميل رؤيته، ويتطلب نقاط نهاية تدعم التأطير نفسه، وهو إعادة تصميم لنموذج الشبكة لا إصلاح لبادئة متداخلة. تحويل نشر موجه إلى TAP لعلاج خطأ في خطة العناوين يقايض مشكلة صغيرة بمشكلة أكبر.

سجّل أين ظهر طلب ARP وأي نظام أرسله قبل استخلاص النتائج. يخبرك المرسل بما يعتقده عن الوجهة، لا بما يفعله النفق.

صمّم تجمعًا لا يمكن أن يتداخل

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

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

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