Использование WireGuard VPN при подключении к сторонним сетям, например, в отелях, может сопровождаться неприятными сбоями: периодической недоступностью локальных ресурсов, проблемами с разрешением имен или отключением блокировщиков рекламы. Часто пользователи ошибочно полагают, что проблема кроется в самом VPN-туннеле, однако причина нередко кроется в совпадении диапазонов IP-адресов домашней и гостевой сетей.
Почему возникает конфликт адресов
Большинство домашних роутеров используют стандартные диапазоны адресов, такие как 192.168.0.x, 192.168.1.x или настройки, предустановленные производителем (например, 192.168.4.0/22). Когда вы подключаетесь к Wi-Fi сети отеля или используете туристический роутер с аналогичной конфигурацией, возникает конфликт маршрутизации. Ваша операционная система получает два пути для одного и того же диапазона адресов.
В ходе тестов с использованием Windows 11 и WireGuard в режиме раздельного туннелирования выяснилось, что при совпадении префиксов системная таблица маршрутизации может отдавать предпочтение локальному соединению, если его метрика оказывается выгоднее, или наоборот. Если сеть отеля использует более специфическую маску подсети (например, /24 внутри вашего домашнего /22), система будет пытаться обращаться к ресурсам отеля напрямую, прежде чем отправить запрос через VPN-туннель. Это приводит к тому, что соединения с «домашними» IP-адресами обрываются или перехватываются устройствами, находящимися в одной сети с вами.
Особенности сбоев при работе с DNS
Особую опасность представляет совпадение IP-адреса вашего домашнего DNS-сервера с адресом оборудования в гостевой сети. В экспериментах автора при использовании общего DNS-сервера Technitium, запросы часто перехватывались туристическим роутером GL.iNet Mudi 7, так как тот физически находился в той же подсети. В результате браузер мог загружать публичные сайты, но локальные доменные имена переставали разрешаться, а правила фильтрации трафика переставали действовать, так как запросы уходили не в туннель, а в локальную сеть отеля.
Как устранить проблемы с маршрутизацией
Существует несколько способов решения проблемы, от временных «костылей» до радикальной перенастройки сети.
Добавление специфических маршрутов
Самый быстрый способ — добавление хостовых маршрутов с маской /32 в конфигурацию WireGuard (параметр AllowedIPs). Маршрут /32 является максимально специфическим, поэтому он всегда будет приоритетнее, чем общая подсеть /24 или /22. Добавление адресов вашего DNS-сервера и критически важных узлов (например, 192.168.4.61/32) позволит «пробросить» их через туннель, игнорируя локальные конфликты.
Смена диапазона домашней сети
Единственный надежный метод — изменение IP-диапазона вашей домашней сети. Рекомендуется выбрать нестандартный диапазон из частной подсети 10.0.0.0/8, используя случайные значения для третьего октета. Это поможет избежать пересечений с заводскими настройками большинства роутеров, которые вы можете встретить в путешествиях. Переход на сеть, например, 10.73.19.0/24, полностью исключает риск коллизий.
Дополнительные советы
Если вы используете WireGuard на базе контейнеров (например, в Proxmox), убедитесь, что роутер не помечает устройство как «оффлайн» из-за отсутствия активности, что может привести к сбросу правил проброса портов. Периодические пинг-запросы (раз в 20 секунд) помогут поддерживать соединение активным. Если вы уже находитесь в поездке и не можете сменить настройки роутера, проверьте IP-адрес вашего текущего Wi-Fi соединения и добавьте критически важные хосты в исключения с маской /32 в конфигурации VPN-клиента.
Почему «здоровый» туннель не гарантирует доступность ресурсов
Важно понимать, что при таких конфликтах соединение WireGuard может оставаться стабильным: рукопожатие (handshake) остается «свежим», туннель не разрывается, а NAS корректно отвечает на запросы. Проблема носит избирательный характер: одни сервисы могут работать нормально, другие — требовать повторной попытки подключения, а часть функций (например, блокировка рекламы) просто перестает работать. Это создает обманчивое впечатление, что VPN исправен, а сбоят сами целевые узлы.
Особенности поведения Windows при конфликте маршрутов
В ходе тестов с Windows 11 и WireGuard в режиме split-tunneling выяснилось, что система ведет себя по-разному в зависимости от того, как соотносятся маски подсетей:
- При одинаковых размерах сети (например, обе /22): Windows видит два пути для одного диапазона. Она выбирает маршрут с меньшей метрикой. В экспериментах туннель имел метрику 5 против 286 у Wi-Fi, поэтому запросы уходили через VPN. Однако это лишало пользователя доступа к ресурсам отеля в этом же диапазоне.
- При более узкой сети отеля (/24 внутри домашнего /22): Здесь проявляется коварство системы. Windows пытается сначала обратиться к локальной сети отеля. Если устройство не отвечает (ARP-запрос провальный), система помечает этот узел как недоступный, и только после этого происходит переключение на туннель. Именно поэтому сбои кажутся «плавающими»: первый пакет теряется, а второй — проходит.
- Когда в сети отеля есть устройство с нужным IP: Если в отеле физически присутствует устройство с тем же IP, что и ваш домашний сервер, Windows будет направлять трафик на него. Например, при назначении iPhone статического IP 192.168.4.64, тестовый ноутбук направлял пакеты на телефон вместо домашнего сервера. При этом TTL (time-to-live) пакетов составлял 64, в то время как через туннель он был равен 63, что доказывает прямое взаимодействие с локальным «враждебным» устройством.
Специфика DNS: почему это самый незаметный сбой
Наиболее критичный сценарий — когда адрес вашего домашнего DNS-сервера совпадает с IP-адресом шлюза в отеле. В тестах это был адрес 192.168.4.61. Поскольку туристические роутеры почти всегда активны в своей сети, все DNS-запросы перехватывались «отельным» оборудованием. Это приводило к тому, что:
- Публичные сайты загружались исправно, создавая иллюзию рабочего интернета.
- Внутренние доменные имена лаборатории не резолвились, возвращая пустой ответ.
- Сторонние домены, которые должны были блокироваться через Technitium, внезапно начали отдавать реальные AWS-адреса, так как запросы уходили мимо туннеля.
Интересно, что системный резолвер Windows иногда опрашивает оба адаптера. Если туннель отвечал быстро, система принимала верный ответ, но приложения, обращающиеся к DNS-серверу напрямую, получали данные от роутера отеля.
Нюансы хостинга WireGuard за Eero
В процессе отладки выяснилось, что препятствием может стать и домашнее оборудование. Если WireGuard-сервер запущен в контейнере Proxmox, роутер (например, Eero) может перестать направлять пакеты на порт, если сочтет контейнер «оффлайн» из-за отсутствия активности. При этом порт в приложении роутера остается открытым. Помогает либо перевод контейнера на DHCP с резервированием, либо настройка автоматического «пинга» каждые 20 секунд, чтобы роутер видел активность хоста.
Рекомендации по безопасности конфигурации
Помимо очевидной смены домашнего диапазона, стоит учитывать, что принудительное назначение хостовых маршрутов (/32) — это лишь временная мера («заплатка»). Она защищает только те IP, которые вы внесли вручную. Если вы путешествуете часто, единственный способ обезопасить себя — заранее отказаться от стандартных «заводских» диапазонов (вроде 192.168.0.x или 192.168.4.x), так как именно они чаще всего используются в отельном бизнесе и на туристических роутерах. Если вы уже в дороге и столкнулись с подобным — сравните IP-адрес вашего Wi-Fi шлюза с диапазоном домашней сети и добавьте адрес критически важного DNS-сервера как /32 в AllowedIPs.
