VirtualBox با NAT یا پل: VPN ماشین مجازی کجا تمام می‌شود

دو پرسش متفاوت هر بار که یک ماشین مجازی یک کارخواه VPN را اجرا می‌کند با هم می‌رسند، و پاسخ‌هایشان متفاوت است. پرسش نخست این است که آیا تونلی درون مهمان از میزبان محافظت می‌کند، و پرسش دوم این است که آیا تونلی روی میزبان مهمان را می‌پوشاند. حالت آداپتور هر دو را تعیین می‌کند، بیش از خود نرم‌افزار VPN. آداپتور NAT میزبان را نقطه پایانی دیدنی می‌کند، حال آنکه آداپتور پل مهمان را با نشانی خودش روی شبکه می‌گذارد.

چه کسی در واقع نشست رمزنگاری‌شده را پایان می‌دهد

نشست رمزنگاری‌شده از آن ماشینی است که آن را پایان می‌دهد، و این ماشین مهمان است هنگامی که کارخواه درون ماشین مجازی اجرا می‌شود. تنها ترافیکی که به آداپتور مجازی مهمان وارد می‌شود از آن تونل می‌گذرد، و ابرناظر هرگز خودش ماشین دیگری را از میان مهمان مسیریابی نمی‌کند. به همین دلیل مهمان می‌تواند تونل کارآمدی نگه دارد در حالی که میزبان آشکارا مرور می‌کند. عکس آن متقارن نیست، و همین نامتقارنی بخشی است که بیشتر راهنماها اشتباه می‌گویند.

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

NAT مهمان را بازنویسی می‌کند تا شبیه میزبان شود

با NAT، ابرناظر هر بسته مهمان را پیش از رسیدن به نخستین سوئیچ به نشانی میزبان بازنویسی می‌کند. آن ترافیک سپس به پشته شبکه خود میزبان سپرده می‌شود، جایی که از جدول مسیریابی او پیروی می‌کند، از جمله مسیر پیش‌فرضی که در اختیار تونلی روی میزبان است. پس مهمان NAT بدون هیچ پیکربندی با تونلی روی میزبان پوشانده می‌شود، که عکس آن چیزی است که حالت مهمان به میزبان القا می‌کند.

# on the host: adapter mode and NAT DNS behaviour
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
VBoxManage modifyvm "lab-vm" --natdnshostresolver1 on

مهمانی که کارخواه خودش را اجرا می‌کند آن تونل را درون مهمان پایان می‌دهد، و ترافیک رمزنگاری‌شده سپس از همان بازنویسی بیرون می‌رود، بنابراین برنامه‌های میزبان مسیر خود و نشانی خروج خود را نگه می‌دارند. VirtualBox در این حالت مالکیت تحلیل نام را هم دارد و پرس‌وجوهای مهمان را از موتور خودش عبور می‌دهد مگر آنکه --natdnshostresolver1 فعال باشد. فعال کردن آن جست‌وجوهای مهمان را به تحلیلگر میزبان می‌سپارد، که هرگاه نگاه خود میزبان درست باشد تحلیل را درست می‌کند و به همان اندازه تحلیلگری می‌سپارد که شاید فقط درون یک تونل وجود داشته باشد. ماشین مجازی باید پیش از تغییر تنظیم خاموش شود، و تنظیم از آن آداپتور است نه نرم‌افزار مهمان.

پل به مهمان اجاره خودش و در معرض دید بودن خودش را می‌دهد

پل قاب‌های مهمان را به بخش فیزیکی می‌فرستد، پس DHCP به آن اجاره می‌دهد و شبکه با آن مانند میزبانی جدا رفتار می‌کند. هر مهمان پل‌شده می‌تواند تونلی مستقل با مسیر پیش‌فرض خودش نگه دارد، و جدول میزبان هرگز تغییر نمی‌کند. بهای آن در معرض دید بودن است: مهمان به پخش‌ها پاسخ می‌دهد، در جدول‌های همسایه ظاهر می‌شود، و زیر امنیت درگاه سوئیچ و جداسازی کارخواه‌های بی‌سیم می‌رود. تونلی روی میزبان این چیدمان را هم نمی‌پوشاند، چون قاب‌های مهمان هرگز از پشته میزبان نمی‌گذرند.

