Роутер как WireGuard-клиент или сервер: где что настраивать

MAATRIX

«Настроить WireGuard на роутере» — фраза, которая на практике распадается на две противоположные задачи. В одном случае роутер сам подключается к чужому серверу и заворачивает через него трафик всего дома наружу. В другом — сам становится точкой входа, к которой подключаются извне, чтобы попасть в домашнюю сеть. Конфиги внешне похожи, но перепутать роль — значит потратить вечер на туннель, который поднимается, но не делает то, что нужно. Разберём, где какая настройка и как не перепутать местами Endpoint и ListenPort.

Клиент и сервер в WireGuard — не совсем то, что кажется

У WireGuard нет встроенного понятия «сервер» и «клиент» на уровне протокола — с точки зрения самого туннеля это два равноправных peer'а, каждый со своей парой ключей. Термины «клиент» и «сервер» — это описание роли в конкретной сети, а не разных технологий:

• Сервер — сторона с постоянным адресом (или DDNS-именем) и открытым портом, которая ждёт входящих подключений. У неё в конфиге peer'а нет строки Endpoint — она не знает заранее, откуда придёт клиент, только принимает.
• Клиент — сторона, которая знает адрес сервера заранее и сама инициирует соединение. В его конфиге Endpoint обязателен, а порт может быть любым, даже за NAT без единого проброшенного порта.

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

Роль первая: роутер тянет VPN наружу (клиент)

Это сценарий «весь дом через VPN»: роутер подключается исходящим соединением к серверу — вашему VPS в нужной локации или сервису — и все устройства в локальной сети автоматически идут через туннель, не зная о его существовании.

Что нужно на стороне роутера:

• пара ключей (приватный/публичный), сгенерированная на самом роутере или заранее;
• публичный ключ и адрес сервера (Endpoint) — то есть вы уже знаете, куда стучаться;
• AllowedIPs, обычно 0.0.0.0/0 — весь трафик в туннель, или конкретные подсети для split-tunneling;
• PersistentKeepalive — обязателен, если роутер сидит за NAT провайдера (а он почти всегда сидит), иначе NAT-таблица провайдера тихо забывает про сессию, и туннель «висит зелёным», но трафик не ходит.

Пример конфигурации на MikroTik RouterOS 7:

/interface wireguard add name=wg-out listen-port=13231 private-key="приватный_ключ_роутера"
/interface wireguard peers add interface=wg-out public-key="публичный_ключ_сервера" \
  endpoint-address=203.0.113.10 endpoint-port=51820 allowed-address=0.0.0.0/0 persistent-keepalive=25s
/ip address add address=10.66.66.2/24 interface=wg-out
/ip route add gateway=wg-out

Обратите внимание: listen-port здесь не обязан быть проброшенным наружу — это порт, на котором роутер слушает исходящий UDP-сокет, а не входящие подключения. Проброс портов для этой роли не нужен вообще: роутер сам инициирует соединение, NAT провайдера пропускает ответный трафик автоматически, как для любого исходящего UDP-запроса.

На Keenetic та же роль настраивается через веб-интерфейс: «Другие подключения» → WireGuard → импорт .conf-файла с сервера или ручной ввод ключей, endpoint и allowed-ips. Подробный пошаговый разбор с типичными ошибками — в статье про настройку WireGuard-клиента на MikroTik; сам сервер для этой схемы поднимается по инструкции WireGuard на VPS.

Роль вторая: роутер принимает подключения снаружи (сервер)

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

Что здесь принципиально иначе:

• в конфиге peer'а (клиентских устройств) нет Endpoint — сервер не звонит клиенту первым, только принимает;
• нужен либо реальный публичный IP на WAN-интерфейсе роутера, либо проброс UDP-порта на сам роутер (не на устройство внутри сети — проброс идёт до самого роутера как конечной точки туннеля);
• если IP динамический, нужен DDNS — у Keenetic это встроенный имя.keenetic.link, на MikroTik используется собственный DDNS-сервис или сторонний;
• каждому подключающемуся устройству — отдельный peer с уникальной парой ключей, а не один конфиг на всех.

