مختبر VPN في VirtualBox: جهاز البوابة الافتراضي مقابل شبكة المضيف فقط
اختر بين جهاز بوابة افتراضي موجّه وشبكة مضيف فقط لمختبر VPN في VirtualBox، ثم اجعل الضيف يفشل مغلقًا عندما يسقط النفق.
عليك أن تقرر مقدار الآلة التي يستحقها مختبر VPN لديك. جهاز بوابة افتراضي موجّه بين شبكتين في VirtualBox يعيد إنتاج ترجمة العناوين ومسار العودة وموضع الجدار الناري الذي يقف خلفه عميل حقيقي. شبكة واحدة من نوع المضيف فقط تمنحك بابًا واحدًا تحت السيطرة ولا شيء غير ذلك. نسخة البوابة تكلّف ثلاثة أضياف وجدول توجيه تديره أنت؛ ونسخة المضيف فقط تكلّف ضيفًا واحدًا وسياسة واحدة. ثلاثة أسئلة تفصل بينهما، والثالث يحدد ما إذا كان اختبارك قادرًا على النجاح أصلًا.
أجب عن ثلاثة أسئلة قبل أن تنسخ أي شيء
ابدأ بما يجب أن يلاحظه خادم VPN. إذا كان على الخادم أن يرى عنوان مصدر ليس عنوان الضيف المُختبَر، فلا بد لشيء أن يترجم بينهما، ولا بد لهذا الشيء أن يكون موجّهًا تديره أنت. شبكة المضيف فقط تعطي المضيف محولًا على شبكة الضيف، لا مترجمًا. وعندما يحتاج الضيف بعد ذلك إلى الوصول إلى أي شيء خارجي، تُرفق محول NAT، فيعيد محرك NAT الخاص بـ VirtualBox كتابة المصدر دون أن يسألك.
اسأل بعد ذلك ما إذا كان يجوز للضيف الوصول إلى أي شيء إلا عبر النفق. هذا الجواب يختار الداخلية أو المضيف فقط، وهو السؤال الذي تتخطاه معظم تقارير المختبرات. اسأل أخيرًا عما يجب أن يحدث عندما يسقط النفق، لأن ذلك يحدد السياسة لا الطوبولوجيا، والمختبر الذي يثبت المسار السعيد وحده لم يختبر شيئًا تقريبًا.
| What the test requires | Routed gateway VM | Host-only guest |
|---|---|---|
| Server sees a translated source address | Yes, from your own MASQUERADE rule | No, VirtualBox NAT does it instead |
| The guest has exactly one egress | Yes, while the second adapter faces the tunnel | Only until a NAT adapter is attached |
| Policy is testable during a tunnel failure | Rules live in one place | Rules live on each guest |
وصّل الأدوار الثلاثة بشبكات داخلية
استخدم ثلاثة أضياف وشبكتين مسمّاتين، مع جعل البوابة الجهاز الوحيد الذي يحمل محولًا على كلتيهما:
VBoxManage modifyvm lab-client --nic1 intnet --intnet1 WAN
VBoxManage modifyvm lab-server --nic1 intnet --intnet1 LAN
VBoxManage modifyvm lab-gw --nic1 intnet --intnet1 WAN --nic2 intnet --intnet2 LANلا توجد خطوة إنشاء منفصلة لشبكة داخلية. السلسلة في --intnet1 هي الشبكة: يشترك جهازان فيها فقط إذا تطابق الاسم تمامًا، ولا شيء على المضيف متصل بها. هذه الخاصية الأخيرة هي سبب تكرار المختبر بنظافة، لأن مسارات المضيف وعميل VPN الخاص به وجداره الناري لا يمكنها الوصول إلى الأضياف بالخطأ. كما أن الشبكة الداخلية لا تحتوي على خادم DHCP ما لم تضف واحدًا، لذا فالعناوين الثابتة هي أقصر طريق.
أعطِ العميل عنوان WAN الخاص به فقط، مع بوابة افتراضية تشير إلى عنوان WAN الخاص بالبوابة. يحصل الخادم على عنوان LAN ويستخدم عنوان LAN الخاص بالبوابة كبوابة افتراضية له. الضيف الذي يحتفظ بعنوانين على شبكة واحدة، أو بمسار شارد إلى الشبكة الأخرى، لديه مسار يلتف حول الموجّه، وستكذب عليك الاختبارات أدناه.
أحتفظ بملف نصي بجانب أسماء الأجهزة الافتراضية فيه العناوين الأربعة واسما الشبكتين، وألصقه في كل صدفة. بعد أسابيع، عندما يكسر تغيير في ملف التعريف شيئًا، يكون ذلك الملف هو الفرق بين تصحيح ملف التعريف وتصحيح ذاكرتي.
اختر الداخلية أو المضيف فقط للشبكة التي يجب ألا تتسرب
ينشئ وضع المضيف فقط محولًا افتراضيًا على المضيف نفسه، عادةً vboxnet0، ويمنح المضيف عنوانًا على شبكة الضيف. ذلك مريح للإدارة وقاتل لاختبار العزل، لأن المضيف يستطيع الآن الوصول إلى الضيف مباشرة، وتصبح كل خدمة على جانب المضيف مسارًا محتملًا. الوضع الداخلي لا يحتوي على محول مضيف على الإطلاق. من السهل الخلط بين الوضعين في لوحة إعدادات الشبكة، لذا تحقق من الفرق الموثّق بدلًا من التسمية (انظر صفحة تفاصيل الشبكات في VirtualBox).
بالنسبة إلى ضيف يجب أن يستخدم النفق، الوضع الداخلي هو الافتراضي الأكثر أمانًا، مع البوابة كمخرج وحيد. إذا أبقيت المضيف فقط، فتعامل مع محول المضيف كمسار إداري وقل ذلك صراحةً: يجوز للمضيف الوصول إلى الضيف، ويجب ألا يستطيع الضيف استخدام المضيف كمخرج.
VBoxManage modifyvm lab-client --nic1 hostonly --hostonlyadapter1 vboxnet0العزل الذي يمكنك إثباته هو العزل الذي أعددته. الضيف الذي لديه محول داخلي واحد ومسار افتراضي عند البوابة ولا محول NAT ليس لديه مسار يتجاوز البوابة. والضيف الذي لديه محول مضيف فقط ومحول NAT لديه مسارَان، وواحد منهما فقط هو الذي قصدت اختباره.
وجّه وترجم على البوابة، ثم اجعلها تفشل مغلقة
لا يمرّر VirtualBox بين الشبكات؛ الضيف هو من يفعل ذلك. مع وجود جهاز خادم VPN خلف البوابة، فعّل التمرير وترجم حركة العميل وهي تغادر نحو الخادم:
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADEبهذه القاعدة يرى الخادم عنوان LAN الخاص بالبوابة بدلًا من عنوان العميل، وهذا هو شكل عميل حقيقي خلف NAT المشغّل أمام رأس شبكة. احفظ قيمة sysctl في /etc/sysctl.d/ والقاعدة في أي خدمة جدار ناري تستخدمها التوزيعة، وإلا أعاد إعادة التشغيل المختبر بصمت إلى حالة موجّهة لكن غير مترجمة.
التمرير ليس تخويلًا. في ظل سياسة FORWARD الافتراضية من ACCEPT، يخرج الضيف الذي يشير مساره الافتراضي إلى البوابة عبر الواجهة التي يختارها جدول التوجيه، سواء كانت النفق أم لا. وإذا كانت للبوابة أيضًا محول NAT لتثبيت الحزم، فذلك المحول مخرج عامل غير مشفّر في اللحظة التي يسقط فيها النفق، ولم يكن اختبارك المخصّص لـ VPN وحده اختبارًا كذلك قط.
وعندما يكون الخادم بعيدًا بدلًا من ذلك وتنهي البوابة النفق بنفسها، فإن القرار نفسه يشير إلى واجهة النفق، لا إلى بطاقة الشبكة التي تصل إلى الإنترنت:
iptables -P FORWARD DROP
iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPTأبقِ النقل الخارجي الخاص بالنفق ومسار الإدارة خارج النطاق منفصلين عن الحركة الممرَّرة. إذا كانت الطريقة الوحيدة لإصلاح البوابة هي المرور عبر النفق الذي تصححه، يصبح المختبر تمرينًا على الإغلاق. وحدة تحكم تسلسلية، أو محول إدارة من نوع المضيف فقط، أو لقطة لحالة سليمة معروفة أرخص من استعادة موجّه معطوب يدويًا.
تحقّق من المسار من الضيف، لا من المضيف
اعمل من الداخل إلى الخارج. تأكد من أن العميل يستطيع الوصول إلى عنوان WAN الخاص بالبوابة، ثم إلى الخادم عبر البوابة، ثم من أن اتصالًا بمنفذ VPN يخرج ويعود. يكشف التقاط على واجهتي البوابة ما إذا كان الرد يصل ويُسقَط في مسار العودة، وهو ما لا يستطيع التقاط على العميل وحده تمييزه:
tcpdump -ni eth0 udp port 1194
tcpdump -ni tun0 udp port 1194ثم أثبت المخرج. اسأل من الضيف خدمة انعكاس عناوين ما المصدر الذي تراه وقارن ذلك بعنوان الخروج الخاص بالبوابة؛ إذا طابق الجواب عنوان المضيف، فهناك مسار يلتف حول النفق. تحقق من أي مُحلّل يستخدمه الضيف فعليًا، وتحقق من IPv6 على حدة، لأن الشبكة التي يكون فيها IPv6 مفعّلًا بينما يحمل النفق IPv4 فقط تتسرب بالتصميم لا بالخطأ.
أخيرًا، اكسرها عمدًا. أوقف النفق، أو احجب منفذه الخارجي، وافتح اتصالًا جديدًا من الضيف. يجب أن يفشل، ويجب أن يكون السبب واحدًا تستطيع تسميته: لا مسار، أو قاعدة رفض، أو مُحلّل ميت. أعد تشغيل النفق وتأكد من أن الضيف يتعافى دون إعادة بناء الشبكة. إذا شارك VPN شبكي مثل Hamachi أو ZeroTier المختبر، فتذكّر أن المحول الجسري يتبع اسم المحول لا الشبكة الشبكية، لذا يجب إعادة توجيه الجسر بعد أن يثبّت العميل محوله الافتراضي الخاص.
VBoxManage list bridgedifs
VBoxManage modifyvm lab-client --bridgeadapter1 <mesh-adapter-name>مشاركة نفق الضيف مع المضيف تعكس المشكلة نفسها. توجيه المسار الافتراضي للمضيف إلى الضيف ينجح، وكذلك وكيل داخل الضيف؛ أما NAT عبر المضيف فلا يحمل نفق الضيف للحركة التي نشأها المضيف. احفظ أسماء الشبكات وقواعد الجدار الناري في مكان واحد، وخُذ لقطة للحالة العاملة، وسجّل عنوان المصدر الذي رصده الخادم. عندئذٍ يكلّف تغيير ملف التعريف التالي تشغيلًا واحدًا لسكربت بدلًا من مختبر مُعاد بناؤه.