لماذا لا يُعدّ موقعان بالشبكة الفرعية نفسها شبكة محلية واحدة

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

المضيف يقرّر قبل الموجّه

يقارن مضيف بعنوان 192.168.77.10/24 الوجهة ببادئته الخاصة. كل ما يقع داخل تلك البادئة يكون على الرابط، فيحلّ المضيف عنوان طبقة الربط للوجهة مباشرة. وكل ما يقع خارجها يذهب إلى البوابة الافتراضية.

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

لذلك حين يوجد 192.168.77.20 في الموقع الآخر فقط، يطلب المضيف المحلي عنوانه عبر ARP ولا يتلقى جوابًا. قد تكون مصافحة VPN سليمة تمامًا بينما يفشل هذا. ويبدو الفشل كمضيف ميت لا كمشكلة توجيه. والتعرّف على هذه البصمة يوفّر ساعة من تنقيح النفق.

ARP سؤال يخصّ الرابط المحلي

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

ويزيد الأمر سوءًا وجود جهازين بالعنوان نفسه: فحتى الحل الناجح لا يخبرك أيّهما أجاب.

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

المقطع الممتد ينقل الإطارات لا المسارات

نفق يحمل إيثرنت وموصول بجسور يجعل الموقعين جزءًا من نطاق طبقة ربط واحد. تصل بثوث ARP إلى الجانب الآخر، ويتعلّم كل جسر أين تقع عناوين MAC. توثيق الجسر في Linux يصف حدّ التمرير القائم على MAC.

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

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

ARP الوكيل تصميم ثالث

يستطيع موجّه أن يجيب عن ARP لعنوان بعيد ثم يوجّه نحوه. وهذا يجعل المضيف البعيد يبدو على الرابط للمرسل دون مدّ نطاق بث.

إنه أداة أضيق من الجسر: فهو يعتمد على التمرير ومسارات العودة ومالك واضح لكل عنوان.

ولا يجعل بروتوكولات غير IP العشوائية قابلة للتوجيه، ولا يعيد إنتاج نطاق بث إيثرنت. استخدمه عندما تكون المتطلّبة هي ذلك الاستبدال بالضبط، لا كطريق مختصر لتأجيل إعادة الترقيم.

اختر من المتطلّبة ثم تحقّق

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

تأكّد من التصميم الذي لديك فعلًا بأن تسأل مضيفًا عمّا يفعله بالوجهة:

ip route get 192.168.77.20
ip neigh show 192.168.77.20

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