بادئة فرع IPv6: iroute-ipv6 أم route-ipv6 على الخادم؟

يظهر توجيهان بالاسم نفسه تقريبًا في كل مثال عامل، ونسخ أحدهما دون الآخر ينتج نفقًا يبدو صحيحًا ويُسقط بادئة الفرع بصمت. يقومان بعملين مختلفين على جانبين من الحد نفسه: أحدهما يعلّم نواة الخادم أين تعيش البادئة، والآخر يعلّم OpenVPN أي عميل موثَّق يحملها. إن صحّ الاثنان تدفقت البادئة؛ وإن صحّ واحد فقط فلدى الحزم مسار لكن ليس لها مالك.

توجيهان، عملان مختلفان

route-ipv6 هو تثبيت مسار عادي: يضيف الخادم مسار نواة يوجّه البادئة إلى واجهة النفق لديه. iroute-ipv6 يخص سياقًا خاصًا بالعميل ويعلن الملكية الداخلية، حتى يعرف الخدمة أن حركة هذه البادئة يجب أن تُرسل إلى عميل معيّن لا إلى النظير الذي يسمّيه مسار النواة مصادفة.

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

في إعداد userspace التقليدي يحتاج الأمر إلى كليهما وهما يكملان بعضهما. مسار النواة وحده يترك الخدمة عاجزة عن اختيار نظير. و iroute وحده يترك النواة بلا طريق إلى النفق. ومن هنا يأتي معظم الالتباس حول الملفات لكل عميل: الملف ليس إدخالًا في جدول المسارات، وإدخال المسار ليس إعلانًا عن الملكية.

ip -6 route show | grep fd00:7a
ip -6 route get fd00:7a::1

أين ينتمي كل واحد

المسار يوضع في إعدادات الخادم المُدارة، حيث ينطبق على عملية الخادم تلك. أما iroute فيوضع في الملف الخاص بالعميل، المسمّى بهوية جهاز الفرع الموثَّقة.

اسم ملف لا يطابق الهوية الفعلية لا يُقرأ أبدًا، والعَرَض مطابق لغياب iroute. تحقّق من الهوية التي وثّقها الخادم، ثم تحقّق من اسم الملف حرفًا بحرف.

# /etc/openvpn/server/server.conf
route-ipv6 fd00:7a::/64
client-config-dir /etc/openvpn/server/ccd

# /etc/openvpn/server/ccd/branch-b
iroute-ipv6 fd00:7a::/64

أبقِ التجمع وبادئة الفرع منفصلين، لأن تداخلهما يصنع أحجية لا يحلها أي توجيه.

ما يحتاجه عميل آخر

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

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

إرسالها إلى الجميع خيار له تبِعات: حينها يعتقد كل عميل أن الفرع يمكن الوصول إليه عبر النفق، بمن فيهم عملاء لم تقصد يومًا منحهم ذلك الوصول. الإعلان في الممارسة قرار وصول، وإن كان التوجيه يبدو كعمل سباكة. مرجع خيارات الخادم يوثّق iroute-ipv6 كملكية خاصة بالعميل، وهذا هو الفرق الذي يستحق البقاء.

مسار العودة على جهاز الفرع

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

مسار العودة هذا هو المكافئ لـIPv6 لمشكلة المسار المفقود التي يصطدم بها الناس مع IPv4.

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

حين لا يزال الزوج غير كافٍ

بعض عمليات النشر لا تستخدم هذا المسار إطلاقًا. مسار بيانات النواة والخوادم التي يديرها المنتج لديها معالجة مسارات مدعومة خاصة بها، وقد لا ينتقل مثال userspace مباشرة.

تحقّق من مسار البيانات الذي يستخدمه بناؤك قبل نسخ توجيهات من دليل كُتب للآخر.

وأخيرًا، تذكّر نطاق العناوين: بادئة محلية فريدة مثل fd00:7a::/64 خاصة بالتصميم ولا تقول شيئًا عن إمكانية الوصول العامة إلى IPv6. تعامل معها كوصول داخلي، وأبقِ الخروج إلى الإنترنت مسألة منفصلة بسياسة خاصة بها.