مفتاح الإيقاف يحظر IPv4 فقط: لماذا يظل IPv6 يتسرب

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

تحمل الأجهزة مزدوجة المكدس طريقتين مستقلتين للخروج. حظر إحداهما هو نصف حظر.

مجموعتان من القواعد، ووضعان افتراضيان

في Linux، تُعدّ iptables وip6tables جدولين منفصلين بسياسات منفصلة. ضبط سلاسل INPUT وOUTPUT في جدول IPv4 على DROP لا يغيّر شيئًا في جدول IPv6، حيث يكون الوضع الافتراضي عادةً ACCEPT. وينطبق الانقسام نفسه على nftables، حيث يمكنك فحص عائلة والعثور على أن إحداهما فقط تحمل قواعدك. هذا التفاوت طبيعي، وهو المشكلة كلها.

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

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

ما الذي تخبرك به إعدادات الواجهة

تحتوي صفحة دليل wg-quick على قواعد IPv6 في إعدادها النموذجي، والسبب هو هذه الفجوة بالضبط. المثال ليس زينة. وهو موجود لأن قواعد IPv4 وحدها ستترك العائلة الثانية مفتوحة.

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

# what is actually installed, per family?
sudo iptables -S OUTPUT | head -20
sudo ip6tables -S OUTPUT | head -20

# nftables: inspect each family separately
sudo nft list ruleset inet | head -40

# does this host even have a usable IPv6 path?
ip -6 route show default

إذا طبعت الأوامر الثانية سياسة متسامحة بينما تطبع الأولى DROP، فقد وجدت الجواب دون لمس العميل. هذا التفاوت هو الخلل.

لماذا لا يكفي بحث واحد لرواية القصة كاملة

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

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

اختبر الحالة التي يكون فيها النفق متوقفًا

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

# with the tunnel stopped, does anything still leave?
ip -6 route get 2606:4700:4700::1111
curl -6 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv6.example.net/
curl -4 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv4.example.net/

ينبغي أن تفشل كلتا العائلتين مغلقة. إذا انتهت مهلة طلب IPv4 وأعاد طلب IPv6 رمز حالة، فالسياسة غير مكتملة، ولن يغيّر إعادة اختبار النفق ذلك مهما بلغت.

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