این تفاوت با حالت NAT ارزش دارد که آشکارا گفته شود نه آنکه به عنوان تلویح رها شود. مهمان پل‌شده هرگاه ترافیکش باید از تونل استفاده کند به کارخواه خودش و اعتبارنامه‌های خودش نیاز دارد. جایی که مهمان باید برای شبکه محلی نادیدنی بماند، NAT یا شبکه‌ای فقط درونی با مسیریابی کنترل‌شده طراحی بهتری است.

چرا مهمان نمی‌تواند دروازه میزبان باشد

وام دادن تونل مهمان به میزبان هیچ کلید پشتیبانی‌شده‌ای در هیچ‌یک از دو ابرناظر بزرگ ندارد. میزبان هیچ مسیری به تونل مهمان و هیچ قاعده ترجمه‌ای که به آن اشاره کند ندارد، پس ترافیک مهمان و میزبان جریان‌هایی جدا با مالکان جدا می‌مانند. این جهت صرف‌نظر از حالت آداپتور شکست می‌خورد.

جانشین‌های کارآمد ارجاع‌ها و پیشکارها هستند. ارجاع محلی SSH به میزبان اجازه می‌دهد به لوپ‌بک خودش وصل شود در حالی که مهمان جریان را به تونل می‌برد، و این خدمات TCP را بدون نصب کارخواه دوم می‌پوشاند. واداشتن ترافیک IP خود میزبان به استفاده از تونل مهمان به جای آن به مسیریابی درون مهمان نیاز دارد به همراه مسیری صریح روی میزبان و ترجمه روی میزبان. این یک طراحی شبکه کوچک است نه یک جعبه تیک، و به برنامه‌ای برای مسیر بازگشت نیاز دارد. وقتی مهمان فقط برای اجرای کارخواه وجود دارد، کارخواه را روی میزبان بگذار و گام اضافی را حذف کن.

ssh -N -f -L 8080:internal-host.example:80 user@lab-vm

تحلیلگرها و مسیرها از مرز عبور نمی‌کنند

DNS از آداپتوری پیروی می‌کند که گزینه را دریافت کرده، پس مهمان تحلیلگر تونل میزبان را به ارث نمی‌برد و میزبان هرگز کارساز فرستاده‌شده به مهمان را نمی‌داند. مقادیر dhcp-option DNS فرستاده‌شده برای واسطی اعتبار دارند که آنها را پذیرفته، و به همین دلیل مهمان پل‌شده بدون کارخواه نمی‌تواند نام‌های درونی را تحلیل کند. مهمان NAT معمولاً به جای آن از مدیریت DNS ابرناظر استفاده می‌کند، و تفاوت در یک فرمان برای هر محیط دیده می‌شود.

# on the host
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
# inside a Linux guest
ip -4 route
resolvectl status
# inside a Windows guest
Get-DnsClientServerAddress

تحلیلگر و مسیر را درون مهمان بخوان پیش از آنکه فرض کنی یکی از آنها از میزبان پیروی می‌کند. تحلیلگر تونل را وقتی نام‌های درونی باید همان‌جا تحلیل شوند به آداپتور خود مهمان بیفزا، سپس با نامی که فقط پشت تونل وجود دارد بررسی کن. حالت آداپتور، مالک تونل و منبع تحلیلگر را برای هر ماشین مجازی ثبت کن، چون این سه واقعیت تقریباً به هر پرسش بعدی پاسخ می‌دهند. ابرناظرهای دیگر نام حالت‌ها را عوض می‌کنند و اصل را دست‌نخورده می‌گذارند.