NAT срещу мостов режим на VM мрежата: кой пренася VPN трафика?
NAT гостите заемат тунела на хоста само ако клиентът тунелира по маршрут; мостовите гости се маршрутизират сами. Тествайте госта, после изберете подходящия режим.
Мостовият режим и NAT не са два начина да свържете един и същ гост към вашата VPN; те решават чии са пакетите на госта, преди да е замесен какъвто и да е тунел . В режим NAT хипервизорът пренаписва трафика на госта и го излъчва от код на страната на хоста, така че гостът се движи по маршрута, който хостът даде на този код. В мостов режим гостът получава собствена идентичност на каналния слой във физическия сегмент и избира свой шлюз по подразбиране, което прави тунела на хоста без значение за него, освен ако рутерът на LAN не е този, който прави тунела. Спрях да приемам VM като част от VPN и започнах да гледам на това като на въпрос къде сочи маршрутът по подразбиране на госта. Тестът по-долу отнема няколко минути на режим и го решава без догадки.
NAT държи госта зад кода на хипервизора, където важат маршрутите на хоста
Във VirtualBox NAT гостът седи на 10.0.2.0/24 с виртуален шлюз 10.0.2.2, DNS прокси 10.0.2.3 и без собствен маршрут към физическата мрежа. Изходящите пакети се поемат от NAT машината, пренаписват се така, че източникът да е хостът, и се подават към IP стека на хоста. Оттам трафикът на госта е поток на хоста и търсенето на маршрут е по местоназначение: клиент с пълен тунел, който инсталира 0.0.0.0/1 и 128.0.0.0/1 на хоста, го прихваща, без изобщо да знае, че съществува VM. Главата за мрежи на VirtualBox от Oracle изброява тези стойности по подразбиране, ако искате да потвърдите адресите във вашата инсталация.
Мрежата по подразбиране на libvirt стига до същото място от 192.168.122.0/24, където dnsmasq раздава наеми, а хостът маскира подмрежата, така че пакетите на госта отново стигат до маршрутното решение на хоста. Изключението е клиент, който избира трафика по процес, а не по маршрут. Ако списъкът за разделен тунел съдържа само браузъра ви, NAT машината не е в този списък и гостът напуска машината без тунел, докато браузърът на хоста все още изглежда покрит. Същата подмрежа, обратен резултат.
Мостовият режим дава на госта собствено място във физическата LAN
На мостовия гост се дава виртуална NIC, свързана към реален адаптер, получава собствен MAC адрес и взема DHCP наем от физическата мрежа. Шлюзът му по подразбиране е рутерът на LAN, не хипервизорът, и кадрите му излизат по кабела през този адаптер. Тунелните маршрути на хоста живеят в таблицата на хоста и никога не се питат, защото кадрите на госта никога не влизат в IP стека на хоста.
Това реже и в двете посоки. mDNS и SMB разглеждането започват да работят, защото гостът вижда broadcast трафика на LAN, и гостът става достъпен от други машини в същия сегмент без защитна стена на хоста между тях. Мостът също не е начин да прокарате гост през съществуващ тунел: свързването на VM към интерфейса WireGuard или OpenVPN на хоста не е нещо, което VirtualBox или libvirt прави вместо вас. Ако мостов гост трябва да бъде тунелиран, тунелът трябва да завърши някъде в тази LAN.
Тестът, който прекратява спора
Изпълнете същите проверки в двата режима и запишете отговорите:
- На хоста
curl -s https://ifconfig.meдава публичния v4 адрес. - В госта същата команда, плюс
ip routeв Linux илиGet-NetRoute -DestinationPrefix 0.0.0.0/0в Windows за шлюза по подразбиране. - Идентичност на резолвера:
resolvectl statusилиcat /etc/resolv.confв госта, за да видите дали сочи към 10.0.2.3 или към сървър в LAN. - Семейство адреси:
ip -6 addr show scope globalи една v6 заявка, защото v4 тунел не казва нищо за глобален v6 адрес, който гостът може да има.
Съвпадащи публични адреси означават, че гостът е по пътя на хоста. Гостов адрес, който съвпада с обичайния изход на LAN, означава, че не е. Стъпката, която хората пропускат, е контролата: спрете тунела на хоста и повторете заявката от госта. Ако гостът продължава да разглежда, той никога не е зависел от тунела на хоста, каквото и да подсказва името на режима. В режим NAT гостът трябва да загуби интернет при спрян тунел на хоста, освен ако клиентът не е настроен да допуска трафик извън тунела, което си струва да се знае само по себе си.
Два сигнала лъжат. Успешният ping доказва достъпност, не изходен път. И DNS може да бъде отговорен от проксито 10.0.2.3 през резолвера на хоста, докато TCP поема друг маршрут, и така получавате страница, която се зарежда, и вход, който никога не завършва.
Кой режим пасва на задачата
Режимът е маршрутно решение, затова го избирайте от изискването, а не от навика:
| Requirement | Mode that fits |
|---|---|
| Every guest flow must exit through the host tunnel | NAT, with a host client that tunnels by route, verified from inside the guest |
| The guest needs its own VPN account or profile | Bridged, or NAT with a client running inside the guest, not both |
| The guest must serve SSH, SMB, or a dev server to the LAN | Bridged; NAT needs a port forward, which does not change the outbound path |
| The guest must stay invisible to the LAN | NAT; a bridged guest is another host on the segment |
| The guest needs a real public IPv6 address | Bridged; VirtualBox NAT mode has no IPv6 forwarding |
| Isolation from the LAN with access to the host | Host-only adapter, not NAT |
Първият ред е където хората се хващат: NAT плюс клиент с пълен тунел на хоста наистина покрива гост, но само докато клиентът тунелира по маршрут и връзката на хоста е този тунел. Преместете клиента в списък само за браузър и покритието изчезва без никаква грешка. Четвъртият ред е обратната грешка: гост, мостнат за удобство, тихо започва да отговаря на SMB или SSH в офис LAN.
Провали, които се преписват на VPN
В Windows NAT транслацията работи вътре в процеса на VirtualBox VM, затова клиент за отделни приложения се нуждае точно от този образ в списъка си, а не от общо правило за виртуални машини. Когато актуализация на клиента преизгради списъка с разрешени процеси, NAT гостите губят покритие първи и докладът изглежда като VM, който стига до LAN, но не до интернет, докато хостът е добре.
Мост към Wi-Fi е другата класика. Точките за достъп рядко препращат кадри с чужд изходен MAC, така че мост към wlan0 или се проваля напълно, или работи, докато изолацията на клиенти в точката започне да го изхвърля. VirtualBox все още ще предлага безжичния адаптер в списъка си. Ако хостът е на Wi-Fi и гостът трябва да е мостнат, планирайте тест, вместо да го предполагате.
MTU е третият. Мостовият гост запазва MTU на LAN от 1500 байта и ако пусне собствен WireGuard клиент на 1420, големите TLS ръкостискания забиват, докато малките заявки минават. Под NAT MTU на тунела на хоста е проблем на хоста, но гостът все още вярва в 1500 и UDP с бит „не фрагментирай“ попада в същата черна дупка.
Запишете режима, после проверете отново след всяка смяна на адаптер
Запишете режима, интерфейса на хоста, който мостът използва, шлюза по подразбиране на госта, неговия резолвер и неговите v4 и v6 изходни адреси. Този запис прави следващия провал евтин: когато лаптоп премине от док към Wi-Fi, мостовият гост следва моста към друг физически адаптер и може да вземе наем в друга подмрежа, докато NAT гостът запазва адреса си 10.0.2.x и тихо наследява друга връзка.
Преди да затворите тикета, потвърдете всяко от тези:
- Изходният адрес на госта се различава от изходния адрес на хоста, значи не е в тунела на хоста.
- Резолверът е проксито 10.0.2.3 или сървър в LAN и знаете кой е отговорил.
- В госта няма глобален v6 адрес, ако дизайнът на тунела е само v4.
- При спрян тунел на хоста гостът спира да разглежда, или вече знаете, че никога не е зависел от него.
- Гостът не вижда broadcast трафик на LAN, който не би трябвало да вижда.