شبكات NAT مقابل الشبكات الجسرية للأجهزة الافتراضية: أيّهما ينقل حركة VPN؟

ينسخ ضيوف NAT نفق المضيف فقط إذا كان العميل ينفق بحسب المسار؛ أما الضيوف الجسريون فيوجّهون أنفسهم. اختبر الضيف ثم اختر النمط المناسب.

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

NAT يبقي الضيف خلف شيفرة الهايبرفايزر، حيث تنطبق مسارات المضيف

في VirtualBox يجلس ضيف NAT على 10.0.2.0/24 مع بوابة افتراضية عند 10.0.2.2، ووكيل DNS عند 10.0.2.3، ولا مسار خاص به إلى الشبكة الفيزيائية. تأخذ محرّكة NAT الحزم الصادرة وتعيد كتابتها ليصبح المصدر هو المضيف ثم تمررها إلى مكدس IP في المضيف. من هناك تصبح حركة الضيف تدفقًا على المضيف، ويتم البحث عن المسار حسب الوجهة: عميل نفق كامل يثبّت 0.0.0.0/1 و128.0.0.0/1 على المضيف يلتقطها دون أن يعرف أن جهازًا افتراضيًا موجود. فصل الشبكات في VirtualBox من Oracle يسرد هذه القيم الافتراضية إن أردت تأكيد العناوين في نسختك.

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

النمط الجسري يمنح الضيف مكانه الخاص على الشبكة المحلية الفيزيائية

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

وهذا يقطع في الاتجاهين. يبدأ تصفح mDNS وSMB بالعمل لأن الضيف يرى حركة البث في الشبكة المحلية، ويصبح الضيف قابلًا للوصول من أجهزة أخرى على المقطع نفسه دون جدار حماية للمضيف بينهما. كما أن الجسر ليس طريقة لدفع ضيف عبر نفق قائم: توصيل جهاز افتراضي بواجهة WireGuard أو OpenVPN في المضيف ليس شيئًا يفعله VirtualBox أو libvirt نيابة عنك. وإذا كان لا بد من إنفاق ضيف جسري، فيجب أن ينتهي النفق في مكان ما على تلك الشبكة المحلية.

الاختبار الذي ينهي الجدل

نفّذ الفحوص نفسها في النمطين واكتب الأجوبة:

  • على المضيف يعطي curl -s https://ifconfig.me عنوان v4 العام.
  • في الضيف، الأمر نفسه، مع ip route على Linux أو Get-NetRoute -DestinationPrefix 0.0.0.0/0 على Windows للحصول على البوابة الافتراضية.
  • هوية المزوّد: resolvectl status أو cat /etc/resolv.conf داخل الضيف، لترى ما إذا كان يشير إلى 10.0.2.3 أو إلى خادم في الشبكة المحلية.
  • عائلة العناوين: ip -6 addr show scope global وطلب v6 واحد، لأن نفق v4 لا يقول شيئًا عن عنوان v6 عام قد يملكه الضيف.

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

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

أي نمط يناسب المهمة

النمط قرار توجيه، فاختره من المتطلب لا من العادة:

RequirementMode that fits
Every guest flow must exit through the host tunnelNAT, with a host client that tunnels by route, verified from inside the guest
The guest needs its own VPN account or profileBridged, or NAT with a client running inside the guest, not both
The guest must serve SSH, SMB, or a dev server to the LANBridged; NAT needs a port forward, which does not change the outbound path
The guest must stay invisible to the LANNAT; a bridged guest is another host on the segment
The guest needs a real public IPv6 addressBridged; VirtualBox NAT mode has no IPv6 forwarding
Isolation from the LAN with access to the hostHost-only adapter, not NAT

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

أعطال تُنسب إلى VPN

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

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

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

سجّل النمط ثم أعد الفحص بعد أي تغيير في المهايئ

دوّن النمط، وواجهة المضيف التي يستخدمها الجسر، والبوابة الافتراضية للضيف، ومزوّده، وعنواني خروجه v4 وv6. هذا السجل هو ما يجعل العطل التالي رخيصًا: عندما ينتقل حاسوب محمول من القاعدة إلى Wi-Fi، يتبع الضيف الجسري الجسر إلى مهايئ فيزيائي آخر وقد يعيد الإيجار في شبكة فرعية أخرى، بينما يحتفظ ضيف NAT بعنوانه 10.0.2.x ويرث بهدوء رابطًا صاعدًا مختلفًا.

قبل إغلاق التذكرة، أكّد كل بند من هذه:

  • عنوان خروج الضيف يختلف عن عنوان خروج المضيف، فهو ليس على نفق المضيف.
  • المزوّد هو وكيل 10.0.2.3 أو خادم في الشبكة المحلية، وأنت تعرف أيهما أجاب.
  • لا يوجد عنوان v6 عام في الضيف إذا كان تصميم النفق v4 فقط.
  • مع إنزال نفق المضيف يتوقف الضيف عن التصفح، أو تعرف الآن أنه لم يعتمد عليه قط.
  • لا يرى الضيف حركة بث في الشبكة المحلية ليس من شأنه رؤيتها.

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