IPv6 عبر نفق OpenVPN: دليل عملي لموجّه الشبكة المنزلي
يموت IPv6 أو يتسرّب عندما يمنح النفق بادئة لا يستطيع الموجّه توجيهها. تتبّع العميل والمجمّع وإعادة التوجيه ووكيل NDP ومسار العودة بالترتيب.
الحاسوب المحمول لديه عنوان IPv6، والنفق يعمل فوق IPv4، ومع ذلك يفشل كل اختبار IPv6. والأسوأ من ذلك أن الاختبار ينجح و الحركة خرجت عبر مسار مزوّد الخدمة دون أن تدخل النفق أبدًا. تعود النتيجتان إلى قرار واحد مفقود: لم يمنح أحد الموجّه بادئة يستطيع توجيهها نحو العملاء. وتتبّع المسار من العميل إلى الخارج يكشف الجزء الغائب.
ابدأ من حيث يجلس العميل
انظر إلى العميل قبل أن تلمس الخادم. ip -6 addr يجب أن يعرض عنوان نفق من المجمّع، و ip -6 route يجب أن يعرض البادئة المدفوعة مشيرةً إلى جهاز النفق. وعندما يكون العنوان موجودًا ولا يوجد مسار، تكون الدفعة غائبة أو أن العميل تجاهلها. وعندما لا يوجد أي منهما، لم يخصّص الخادم شيئًا على الإطلاق.
ثم تحقّق مما يعتقده العميل عن العالم الخارجي. المسار الافتراضي عبر النفق يطالب بكل حركة IPv6، بينما مسار لـ 2000::/3 يطالب بالعناوين العامة فقط. كلاهما قد يكون صحيحًا، وكلاهما يجيب عن سؤال مختلف حول التسريب.
العميل الذي لا يملك مسارًا افتراضيًا لـ IPv6 على الإطلاق يفشل في كل اختبار عام بينما النفق نفسه سليم تمامًا. هذه فجوة في السياسة وليست نفقًا معطوبًا.
افحص المجمّع الذي يستطيع الخادم توجيهه فعلًا
لا يستطيع الخادم أن يخصّص إلا من بادئة يتحكم فيها فعلًا. إذا فوّض مزوّد الخدمة /56، فاحتفظ بـ /64 للنفق واترك الباقي للشبكة المحلية. وحين يسلّم المزوّد /64 واحدًا فقط على واجهة WAN دون توجيه إضافي، فاترك بادئة الشبكة المحلية وشأنها وأعطِ النفق نطاقًا محليًا فريدًا، مع قبول أن العملاء لن يكون لهم مخرج عام.
المجمّع والدفعة أمر واحد. server-ipv6 2001:db8:80:10::/64 يخصّص العناوين، و push "route-ipv6 2000::/3" يخبر العملاء بما يجب أن يرسلوه إلى النفق. دفع 2000::/3 يغطي العناوين العامة ويُبقي نطاقات link-local و multicast خارج النفق.
اكتب البادئة المختارة في سجل النشر. ومن يغيّر تسليم المزوّد لاحقًا يحتاج إلى معرفة أي /64 يشغله النفق بالفعل.
شغّل إعادة التوجيه للعائلة الثانية
إعادة توجيه IPv4 لا تعني إعادة توجيه IPv6. اضبط net.ipv6.conf.all.forwarding=1 وانسخ ما تسمح به سياسة FORWARD الخاصة بـ IPv4 بالفعل. على موجّه تُسقط سلسلة FORWARD لديه كل شيء افتراضيًا، تبدو مجموعة القواعد الغائبة تمامًا كنفق ميت.
تنجح المصافحة، ويحصل العميل على عنوان، ولا يعود شيء. أضف قواعد للاتجاهين ولجزء WAN، لأن نفقًا يبلغ الشبكة المحلية ولا يبلغ الإنترنت يفشل في الاختبار الثالث. افحص عدّادات السلسلة بعد محاولة فاشلة، لأن قاعدة لم تطابق قط مشكلة مختلفة عن قاعدة طابقت وأسقطت.
ip6tables -A FORWARD -i br0 -o tun0 -j ACCEPT
ip6tables -A FORWARD -i tun0 -o br0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -i tun0 -o wan0 -j ACCEPT
هناك أثر جانبي يوقع في الفخ من ينتهي به الأمر إلى لوم النفق. تشغيل إعادة التوجيه يجعل النواة تتخطى تكوين العنوان عبر إعلانات الموجّه ما لم تُخبره بغير ذلك، والمسار الافتراضي المكتسب بهذه الطريقة يختفي معها. إما أن تثبّت مسارًا افتراضيًا صريحًا على واجهة WAN، أو تضبط accept_ra على 2 هناك عن قصد. بعد أي من التغييرين، تأكد من أن الموجّه لا يزال لديه مسار IPv6 صالح إلى الخارج قبل اختبار العملاء مرة أخرى.
أجب عن اكتشاف الجيران عندما لا يوجّه الطرف الأعلى
تتعامل معدات الطرف الأعلى أحيانًا مع /64 المفوّض على أنه يخص ارتباطها هي، وترفض توجيه أي بادئة فرعية إلى صندوق VPN. وعندما يحدث ذلك، يجب أن يجيب شيء عن طلبات الجيران لكل عنوان عميل على حدة.
OpenVPN يعرّض العنوان المخصّص لخطّاف client-connect، كي تتبع الإدخالات المجمّع الحقيقي بدل قائمة تُصان يدويًا. يضيف الخطّاف ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0، ويحذفه خطّاف client-disconnect المطابق. وبدون الحذف، يتقادم جدول الوكيل ويمكن لعميل لاحق أن يرث إدخالًا لعنوان لم يستلمه يومًا. تأكد من الحالة باستخدام ip -6 neigh show proxy.
اعتبر الوكيل حلًا مؤقتًا. المسار الثابت للـ /64 الخاص بالنفق والموجّه إلى الموجّه يصمد أمام تغيّر العملاء ولا يحتاج إلى أي خطّاف shell بصلاحيات خاصة.
تابع المسار إلى الخارج، خطوة بقفزة
اختبر نحو الخارج في ثلاث خطوات: عنوان نفق الموجّه أولًا، ثم مضيف في الشبكة المحلية، ثم وجهة عامة عبر traceroute6 ثالثًا. الخطوة الأولى تثبت المجمّع، والثانية إعادة التوجيه وجدار حماية الشبكة المحلية، والثالثة مسار العودة عبر الطرف الأعلى. كل فشل يضيّق البحث إلى جهاز واحد بدل إعادة فتح التصميم كله.
راقب MTU النفق، لأن موجّهات IPv6 على المسار لن تجزّئ نيابةً عنك. يظهر MTU المفرط كخطأ packet too big وكتوقف في TLS بدل فشل نظيف. اضبطه صراحةً واختبر بحمولة قريبة من الحد.