حظر IPv6 لتأمين WireGuard يعطّل المضيف

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

ثلاث مسؤوليات، مجموعة قواعد واحدة

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

هذه ثلاث سياسات مختلفة، والثانية والثالثة فقط تتعلقان بالـ VPN. مجموعة القواعد التي تتعامل معها كسياسة واحدة ترث نمط فشل تُضعف فيه تضييقُ حدود التطبيق ارتباطَ المضيف بصمت.

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

ما يفعله ICMPv6 من أجل المضيف

يعتمد IPv6 على ICMPv6 في أكثر بكثير من الصدى. طلب الجار وإعلانه يحلّان محل ARP وهما مطلوبان للتسليم المحلي. تحمل Packet Too Big معلومات MTU للمسار، وتجاهلها يُنتج نقلًا يتوقف عند الحزم الكبيرة. تحمل إعلانات الموجه المسار الافتراضي ومعلومات البادئة عندما تستخدم الوصلة تكوينًا آليًا.

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

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

استبدال كل ذلك بسماح شامل بـ ICMPv6 يحل مشكلة التوفر ويتخلى عن الترشيح. واستبداله برفض شامل يحل مشكلة الترشيح ويتخلى عن المضيف.

اسمح بالنفق، ثم اسمح بالخدمة

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

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

اقرأ مجموعة القواعد كما هي موجودة، لا كما يصفها الملف:

sudo nft list ruleset
ip -6 addr show
ip -6 route show default

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

اختبر الوصلة، لا النفق فقط

نفق يعمل بعد التغيير يثبت أقل مما يبدو، لأن إدخال جار قائم واتصالًا مؤسسًا قد يخفيان رسالة تحكم ترفضها السياسة الآن.

افحص الارتباط مباشرة، ثم افحص أن المسار المستثنى ما زال يفشل:

ip -6 neigh show
ping -6 -c 3 2001:db8:1::1
sudo nft -c -f /etc/nftables.conf

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

استعد مضيفًا أغلقت نفسك خارجه

قبل تغيير قواعد جدار حماية تحمل جلستك الإدارية، احتفظ بقناة ثانية: وحدة تحكم، أو اتصال تسلسلي، أو تراجع مجدول يزيل القواعد الجديدة إن لم تلغه.

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

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