VPN работает с ноутбука, но не с роутера: сравнение маршрутов по шагам

Два устройства обращаются к одному и тому же VPN-серверу. Ноутбук открывает страницы, пингует внутренние адреса и вообще ведёт себя образцово. Роутер рапортует о «подключении» или молчит, а клиенты за ним ничего полезного не получают. Первая реакция — сменить DNS, потом MTU, потом пересоздать туннель, потом всё сразу. После этого уже непонятно, что именно починило или сломало картину.

Лучше сделать иначе: положить рядом два пути пакета и искать место, где они расходятся. Ноутбук здесь работает как эталон. Он доказывает, что сервер жив, ключ принимается, порт доступен, а нужные ресурсы за туннелем существуют. Всё остальное — различия, и их конечное число. Ниже разбираем их по порядку, и после каждого шага меняем не больше одного параметра.

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

Два пути пакета рядом

Для начала нарисуем, как пакет идёт в обоих случаях.

Видно, что у роутера шагов больше: он одновременно участник туннеля и маршрутизатор для чужих устройств. Сломаться может каждое звено, поэтому порядок проверок важен. Начнём с самого раннего: дошёл ли пакет до сервера и признал ли тот отправителя.

Handshake и реальный обмен данными — не одно и то же

В WireGuard peer идентифицируется открытым ключом, и у каждого участника есть пара из закрытого и открытого ключа. Состояние показывает команда wg show; об этом сказано в WireGuard Quick Start. Именно с неё удобно начинать сравнение, потому что вывод на ноутбуке и на роутере (если на нём есть консоль или аналогичная страница статуса) читается одинаково.

Смотрим два признака: время последнего handshake и счётчики переданных и принятых байтов. Из них получается небольшая таблица случаев.

• Handshake нет, отправленные байты растут, принятых нет. Роутер шлёт пакеты, но сервер их не принимает или ответ не возвращается. Подозреваем неверный открытый ключ сервера в конфигурации роутера, неверный endpoint или порт, либо блокировку выше по цепочке. Сервер не знает открытый ключ роутера — тоже сюда: он отбрасывает пакеты от неизвестного peer молча.
• Handshake свежий, а байты почти не растут. Туннель поднят, но трафик в него не попадает. Это уже не про ключи, а про маршруты и политику на роутере.
• Handshake свежий, отправлено много, принято почти ничего. Пакеты уходят, а обратно ничего не приходит. Смотрим AllowedIPs на сервере и ответный путь.
• Handshake был один раз давно. Возможно, NAT забыл соответствие. Для таких случаев есть PersistentKeepalive: по документации он поддерживает состояние NAT, по умолчанию выключен и нужен не каждой конфигурации. Включать его стоит, если роутер сидит за NAT и сервер не может сам первым достучаться до него. Но как первое лекарство это не годится: сначала убедитесь, что handshake вообще когда-либо проходил.

Здесь же проверяем самую банальную причину. Ключи на ноутбуке и роутере должны быть разными. Если один и тот же закрытый ключ скопирован на оба устройства, сервер видит одного peer, который «прыгает» между двумя адресами. Endpoint у peer обновляется по корректно аутентифицированным пакетам (справка wg(8)), так что побеждает тот, кто написал последним. Ноутбук включили — роутер замолчал, и наоборот. Звучит как мистика, а на деле это один peer на двоих. Решение: отдельная пара ключей и отдельная запись peer для роутера.

Одна осторожность при сравнении конфигураций. Вывод wg showconf и машинный дамп могут содержать секреты, как отмечено в той же справке. Когда будете делиться выводом с коллегой или вставлять его в чат поддержки, замените закрытый ключ заглушкой. Сравнивать нужно открытые ключи и адреса, а закрытый ключ для сравнения не нужен.

Адреса: LAN, туннель и случайное пересечение

