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

Прочитайте резолвер і маршрут усередині гостьової системи, перш ніж припускати, що щось із цього йде за хостом. Додайте резолвер тунелю до власного адаптера гостьової системи, коли внутрішні імена мають розв'язуватися саме там, і перевірте іменем, що існує лише за тунелем. Записуйте режим адаптера, власника тунелю й джерело резолвера для кожної віртуальної машини, бо ці три факти відповідають майже на будь-яке подальше питання. Інші гіпервізори перейменовують режими й залишають принцип незмінним.