Запускать 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 и оба семейства адресов разрешаются внутри гостя, что мёртвый туннель оставляет работоспособную сеть вместо чёрной дыры и что перезагрузка или восстановление снимка воспроизводят то же состояние.