اختفى المسار الافتراضي لـ IPv6 بعد تمكين إعادة التوجيه على Linux

ضبطت net.ipv6.conf.all.forwarding=1 على بوابة Debian لتتمكن من تمرير حركة عملاء VPN، وبعد نحو نصف ساعة لم يكن لدى الجهاز أي مسار افتراضي لـ IPv6. كان الموجّه الأعلى يعمل، والجار link-local ما زال يجيب، والوصلة الصاعدة ما زالت تحتفظ بعنوانها العام. الذي توقف هو استعداد النواة لمواصلة استقبال إعلانات الموجّه على تلك الواجهة. لم يختفِ المسار لحظة كتابة sysctl، بل اختفى عندما انتهت مدة حياة المسار الافتراضي المكتسب من RA ولم يجدّده شيء.

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

اقرأ جدول المسارات قبل أن تلمس أي sysctl

ابدأ بـ ip -6 route show default واقرأ السمات، لا البوابة وحدها. المسار الافتراضي المكتسب من RA معلَّم بـ proto ra ويحمل تفضيلًا ويظهر عدًّا تنازليًّا expires. المسار الذي أضفته يدويًّا لا يملك أيًّا منهما، وهذا الفرق يخبرك أي آلية تملك المسار.

$ ip -6 route show default
default via fe80::1 dev eth0 proto ra metric 1024 expires 1432sec hoplimit 64 pref medium

ثم انظر إلى العنوان: ip -6 addr show dev eth0. العنوان العام ذو مدد الحياة المفضّلة والصالحة المقيسة بالساعات سيبقى أطول من مسار افتراضي تُقاس مدة حياة موجّهه بالدقائق. وجود العنوان مع غياب المسار الافتراضي هو بصمة مشكلة إعلانات. وإذا غاب العنوان أيضًا، فالوصلة أو معلومات البادئة أو كشف العناوين المكرّرة هو ما يجب تتبعه أولًا.

لماذا تُطفئ إعادة التوجيه معالجة RA

إعلان الموجّه حزمة ICMPv6 من النوع 134 تُرسل من مصدر link-local بحد قفزة 255. قبل أن تستخدمها النواة تتحقق من accept_ra الخاص بالواجهة. القيمة الافتراضية 1، و1 لا تعني نعم. تعني: اقبل فقط ما دام هذا المضيف لا يعيد التوجيه. اضبط forwarding=1 فيفشل ذلك الشرط، وبالتالي يُسقط الإعلان قبل النظر في أي بادئة أو موجّه افتراضي بداخله.

توجد ثلاث قيم، ولا تنجو من إعادة التوجيه إلا الثالثة:

هناك رايتان أخريان تحدّدان ما يُثبَّت فعلًا. تتحكم accept_ra_defrtr في ما إذا كان الموجّه الافتراضي في الإعلان يصبح مسارًا، وتتحكم accept_ra_pinfo في ما إذا كانت معلومات البادئة تُستخدم لتكوين العنوان. إطفاء accept_ra_defrtr هو الطريقة المعتادة لإبقاء عناوين SLAAC على مضيف يعيد التوجيه دون تعلّم مسار افتراضي. هذا ذراع مختلف عن accept_ra، وهو ما يُستخدم عندما تريد عناوين لا مسارًا. مرجع النواة الخاص بـ IP sysctl يسرد الثلاثة.

أكّد ذلك بثلاثة أوامر

أولًا، اقرأ القيم الحيّة بدلًا من الملف الذي تظنه محمّلًا:

sysctl net.ipv6.conf.eth0.forwarding net.ipv6.conf.all.forwarding \
       net.ipv6.conf.eth0.accept_ra net.ipv6.conf.eth0.accept_ra_defrtr

ثانيًا، أثبت أن الإعلانات ما زالت تصل. يكفي الترشيح حسب بايت نوع ICMPv6، وهو يوفّر عليك قراءة جدار من حركة اكتشاف الجيران:

tcpdump -ni eth0 'icmp6 and ip6[40] == 134'

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

rdisc6 eth0

