توجيه حركة المضيف عبر VPN داخل آلة افتراضية: ستة فحوص

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

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

الفحص 1: يحتاج المضيف إلى وصلة يمكنه عنونتها

يجب أن يملك المضيف واجهة تقع في البادئة نفسها التي يقع فيها المحول الثاني للضيف. الوضع المضيف فقط في VirtualBox، أو المضيف فقط أو VMnet مخصص في VMware Workstation، أو جسر داخلي أو جهاز tap في QEMU/KVM، أو محول Internal في Hyper-V، كلها تفي بالشرط. الضيف 192.168.56.2، المضيف 192.168.56.1، البادئة 192.168.56.0/24 هو التصميم الذي أستخدمه في المختبرات.

شبكة QEMU في وضع المستخدم (-netdev user، الواجهة الخلفية الافتراضية SLIRP) و NAT في VirtualBox يفشلان في هذا الفحص تمامًا. تصل حزم الضيف إلى عملية وكيل على المضيف، فلا يرى المضيف أبدًا جهازًا يحمل عناوين الضيف وليس لديه ما يوجّه مسارًا إليه. محول Default Switch في Hyper-V هو القصة نفسها. إذا فشل ping 192.168.56.2 من المضيف، فتوقف: لا مسار يُضاف لاحقًا سيعالج ذلك.

الفحص 2: الضيف يمرر ويترجم

تصل الحزم من المضيف بمصدر عنوان من شبكة المضيف فقط ووجهة داخلية، فعلى الضيف أن يمررها ثم يخفيها خلف عنوان نفقـه. على ضيف Linux يعني ذلك التمرير، وزوج قبول FORWARD، و NAT للمصدر نحو النفق:

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
sudo iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -t nat -A POSTROUTING -s 192.168.56.0/24 -o tun0 -j MASQUERADE

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

ضيف Windows أكثر تعقيدًا. IPEnableRouter=1 تحت SYSTEM\CurrentControlSet\Services\Tcpip\Parameters يشغّل التمرير دون ترجمة، لذا يعمل فقط حيث يكون توجيه الشركة يشير أصلًا رجوعًا إلى بادئة المضيف فقط. مشاركة اتصال الإنترنت تترجم فعلًا، لكنها تعيد ترقيم المحول المشترك إلى 192.168.137.1، فاقرأ العنوان الذي أخذه فعلًا قبل كتابة مسارات المضيف.

الفحص 3: مسارات المضيف تسمّي الضيف، لا النفق

أرسل فقط البادئات التي يحتاجها المضيف عبر الضيف. على Linux يكفي مسار واحد لكل بادئة وينعكس بنظافة:

sudo ip route add 10.20.0.0/16 via 192.168.56.2
ip route get 10.20.30.40

على Windows المكافئ هو route add 10.20.0.0 mask 255.255.0.0 192.168.56.2. اترك -p أثناء الاختبار، حتى يموت المسار السيئ عند إعادة التشغيل، وأضفه عندما يعمل المسار. لا تحذف المسار الافتراضي للمضيف إلا إذا كان يجب أن تستخدم كل تطبيقات المضيف النفق؛ وإذا كان النفق الكامل هو المطلوب فعلًا، فأضف مساري /1 واحتفظ بالمسار المباشر إلى شبكة المراقب الافتراضي:

sudo ip route add 0.0.0.0/1 via 192.168.56.2
sudo ip route add 128.0.0.0/1 via 192.168.56.2

على مضيف Windows، افحص مقياس الواجهة أيضًا. المسار المضاف بينما كان محول المضيف فقط معطلًا يبقى في الجدول لكنه لا ينقل أي حركة، ومحول ثانٍ بمقياس أقل قد يفوز في البحث عن البادئة نفسها.

الفحص 4: DNS يتبع المسار، لا الوضع الافتراضي للنفق

المسارات تحرّك الحزم؛ والمحلّل يقرر أي الأسماء تنتج حزمًا. احصر محلّل الشركة في نطاق الشركة بدلًا من استبدال محلّل المضيف، ووجّهه إلى خادم DNS يصل إليه المسار الجديد أصلًا. مع systemd-resolved على المضيف:

