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

الاسم البديل محلي، والملكية بعيدة

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

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

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

أضف العنوان على العميل بشكل دائم

ضع عنوان الخدمة على loopback ببادئة مضيف، حتى يتعامل معه المضيف كدخل محلي لا كشبكة فرعية يجب الوصول إليها. ip address add 10.66.0.10/32 dev lo يفعل ذلك لعنوان واحد، وتكرار الأمر لعنوان ثانٍ يمثل خدمتين.

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

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

طالِب به في ملف CCD الذي يقرأه المركز فعليًا

على الخادم، يذهب إعلان الملكية إلى ملف العميل المختار بالاسم الشائع الموثق، داخل الدليل المسمى بواسطة client-config-dir. السطر هو iroute 10.66.0.10 255.255.255.255، واحد لكل عنوان، وهو يخبر الخادم أي نظير يجب أن يتلقى الحركة لهذه الوجهة.

تفصيلان يكسران ذلك بهدوء. يجب أن يطابق اسم الملف الاسم الذي يستخدمه الخادم فعليًا، وهو يختلف عندما يكون username-as-common-name قيد الاستخدام. وأما iroute فلا يسري إلا في وضع TUN مع دليل إعداد عميل مُعدّ، لذا فالسطر نفسه لا يفعل شيئًا في نشر جسر. أضف أسطرًا إلى الملف الموجود بدل استبداله، لأنه قد يحمل بالفعل عنوانًا ثابتًا أو خيارات push. ويوثّق مرجع OpenVPN 2.6 كلاً من الدليل وتوجيه الملكية.

تحتاج نواة المركز نفسها أيضًا إلى مسار إلى تلك الوجهات حتى تدخل الحركة المولّدة محليًا عملية النفق. route 10.66.0.10 255.255.255.255 في إعداد الخادم يغطي الحركة التي يصدرها الخادم، بينما يحتاج العملاء الآخرون إلى push "route 10.66.0.10 255.255.255.255" ليتعلموا الوجهة بأنفسهم.

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

تحقق من سياسة الدخل ومسار الرد

تصل الحزمة الموجهة إلى الاسم البديل إلى المضيف المالك كدخل محلي، فالسؤال هو هل تسمح الجدار الناري المحلي بذلك المصدر والمنفذ. اسمح بمنفذ الخدمة المحدد من نطاق مصدر VPN بدل فتح العنوان كله.

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

احترس من مستمع ثانٍ على المنفذ نفسه مرتبط بعنوان مختلف، لأن النواة تسلّم إلى أي مقبس يطابق، وتبدو النتائج عشوائية. تحقق باستخدام ss -lntp وأكد أن العنوان المرتبط هو الاسم البديل للخدمة. لا حاجة إلى NAT المصدر هنا، وإضافته تخفي هوية المتصل التي تعتمد عليها سجلاتك.

اختبر العناوين والملكية على حدة

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

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

مقالات ذات صلة