هل تستخدم الآلة الافتراضية VPN المضيف؟ اختبرها من داخل الضيف

تتحقق من عنوان IP العام للمضيف، فيظهر عليه VPN، وتستنتج أن الآلة الافتراضية مغطاة. هذا الاستنتاج لا يدعمه الاختبار. للضيف جدول توجيه خاص به ومحلّل أسماء خاص به وواجهات خاصة به، وعنوان خروج المضيف لا يقول شيئًا عنها.

يجب أن يُجرى الاختبار داخل الضيف، ويجب أن يسمّي ما قاسه.

ابدأ داخل الضيف، لا في متصفح المضيف

سجّل وضع شبكة الهايبرفايزر أولًا: NAT أو bridged أو host-only أو macvtap. في وضع NAT يوجّه المضيف حركة الضيف، لذا قد ينطبق نفق المضيف أو لا ينطبق بحسب طريقة تثبيت العميل للمسارات. في وضع bridged يكون الضيف نظيرًا على الشبكة المحلية الفعلية ونفق المضيف لا صلة له. هذان الوضعان يعطيان إجابتين متعاكستين من الإعداد نفسه للمضيف.

اكتب الوضع قبل أن تغيّر أي شيء، لأنه يحدد ما يمكن أن تعنيه النتيجة.

أرسل طلبًا واحدًا تعرف وجهته

استخدم طلبًا غير مؤذٍ إلى خدمة تُبلّغ عن عنوان المصدر الذي رأته. ثم افحص قرار التوجيه الخاص بالضيف لتلك الوجهة: ip route get 203.0.113.5 يطبع الواجهة والبوابة التي سيستخدمها الضيف.

إذا كانت الواجهة هي بطاقة الشبكة العادية للضيف، فالحركة لا تمر عبر نفق داخل الضيف.

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

افحص محلّل الأسماء بشكل منفصل

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

يمكن أن يختلف هذان في أي اتجاه، والاختلاف غالبًا هو العلة الفعلية.

على مضيف systemd، resolvectl query يسمّي الواجهة وخادم DNS وراء الإجابة. الإعدادات الأقدم تُظهر الخادم في مخرجات dig — وفي الحالتين الهدف هو رؤية أي خادم ردّ، لا مجرد وصول رد.

اختبر سياسة الفشل، لا النجاح فقط

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

الضيف الذي يعود إلى بطاقة الشبكة الفعلية عند سقوط النفق يفعل بالضبط ما يسمح به وضع NAT.

سجّل الوضع والنطاق

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

إذا تبع IPv4 النفق فقل ذلك. لا توسّع الادعاء إلى IPv6 أو نطاق أسماء آخر أو آلة افتراضية أخرى على شبكة مختلفة.