IPv6 عبر خادم VPN يعمل بـ IPv4 لا يزال يحتاج إلى مخرج IPv6

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

العَرَض: عنوان بلا مسار

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

اقرأ جدول التوجيه الخاص بالخادم قبل أن تمس العميل، لأن النصف المفقود من المسار يقيم هناك. الخادم الذي يملك مسارًا افتراضيًا واحدًا لـ IPv4 قد أخبرك بالجواب سلفًا.

تتبَّع الحزمة بعد فك التغليف

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

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

طبقتي نفق، وفحصان مستقلان

تحقّق من كل طبقة على حدة، لأن نفقًا خارجيًا عاملًا يخفي نفقًا داخليًا معطلًا. افحص المسار الخارجي بأمر ping عبر IPv4 من العميل إلى الخادم وتأكد من المنفذ الذي تستخدمه. ثم افحص المسار الداخلي على الخادم، حيث يجب أن يُظهر ip -6 route مسارًا افتراضيًا أو مسارًا محددًا تعلَّمه من منبع فعلي، ويجب أن يُظهر ip -6 addr بادئة مصدر يقبلها المنبع. أي شيء أقل من ذلك زينة على الواجهة.

العنوان المحلي الفريد، أو البادئة التي تبدو عالمية ولا يعود إليها أي توجيه، سيظهران بكل سرور على واجهة ولن يذهبا إلى أي مكان. الوصول العام يمنحه المنبع، لا شكل العنوان.

الأمر نفسه ينطبق على العميل: ip -6 route get 2001:4860:4860::8888 يجب أن يسمّي جهاز النفق، وإن سمّى الجهاز الفيزيائي فإن العميل لا يستخدم VPN لـ IPv6 إطلاقًا.

بادئة المصدر والحجم وICMPv6

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

احسب هامشًا للتغليف الإضافي الذي تستخدمه حزمتك فعليًا، وأبقِ ICMPv6 عاملًا، بما في ذلك Packet Too Big. رأس ثانٍ يصغّر الحمولة القابلة للاستخدام، لذا قد يفشل مسار يستجيب لعمليات ping الصغيرة في نقل ملف، وجدار ناري يُسقط كل ICMPv6 يحوّل مشكلة حجم قابلة للإصلاح إلى ثقب أسود. اختبر نقلًا كبيرًا واحدًا قبل أن تعلن الخدمة.

ما هو مشكلة مختلفة تمامًا

الوصول إلى تطبيق يعمل بـ IPv4 فقط من عميل يعمل بـ IPv6 فقط هو ترجمة، لا أنفاق، ويحتاج إلى شيء مثل ترتيب NAT64 منشور عن قصد. لن تفهم الوجهة رأس نفق إضافيًا لمجرد أنك أضفته. خدمات الانتقال التاريخية تستحق العناية نفسها: فقد ألغت RFC 7526 نموذج مرحّل 6to4 بالبث، لذا فإن أي دليل مكتوب حوله يصف شيئًا لم يبق له مرحّل عام مُصان.

إذا لم يكن لدى الخادم منبع IPv6 صالح للاستخدام، فالخيارات هي منبع مدعوم، أو مخرج مختلف، أو قرار موثّق بأن يبقى IPv6 خارج النفق. وغير المقبول أن تخبر العملاء بوجود خدمة IPv6 بينما اتصالهم العادي بـ IPv6 يتجاوز VPN بهدوء.