WireGuard работает на мобильных данных, но не в той же wifi-сети
Запрос изнутри LAN к публичному адресу роутера идёт другим путём, чем запрос с мобильных данных. Проверьте снаружи, затем выберите локальный путь.
Туннель поднимается на мобильных данных и затем остаётся на подключении дома, с тем же профилем, тем же ключом peer и без изменений конфигурации между ними. Разница в маршруте: запрос изнутри LAN к публичному адресу роутера — не то же путешествие, что запрос, приходящий из интернета. Большинство домашних шлюзов либо вообще не реализуют обратный путь, либо реализуют его только для определённых протоколов. Из-за этого симптом выглядит как сломанный ключ, хотя с ключом ничего не произошло. Определите, какой путь отказал, прежде чем трогать ключ, проброс порта или профиль клиента.
Один адрес, два разных пути
Снаружи пакет достигает публичного адреса роутера, и правило проброса порта передаёт его слушателю WireGuard на внутреннем хосте. Изнутри клиент набирает тот же публичный адрес, поэтому пакет уходит от клиента, приходит на роутер и должен быть развёрнут обратно в сторону LAN. Именно на этом развороте два пути расходятся, потому что роутер должен транслировать поток, который одновременно выходит и снова входит через один и тот же интерфейс. Многие реализации отбрасывают его вместо трансляции, и клиент затем ждёт рукопожатие, которое так и не было отправлено.
Такое поведение обычно называют NAT loopback или hairpinning, и оно относится к роутеру, а не к WireGuard; RFC 4787 описывает случаи трансляции, в которых шлюз может поддерживать его или нет. Сам WireGuard не имеет мнения о пути, потому что видит только пакеты, достигающие его интерфейса. Когда роутер отбрасывает поток, демон не получает ничего, клиент сообщает о тайм-ауте рукопожатия, а журнал сервера остаётся пустым. Пустой журнал поэтому подсказывает, где остановился пакет, а не доказывает, что сервер упал. Это же причина, по которой переустановка ничего не меняет.
Обратное тоже важно: журнал сервера, показывающий попытку рукопожатия с адреса LAN, доказывает, что пакет дошёл и путь в порядке, а это переводит расследование к ключам и разрешённым адресам. Читайте журнал ради того, что он доказывает, а не ради того, что вы надеялись увидеть.
Сначала воспроизведите, потом меняйте
Проверьте из авторизованной внешней сети с тем же устройством и тем же профилем, затем повторите проверку внутри LAN, ничего не редактируя. Завершённое рукопожатие снаружи и клиент, который изнутри никогда не покидает устройство, воспроизводят состояние вместо догадок. Обе попытки должны использовать один профиль, иначе сравнение ничего не доказывает.
Затем посмотрите, во что разрешается имя конечной точки для этого устройства. Три следующие команды также показывают, какой адрес клиент на самом деле набрал:
wg show wg0 endpoints
dig +short vpn.example.net A
resolvectl query vpn.example.netПервая команда сообщает конечную точку, которую интерфейс использует сейчас, а две другие показывают, во что имя разрешается на этой машине. Клиент, набирающий публичный адрес, находясь в той же сети, что и сервер, использует путь hairpin. Клиент, набирающий адрес LAN, этого не делает, и сбой там относится к другому расследованию. Это различие решает, применим ли следующий раздел вообще.
Поддерживаемые способы добраться до близкого сервера
Самая чистая схема — ответ с разделением горизонта: публичное имя разрешается в публичный адрес для интернета и в адрес LAN сервера для клиентов внутри. Профиль хранит одно имя конечной точки, а резолвер выбирает путь. Для этого нужен контроль над внутренним ответом DNS, который домашний роутер обычно предлагает, а организация может устроить намеренно. Без такого контроля остаются функция роутера или второй профиль.
Функция роутера — отражение: шлюз транслирует поток изнутри наружу и отправляет его обратно внутрь. Там, где она работает, изменения клиента не нужны, а там, где не работает, никакая настройка клиента её не спасёт. Проверьте её, наблюдая за журналом сервера во время внутренней попытки, а не читая список функций роутера.
Правка профиля на частный адрес — это диагностика, а не проект. Она доказывает, что сервер отвечает в LAN, и ломает тот же профиль в тот момент, когда ноутбук уезжает из дома.
| Approach | What it depends on | Where it fails |
|---|---|---|
| Split-horizon name | Control of the internal DNS answer | Clients that resolve through a server outside the zone |
| Router reflection | Gateway support for hairpin translation | Routers that drop the flow silently |
| Private address in the profile | Nothing beyond the LAN | Every network except the one at home |
Сохраняйте профиль пригодным вне дома
Какой бы путь вы ни выбрали, не трогайте проверку подлинности. Адрес конечной точки — не идентичность peer, и смена адреса никогда не оправдывает принятие постороннего публичного ключа, который случайно отвечает. WireGuard аутентифицирует по ключу, поэтому неверный хост проваливает рукопожатие вместо того, чтобы дать доступ к чему-то неожиданному.
Если публичный адрес меняется, именно динамический DNS сохраняет имя полезным, а поведение обновления у клиента решает, как быстро изменение доедет. Проверьте это снаружи после смены адреса, потому что случай LAN этого не подтвердит. Следите за резолвером, который кэширует старый ответ дольше времени жизни записи. Имя, всё ещё указывающее на прежний адрес, выглядит точно как упавший сервер.
Запишите, какое имя использует профиль и во что оно разрешается по каждую сторону границы. Профиль, зависящий от функции роутера, которую никто не зафиксировал, — это звонок в поддержку в ожидании следующего обновления прошивки. Запись также говорит следующему человеку, является ли внутренний сбой известным случаем hairpin или чем-то новым.