هل يجب توجيه حركة IPv6 عبر VPN أم مباشرة؟
قرّر ما إذا كان ::/0 ينتمي داخل النفق، بثلاثة شروط: دعم المخرج، ووصول الطرف الآخر، والشبكات المحلية فقط.
سألني شخصان الشهر الماضي عن نتيجتين متعاكستين: أراد أحدهما أن يغطي VPN حركة IPv6، وأراد الآخر أن تستمر طابعة المكتب في العمل. لا يمكن لمسار واحد ::/0 أن يحقق الأمرين بمفرده. يعتمد ما إذا كان هذا المسار ينتمي داخل النفق على ثلاثة شروط، والشرط الأول يستبعده من معظم المخارج التجارية. إذا لم يحمل المخرج أي IPv6، فإن توجيه المسار الافتراضي إليه يخفي حركة المرور في نفق لا مكان لديه لإرسالها.
ثلاثة شروط تحدد الجواب
المسار الافتراضي سطر واحد، ::/0، وهو يطابق أي وجهة IPv6 لا يوجد لها مسار أكثر تحديدًا (RFC 4291). تثبيته سهل. أما تحديد ما إذا كان ينبغي لك ذلك فيرجع إلى ثلاثة شروط.
الشرط الأول: المخرج الذي تتصل به يعمل لديه IPv6 وهو مستعد لتمريره. الشرط الثاني: يستطيع عميلك الاحتفاظ بمسار إلى طرف النفق، وهو عادةً داخل النطاق الذي أنت على وشك توجيهه. الشرط الثالث: يمكنك تسمية وجهات IPv6 المحلية التي يجب أن تبقى خارج النفق.
يفشل كل شرط بطريقته، ولهذا يكلّفك التخمين أمسية كاملة. الشرط الأول الفاشل يمنحك صمتًا وجدول توجيه يبدو صحيحًا. الشرط الثاني الفاشل يقتل المصافحة بعد ثوانٍ من بدئها. الشرط الثالث الفاشل يترك نفقًا يعمل وزميلًا غير سعيد عند الطابعة.
| What you see | Decision |
|---|---|
| Exit answers IPv6 probes, no local IPv6 devices to protect | Route ::/0 into the tunnel |
| Exit answers IPv6 probes, printer or NAS reachable by a global address | Route ::/0, then give those prefixes a route of their own |
| Exit is IPv4-only inside the tunnel | Do not route ::/0; block IPv6 on the client |
Endpoint is reached over IPv6 and sits inside ::/0 | Install a host route for the endpoint first |
هل يحمل المخرج IPv6 فعلاً؟
واجهة نفق تحمل عنوان IPv6 لا تثبت شيئًا عن الطرف الآخر. كثير من الملفات التجارية تعمل بـ IPv4 فقط من الداخل: يمنحك الخادم عنوان v4 ويسقط كل شيء آخر. ثبّت افتراضيًا من AllowedIPs فوق ذلك وسيرسل النواة IPv6 بكل سرور إلى واجهة لا يراها نظيرها أبدًا.
اختبر من العميل والنفق قائم. ping -6 -c 3 2001:4860:4860::8888 و ip -6 route get 2001:4860:4860::8888 يجيبان عن سؤالين مختلفين: هل يعود رد، وأي جهاز اختارت النواة. عندما يسمّي الثاني نفقك ويعود الأول بلا شيء، تكون المشكلة في المخرج لا في المسار.
إذا كنت تدير المخرج بنفسك، فقد ينجح اختبار العميل ويظل المسار مسدودًا. تأكد من net.ipv6.conf.all.forwarding=1 على البوابة، ومن أن جدار الحماية يقبل الحزم المعاد توجيهها خارج النفق. الحزمة الموجهة بشكل صحيح إلى مخرج يرفض العبور تبدو تمامًا كخطأ توجيه من جهة العميل.
هل يستطيع العميل الاحتفاظ بمساره إلى طرف النفق؟
هذا هو ما أوقعني على حاسوب محمول بطرف WireGuard يعمل بـ IPv6 فقط. عنوان الطرف عنوان عام عادي، لذا يقع داخل ::/0. وجّه البادئة كاملة إلى الواجهة وستطارد حزم المصافحة نفسها داخل النفق الذي ما زالت تحاول بنائه. لا يقوم النفق أبدًا، ولا شيء في مخرجات العميل يوضح السبب.
wg-quick يتعامل مع هذا على لينكس. يستمد المسارات من AllowedIPs، ويثبتها في جدوله الخاص، ويضيف قاعدة سياسة بحيث تُحل حركة المرور إلى الطرف عبر الجدول الرئيسي أولاً: قاعدة suppress_prefixlength 0 التي تجدها في ip -6 rule. ولهذا ينجح wg-quick up حيث يقطع ip -6 route add default dev wg0 المكتوب يدويًا اتصالك.
افحص الحالتين باستخدام ip -6 route get <endpoint-v6>، قبل رفع النفق وبعده. إذا تغيّر الجواب إلى جهاز النفق لديك، فقد أزلت المسار الذي يحتاجه النفق. حين تكتب المسارات بنفسك، أضف مسارًا للمضيف إلى الطرف عبر البوابة الأصلية، أو اتصل بالطرف عبر IPv4 واترك IPv6 للحمولة.
ما الذي يجب أن يبقى خارج النفق؟
المسارات الأكثر تحديدًا تتغلب على الافتراضي، لذا تبقى بادئة على الرابط أو نطاق ULA له مساره الخاص يعمل دون جهد إضافي. هذا هو السبب الهادئ وراء صمود كثير من إعدادات IPv4 ذات النفق الكامل: بادئات الشبكة المحلية أكثر تحديدًا من الافتراضي ولا تدخل النفق أبدًا.
ينهار ذلك حين يكون جهاز محلي قابلًا للوصول عبر عنوان عام، وهو أمر طبيعي لطابعة منحها الموجّه نفسه بادئة عامة، أو NAS، أو تلفاز. تطابق تلك العناوين ::/0 ولا شيء غيره، لذا تنتقل إلى النفق مع كل شيء آخر وتختفي.
قرّر وفق الوجهة لا وفق البروتوكول. إذا كانت مضيفتان أو ثلاثة محلية مهمة، أعط بادئاتها مسارًا عبر الواجهة الفعلية، أو احذفها من المجموعة المتفاوض عليها. إذا استمرت القائمة في النمو، فالجواب الصادق هو نفق منقسم لـ IPv6 مع قائمة استثناءات مكتوبة، لا افتراضي تعيد ترقيعه.
إذا كان الجواب لا، فاحجبه
ترك IPv6 بلا مسار ليس مثل تركه وشأنه. المضيف الذي لديه افتراضي IPv6 عامل يواصل استخدامه بينما يحمل النفق IPv4، لذا تغادر الحركة بجانب VPN وكل خدمة تفضّل IPv6 ترى عنوانك الحقيقي. هذا تسريب لا نفق منقسم.
اختر واحدًا واكتب أيّهما اخترت. وجّه الافتراضي واقبل المقايضات أعلاه، أو عطّل IPv6 طوال مدة النفق. إغفال البادئة من AllowedIPs لا يكفي وحده، لأن نظام التشغيل يحتفظ بافتراضيه الخاص. على لينكس الصيغة المباشرة هي sysctl -w net.ipv6.conf.all.disable_ipv6=1؛ والصيغة الأدق تُسقط IPv6 خارج النفق بقاعدة جدار حماية. عملاء الهواتف يأتون بمفتاح صريح لحجب IPv6 يؤدي الغرض نفسه.
تحقق منه كما تتحقق من تسريب
ارفع النفق واقرأ الحالة بدلًا من الوثوق بالمفتاح. يجب أن يُظهر ip -6 route show default افتراضيًا واحدًا، وأن يسمّي ip -6 route get جهاز النفق لوجهة خارج شبكتك المحلية. كرّر الأمرين بعد فصل الاتصال: افتراضي يبقى بعد النفق هو الخطأ الذي كنت تبحث عنه.
ثم اختبر الاتجاه الآخر. من مضيف على الشبكة المحلية، اصل إلى العميل عبر عنوانه المحلي IPv6. إذا توقف ذلك عن العمل، فالشرط الثالث لم يتحقق قط، مهما ادّعى جدول التوجيه حينها.
اكتب النتيجة حيث سيجدها الشخص التالي: أي بادئات تبقى محلية، ولماذا، وماذا يفعل العميل بعد فصل الاتصال. سطران في دليل تشغيل يوفران على المهندس التالي اكتشاف حلقة الطرف من جديد في منتصف الليل.