Ubiquiti EdgeRouter: настройка WireGuard-клиента

MAATRIX

EdgeRouter — не бытовой роутер с красивым мастером настройки, а маршрутизатор, который честно ждёт от вас команд в CLI на базе EdgeOS (наследник Vyatta), и WireGuard-клиент тут не исключение: веб-интерфейс Router UI умеет показать уже настроенный туннель, но собрать его с нуля проще и надёжнее через консоль. Плюс в том, что один раз настроенный клиент на EdgeRouter заворачивает в VPN сразу всю сеть — офис, домашнюю подсеть, гостевой Wi-Fi — без единого VPN-клиента на конечных устройствах. Ниже — весь путь по командам EdgeOS: от генерации ключей до проверки, что трафик действительно идёт через туннель, а не только рукопожатие происходит.

Что нужно подготовить

Эта статья — про клиентскую часть: EdgeRouter подключается к уже существующему WireGuard-серверу. Если сервера ещё нет, разверните его сначала — например на VPS, подробный процесс с нуля описан в статье про установку WireGuard на VPS. Здесь предполагается, что сервер уже поднят и у вас есть его публичный ключ, IP-адрес и порт.

Перед началом под рукой должно быть:

• Доступ к EdgeRouter — по SSH (обычно ssh ubnt@<IP_роутера>) или через встроенный CLI-терминал в Router UI (раздел CLI).
• Публичный ключ, IP и порт WireGuard-сервера — берутся из его конфигурации, порт по умолчанию 51820/udp.
• Диапазон VPN-сети и свободный адрес для самого EdgeRouter в этом диапазоне, например 10.10.20.0/24.
• Версия EdgeOS — нативная поддержка WireGuard есть во второй ветке прошивки (EdgeOS v2.x). Проверить версию можно в Router UI на вкладке System, либо командой show version в CLI. Если стоит первая ветка или ранняя v2.x без WireGuard среди типов интерфейсов — сначала обновите прошивку через Router UI, иначе команды ниже просто не найдутся в дереве конфигурации.
• IP шлюза провайдера (WAN gateway) — понадобится на шаге с маршрутизацией, чтобы не загнать сам туннель в петлю.

Общая логика «весь дом или офис через один туннель» и когда она уместнее, чем VPN-клиент на каждом устройстве, разобрана в статье про VPN на роутере для всего дома — здесь сразу переходим к EdgeRouter.

Генерация ключей WireGuard

Заходим в режим конфигурации и генерируем пару ключей встроенной командой EdgeOS:

configure
generate wireguard default-keypair
commit

Эта команда создаёт приватный и публичный ключ и привязывает их как ключи по умолчанию для будущего WireGuard-интерфейса. Точное название команды и то, привязывается ли ключ автоматически к конкретному интерфейсу или его нужно указать явно, немного отличается между сборками EdgeOS — если generate wireguard default-keypair не находится автодополнением (клавиша Tab после generate wireguard ), сгенерируйте ключи вручную через сам wg (он уже установлен, так как WireGuard работает поверх стандартного модуля ядра и утилит):

sudo wg genkey | tee /config/auth/wg0-private.key | wg pubkey | sudo tee /config/auth/wg0-public.key

и затем пропишите приватный ключ явно при создании интерфейса командой set interfaces wireguard wg0 private-key '<КЛЮЧ>' вместо генерации по умолчанию. Публичный ключ роутера, который нужно будет добавить на сервер как peer, смотрится командой:

show interfaces wireguard wg0 public-key

(доступна после того, как интерфейс wg0 создан хотя бы с базовыми параметрами — следующий шаг).

Интерфейс wg0 и подключение к серверу

Создаём сам интерфейс, задаём ему адрес в VPN-сети и описываем peer — то есть параметры сервера, к которому подключается роутер:

set interfaces wireguard wg0 address 10.10.20.2/24
set interfaces wireguard wg0 listen-port 51820
set interfaces wireguard wg0 route-allowed-ips true
set interfaces wireguard wg0 peer SERVER_PUBLIC_KEY allowed-ips 0.0.0.0/0
set interfaces wireguard wg0 peer SERVER_PUBLIC_KEY endpoint 203.0.113.10:51820
set interfaces wireguard wg0 peer SERVER_PUBLIC_KEY persistent-keepalive 25
commit
save

По ключевым параметрам:

• address — адрес EdgeRouter внутри VPN-сети, тот, что выделен ему на сервере.
• route-allowed-ips true — особенность EdgeOS, которой нет в некоторых других системах: значение это указывает роутеру автоматически добавить маршрут на основе allowed-ips peer'а. Именно это избавляет от части ручной работы с таблицей маршрутизации — но не от всей, о ловушке ниже.
• allowed-ips 0.0.0.0/0 — какой трафик заворачивать в туннель со стороны роутера; 0.0.0.0/0 означает «весь». Для частичного туннеля вместо этого указывается конкретная подсеть.
• persistent-keepalive 25 — держит NAT провайдера «в курсе» соединения на простое, отправляя пустой пакет раз в 25 секунд; без этого туннель может проседать после нескольких минут без активного трафика.

