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

مسار افتراضي واحد، مالكَان

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

لدى OpenVPN مفتاح لهذا الغرض تحديدًا. route-noexec يمنع العميل من لمس الجدول الرئيسي على الإطلاق، وتُصدَّر القيم التي كان سيستخدمها إلى سكربت route-up حيث تصبح متاحة باسم route_vpn_gateway و dev وعناوين الواجهة. بعد ذلك تقرر أنت أي جدول يستقبل أي مسار، في شيفرة يمكنك قراءتها لاحقًا.

جدول السياسات مقابل إعادة كتابة الجدول الرئيسي

ApproachWhat it buysWhat it costs
Separate table plus source ruleLAN traffic and host traffic keep independent defaultsEvery lookup now depends on rule order
Editing the main table onlyFewer moving parts on a single-purpose hostOne mistake takes the gateway offline entirely
Two half-default routesWorks for a full-tunnel clientAmbiguous on a host that must answer on its LAN address

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

echo "10 vpn" >> /etc/iproute2/rt_tables
ip rule add from 192.168.50.0/24 table vpn
ip route add default via 10.8.0.1 dev tun0 table vpn

العناوين هنا عناصر نائبة. استبدل بادئة الشبكة المحلية وبوابة النفق واسم الجهاز من نشرك الخاص قبل تشغيل أي شيء.

يجب أن تطابق القاعدة المضيف أيضًا

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

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

ip route get 203.0.113.9 from 192.168.50.1

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

NAT أم مسار على الجهة البعيدة

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

iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

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

في الحالتين يجب تمكين التمرير، وقد تُسقط تصفية مسار العودة الصارمة الرد عندما لا يكون main قد اختار النفق لذلك المصدر. تحقق من القيمة الفعلية قبل أن تلوم النفق.

اجعل الانقسام يصمد أمام إعادة الاتصال

القواعد والمسارات المضافة يدويًا تختفي عند إعادة إنشاء الواجهة، وقد يعيش إدخال جدول قديم أطول من الجلسة التي برّرته. ضع قاعدة الجدول ومسار النفق وإدخال التمويه داخل سكربت route-up للعميل، وافرغ الجدول في أعلى السكربت حتى لا تعيش بوابة قديمة في الجلسة الجديدة.

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

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