مالكان وعنوان واحد: عناوين IP مكررة على جسر TAP

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

اقرأ أدلة التعارض قبل أن تلمس الجسر

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

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

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

اجرد كل مطالبة على القطاع

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

امشِ في القائمة بهذا الترتيب: العناوين على كل جهاز جسر ومنافذه الأعضاء، ومجموعة OpenVPN وأي تخصيص ثابت لكل عميل، وأي خادم DHCP يغطي القطاع المجسر. ثم طابق العنوان العتادي من تقرير التعارض مع الواجهات التي وجدتها.

ip -4 addr show | grep -E 'inet |^[0-9]+: '
bridge link show
ip neigh show dev br0

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

رقّم الجسور فقط حيث تحتاج إلى هوية

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

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

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

اجعل التصحيح يصمد أمام إعادة التشغيل

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

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

احجز عناوين الجسر داخل نطاق DHCP كاستثناءات، أو انقلها خارجه. الحجز الموجود في جدول بيانات فقط ليس استثناءً، ولن يقرأه الموزّع.

أثبته مع كل عميل متصل

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

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

arping -D -I br0 10.8.0.2
ip neigh show dev br0 | grep 10.8.0.2

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