جسر TAP معزول بين لوحتين عبر OpenVPN

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

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

ما ينقله الجسر فعلاً

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

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

Board A -- bench0 -- br-test -- tap-bench
                                 |  OpenVPN TAP
Board B -- bench0 -- br-test -- tap-bench

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

عنونة الجسر لا منافذه الأعضاء

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

ip link add br-test type bridge
ip link set bench0 master br-test
ip link set tap-bench master br-test
ip address add 172.30.90.2/24 dev br-test
ip link set bench0 up
ip link set tap-bench up
ip link set br-test up

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

لماذا منفذ مخصص واحد لكل طاولة عمل

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

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

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

الحد الذي لا ينشئه الجسر

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

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

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

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

الاستمرارية والاختبارات التي تثبتها

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

bridge link show
ip -d link show br-test
bridge fdb show br br-test | head

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