Запускати VPN на хості чи всередині VM? Настанови щодо рішення

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

Визначте власника, перш ніж торкатися клієнта

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

Три питання зазвичай вибирають розміщення за вас. Чи має трафік гостьової системи витримати корпоративний клієнт на хості? Тоді тунель у гостьовій системі. Чи потрібні кільком гостьовим системам одні облікові дані й одна адреса виходу? Тоді він на хості, з навмисно налаштованим пересиланням. Чи має трафік гостьової системи залишатися повністю поза VPN хоста? Тоді тунель у гостьовій системі — єдина схема, яка дає це самою конструкцією.

Запишіть відповідь одним рядком біля імені VM: guest-owned або host-owned. У лабораторії з шести машин ця нотатка економить більше часу, ніж будь-який крок нижче, бо не дає вам шукати несправність у тунелі, якого ніколи не було в машині, до якої ви увійшли.

WSL1 і WSL2 — протилежні випадки

WSL1 не є віртуальною машиною, тому питання розміщення здебільшого зникає. Його двійкові файли Linux працюють поверх мережевого стеку Windows через шар трансляції, і клієнт VPN для Linux не має незалежних інтерфейсів для налаштування. Працює схема з тунелем на боці Windows, коли дистрибутив використовує результат, нічим не володіючи.

WSL2 — навпаки. Він запускає справжнє ядро в легкій допоміжній VM за віртуальним комутатором Hyper-V, а його адресний простір транслюється через NAT адаптером на боці хоста. Тому клієнт Linux усередині дистрибутива поводиться як на фізичній машині Linux: створює tun0 або wg0, встановлює власні маршрути і працює. Відмова живе на боці хоста. Коли клієнт VPN для Windows підключається з політикою, що блокує трафік у локальних мережах, він вважає підмережу WSL2 недовіреною локальною мережею і обриває шлях NAT. Тоді дистрибутив втрачає DNS і зовнішній доступ, хоча його власний тунель ще здоровий: wg show повідомляє про рукостискання, ip route виглядає правильно, а curl зависає.

Яке виправлення ви можете використати, залежить від збірки Windows. Старіше — виняток у клієнті хоста для підмережі WSL, доданий у налаштуваннях локальної мережі або розділеного тунелю клієнта. Новіше, у збірках Windows 11, які його підтримують, — дзеркальна мережа: поставте networkingMode=mirrored у розділ [wsl2] файлу %UserProfile%\.wslconfig, виконайте wsl --shutdown, і дистрибутив ділитиме інтерфейси хоста замість приватної підмережі NAT. Дзеркальний режим також змінює поведінку localhost і вхідних портів, тому ставтеся до нього як до міграції, а не як до перемикача.

NAT, міст і що хост може бачити

Під NAT пакети тунелю гостьової системи адресуються публічній адресі сервера VPN і виходять через адаптер хоста як зашифрований UDP або TCP. Хост бачить один потік і кількість його байтів, нічого про призначення всередині. Під мостовим адаптером гостьова система має власну ідентичність рівня 2 у фізичній LAN, бере власну оренду DHCP і для будь-якої політики на основі MAC виглядає як другий пристрій. Жоден із режимів не дозволяє хосту читати корисне навантаження тунелю; мостова гостьова система просто значно помітніша для мережі навколо неї.

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

Настанова: розмістіть, налаштуйте, доведіть

Виконайте ці чотири перевірки по черзі в новій оболонці гостьової системи і зупиніться на першій, яка не збігається із записаним власником.

1. ip route get 1.1.1.1, що повертає tun0 або wg0, означає власність гостьової системи, а eth0 з приватнимо наступним кроком означає власність хоста.
2. resolvectl query example.com, або прочитайте /etc/resolv.conf там, де гостьова система не запускає службу розв'язувача. Тунель, який несе трафік, але не DNS, — найпоширеніший наполовину налаштований стан.
3. Порівняйте виходи: curl -4 -s https://ifconfig.me у гостьовій системі проти curl.exe -4 -s https://ifconfig.me на хості. Різні адреси означають, що тунелем володіє гостьова система, а хост у VPN із гостьовою системою, що показує домашнього провайдера, — це випадок, коли нічого не успадковано.
4. Повторіть обидва з -6. Тунель лише для v4 пропускає v6, якщо клієнт його не блокує або не маршрутизує, і багато клієнтів за замовчуванням залишають v6 на фізичному інтерфейсі.

У схемі зі шлюзом на хості, де кілька гостьових систем ділять один тунель, хост має пересилати й транслювати. На хості Linux це три частини, і гостьова система тихо повертається до свого звичайного маршруту, коли якоїсь бракує:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
iptables -A FORWARD -i virbr0 -o wg0 -j ACCEPT
iptables -A FORWARD -i wg0 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT

На боці WireGuard AllowedIPs партнера хоста має містити підмережу гостьових систем, наприклад 192.168.122.0/24, інакше зворотні пакети ніколи не прийдуть, і налаштування виглядатиме як проблема брандмауера. Хост Windows досягає того самого результату через спільний доступ до підключення до Інтернету або правило NAT на комутаторі Hyper-V і потребує тієї самої перевірки зворотного шляху.

Коли схема ще відкрита, ця таблиця охоплює найчастіші варіанти:

Два тунелі, дві гостьові системи й конфлікти між ними

Коли потрібні два виходи одночасно, схема, що тримається, — один тунель на гостьову систему. Кожна VM зберігає свій маршрут за замовчуванням і свій розв'язувач, хост залишається у звичайній мережі, і два тунелі ніколи не сперечаються за ту саму таблицю маршрутизації. Об'єднання двох гостьових систем мостом теж не зливає їхні маршрути: віртуальна мережа дає шлях, і кожному клієнту все ще треба сказати, що цей локальний трафік може обходити тунель.

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

Перевірте, а потім залиште відновлення власнику

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

Відновлення також належить власнику. Тунель, що належить гостьовій системі, відновлюється власним клієнтом гостьової системи та маршрутами, які він записав. Схема, що належить хосту, відновлюється послідовністю завантаження хоста, а правила пересилання не переживуть перезавантаження, якщо їх знову не застосує unit або завдання запуску. Відновлений знімок — це розгортання, а не скасування, бо він повертає старі облікові дані та старі маршрути разом із диском. Перш ніж оголосити роботу завершеною, підтвердьте, що власник досі відповідає записаному рядку, що DNS і обидві родини адрес розв'язуються всередині гостьової системи, що мертвий тунель залишає працездатну мережу замість чорної діри, і що перезавантаження або відновлення знімка відтворює той самий стан.