resolvectl dns eth1 10.20.0.53
resolvectl domain eth1 '~corp.example.com'

على Windows يقوم إدخال في جدول سياسة تحليل الأسماء بالمهمة نفسها: Add-DnsClientNrptRule -Namespace ".corp.example.com" -NameServers 10.20.0.53. إذا كان الضيف يشغّل محلّله الخاص على عنوان المضيف فقط، فاستخدم ذلك العنوان بدلًا منه، لكن بعد التأكد من أنه يجيب على 192.168.56.2 وليس على loopback.

ثم افحص MTU قبل أن تلوم DNS على بطء الصفحات. واجهة النفق أصغر من واجهة المضيف ذات 1500 بايت، فالمضيف الذي يرسل مقاطع بالحجم الكامل مع ضبط بت DF تُسقَط في مكان ما داخل الضيف. العَرَض الكلاسيكي هو ping عامل وتطبيق ويب داخلي يتوقف بعد مصافحة TLS. اضبط MSS في مسار التمرير داخل الضيف:

sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

الفحص 5: تحقّق من الطرفين

من المضيف، يجب أن يُظهر traceroute أو tracert إلى عنوان داخلي 192.168.56.2 كأول قفزة، لا البوابة الفيزيائية. وفي الضيف، راقب خروج المحاولة نفسها: يُظهر tcpdump -ni any host 10.20.30.40 الطلب الممرَّر على جانب المضيف فقط والطلب المترجَم على النفق. الطلب الذي يخرج ويعود ويظل المضيف صامتًا يشير إلى مسار العودة.

فشلان يفسران معظم ذلك. إما أن نفق الضيف لا يحمل مسار عودة لبادئة المضيف فقط لأن قاعدة NAT غائبة، أو أن مسار المضيف يشير إلى عنوان لم يعد الضيف يحمله بعد إعادة التشغيل. أعد قراءة العناوين باستخدام ip -br addr و ip route get بدلًا من الوثوق بملاحظات الجلسة السابقة.

الفحص 6: اجعله يصمد أمام إعادة التشغيل وترقية المراقب الافتراضي

ثبّت النصفين: إعداد مسار netplan أو NetworkManager على المضيف، و route add ... -p على Windows، و net.ipv4.ip_forward=1 في /etc/sysctl.d/ إضافة إلى مجموعة قواعد جدار ناري تُعاد تحميلها في الضيف. خذ لقطة للضيف بمجرد أن يتحقق الإعداد، قبل وصول تحديث عميل الشركة التالي.

تُعاد ترقيم شبكات المضيف فقط عندما يعيد المراقب الافتراضي إنشاء محولاته، وهذا يبطل بصمت كل مسار وقاعدة NAT مبنية على 192.168.56.0/24. بعد الترقية، أعد تنفيذ الفحوص الثلاثة الأولى بالترتيب؛ يكلف ذلك دقيقة ويكشف الحالة التي يحتفظ فيها المضيف بمساره بينما انتقل الضيف إلى شبكة فرعية جديدة.

IPv6 يحتاج جولة خاصة به. قواعد ip6tables وسجلات AAAA وعائلة ثانية من مسارات المضيف لا تتبع إعداد IPv4، والخدمة الداخلية التي يمكن الوصول إليها عبر IPv6 ستبدو معطلة دائمًا بينما يعمل IPv4.

نجاحًا أو فشلًا، بالترتيب: يمكن للمضيف أن يرسل ping إلى عنوان الضيف على شبكة المضيف فقط؛ والضيف يمرر ويطبق MASQUERADE نحو النفق؛ و ip route get يعيد الضيف كبوابة للبادئة الداخلية؛ وأسماء الشركة تُحل عبر المحلّل المحصور؛ و traceroute يُظهر الضيف أولًا؛ والأجوبة الستة نفسها تصمد أمام إعادة التشغيل.