Если handshake проходит, переходим к адресам. У роутера в игре три разных сети: локальная сеть за ним, адрес самого туннеля и сети по ту сторону VPN. Ноутбук тоже живёт в какой-то локальной сети, но обычно она мешает меньше: ему нужно лишь не пересекаться с удалёнными подсетями. Роутер же не может «не пересекаться» — у него в LAN стоят десятки устройств.

Пример условный, для иллюстрации. Допустим, дома у роутера сеть 192.168.1.0/24, и в офисе за VPN тоже 192.168.1.0/24. Ноутбук в кафе имеет адрес из другой сети и спокойно ходит в офис. Роутер дома, получив пакет на 192.168.1.20, считает адрес локальным и отдаёт его в свой LAN, а не в туннель. Для него это не ошибка маршрутизации, а правильное поведение: локальный адрес ближе. Туннель живой, handshake свежий, а офисный сервер недостижим.

Лечится это не волшебной опцией, а честной развязкой адресных планов. Либо одна из сторон меняет подсеть, либо доступ строится через трансляцию адресов, и тогда придётся осознанно описать, какой диапазон «подменяет» какой. Сначала просто убедитесь, пересекаются ли сети: выпишите три диапазона в столбик и сравните.

Второй тип проблем — адрес самого туннеля. Сервер выдаёт каждому peer свой адрес внутри сети туннеля. Если у роутера и у ноутбука там одинаковый адрес, получаем конфликт того же рода, что и с общим ключом. Если же адрес роутера в конфигурации сервера записан в AllowedIPs другого peer, пакеты будут уходить не туда.

AllowedIPs: два смысла одного поля

По справке wg(8), AllowedIPs задаёт допустимые адреса входящего трафика от peer и одновременно направления исходящего; IPv4 и IPv6 перечисляются отдельно. Это поле работает сразу как фильтр и как маршрутная таблица, поэтому ошибка в нём бьёт в обе стороны.

Для роутера это важнее, чем для ноутбука. У ноутбука единственный источник пакетов — он сам, с адресом туннеля. У роутера источниками становятся устройства из LAN. Если трафик клиентов уходит в туннель без трансляции адресов, то исходящие пакеты несут адрес вроде 192.168.1.50. Сервер, у которого в AllowedIPs для роутера записан только адрес туннеля, отбросит такие пакеты как недопустимые. Handshake при этом идеален, самого роутера можно пинговать, а клиенты за ним не работают.

Тут два честных пути. Либо роутер транслирует адреса клиентов в собственный туннельный адрес, либо на сервере в AllowedIPs для этого peer добавляется подсеть LAN роутера (и сервер знает, как отвечать туда). Первый путь проще, второй нужен, когда ресурсам за VPN важно видеть настоящие адреса. Выбирайте один и меняйте на одной стороне за раз.

Ещё деталь: IPv4 и IPv6 в AllowedIPs перечисляются отдельно. Если на роутере туннельный маршрут есть только для IPv4, а клиент пробует IPv6 и получает ответ в обход туннеля, картина выглядит странно: часть сайтов открывается «не отсюда», часть вообще зависает. Тогда сравните два списка адресов и проверьте, что для IPv6 решение принято осознанно — либо он тоже идёт через VPN, либо отключён намеренно, а не по забывчивости.

Маршрут самого роутера и маршрут клиента — это два разных вопроса

Самая коварная ловушка в этой теме выглядит так: роутер считает туннель рабочим, при этом пинг с него самого до адреса за VPN успешен. Значит всё починено? Нет. Мы проверили путь, который начинается на роутере. Клиентский путь начинается на телефоне или ПК и проходит через правила, которые решают, кто идёт в туннель.

