WireGuard на DD-WRT: настройка клиента

MAATRIX

DD-WRT ставят на сотни моделей роутеров разных производителей — от старых Linksys до современных Netgear и Asus, — и это одна из причин, почему инструкции по WireGuard для неё разбросаны и часто противоречат друг другу: то, что работает на одной сборке прошивки, отсутствует на другой. В отличие от Keenetic или MikroTik, где поддержка протокола однородна для всей линейки, в DD-WRT она зависит от конкретного билда и модели, поэтому первый шаг — не открывать веб-интерфейс, а понять, какая у вас сборка и потянет ли она WireGuard вообще. Дальше — сама настройка клиента: через GUI, где это возможно, и через SSH-консоль там, где интерфейс урезан или не сохраняет нужные параметры.

Что нужно перед началом

Соберите три вещи заранее, это сэкономит время на прошивках вслепую:

• Сборка DD-WRT с поддержкой WireGuard. Протокол доступен не во всех вариантах прошивки — в «облегчённых» сборках (micro, nokaid, иногда базовый std) раздела WireGuard в GUI просто нет, потому что для него урезали место под дополнительный код. Нужна сборка Kong (для чипов Broadcom) или полноценный Mega/NEWD-2 build (для Atheros/Qualcomm) — какая именно подходит вашей модели, стоит свериться по списку поддерживаемых устройств DD-WRT, там же указывается доступный объём флеш-памяти.
• Флеш-память от 8 МБ, лучше 16 МБ. На роутерах с 4 МБ флеша полноценный Kong/Mega-билд обычно либо не устанавливается, либо после прошивки не остаётся свободного места под NVRAM для сохранения ключей и параметров пира — конфиг будет «слетать» после перезагрузки.
• Готовый конфиг клиента с сервера — обычно .conf-файл с приватным ключом, публичным ключом сервера, Endpoint и AllowedIPs. Если сервера ещё нет, я подробно разбирал его настройку в статье про установку WireGuard на VPS.
• Доступ по SSH на всякий случай. Включите его заранее в Services → Services → Secure Shell — пригодится, если веб-интерфейс не сохраняет часть настроек или нужен скрипт автозапуска (раздел ниже).

Проверяем, потянет ли текущая прошивка WireGuard

Прежде чем что-то настраивать, откройте Status → Sysinfo и посмотрите строку с версией прошивки — там будет что-то вроде DD-WRT v3.0-r53500 kong или ... mega. Если в названии сборки нет kong или mega, а стоит std, micro или nokaid — переходите в Services → VPN и проверяйте, есть ли там вообще раздел WireGuard. Отсутствие раздела означает, что нужна другая сборка.

Обновление на нужный билд — стандартная процедура DD-WRT, но с оговорками:

1. Скачайте .bin-файл нужной сборки для точной модели роутера (не «похожей», а именно вашей ревизии) с официального сайта.
2. Сделайте бэкап текущей конфигурации: Administration → Backup → Backup.
3. Прошивайтесь через Administration → Firmware Upgrade, при смене типа сборки (например, со std на kong) после прошивки сделайте сброс к заводским настройкам — смешанные NVRAM-переменные между разными билдами регулярно приводят к нестабильной работе.
4. После сброса настройте роутер заново — WAN, Wi-Fi и только затем WireGuard.

Учитывайте риск: неудачная прошивка «не той» сборки на слабом по флешу устройстве может привести к необходимости восстановления через TFTP или JTAG, поэтому для моделей на грани по памяти (4–8 МБ) стоит трезво оценить, нужен ли вам полноценный Kong-билд, или проще вынести WireGuard-клиент на OpenWrt-роутер, если конкретная модель для WireGuard откровенно слаба.

Ориентир, какие сборки обычно поддерживают протокол:

Настраиваем клиента через веб-интерфейс

Если сборка подходящая, раздел находится в Services → VPN, вкладка WireGuard:

1. В блоке WireGuard Client переключите Enable в положение включено.
2. Нажмите Generate Keys — прошивка создаст пару приватный/публичный ключ для интерфейса роутера. Если сервер уже выдал вам конкретный приватный ключ под этого пира (как в готовом .conf) — вставьте его вручную вместо генерации, иначе публичный ключ роутера не совпадёт с тем, что прописан на сервере.
3. Заполните IP Address — адрес интерфейса из конфига (например, 10.20.0.2/32).
4. Поле Listen Port для клиента обычно можно оставить пустым или указать любой свободный порт — если роутер не принимает входящие подключения как сервер, это не критично.
5. В блоке Peers нажмите Add и укажите:

• Public Key — публичный ключ сервера;
• Endpoint Address и Endpoint Port — адрес и порт сервера;
• Allowed IPs — 0.0.0.0/0, ::/0 для полного туннелирования всего трафика роутера или конкретную подсеть для split tunnel;
• Persistent Keep Alive — 25 секунд, это важно для соединений через NAT провайдера, без keepalive туннель может «засыпать»;
• галочку Route Allowed IPs — она указывает DD-WRT автоматически добавить маршруты на основании Allowed IPs, без неё интерфейс поднимется, но трафик через него ходить не будет.

