انقطاع حركة IPv6 بعد إعادة تشغيل OpenVPN: تحقّق من ملكية البادئة
تموت حركة IPv6 بعد إعادة إنشاء النفق. حدّد من يملك البادئة المفوّضة وعناوين العملاء ومسار العودة قبل إعادة تشغيل أي شيء.
تتوقف IPv6 عن تمرير حركة المرور في اللحظة التي OpenVPN يُعاد تشغيله، ويواصل IPv4 العمل. أُعيد إنشاء واجهة النفق، وفقد شيء آخر كان يدير حالة IPv6 فيها إمّا العنوان أو المسار الذي يجعل البادئة قابلة للوصول. هناك ثلاثة أجزاء منفصلة من الحالة، ولكل منها مالك مختلف: البادئة المفوّضة من المزوّد وعمرها، والعناوين الممنوحة لعملاء VPN، ومسار المنبع الذي يعيد بادئة العميل تلك إلى الخادم. حدّد مالك كل جزء قبل أن تمسّ أي daemon، لأن إعادة تشغيل daemon خاطئ تخفي المشكلة ليوم واحد ثم تعيدها عند الاتصال التالي.
ثلاثة أجزاء من حالة IPv6 وثلاثة ملاك
| State | Typical owner | What breaks when it is wrong |
|---|---|---|
| Delegated prefix and lifetime | Upstream router or provider via DHCPv6-PD | Clients keep addresses that the upstream no longer routes |
| Client addresses inside the tunnel | OpenVPN server config or a delegation daemon | No global address, or an address outside the routed prefix |
| Return route for the client prefix | Upstream router, or the server's own routing table | Outbound works, replies never arrive |
لا يكفي عنوان ذو نطاق عالمي داخل النفق وحده. ما زال على موجّهات المنبع أن ترسل تلك البادئة راجعة نحو خادم VPN، ولن تفعل ذلك لمجرد أن الخادم يحمل عنوانًا منها.
ولهذا أيضًا يُعدّ نسخ بادئة عامة /64 إلى مجموعة نفق أمرًا محفوفًا بالمخاطر. البادئة الموجّهة إلى الخادم ليست مثل البادئة التي يعتبرها المنبع على الوصلة، ولن يسدّ اكتشاف الجيران هذه الفجوة.
اقرأ حالة الخادم قبل أن تغيّر أي شيء
التقط الحالة مرتين، مرة أثناء عمل IPv6 ومرة بعد إعادة التشغيل، ثم قارن. تكفي العروض للقراءة فقط، ولا تكلّف شيئًا أثناء نافذة الصيانة:
ip -6 addr show
ip -6 route show table all
ip -6 rule show
sysctl net.ipv6.conf.all.forwardingابحث عن ثلاثة فروق محدّدة: مسار اختفى، وعنوان انتقل إلى عمر مهجور أو غير صالح، وبادئة تغيّرت بعد إعادة التفويض بينما لا يزال إعداد VPN يعلن القديمة.
إذا اختفى العنوان دون أن تتغيّر البادئة، فقد توقّف daemon الذي يسنُده عن إدارة الواجهة. وإذا تغيّرت البادئة دون أن تتغيّر العناوين، فإن إعداد العميل قديم. الفشلان يبدوان متطابقين من المتصفح ولا يشتركان في شيء.
قرّر ما إذا كان ينبغي لـ dhcpcd إدارة النفق
يستطيع dhcpcd اكتشاف الواجهات وتفويض أجزاء من بادئة DHCPv6 إلى واجهات المصب، ويمكن لإعداده تسمية أهداف التفويض صراحةً. وبدون هدف صريح، قد يشمل سلوكه الموثّق واجهات أخرى، وهكذا ينتهي النفق بعنوان لم يخطّط له أحد.
هناك شرطان ينبغي أن يدفعاك إلى ترك OpenVPN يملك العنونة الساكنة للنفق: أن يدفع الخادم عناوين ثابتة في إعداده، وأن يتغيّر اسم النفق عند إعادة الاتصال. إذا تحقّق الشرطان، فاستبعد النفق عمدًا من daemon التفويض، مع تعليق يوضّح السبب.
إذا كان التفويض إلى النفق مقصودًا بدلًا من ذلك، فنفّذ معالجة تغيّر البادئة. يعني ذلك التفاعل عندما تتغيّر البادئة المفوّضة أو عمرها، وتحديث بادئة العميل المعلنة من الخادم، وإعادة إضافة المسار. واستبعاد الواجهة في ذلك التصميم يزيل المكوّن الوحيد الذي يعرف البادئة الجديدة.
قد تبدو إعادة تشغيل dhcpcd وكأنها تصلح الأمور لأنها تعيد إنشاء الحالة، لكنها أيضًا تجدّد أو تسحب إعدادًا لواجهات لم تكن تفكر فيها. هذا التعافي لا يجعله شرطًا بعد كل إعادة تشغيل لـ VPN. كما أنه يصفّر العدّادات التي كنت تستخدمها كدليل. فضّل إعادة تحميل موجّهة للواجهة التي غيّرتها فعلًا.
تحقّق من IPv6 بشكل منفصل عن NAT الخاص بـ IPv4
تأكّد من أن التمرير مفعّل وأن مسار المنبع يشير إلى بادئة العميل الفعلية، ثم أنشئ اتصال IPv6 جديدًا مسموحًا. افحص أيضًا جدول التوجيه IPv6 الخاص بالعميل، لأن عميلًا يعرض عنوانًا عامًا لا يثبت أن طلبه استخدم النفق.
حلّ إخفاء IPv4 مشكلة مختلفة: مسار العودة للمصادر الخاصة. لا يفعل شيئًا لبادئة IPv6 مسحوبة، وإضافته لن تعيد IPv6.
أغلق بسجل الملكية: أي مكوّن يفوّض البادئة، وأيها يسنُد عناوين العملاء، وأيها يحمل مسار العودة، وماذا يحدث لكل منها عند إعادة الاتصال. أربعة أسطر في دليل تشغيل توفّر على الشخص التالي إعادة تشغيل ثلاثة daemons ليجد daemon المهم.