تفويض بادئة IPv6 عبر VPN من موقع إلى موقع: قائمة تحقق

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

اكتب خريطة البادئات قبل أن تمس النفق

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

سجّل لكل موقع البادئة المفوَّضة، والـ /64 المستخدمة فعلاً على الشبكة المحلية، وعناوين النفق، ومالك كل مسار. يفوّض المزوّد 2001:db8:a1::/56 إلى الموقع A، الذي يخدم 2001:db8:a1:10::/64 على شبكته المحلية؛ ويحتفظ الموقع B بـ 2001:db8:b2::/64. وإذا كان الموقع A يخدم تلك الـ /64 وحدها، فينبغي أن يذكر الطرفان 2001:db8:a1:10::/64 بدلاً من الـ /56 كاملة.

خطآن يظهران في كل مرة تقريباً. الأول هو معاملة البادئة البعيدة كأنها على الرابط، بجسرها أو وضعها على واجهة النفق حتى تجيب البوابة على استعلام الجار عن مضيفين لا تستطيع الوصول إليهم. والثاني هو الإعلان عن الـ /56 كاملة بينما لم تُهيأ سوى /64 واحدة: فيدّعي جدول المسارات أن الكتلة قابلة للوصول بينما تختفي معظم العناوين في ثقب أسود.

طابِق محدِّدات الحركة في الطرفين مع المسارات

يرفض كل من IKEv2 و WireGuard الحركة غير المتطابقة، بهدوء يكفي ليظل النفق يبدو سليماً.

في strongSwan تكون المحدِّدات صريحة. على الموقع A:

conn a-to-b
    left=2001:db8:ff::1
    leftsubnet=2001:db8:a1:10::/64
    right=2001:db8:ff::2
    rightsubnet=2001:db8:b2::/64
    auto=start

تنسخ conn الخاصة بالموقع B الشبكتين الفرعيتين. وعندما تختلفان، يرفض المستجيب CHILD_SA بالخطأ TS_UNACCEPTABLE، فلا تصعد أبداً رابطة الابن رغم أن IKE_SA صعدت. وفي الطرفين يجب أن تساوي الشبكة الفرعية المهيأة ما يوجّهه النواة المحلية نحو النفق.

يحمل WireGuard المعلومة نفسها في AllowedIPs، مع التفاف واحد: AllowedIPs مرشّح للمصدر عند الاستقبال ومسار عند الإرسال في آن واحد. وإذا أغفل إدخال النظير في الموقع B الخاص بالموقع A العنوان 2001:db8:a1:10::/64، وصلت حزم الموقع A عبر مصافحة صحيحة ثم أُسقطت باعتبارها غير مسموح بها. وهذا يولّد النمط المألوف: مصافحة تتجدد باستمرار بينما لا يخرج أي رد أبداً. قارن الطرفين بالأمر wg show wg0 allowed-ips. أعد فحص القائمة كلما تغيّر التفويض؛ فالـ /64 القديمة تُبقي الجلسة قائمة وتبقي البادئة الجديدة غير قابلة للوصول.

استبعد التوجيه والجدار الناري و MTU أولاً

قبل أن تقرأ سطر سجل آخر، تأكد من أن البوابات تمرّر الحركة أصلاً. يجب أن يعيد sysctl net.ipv6.conf.all.forwarding القيمة 1 على الاثنتين، مطبقةً أيضاً على واجهتي النفق والشبكة المحلية. ويأتي مع ذلك فخ واحد: بمجرد تشغيل التمرير، تتوقف واجهة ذات accept_ra=1 عن قبول إعلانات الموجه من المزوّد، فيمكن للجهاز أن يفقد مساره الافتراضي الصاعد بينما يوجّه على نحو مثالي داخل النفق. اضبط accept_ra=2 حيثما يلزم إعلان موجّه من المزوّد.

بعد ذلك يجب أن تسمح قواعد الجدار الناري بالبادئة في الاتجاهين، وأن يبقى ICMPv6 حياً: فاكتشاف الجار، وحزمة-أكبر-من-اللازم، والوجهة-غير-قابلة-للوصول ليست أموراً اختيارية. أسقطها فينكسر اكتشاف MTU للمسار، فتحصل على اتصالات تُفتح ثم تتوقف عند أول استجابة كبيرة. ويبدو الحد الأدنى من القواعد هكذا:

nft add rule inet filter forward ip6 saddr 2001:db8:a1:10::/64 ip6 daddr 2001:db8:b2::/64 accept
nft add rule inet filter forward ip6 saddr 2001:db8:b2::/64 ip6 daddr 2001:db8:a1:10::/64 accept
nft add rule inet filter forward icmpv6 type { packet-too-big, nd-neighbor-solicit, nd-neighbor-advert } accept

يقع MTU خلف ذلك. النفق يقلّص MTU القابلة للاستخدام إلى ما دون 1500، ويشترط IPv6 أن يحمل كل رابط 1280 على الأقل. نبضات الفحص الصغيرة تمر، وجلسة SSH تتجمد عند دفعة كبيرة، ويُظهر /proc/net/snmp6 رسائل حزمة-أكبر-من-اللازم التي لا تعود أبداً. اضبط MTU للنفق صراحةً، أو اقصص TCP MSS في جدول mangle، ودع ICMPv6 التي تبلّغ عن MTU الأصغر تعود.

اختبر مسار العودة، لا عنوان النفق

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

يحسم أمرين اثنان معظم الحالات. على الموقع A يُظهر ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 أي واجهة سيستخدمها رد من ذلك المصدر؛ ونفّذ الفحص المقابل على الموقع B. ثم ولّد حركة من مضيف لا من البوابة وقارن العدادات في الطرفين.

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

خطّط لتغيّر البادئة تحتك

تفويض البادئة إجارة بين الموجه المفوِّض والموجه الطالب، والتجديد قد يعيد كتلة مختلفة: /56 مختلفة بعد ترحيل المزوّد، أو إجارة أقصر من مدة بقاء النفق. وكل موضع يذكر البادئة القديمة يصبح قديماً دفعة واحدة: المسارات والمحدِّدات و AllowedIPs وقواعد الجدار الناري وسجلات DNS وأي مراقبة تُثبّت عناوين حرفية. ومسار الرسائل في RFC 8415.

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

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