Мережа ВМ у режимі NAT чи bridged: що пропускає трафік VPN?
Гості в NAT позичають тунель хоста лише тоді, коли клієнт тунелює за маршрутом; гості в bridged маршрутизують самі. Перевірте гостьову систему і виберіть режим під задачу.
Bridged і NAT — не два способи під'єднати ту саму гостьову систему до вашого VPN; вони вирішують, кому належать пакети гостьової системи ще до того, як з'явиться будь-який тунель. У режимі NAT гіпервізор переписує трафік гостьової системи й випускає його з коду на боці хоста, тож гостя йде тим маршрутом, який хост дає цьому коду. У режимі bridged гостьова система отримує власну ідентичність канального рівня на фізичному сегменті й обирає власний шлюз за замовчуванням, через що тунель хоста для неї не має значення, якщо тільки тунелюванням не займається сам маршрутизатор LAN. Я перестав вважати ВМ такою, що перебуває у 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 на хості, перехоплює його, навіть не знаючи, що ВМ існує. Розділ Oracle про мережі у VirtualBox перелічує ці значення за замовчуванням, якщо ви хочете звірити адреси у своїй збірці.
Мережа libvirt за замовчуванням приводить туди ж із 192.168.122.0/24, де dnsmasq видає оренди, а хост маскує підмережу, тож пакети гостьової системи знову доходять до рішення про маршрутизацію на хості. Виняток — клієнт, який вибирає трафік за процесом, а не за маршрутом. Якщо список роздільного тунелювання містить лише ваш браузер, механізму NAT у цьому списку немає, і гостьова система покидає машину без тунелю, поки браузер на хості все ще виглядає захищеним. Та сама підмережа, протилежний результат.
Bridged дає гостьовій системі власне місце у фізичній LAN
Гостьова система в bridged отримує віртуальний мережевий адаптер, під'єднаний до реального, власну MAC-адресу й оренду DHCP із фізичної мережі. Її шлюз за замовчуванням — маршрутизатор LAN, а не гіпервізор, і її кадри виходять у провід через цей адаптер. Тунельні маршрути хоста лежать у таблиці хоста і ніколи не запитуються, бо кадри гостьової системи не потрапляють до стеку IP хоста.
Це працює в обидва боки. Перегляд mDNS і SMB починає працювати, бо гостьова система бачить широкомовний трафік LAN, і вона стає доступною з інших машин того самого сегмента без брандмауера хоста посередині. Bridging — це ще й не спосіб проштовхнути гостьову систему через наявний тунель: під'єднати ВМ до інтерфейсу WireGuard або OpenVPN хоста за вас не стане ні VirtualBox, ні libvirt. Якщо гостьову систему в bridged треба тунелювати, тунель має закінчуватися десь у цій 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 плюс клієнт із повним тунелем на хості справді покриває гостьову систему, але лише поки клієнт тунелює за маршрутом і висхідний канал хоста — це той самий тунель. Переведіть клієнт на список дозволених лише для браузера, і покриття зникне без жодної помилки будь-де. Четвертий рядок — зворотна помилка: гостьова система в bridged заради зручності, яка тихо починає відповідати на SMB або SSH в офісній LAN.
Збої, які валять на VPN
У Windows трансляція NAT виконується всередині процесу ВМ VirtualBox, тож клієнту за застосунками потрібен саме цей образ у списку, а не загальне правило для віртуальних машин. Коли оновлення клієнта перебудовує список дозволених процесів, гостьові системи NAT першими втрачають покриття, і звіт звучить як ВМ, що дістає до LAN, але не до інтернету, поки хост у порядку.
Bridging у Wi-Fi — інша класика. Точки доступу рідко пересилають кадри з чужим MAC-адресою джерела, тож міст на wlan0 або одразу не працює, або працює, поки ізоляція клієнтів на точці доступу не почне його відкидати. VirtualBox усе одно запропонує бездротовий адаптер у списку. Якщо хост у Wi-Fi, а гостьову систему треба зробити bridged, плануйте перевірку, а не покладайтеся на припущення.
MTU — третій. Гостьова система в bridged зберігає MTU LAN у 1500 байтів, і якщо в неї власний клієнт WireGuard на 1420, великі рукостискання TLS зупиняються, а дрібні запити проходять. Під NAT MTU тунелю хоста — турбота хоста, але гостьова система досі вірить у 1500, і UDP з увімкненим бітом don't-fragment іде в чорну діру так само.
Запишіть режим і перевірте знову після будь-якої зміни адаптера
Зафіксуйте режим, інтерфейс хоста, який використовує міст, шлюз за замовчуванням гостьової системи, її резолвер і адреси виходу v4 та v6. Саме цей запис робить наступний збій дешевим: коли ноутбук переїжджає з док-станції на Wi-Fi, гостьова система в bridged іде за мостом на інший фізичний адаптер і може отримати оренду в іншій підмережі, тоді як гостьова система NAT зберігає адресу 10.0.2.x і тихо успадковує інший висхідний канал.
Перш ніж закрити тікет, підтвердьте кожен із цих пунктів:
- Адреса виходу гостьової системи відрізняється від адреси виходу хоста, тобто вона не в тунелі хоста.
- Резолвер — це проксі 10.0.2.3 або сервер LAN, і ви знаєте, котрий із них відповів.
- У гостьовій системі немає глобальної адреси v6, якщо схема тунелю лише для v4.
- Коли тунель хоста опущено, гостьова система перестає відкривати сторінки — або ви тепер знаєте, що вона ніколи від нього не залежала.
- Гостьова система не бачить широкомовного трафіку LAN, якого їй бачити не потрібно.