Как стандартный диапазон IP домашнего роутера незаметно ломает WireGuard VPN

Подробности изложены в материале первоисточника. Мой VPN-туннель WireGuard выглядел полностью стабильным: соединение не обрывалось, сетевое хранилище отзывалось, однако локальные хосты периодически переставали резолвиться, блокировка рекламы отключалась, а некоторые сервисы срабатывали только со второй попытки. Проблема кроется в пересечении подсетей домашнего оборудования и публичных сетей в поездках. Ссылка на оригинальный материал поможет детально изучить этот технический кейс.

Для проверки этой гипотезы я развернул тестовый дорожный роутер в качестве импровизированной отельной точки доступа и собрал подробные логи сетевой активности через PowerShell. Поведение операционной системы Windows при совпадении IP-адресов оказалось весьма специфическим и неочевидным.

Эмуляция отельной сети и сбор данных

В роли стенда выступил дорожный маршрутизатор GL.iNet Mudi 7, работающий через сотовую сеть и пропускающий весь трафик через интернет. Я настроил его локальную сеть на диапазон 192.168.4.61 — ровно по этому адресу дома располагается мой DNS-сервер Technitium. Дома за работу VPN отвечает небольшой контейнер на Proxmox. Тестовый ноутбук под управлением Windows 11 использовал официальный клиент WireGuard в режиме раздельного туннелирования, перенаправляя подсеть 192.168.4.0/22 в туннель и задействуя домашний IP для DNS-запросов. Специальный скрипт фиксировал таблицы маршрутизации, ARP-таблицы, доступность хостов и ответы DNS-сервера.

Проблемы с самим VPN-сервером до тестов сети

Прежде чем приступить к основным испытаниям, мне пришлось разобраться со странным поведением собственного домашнего роутера eero. Туннель поднимался примерно на три минуты, после чего сервер полностью переставал принимать входящие пакеты. Дамп трафика на контейнере показывал абсолютный ноль на порту WireGuard, хотя правило перенаправления портов в мобильном приложении eero оставалось активным. Как выяснилось, eero поддерживает форвардинг только для устройств, которые считает активными в текущий момент. Статически настроенный контейнер без регулярного сетевого обмена быстро получает статус оффлайн. Перевод контейнера на DHCP с постоянным резервированием адреса помог частично, но окончательным решением стала отправка простых пингов каждые 20 секунд для поддержания активности.

Взаимодействие сетей одинакового размера

При совпадении префиксов и одинаковых размерах подсетей /22 я ожидал тривиального сбоя, когда локальная сеть побеждает и домашние ресурсы становятся недоступными. Однако логика Windows работает иначе: система анализирует две идентичные дороги и при равенстве префиксов отдает приоритет маршруту с меньшей метрикой. Эффективная метрика туннеля составила 5 против 286 у Wi-Fi, поэтому весь домашний трафик пошел через WireGuard. Моя NAS корректно ответила на порту 5000, а DNS-запросы обрабатывал Technitium, создавая полное ощущение присутствия дома. Негативный эффект проявился на стороне гостиничного оборудования: его собственные устройства в том же диапазоне оказались полностью недоступны с моего ноутбука, что создало бы проблему при попытке авторизоваться через отельный портал captive portal.

Поведение при уменьшении отельной подсети до /24

Когда я сузил отельную сеть до /24 внутри домашнего диапазона /22, ситуация изменилась. Более специфичный маршрут в теории всегда имеет приоритет, поэтому запросы к IP вроде 192.168.4.x должны были уходить в локальный Wi-Fi и падать. Тем не менее, Windows ведет себя умнее: сначала система проверяет Wi-Fi, и если ARP-запрос остается без ответа, помечает соседа недоступным и перенаправляет трафик в туннель. Пинг-тесты зафиксировали эту последовательность воочию: первый ответ выдавал ошибку о недоступности хоста прямо с ноутбука, затем следовали два таймаута, после чего приходил успешный ответ от моего сервера через VPN. Именно поэтому неполадка воспринимается как плавающая.

Чтобы подтвердить этот сценарий, я назначил своему iPhone статический адрес 192.168.4.64 на дорожном маршрутизаторе. В этот момент Windows мгновенно перенаправила трафик к серверу Caddy на этот телефон, TCP-соединение разорвалось, а TTL в ответах пинга изменился. При этом сетевое хранилище на другом адресе продолжало функционировать стабильно, поскольку гостиничная подсеть его не затрагивала.

Скрытые сбои в разрешении DNS-имен

Самым незаметным элементом проблемы стали DNS-запросы. Поскольку адрес моего домашнего сервера совпал с IP отельного маршрутизатора, любые запросы к Technitium улетали по Wi-Fi на дорожное устройство. Публичные сайты продолжали открываться, маскируя проблему, но локальные домены лаборатории выдавали пустые ответы, а служебный домен телеметрии разрешался на реальные адреса AWS. Логи DNS-сервера подтвердили отсутствие входящих обращений из туннеля. При этом приложения, использующие системный резолвер Windows, работали нормально, а запросы, отправленные напрямую к DNS-серверу, тихо терялись.

Способы решения: от временных мер до кардинальных

Для быстрого исправления ситуации можно прописать точечные маршруты /32 в конфигурации WireGuard. Поскольку хостовый маршрут является наиболее специфичным, он гарантированно перекрывает отельную подсеть /24. Добавив принудительные правила для критически важных IP-адресов рядом с основным префиксом, удается вернуть стабильный доступ к серверу имен и внутренним службам. Тем не менее, это ручной метод, требующий постоянной корректировки под новые условия.

Единственным по-настоящему надежным методом является полный отказ от стандартных диапазонов адресов в домашней сети. Перенос маршрутизатора на редкую подсеть полностью исключает любые пересечения с типовыми заводскими настройками оборудования. Стоит избегать распространенных сетей и уделить особое внимание расположению DNS-сервера, так как именно этот узел чаще всего становится первой жертвой сетевых коллизий.