Текст и данные · Инструкция
WireGuard endpoint roaming
WireGuard endpoint roaming. WireGuard может обновлять endpoint пира по последнему корректно аутентифицированному пакету, поэтому смена Wi‑Fi на мобильную сеть обычно не требует вручную переписывать клиентский внешний.
Короткий ответ
WireGuard может обновлять endpoint пира по последнему корректно аутентифицированному пакету, поэтому смена Wi‑Fi на мобильную сеть обычно не требует вручную переписывать клиентский внешний IP.
Что именно roaming меняет у peer
WireGuard связывает пир прежде всего с public key, а endpoint — это текущий IP:порт для доставки пакетов. Официальное описание WireGuard прямо указывает на встроенный roaming: endpoint может изучаться по аутентифицированному пакету. AllowedIPs при этом остаётся отдельным механизмом маршрутизации и проверки адресов; roaming его не заменяет.
Совет: Зафиксируйте исходную точку: на доступной стороне выполните `wg show` и запишите endpoint, latest handshake и RX/TX нужного пира.
Что делать по порядку
- 1. На доступной стороне выполните `wg show` и запишите endpoint, latest handshake и RX/TX нужного пира.
- 2. Переключите клиент с Wi‑Fi на мобильную сеть или наоборот, не меняя конфигурацию вручную.
- 3. Создайте трафик к адресу, который точно идёт через WireGuard, например к внутреннему сервису.
- 4. Снова посмотрите `wg show`: новый endpoint вместе с обновившимся handshake и растущими счётчиками подтверждает roaming.
- 5. Если ничего не меняется, отдельно проверяйте маршрут, UDP, NAT и AllowedIPs; не начинайте с замены ключей.
Важно: PersistentKeepalive не исправляет неверные ключи или маршруты; он решает более узкую задачу поддержания NAT/firewall state.
Где искать следующий сигнал
Если пир находится за NAT и должен оставаться достижимым после долгой паузы, PersistentKeepalive может поддерживать сопоставление NAT. Старый endpoint при полном отсутствии трафика сам по себе не доказывает неисправность, потому что WireGuard старается не создавать лишний фоновый трафик. Roaming подтверждается не самим фактом смены сети, а тем, что пир продолжил обмен уже через новый IP:порт. На стороне, где виден `wg show`, endpoint должен измениться после аутентифицированного трафика, а RX/TX — расти. Если клиент ушёл за другой NAT и долго молчит, серверу нечего «выучить». Поэтому сначала инициируйте трафик с клиента. PersistentKeepalive нужен только когда обратная достижимость должна сохраняться в период бездействия; он не заменяет корректные ключи, AllowedIPs и открытый UDP-путь. Для подтверждения повторите переключение сети ещё раз и убедитесь, что новый endpoint снова изучается автоматически.
Предупреждение: Private key не нужно отправлять в тикеты или скриншоты при диагностике.
Ограничения и безопасность
PersistentKeepalive не исправляет неверные ключи или маршруты; он решает более узкую задачу поддержания NAT/firewall state. Private key не нужно отправлять в тикеты или скриншоты при диагностике. Private key и preshared key не нужны для скриншота диагностики; достаточно public key, endpoint и обезличенных счётчиков.
Что учитывать
PersistentKeepalive не исправляет неверные ключи или маршруты; он решает более узкую задачу поддержания NAT/firewall state. Private key не нужно отправлять в тикеты или скриншоты при диагностике. Private key и preshared key не нужны для скриншота диагностики; достаточно public key, endpoint и обезличенных счётчиков.
Источники и проверка
Фактическая часть сверена по первичным источникам (в т.ч. WireGuard Quick Start). Пример и формулировки — редакция N1RO на 2026-09-23.