يأتي rdisc6 ضمن حزمة ndisc6 على Debian وUbuntu. في الخرج، انظر إلى مدة حياة الموجّه والتفضيل قبل تغيير أي شيء آخر. الإعلان ذو مدة حياة الموجّه 0 هو تعليمات بإزالة الموجّه الافتراضي، ولا قيمة من accept_ra تحوّله إلى مسار صالح للاستخدام. بهذه الطريقة أيضًا تلتقط جهاز CPE أعلى في وضع الجسر يوزّع البادئات لكنه لا يعرض نفسه موجّهًا قط.

اجعل الوصلة الصاعدة الواجهة المتسامحة الوحيدة

إذا كان على الجهة الأعلى أن تكون الموجّه الافتراضي، فاقبل الإعلانات هناك رغم إعادة التوجيه، ولا في أي مكان آخر:

# /etc/sysctl.d/60-ipv6-router.conf
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.eth0.accept_ra = 2
net.ipv6.conf.eth0.accept_ra_defrtr = 1

تحديد النطاق مهم لأن إعادة توجيه IPv6 في Linux مفتاح عام واحد، لا مفتاح لكل وصلة. اكتب 1 في net.ipv6.conf.wg0.forwarding ثم اقرأ net.ipv6.conf.all.forwarding: تنقلب القيمة العامة وتبدأ كل واجهة بإعادة التوجيه. لا يمكنك أن تكون موجّهًا على النفق ومضيفًا عاديًّا على الشبكة المحلية. ما يمكنك تقييده هو القبول. أبقِ accept_ra=2 على الوصلة الصاعدة واترك واجهتي النفق والشبكة المحلية على 1 أو 0، كي لا يستطيع إعلان تائه يصل عبر النفق تثبيت مسار افتراضي يشير إليه.

لا يصمد sysctl -w المؤقت بعد إعادة التشغيل التالية، وكل من systemd-networkd وNetworkManager يكتب هذه القيم من تكوينه الخاص. في networkd اضبط IPv6Forwarding=yes و IPv6AcceptRA=yes في ملف .network الخاص بالوصلة الصاعدة؛ ويوثّق networkd أن IPv6Forwarding عام للسبب نفسه في النواة. مع NetworkManager، فإن ipv6.method=auto على الوصلة الصاعدة هو ما يقود قيمة accept_ra، لذا أعد قراءة sysctl بعد nmcli connection up بدلًا من الوثوق بالفحص الأول.

البديل الساكن، ip -6 route add default via fe80::1 dev eth0، يعمل فعلًا، وهو إجابة معقولة عندما يكون للموجّه الأعلى عنوان link-local ثابت. كن واضحًا بشأن ما تتخلى عنه. المسار الافتراضي الساكن لا يُجدَّد أبدًا ولا يُسحب أبدًا، فيظل يشير إلى جار ميت بعد استبدال الجهة الأعلى. مسار RA يفشل بأمان، أما الساكن فيفشل في صمت.

اختبر حزمة مُمرَّرة، لا حزمة البوابة نفسها

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

# on the VPN client
ping -6 -c 3 2001:4860:4860::8888

# on the gateway, using a client address
ip -6 route get 2001:4860:4860::8888 from fd42:20::2

ثم انتظر مدة حياة موجّه واحدة وانظر مرة أخرى. الحالة المستقرة التي تريدها هي مسار افتراضي معلَّم بـ proto ra تُعاد قيمة expires فيه إلى الصفر باستمرار، مع all.forwarding=1. إذا كانت expires تتناقص فقط، فالإعلانات ما زالت تُسقط في مكان ما، والمسؤول المعتاد مدير شبكة يعيد كتابة accept_ra بعد أن يكون sysctl عند الإقلاع قد نُفّذ بالفعل.

قبل أن تغلق هذا، أكّد أربعة أشياء: المسار الافتراضي هو proto ra ويتجدد، و accept_ra=2 ينطبق على الوصلة الصاعدة فقط، وإعادة التوجيه ما زالت 1 بعد إعادة التشغيل وبعد إعادة تشغيل المدير، وعميل لا البوابة هو من يكمل ping لـ IPv6. إذا ظل العميل يفشل مع مسار سليم، فإن المشتبه التالي هو مسار العودة أو جدار ناري أعلى، وليس الإعلان.