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 му дава наем и мрежата го третира като отделен хост. Всеки гост зад мост може да държи независим тунел със свой маршрут по подразбиране, а таблицата на хоста никога не се променя. Цената е изложеност: гостът отговаря на broadcast, появява се в таблиците на съседите и попада под сигурността на портовете на комутатора и изолацията на безжичните клиенти. Тунел на хоста също не покрива тази схема, защото кадрите на госта никога не минават през стека на хоста.

Тази разлика спрямо случая с NAT заслужава да се каже направо, вместо да се остави като намек. Гостът зад мост се нуждае от собствен клиент и собствени идентификационни данни, когато трафикът му трябва да минава през тунел. Там, където гостът трябва да остане невидим за локалната мрежа, NAT или мрежа само за вътрешно ползване с контролирано маршрутизиране е по-добрият дизайн.

Защо гостът не може да бъде шлюз на хоста

Даването на тунела на гост на хоста няма поддържан превключвател в нито един от двата големи хипервизора. Хостът няма маршрут към тунела на госта и правило за транслация, което да сочи към него, затова трафикът на госта и хоста остават отделни потоци с отделни собственици. Тази посока не работи независимо от режима на адаптера.

Работещите заместители са пренасочвания и проксита. Локално SSH пренасочване позволява на хоста да се свърже със собствения си loopback, докато гостът носи потока в тунела, което покрива 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

Прочети резолвера и маршрута вътре в госта, преди да приемеш, че някой от тях следва хоста. Добави резолвера на тунела към собствения адаптер на госта, когато вътрешни имена трябва да се разрешават там, после провери с име, което съществува само зад тунела. Записвай режима на адаптера, собственика на тунела и източника на резолвера за всяка виртуална машина, защото тези три факта отговарят на почти всеки следващ въпрос. Другите хипервизори преименуват режимите и оставят принципа непокътнат.