تقسيم /64 الخاص بك لا يوجّه IPv6 إلى عملاء VPN

يعرض العميل عنوان IPv6 عامًا، واكتملت المصافحة، ولا يعود شيء من الإنترنت. يبدو إعداد المجموعة صحيحًا لأنه صحيح؛ العنوان صالح والنفق يحمله. الذي يفشل هو التسليم، والتسليم يعتمد على قرار يُتخذ في الشبكة العليا قبل خادم VPN ولا يمكن لأي إعداد على جانب العميل أن يؤثر فيه.

الخرافة: جزء من /64 الخاص بك متاح بالفعل

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

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

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

ما يتطلبه التسليم على الوصلة فعلًا

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

اقتطاع /65 لا يغيّر ذلك التوقع. ما زالت الشبكة العليا تعامل النطاق كأنه على الوصلة، لأن الشيء الوحيد الذي قد يغيّر رأيها هو مسار أو وسيط يجيب نيابة عن العميل. لا يظهر أي منهما لأنك عدّلت إعداد VPN. تلك الفجوة هي سبب أن مجموعة يمكن أن تعمل بشكل مثالي بين عملائها وتبقى مع ذلك غير قابلة للوصول من أي مكان آخر.

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

ما يتطلبه التسليم الموجّه

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

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

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

مساران مستقلان يجب إتقانهما

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

server-ipv6 2001:db8:42:100::/64
push "redirect-gateway ipv6 !ipv4"

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

أبقِ حركة التحكم التي تعتمد عليها IPv6 عاملة تحت أي سياسة تطبقها. رسائل Packet Too Big هي الضحية الكلاسيكية لجدار ناري لا يسمح إلا بـ TCP وUDP، وإسقاطها ينتج اتصالات تُنشأ ثم تتوقف عند عمليات النقل الأكبر.

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

سجّل التصميم حتى تعيد إعادة البناء إنتاجه

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

ثم اختبر الاتجاه العكسي صراحةً، بحزمة يجب أن تعود من الخارج. يغطي دليل openvpn(8) خيارَي server-ipv6 وredirect، ويغطي تأكيد التوجيه من مزودك النصف الذي لا يستطيع الدليل تغطيته.