SERVER_PUBLIC_KEY — публичный ключ сервера, 203.0.113.10:51820 — его IP и порт, замените на реальные значения.

Маршрутизация всей сети через VPN

Здесь EdgeOS экономит один шаг по сравнению, например, с Mikrotik: route-allowed-ips true из предыдущей команды сам добавит маршрут по умолчанию через wg0, если allowed-ips peer'а — 0.0.0.0/0. Проверить это можно командой:

show ip route

— в выводе должна появиться запись вида S>* 0.0.0.0/0 [1/0] is directly connected, wg0.

Но ловушка остаётся та же, что и на любом роутере с полным туннелем: без отдельной обработки пакеты к самому серверу (на endpoint) тоже попытаются пойти через ещё не поднятый туннель — получится петля. Автоматический маршрут от route-allowed-ips эту проблему не решает сам, поэтому явно закрепите маршрут до IP сервера через обычный WAN-шлюз с более узкой маской, чтобы EdgeOS выбрал именно его как более точное совпадение:

set protocols static route 203.0.113.10/32 next-hop <IP_ШЛЮЗА_ПРОВАЙДЕРА>
commit
save

Если по какой-то причине route-allowed-ips не сработал или вы предпочитаете задавать маршрут явно, у EdgeOS для интерфейсов без собственного IP-шлюза (point-to-point, каким по сути и является WireGuard) есть отдельный тип маршрута — interface-route, где вместо next-hop указывается сам интерфейс:

set protocols static interface-route 0.0.0.0/0 next-hop-interface wg0
commit
save

Если нужен не полный, а частичный туннель — маршрутизировать через VPN только отдельные подсети или сервисы, — самый чистый способ на EdgeOS — policy-based routing через firewall modify и отдельную таблицу маршрутизации, а не общий 0.0.0.0/0; это отдельная и не самая тривиальная тема, выходящая за рамки этой статьи.

NAT и firewall

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

set service nat rule 5010 description 'Masquerade for WireGuard VPN'
set service nat rule 5010 outbound-interface wg0
set service nat rule 5010 type masquerade
commit
save

Дальше — форвардинг. Если на LAN-интерфейсе EdgeRouter уже применён firewall ruleset с политикой по умолчанию drop, добавьте правило, разрешающее трафик из LAN в wg0 и обратно по established/related:

set firewall name LAN_OUT rule 20 action accept
set firewall name LAN_OUT rule 20 description 'Allow LAN to WireGuard'
set firewall name LAN_OUT rule 20 destination interface wg0
commit
save

Если firewall между LAN и остальными интерфейсами роутера у вас не настраивался отдельно (стандартная конфигурация «из коробки» на многих моделях EdgeRouter форвардинг между внутренними интерфейсами не режет), этот шаг можно пропустить — но обязательно проверьте show firewall перед тем как считать, что дело в чём-то другом, если трафик после NAT всё равно не идёт.

DNS и проверка подключения

WireGuard, в отличие от некоторых других протоколов, не раздаёт DNS-сервер клиенту автоматически — если сайты не открываются по имени, хотя пинг по IP через VPN проходит, дело почти всегда в DNS. Самый надёжный вариант для схемы «весь дом через VPN» — сделать сам EdgeRouter DNS-прокси для локальной сети и явно указать ему внешний резолвер:

set system name-server 1.1.1.1
set service dns forwarding cache-size 150
set service dns forwarding listen-on eth0
commit
save

Теперь сама проверка. Сначала — состояние интерфейса и рукопожатие:

show interfaces wireguard wg0

и более подробный вывод от самого wg:

sudo wg show wg0

Смотрите на поле latest handshake: значение в пределах последних одной-двух минут означает, что рукопожатие свежее. Пустое значение или явно устаревшая дата — сервер не отвечает, и разбор причин (от несовпадения ключей до закрытого порта на сервере) детально описан в статье про WireGuard с рукопожатием, но без трафика — там же логика применима к любому клиенту, не только к Mikrotik, для которого статья изначально писалась.

Финальная проверка — не техническая, а по факту: с любого устройства локальной сети (не самого роутера) откройте сайт с определением IP-адреса и убедитесь, что он показывает адрес VPN-сервера, а не адрес, выданный провайдером. Это единственный способ убедиться, что весь трафик действительно идёт через туннель, а не просто «интерфейс поднят и рукопожатие прошло».

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