بادئة عامة عبر OpenVPN: إصلاح مسار العودة

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

يجب أن تُوجَّه البادئة إليك أولًا

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

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

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

مستويا التوجيه: مسار النواة و iroute

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

مسار جهة الخادم يبدو هكذا، مع تطابق البادئة والقناع مع التخصيص:

ip route add 198.51.100.64/28 dev tun0

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

iroute 198.51.100.64 255.255.255.240

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

أين يقيم عنوان الخدمة

البادئة المفوّضة ليست الشيء نفسه كعناوين النفق الخاصة. أبقِ الوصلة مُرقَّمة من الفضاء الخاص إن أردت، وضع عنوان الخدمة العام حيث تعمل الخدمة فعليًا.

على عميل Linux يُنهي الخدمة محليًا، يكفي عنوان مضيف واحد:

ip address add 198.51.100.70/32 dev lo

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

احتفظ بالمصدر العام في مسار العودة

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

على خادم الدخول، قاعدة masquerade عريضة هي المتهم المعتاد. إنها تعيد كتابة المصدر العام إلى عنوان الخادم الرئيسي، ولا يرى العميل العنوان الحقيقي أبدًا:

iptables -t nat -S POSTROUTING

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

تحقّق من الاتجاهين قبل الوثوق به

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

اسأل النواة عن المسار الذي يسلكه عنوان مفوّض، وراقب النفق أثناء تشغيل طلب:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

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

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

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