Логика конфигурации на роутере (Keenetic, для понимания структуры — в веб-интерфейсе это делает мастер):

interface WireGuard0
  description "Домашний VPN-сервер"
  ip address 10.10.10.1/24
  wireguard listen-port 51830
  up

peer wg-peer-phone
  interface WireGuard0
  endpoint-allowed-ips 10.10.10.2/32
  public-key <публичный_ключ_телефона>

Здесь listen-port — это порт, который должен быть доступен снаружи: либо роутер стоит с реальным белым IP и слушает сам, либо перед ним есть другое NAT-устройство, и тогда нужен проброс именно этого UDP-порта на адрес роутера. Если провайдер выдаёт CGNAT (серый адрес, за которым реального внешнего IP просто нет) — эта роль в чистом виде недоступна, и нужен обходной путь через промежуточный сервер с публичным IP.

Полный разбор этой роли — от подготовки DDNS до безопасности и разграничения peer'ов — в статье про VPN-сервер на Keenetic для доступа домой; если роутер стоит за NAT и нужно разобраться именно с пробросом порта, отдельно смотрите статью про проброс портов для VPN-сервера за NAT.

Таблица: что где указывать

Именно перепутанные строки этой таблицы — самая частая причина «туннель поднялся, а трафика нет»: например, AllowedIPs 0.0.0.0/0 на серверной стороне вместо узкой подсети клиента ломает маршрутизацию между несколькими одновременно подключёнными peer'ами.

Может ли роутер быть и клиентом, и сервером сразу

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

Технически это два независимых интерфейса WireGuard на одном устройстве — wg-out для клиентской роли, wg-in (или WireGuard0/WireGuard1 в терминах Keenetic) для серверной. Единственное жёсткое условие — у интерфейсов не должны пересекаться подсети в AllowedIPs/адресации, иначе роутер не сможет однозначно определить, куда маршрутизировать пакет. Если планируете обе роли, сразу разносите их по разным диапазонам, например 10.66.66.0/24 для исходящего туннеля и 10.10.10.0/24 для входящего.

Отдельный нюанс: трафик, который приходит через входящий туннель (роль сервера) и уходит через исходящий (роль клиента) — то есть телефон подключился домой, а роутер перенаправляет его дальше во внешний VPN — работает, но требует явных правил маршрутизации и NAT между интерфейсами. Без них трафик просто не найдёт дорогу ко второму туннелю.

Типичные ошибки при выборе и настройке роли

• Пытаться пробросить порт для роли клиента. Это лишняя работа — исходящему соединению проброс не нужен, а открытый порт без необходимости — просто лишняя поверхность атаки.
• Забыть про PersistentKeepalive на клиенте. Без него туннель «висит», но перестаёт пропускать трафик через 1–5 минут простоя — NAT-таблица провайдера закрывает сессию по таймауту.
• Один peer-конфиг на все устройства в серверной роли. Компрометация одного телефона в этом случае требует пересоздавать ключи для всей семьи; при отдельных peer'ах достаточно отозвать один.
• Не проверить тип IP до настройки серверной роли. CGNAT выясняется постфактум, когда проброс порта не срабатывает ни при каких настройках — это стоит проверить заранее, сравнив внешний IP по любому онлайн-сервису с адресом WAN на роутере.
• Одинаковая адресация у двух ролей на одном устройстве. Если решили держать и клиента, и сервера одновременно, а забыли развести подсети — получите непредсказуемую маршрутизацию и трудноуловимые обрывы.
• Слепое копирование MTU из чужого мануала. Значение зависит от типа подключения провайдера (особенно PPPoE) и одинаково для обеих ролей не бывает — если пакеты фрагментируются, начните проверку с 1420 и подстраивайте под свой канал.

Часть этих граблей — неверный MTU, конфликт allowed-ips, забытые peer'ы — повторяется независимо от роли и требует одной и той же диагностики: сначала проверить статус хендшейка, потом маршруты, потом MTU.

Частые вопросы