تشغيل VPN على المضيف أم داخل الجهاز الافتراضي؟ دليل قرار

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

حدّد المالك قبل أن تلمس العميل

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

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

دوّن الإجابة في سطر واحد بجانب اسم الجهاز الافتراضي: guest-owned أو host-owned. في مختبر من ستة أجهزة يوفّر ذلك التدوين وقتًا أكثر من أي خطوة أدناه، لأنه يمنعك من استكشاف نفق لم يكن أبدًا في الجهاز الذي سجّلت الدخول إليه.

WSL1 وWSL2 حالتان متعاكستان

WSL1 ليس جهازًا افتراضيًا، لذا يتبخّر سؤال الموضع في معظم الحالات. تعمل ملفاته التنفيذية لنظام Linux مقابل مكدّس شبكة Windows عبر طبقة ترجمة، وليس لعميل VPN على Linux واجهات مستقلة يضبطها. والترتيب الذي يعمل هو نفق على جانب Windows، مع استخدام التوزيعة للنتيجة دون أن تملك أي شيء.

WSL2 هو العكس. يشغّل نواة حقيقية في جهاز افتراضي مساعد خفيف خلف مبدّل افتراضي من Hyper-V، وفضاء عناوينه يُترجَم عبر محوّل على جانب المضيف. لذا يتصرّف عميل Linux داخل التوزيعة كما يتصرّف على صندوق Linux فعلي: ينشئ tun0 أو wg0، ويثبّت مساراته، ويعمل. والفشل يسكن في جانب المضيف. عندما يتصل عميل VPN على Windows بسياسة تحجب الحركة على الشبكات المحلية، يعامل شبكة WSL2 الفرعية كشبكة محلية غير موثوقة ويقطع مسار NAT. عندئذٍ تفقد التوزيعة DNS والوصول الصادر بينما نفقها ما زال سليمًا: يبلّغ wg show عن مصافحة، ويبدو ip route صحيحًا، ويبقى curl معلّقًا.

أي إصلاح تستطيع استخدامه يعتمد على بنية Windows. الأقدم هو استثناء في عميل المضيف لشبكة WSL الفرعية، يُضاف تحت إعدادات الشبكة المحلية أو النفق المنقسم في العميل. والأحدث، على بنيات Windows 11 التي تدعمه، هو الشبكات المتطابقة: ضع networkingMode=mirrored في قسم [wsl2] من %UserProfile%\.wslconfig، ونفّذ wsl --shutdown، فتشارك التوزيعة واجهات المضيف بدلًا من شبكة NAT خاصة. كما يغيّر الوضع المتطابق سلوك localhost والمنافذ الواردة، لذا تعامله كترحيل لا كمفتاح تبديل.

NAT، والجسر، وما يستطيع المضيف رؤيته

في وضع NAT تُوجَّه حزم نفق الضيف إلى العنوان العام لخادم VPN وتخرج عبر محوّل المضيف كـUDP أو TCP مشفّر. يرى المضيف تدفقًا واحدًا وعدد بايتاته، ولا شيء عن الوجهات داخله. وفي وضع المحوّل المجسّر يكون للضيف هوية خاصة به من الطبقة 2 على الشبكة المحلية الفيزيائية، ويأخذ إيجار DHCP خاصًا به، ويبدو لأي سياسة مبنية على MAC كجهاز ثانٍ. لا يسمح أي من الوضعين للمضيف بقراءة حمولة النفق؛ والضيف المجسّر ببساطة أشدّ وضوحًا للشبكة من حوله.

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

الدليل: ضعه، اضبطه، أثبته

نفّذ هذه الفحوص الأربعة بالترتيب في صدفة ضيف جديدة، وتوقّف عند أول فحص يخالف المالك الذي دوّنته.

1. ip route get 1.1.1.1 الذي يعيد tun0 أو wg0 يعني نفقًا مملوكًا للضيف، وأما إعادته eth0 مع قفزة تالية خاصة فتعني نفقًا مملوكًا للمضيف.
2. resolvectl query example.com، أو اقرأ /etc/resolv.conf حيث لا يشغّل الضيف خدمة محلّل. والنفق الذي يحمل الحركة ولا يحمل DNS هو أشيع حالة نصف مضبوطة.
3. قارن المخارج: curl -4 -s https://ifconfig.me في الضيف مقابل curl.exe -4 -s https://ifconfig.me على المضيف. اختلاف العنوانين يعني أن الضيف يملك النفق، ومضيف على VPN مع ضيف يُظهر مزوّد الخدمة المنزلي هو حالة «لا شيء موروث».
4. أعد الاثنين مع -6. النفق الذي يدعم v4 فقط يسرب v6 ما لم يحجبه العميل أو يوجّهه، وكثير من العملاء يتركون v6 على الواجهة الفيزيائية افتراضيًا.

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

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
iptables -A FORWARD -i virbr0 -o wg0 -j ACCEPT
iptables -A FORWARD -i wg0 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT

على جانب WireGuard، يجب أن يتضمّن AllowedIPs لنظير المضيف شبكة الضيف الفرعية، مثلًا 192.168.122.0/24، وإلا فلا تصل حزم العودة أبدًا ويبدو الإعداد كمشكلة جدار ناري. ويبلغ مضيف Windows النتيجة نفسها عبر مشاركة اتصال الإنترنت أو قاعدة NAT على مبدّل Hyper-V، ويحتاج فحص مسار العودة نفسه.

حين يكون التخطيط ما زال مفتوحًا، يغطي هذا الجدول الترتيبات الأكثر شيوعًا:

نفقان، وضيفان، والتنازعات بينهما

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

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

تحقّق، ثم أبقِ الاستعادة مع المالك

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

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