أضف IPv6 خاصة إلى مختبر OpenVPN، نقطة تحقق واحدة في كل مرة

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

نقطة التحقق الأولى: الاتصال الذي يعمل بالفعل

اتصل بالعميل وتأكد من مسار IPv4 قبل إضافة أي شيء. النفق العامل يمنحك خط أساس يفصل خطأ IPv6 الجديد عن مشكلة اتصال قديمة. كما يخبرك أي نسخة خادم تعدلها فعلاً.

سجّل التجمع والطوبولوجيا والمسارات المدفوعة التي تعتمد عليها. عمل IPv6 يوسّع ذلك الإعداد؛ ولا يستبدله.

نقطة التحقق الثانية: اختر البادئات الداخلية

اختر ULA /48 للموقع واقتطع منه /64 اثنتين: واحدة لعملاء النفق، وأخرى لقطاع الشبكة المحلية الذي يحمل حمل عمل IPv6. ولّد المعرّف العام بعرض 40 بت بدل نسخ بادئة من مثال، وتحقق من كلا الشبكتين الفرعيتين مقابل كل شبكة يوجهها الموقع بالفعل:

Outer transport: IPv4 OpenVPN UDP
IPv4 pool:       10.90.0.0/24
IPv6 VPN pool:   fd73:93bc:b6e9:77::/64
IPv6 LAN:        fd73:93bc:b6e9:60::/64
Server LAN IPv6: fd73:93bc:b6e9:60::1

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

نقطة التحقق الثالثة: أضف المساعد ودفع المسار

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

server-ipv6 fd73:93bc:b6e9:77::/64
push "route-ipv6 fd73:93bc:b6e9:60::/64"

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

لا يتعايش المساعد مع تجمع IPv6 ثابت ولا مع nopool. إذا كان النشر يخصص العناوين ثابتاً عن قصد، فاحتفظ بتلك السياسة وصمّم المكافئ IPv6 صراحةً بدل حذف السياسة لتناسب مثالاً.

نقطة التحقق الرابعة: التوجيه ومسار الرد

شغّل توجيه IPv6 على الخادم عبر مالك الإعداد الخاص بالنظام، لا بكتابة وقت تشغيل لمرة واحدة ستنسى. صيغة وقت التشغيل مفيدة لاختبار سريع. الإعداد الدائم مكانه ملف drop-in يقرأه مالك الشبكة في التوزيعة:

sysctl -w net.ipv6.conf.all.forwarding=1

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

ثم امنح الشبكة المحلية مساراً عائداً إلى تجمع النفق. بوابة IPv6 لحمل العمل هي موجّه الشبكة المحلية، لا خادم VPN، لذا فالمسار مكانه على ذلك الموجّه ويشير إلى عنوان الخادم في الشبكة المحلية:

ip -6 route add fd73:93bc:b6e9:77::/64 via fd73:93bc:b6e9:60::1

احتفظ بأنواع ICMPv6 التي يحتاجها الرابط، بما فيها تغذية راجعة لـ MTU المسار. قاعدة جدار ناري IPv4 لا تعني قاعدة IPv6، والحجب الشامل لـ IPv6 يكسر اكتشاف الجيران بطرق تبدو كخلل في التوجيه.

نقطة التحقق الخامسة: اقرأ العميل، ثم اختبر

أعد توصيل العميل واقرأ العناوين التي استلمها فعلاً بدل استنتاجها من عنوان المساعد في الخادم. سرد الواجهة يظهر العائلتين على الجهاز نفسه:

ip -6 addr show tun0
ip -6 route get fd73:93bc:b6e9:60::20

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

اختبر التطبيق نفسه على كل عائلة بالتناوب، ثم كرّر بعد إعادة الاتصال وبعد إعادة تشغيل المضيف. مسار أو sysctl يبقى حتى إعادة التشغيل فقط هو اختبار، لا تصميم.

لا تنشر سجل AAAA إلا بعد أن يستجيب مسار IPv6 من طرف إلى طرف. استعلام DNS عبر IPv4 قد يعيد عنوان IPv6، فالاسم القابل للحل ليس دليلاً على أن شيئاً يستمع. يغطي إرشاد RFC 4193 لـ ULA توليد المعرّف العام الذي يجعل هذه البادئات ملكك لا نسخة.