Многие роутеры не отправляют весь LAN в VPN по умолчанию. Они дают возможность привязать к VPN отдельные устройства, сегменты или списки назначений. На примере Keenetic это называется политикой подключения: согласно документации Keenetic, политика содержит выбранные подключения с приоритетами, к ней можно привязать зарегистрированное устройство или сегмент, а незарегистрированные устройства основных сегментов по умолчанию используют политику по умолчанию. Схожая логика встречается и у других производителей, но названия и интерфейс у всех свои, поэтому ищите не слово «политика», а ответ на вопрос: по какому правилу именно этот клиент выходит наружу?

Случай: роутер подключён, телефон не назначен

Разберём сценарий, который хорошо показывает разницу двух путей. Условный пример: на роутере поднят туннель, статус зелёный, handshake свежий. С самого роутера пинг до внутреннего адреса проходит. Ноутбук дома, подключённый к этому же роутеру по Wi-Fi, ходит туда же успешно, потому что его когда-то привязали к политике с VPN. А телефон жены не открывает ничего: он не регистрировался в списке и принадлежит основному сегменту без привязки.

Телефон оказывается в политике по умолчанию, у которой приоритетное подключение — обычный провайдер. Его пакет не получает туннельный маршрут и уходит в интернет напрямую. Внутренний адрес из частной сети там не существует, ответа нет. Никакой ошибки VPN не случилось: пакет просто выбрал другой путь.

Как это поймать, не открывая десятки экранов? Сравните два наблюдения. Первое: счётчики туннеля на роутере растут, когда вы открываете ресурс с ноутбука. Второе: они не меняются, когда то же самое делаете с телефона. Если счётчик молчит, пакет в туннель даже не пытался попасть. Это и есть конкретное различие, которое нужно было найти: проблема не в сервере и не в ключах, а в назначении клиента. Исправление одно — назначить устройству политику с VPN (или назначить её всему сегменту, если так задумано) — и проверить повторно.

Обратите внимание на дисциплину. Здесь не нужно трогать ни DNS, ни MTU, ни параметры сервера. Вы нашли расхождение, поменяли один параметр и сразу проверили.

Если же счётчики растут и с телефона, а ответа нет, значит, пакеты уходят, и вы возвращаетесь к разделу об AllowedIPs: источник из LAN должен быть либо транслирован, либо разрешён на сервере.

Ответный путь: сервер должен знать, куда отвечать

Маршрут в одну сторону — только половина дела. Допустим, клиентский пакет дошёл до внутреннего сервера, и тот готов ответить. Куда он отправит ответ? Если сервер видит источник с адресом из 192.168.1.0/24, он ищет маршрут к этой подсети. Если такого маршрута нет, ответ уходит на шлюз по умолчанию и пропадает.

Ноутбук этой проблемы обычно не имеет: его адрес находится в сети туннеля, и маршрут к ней у сервера уже есть. Поэтому у ноутбука всё «просто работает». Для роутера нужна ещё одна запись: сервер должен знать, что подсеть LAN лежит за таким-то peer. В WireGuard это делается тем же AllowedIPs на стороне сервера, а на соседних устройствах (например, на внутреннем сервере офиса) нужен маршрут к LAN через VPN-шлюз.

Признак такой проблемы: на сервере VPN трафик виден в обе стороны, а на внутреннем хосте запросы приходят, но ответы не доходят до роутера. Проверка простая и не требует изменений: выполните пинг с внутреннего хоста до адреса клиента в LAN и посмотрите, куда он уходит. Если не в туннель — вот ваше расхождение.

Если же вы строите VPN-сервер сами, ресурсы для него скромные: для нескольких peer на старте подойдёт даже небольшой тариф. На VPS MAATRIX доступны NVMe, процессоры AMD EPYC и root-доступ, поэтому вы сможете сами включить пересылку пакетов и описать маршруты до LAN роутера. Начните с младшего тарифа вроде Ba (1 vCPU, 2 ГБ RAM), а затем сравните загрузку на своём трафике. Это отправная точка для теста, а не обещание ёмкости. Если лучше видеть картину в движении, есть смысл заглянуть в соседнюю статью про медленную работу VPN: там уже разбирается ситуация, когда связь есть, а скорость плохая.

