توجيه حركة الأجهزة الافتراضية على شبكة المضيف فقط عبر خادم TUN OpenVPN

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

شبكتان، بادئتان

امنح تجمّع النفق وشبكة المضيف فقط بادئتين مختلفتين ولا تُعِد استخدام إحداهما للأخرى أبدًا. في هذا المثال تجمّع VPN هو 10.44.0.0/24 وشبكة المضيف فقط هي 192.168.99.0/24، مع المضيف على 192.168.99.1 وضيف على 192.168.99.20. إن إسناد البادئة نفسها لكل من جهاز TUN ومحوّل المضيف فقط لا يدمجهما. بل يخلق ادّعاءين على نطاق عناوين واحد، ثم يجيب جدول التوجيه للادّعاء الذي احتفظ به مصادفة.

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

المضيف يملك المسار بالفعل

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

ip -br addr show
ip route show 192.168.99.0/24
sysctl net.ipv4.ip_forward

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

ادفع المسار، ثم صفِّ ما يصل إليه

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

push "route 192.168.99.0 255.255.255.0"
iptables -A FORWARD -i tun0 -o vboxnet0 -d 192.168.99.20 -p tcp --dport 5432 -j ACCEPT
iptables -A FORWARD -i vboxnet0 -o tun0 -s 192.168.99.20 -p tcp --sport 5432 -m conntrack --ctstate ESTABLISHED -j ACCEPT

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

يحتاج الضيف إلى طريق للعودة

على الضيف الذي يُوصَل من 10.44.0.x أن يرسل ردوده إلى عنوان المضيف فقط الخاص بالمضيف، أو على المضيف أن يترجم المصدر. تلقي عنوان من DHCP الخاص بـ VirtualBox لا يقول شيئًا عن أي من الترتيبين.

ip route add 10.44.0.0/24 via 192.168.99.1 dev enp0s8
ip route get 10.44.0.15

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

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

تحقق، ثم اجعله يصمد أمام إعادة التشغيل

اختبر خدمة غير مؤذية من عميل بعيد عادي، وتحقق من مسار العودة للضيف، وتأكد من أن خدمة لم تسمح بها تُرفض بدلًا من أن تكون بطيئة.

ss -lntp '( sport = :5432 )'
conntrack -L | grep 192.168.99.20

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