1. Нажмите Save, затем Apply Settings.

Отдельно проверьте DNS: вкладка WireGuard не всегда даёт задать DNS-сервер для туннеля напрямую. Если серверный DNS нужен всем клиентам сети, пропишите его в Setup → Basic Setup → Static DNS, иначе устройства за роутером продолжат резолвить имена через DNS провайдера даже с поднятым туннелем.

Настройка через SSH, если GUI не справляется

На части сборок раздел в GUI работает нестабильно — не сохраняет пира при перезагрузке или не даёт задать несколько peer-ов. Надёжнее поднять интерфейс вручную через консоль: подключитесь по SSH (ssh root@<ip роутера>) и проверьте, что утилиты wg и wg-quick доступны — они есть на Kong/Mega-сборках из коробки.

Так как /tmp на DD-WRT не переживает перезагрузку, конфиг нужно хранить в постоянном разделе. Если на роутере включён JFFS2 (Administration → Management → JFFS2 Support), используйте /jffs:

mkdir -p /jffs/wireguard
cat > /jffs/wireguard/wg0.conf << 'EOF'
[Interface]
PrivateKey = <приватный_ключ_роутера>
Address = 10.20.0.2/32

[Peer]
PublicKey = <публичный_ключ_сервера>
Endpoint = 203.0.113.10:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25
EOF

Дальше поднимите интерфейс вручную, чтобы убедиться, что конфиг рабочий:

wg-quick up /jffs/wireguard/wg0.conf
wg show

Если wg show показывает интерфейс и растущие счётчики после первого хендшейка — конфиг корректен. Чтобы это происходило автоматически при каждой загрузке роутера, добавьте команду в Administration → Commands, поле Startup:

wg-quick up /jffs/wireguard/wg0.conf

и нажмите Save Startup. Это надёжнее, чем полагаться на GUI-раздел WireGuard, особенно на сборках, где он ведёт себя нестабильно.

Маршрутизация трафика и NAT

В отличие от Keenetic, где политики маршрутизации по устройствам и доменам настраиваются в отдельном разделе интерфейса в несколько кликов, в DD-WRT такого готового инструмента нет — здесь либо весь трафик роутера (full tunnel), либо маршрутизация вручную через ip rule/iptables в консоли.

Full tunnel — самый простой вариант: Allowed IPs = 0.0.0.0/0, ::/0 с включённой галочкой Route Allowed IPs (или, при настройке через SSH, штатное поведение wg-quick) отправляет через туннель весь трафик роутера и всех устройств за ним. Дефолтный маршрут на WAN-провайдера при этом заменяется маршрутом через wg0.

Split tunnel — через туннель идёт только часть трафика (например, определённая подсеть или рабочие сервисы), а остальное — через обычный канал провайдера. В GUI это задаётся ограничением Allowed IPs конкретными подсетями вместо 0.0.0.0/0. Если нужно более тонкое деление по устройствам — придётся добавлять правила вручную через ip rule и маркировку пакетов в iptables в том же скрипте автозапуска, поле Administration → Commands → Firewall. Это заметно менее удобно, чем готовые политики в Keenetic или MikroTik, поэтому если гибкая маршрутизация по устройствам принципиальна, стоит сравнить, что удобнее в вашем случае — VPN на роутере или на отдельных устройствах.

Если сервер ожидает от клиента NAT для своей локальной сети (чтобы устройства LAN за DD-WRT были видны в VPN-сети), добавьте правило маскарадинга в тот же firewall-скрипт:

iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE

В большинстве сценариев «роутер — клиент к серверу», где NAT делает сам сервер, это правило не требуется.

Проверка соединения и типичные проблемы

После поднятия интерфейса — через GUI или wg-quick — проверьте состояние туннеля. Через консоль это надёжнее, чем через веб-интерфейс:

wg show wg0

Строка latest handshake с недавним временем (обновляется примерно каждые 2 минуты при активном трафике или keepalive) и растущие счётчики transfer означают, что туннель живой и трафик реально идёт. Если хендшейк есть, а сайты через VPN не открываются — это распространённая ситуация, не специфичная для DD-WRT, я подробно разбирал причины и порядок диагностики в статье «WireGuard: хендшейк есть, а трафика нет». Чаще всего дело в AllowedIPs на сервере (сервер не знает маршрут обратно к подсети роутера) либо в отсутствующем правиле MASQUERADE на стороне сервера.

Специфичная для DD-WRT проблема — интерфейс не поднимается заново автоматически после смены IP на WAN. Часть сборок не отслеживает это событие для WireGuard-клиента, в отличие от встроенных PPTP/OpenVPN клиентов. Простое решение — cron-задача, которая проверяет доступность шлюза внутри туннеля и перезапускает интерфейс при обрыве:

*/5 * * * * ping -c 2 -W 3 10.20.0.1 > /dev/null || wg-quick down /jffs/wireguard/wg0.conf; wg-quick up /jffs/wireguard/wg0.conf

Строка добавляется через Administration → Cron (нужна опция включения cron в Management). Это не элегантное решение, а рабочий костыль — на MikroTik или Keenetic такого watchdog обычно не требуется, переподключение встроено в саму реализацию клиента.

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