DNS и доступ по IP: разделяем

Теперь переходим к вопросу, который чаще всего бросается чинить первым. Если по адресу всё открывается, а по имени нет, это DNS. Если не открывается ни то, ни другое, DNS ни при чём. Эта простая проверка экономит много времени.

Порядок такой.

1. С устройства за роутером обратитесь к ресурсу по IP-адресу внутри VPN. Работает — маршрут и туннель в порядке.
2. Обратитесь к нему по имени. Не работает — ищем, какой DNS-сервер получил клиент.
3. Сравните с ноутбуком: какой сервер имён он использует при активном VPN? Часто VPN-клиент на ноутбуке сам подставляет DNS из туннеля, а роутер раздаёт клиентам DNS провайдера.

Различие найдено, когда два списка серверов имён не совпадают. Тогда можно менять один параметр: дать клиентам тот DNS, который отвечает на внутренние имена. Подбирать «хорошие» публичные DNS наугад смысла нет: внутреннее имя они всё равно не знают. Не нужно и трогать MTU, пока нет симптомов, указывающих на фрагментацию: например, мелкие запросы идут, а крупные страницы виснут. Без таких признаков это случайное вмешательство, которое только добавляет переменных.

Есть и обратная ситуация: по IP не работает, а имена разрешаются нормально. Тогда DNS не виноват в принципе, он лишь честно возвращает адрес, до которого пакет не может дойти. Это снова возвращает нас к политике назначения, AllowedIPs и обратному маршруту.

Менять по одному: как вести сравнение

Поскольку различий потенциально много, полезно вести маленькую таблицу наблюдений. Это не бюрократия, а способ не потерять нить.

Теперь про сам процесс изменения. В WireGuard правка работающего интерфейса и правка файла конфигурации — разные действия: справка отдельно отмечает, что syncconf применяет различия без пересоздания всех peer, а записью peer можно управлять командами wg set, включая удаление. Практический вывод: после правки конфигурации убедитесь, что она действительно применена к живому интерфейсу, иначе вы будете тестировать старое состояние и ничего не поймёте. Если применять изменения лишь одной командой для конкретного peer, не затрагивая остальных, то заодно не оборвёте соединения других клиентов.

Вторая дисциплина: после каждого изменения возвращаемся к одному и тому же тесту — одинаковому адресу, одному и тому же клиенту. Если сегодня вы проверяете пинг, а завтра открываете страницу в браузере, результаты не сравнить. Один и тот же вопрос, один и тот же клиент, один параметр за раз.

Когда различие найдено

Вернёмся к началу. Ноутбук и роутер подключаются к одному серверу, и каждый шаг пути у них можно сопоставить. Сначала проверили, доходят ли пакеты и признаёт ли сервер отправителя. Затем убедились, что адреса не пересекаются и AllowedIPs понимает источники из LAN. После этого проследили, действительно ли пакет клиента попадает в туннель, а не уходит к провайдеру, как телефон без назначенной политики. Дальше проверили обратный путь и только в конце, отдельно, разобрались с именами.

В большинстве случаев отличие обнаруживается на одном из этих шагов, и оно оказывается совсем небольшим: лишний общий ключ, подсеть, не записанная у сервера, или одно устройство вне нужной политики. Именно поэтому не стоит перебирать все настройки роутера подряд. Достаточно найти единственную точку, где путь пакета с ноутбука расходится с путём пакета от клиента за роутером, исправить её и повторить тот же самый тест.

Если эксперименты с маршрутами упираются в то, что нужен собственный сервер, где можно спокойно менять конфигурацию, VPS с root-доступом даёт такую возможность. Для проверки схемы начните с небольшого тарифа и наблюдайте за реальной нагрузкой: ресурсы плана задают стартовую точку, а не гарантию ёмкости.