آیا VM شما از VPN میزبان استفاده می‌کند؟ آن را از داخل مهمان آزمایش کنید

نشانی IP عمومی میزبان را بررسی می‌کنید، VPN را نشان می‌دهد و نتیجه می‌گیرید که VM پوشش داده شده است. این نتیجه را آزمون پشتیبانی نمی‌کند. مهمان جدول مسیریابی خودش، resolver خودش و رابط‌های خودش را دارد، و نشانی خروج میزبان هیچ چیزی درباره آن‌ها نمی‌گوید.

آزمون باید داخل مهمان اجرا شود و باید نام چیزی را که اندازه گرفته ببرد.

از داخل مهمان شروع کنید، نه در مرورگر میزبان

نخست حالت شبکه هایپروایزر را ثبت کنید: NAT، bridged، host-only یا macvtap. در حالت NAT میزبان ترافیک مهمان را مسیریابی می‌کند، بنابراین تونل میزبان بسته به اینکه کلاینت چگونه مسیرها را نصب می‌کند ممکن است اعمال شود یا نه. در حالت bridged مهمان همتای شبکه فیزیکی LAN است و تونل میزبان بی‌اهمیت است. این دو حالت از همان پیکربندی میزبان پاسخ‌های متضاد می‌دهند.

پیش از تغییر هر چیزی حالت را یادداشت کنید، چون تعیین می‌کند نتیجه چه معنایی می‌تواند داشته باشد.

یک درخواست بفرستید که مقصدش را می‌دانید

درخواستی بی‌ضرر به سرویسی بفرستید که نشانی مبدأیی را که دیده گزارش می‌کند. سپس تصمیم مسیریابی خود مهمان را برای آن مقصد بررسی کنید: ip route get 203.0.113.5 رابط و دروازه‌ای را که مهمان استفاده خواهد کرد چاپ می‌کند.

اگر رابط کارت شبکه معمولی مهمان باشد، ترافیک از تونلی داخل مهمان عبور نمی‌کند.

آداپتور دوم، تنظیم پروکسی یا کلاینت VPN در سمت مهمان می‌تواند پاسخ را برای یک برنامه تغییر دهد و برای برنامه دیگر نه. برنامه‌ای را آزمایش کنید که واقعاً برایتان مهم است، نه یک درخواست عمومی از پوسته.

resolver را جداگانه بررسی کنید

نشانی خروج تغییرکرده به شما نمی‌گوید کدام resolver نام میزبان را پردازش کرده است. نام را به‌صراحت با ابزاری که با پلتفرم می‌خواند بپرسید و یادداشت کنید کدام سرور پاسخ داد. DNS تفکیک‌شده یعنی پرسش resolver و پرسش مسیریابی پاسخ‌های متفاوت دارند.

این دو می‌توانند در هر جهتی واگرا شوند و این واگرایی اغلب همان باگ واقعی است.

روی میزبان systemd، resolvectl query رابط و سرور DNS پشت پاسخ را نام می‌برد. تنظیم‌های قدیمی‌تر سرور را در خروجی dig نشان می‌دهند — در هر حال نکته دیدن این است که کدام سرور پاسخ داد، نه فقط رسیدن پاسخ.

سیاست خرابی را آزمایش کنید، نه فقط موفقیت را

اگر شرط این است که هیچ ترافیکی بیرون از تونل نرود، یک درخواست موفق چیزی را اثبات نمی‌کند. آزمون خرابی کنترل‌شده پشتیبانی‌شده کلاینت را به کار ببرید: تونل را به روش پشتیبانی‌شده متوقف کنید و ببینید آیا درخواست جدید مهمان مسدود می‌شود. فرض نکنید که kill switch کلاینت میزبان هر چیدمان ارسال مجازی را پوشش می‌دهد. دامنه مستندشده آن تنها چیزی است که می‌توانید به آن تکیه کنید.

مهمانی که با افتادن تونل به کارت شبکه فیزیکی برمی‌گردد دقیقاً همان کاری را می‌کند که حالت NAT اجازه می‌دهد.

حالت و دامنه را ثبت کنید

حالت هایپروایزر، رابط و مسیر مهمان، resolver و برنامه‌ای را که آزموده‌اید بنویسید. تاریخ را اضافه کنید، چون بازگردانی snapshot یا به‌روزرسانی هایپروایزر می‌تواند هر چهار مورد را تغییر دهد.

اگر IPv4 از تونل پیروی کرد، همان را بگویید. ادعا را به IPv6، فضای نام دیگر یا VM دیگر در شبکه‌ای دیگر گسترش ندهید.