VPN на роутере: как направить весь домашний трафик через туннель

Зачем VPN на роутере, а не на каждом устройстве​

Когда VPN-клиент работает на отдельном устройстве, только его трафик проходит через туннель. Остальные устройства в сети — смарт-ТВ, IoT-датчики, игровые консоли — остаются без защиты. Установка VPN на роутер решает это на уровне шлюза: весь исходящий трафик локальной сети шифруется до попадания к провайдеру.

Дополнительные преимущества:

• Устройства без поддержки VPN-клиентов (приставки, камеры, принтеры) автоматически получают защищённый канал.
  
• Не нужно устанавливать и обновлять клиент на каждом устройстве.
  
• Единая точка управления: один конфиг, один kill switch, один набор правил маршрутизации.
  

Минусы тоже есть: нагрузка на CPU роутера, сложность настройки, невозможность быстро переключить отдельное устройство на прямой канал без дополнительных правил.

Какие роутеры поддерживают режим VPN-клиента​

Не каждый домашний роутер способен работать как VPN-клиент. Ключевое требование — прошивка с доступом к настройкам туннельных интерфейсов.

Платформа	WireGuard	OpenVPN	Примечание
OpenWrt	Да (ядро ≥ 5.6)	Да	Наиболее гибкий вариант, полная настройка через CLI и LuCI
Keenetic	Да	Да	Встроенная поддержка в фирменной прошивке, настройка через веб-интерфейс
MikroTik RouterOS	Да (v7+)	Да	Мощная маршрутизация, но порог входа выше
Asus + Merlin	Зависит от модели	Да	Merlin добавляет поддержку OpenVPN-клиента на многих моделях
DD-WRT	Ограниченно	Да	Зависит от сборки и модели
Заводские прошивки TP-Link, D-Link, Tenda	Обычно нет	Редко	Бюджетные модели, как правило, не поддерживают VPN-клиент

Если текущий роутер не поддерживает VPN-клиент, варианты: перепрошивка на OpenWrt (если модель совместима), покупка роутера с поддержкой или использование отдельного устройства (мини-ПК, Raspberry Pi) как VPN-шлюза перед основным роутером.

WireGuard на роутере: принцип работы​

WireGuard создаёт виртуальный сетевой интерфейс (обычно wg0), который работает как туннель. Конфигурация строится на паре ключей и списке разрешённых IP-адресов (AllowedIPs). Когда интерфейс отправляет пакет, он определяет пира по адресу назначения из AllowedIPs, шифрует пакет его публичным ключом и отправляет на известный endpoint. При получении — расшифровывает, проверяет источник и пропускает пакет в сеть только если адрес отправителя совпадает с AllowedIPs этого пира.

Для роутера-клиента типичная конфигурация выглядит так:

[Interface]
PrivateKey = <приватный_ключ_роутера>
Address = 10.8.0.2/32
DNS = 10.8.0.1

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

Здесь AllowedIPs = 0.0.0.0/0 означает, что весь трафик роутера направляется в туннель. PersistentKeepalive = 25 поддерживает NAT-проброс, отправляя пустой пакет каждые 25 секунд — это важно, когда роутер находится за NAT провайдера.

Настройка на OpenWrt​

На OpenWrt WireGuard доступен через пакет wireguard-tools (или kmod-wireguard для старых ядер). Установка:

opkg update
opkg install wireguard-tools

Конфигурация интерфейса задаётся в /etc/config/network:

config interface 'wg0'
    option proto 'wireguard'
    option private_key '<приватный_ключ>'
    list addresses '10.8.0.2/32'

config wireguard_wg0
    option public_key '<публичный_ключ_сервера>'
    option endpoint_host 'vpn.example.com'
    option endpoint_port '51820'
    list allowed_ips '0.0.0.0/0'
    option persistent_keepalive '25'

После этого нужно добавить маршрут по умолчанию через wg0 и настроить NAT для локальной сети. В /etc/config/firewall зона wg0 должна быть привязана к WAN-зоне с разрешением masquerade.

Настройка на Keenetic​

В Keenetic OS поддержка WireGuard встроена. Через веб-интерфейс: «Интернет» → «WireGuard» → добавить подключение, вставить ключи и endpoint. Альтернативно через CLI:

interface wireguard0
  ip address 10.8.0.2/32
  peer <публичный_ключ_сервера>
    endpoint vpn.example.com:51820
    allowed-ip 0.0.0.0/0
    persistent-keepalive 25
  exit

Затем нужно назначить wireguard0 как приоритетный интерфейс для выхода в интернет в настройках маршрутизации.

OpenVPN на роутере​

OpenVPN дольше присутствует в роутерных прошивках и поддерживается даже там, где WireGuard недоступен. Работает через TUN-интерфейс (маршрутизация) или TAP (мост). Для домашнего сценария используется TUN.

Конфигурация клиента обычно сводится к загрузке .ovpn-файла от провайдера и указанию учётных данных. На OpenWrt:

opkg install openvpn-openssl

Файл конфигурации помещается в /etc/openvpn/, сервис запускается через /etc/config/openvpn. На Keenetic и Asus Merlin загрузка .ovpn-файла доступна прямо из веб-интерфейса.

OpenVPN медленнее WireGuard из-за накладных расходов TLS и работы в userspace, но на современных роутерах с аппаратным ускорением AES разница заметна только на каналах выше 100 Мбит/с.

DNS: критическая точка утечки​

Если DNS-запросы уходят напрямую провайдеру, а не через туннель, VPN теряет смысл: провайдер видит, какие домены запрашивает сеть. Три варианта решения:

1. DNS через туннель. В конфигурации WireGuard указывается DNS = 10.8.0.1 (адрес DNS-сервера внутри туннеля). На роутере этот адрес раздаётся клиентам через DHCP как единственный DNS.
   
2. DNS-over-HTTPS / DNS-over-TLS на роутере. Если VPN-провайдер не даёт свой DNS, можно направить запросы через DoH/DoT на публичный резолвер (Cloudflare, Quad9). На OpenWrt это реализуется через https-dns-proxy или stubby.
   
3. Принудительное перенаправление. Правило в firewall, которое перехватывает весь UDP/TCP-трафик на порт 53 и перенаправляет его на внутренний DNS-резолвер роутера. Это защищает от устройств, которые игнорируют выданный DHCP-адрес DNS.
   

На OpenWrt пример принудительного перенаправления:

iptables -t nat -A PREROUTING -i br-lan -p udp --dport 53 -j DNAT --to-destination 192.168.1.1:53
iptables -t nat -A PREROUTING -i br-lan -p tcp --dport 53 -j DNAT --to-destination 192.168.1.1:53

Маршрутизация и split tunneling​

По умолчанию AllowedIPs = 0.0.0.0/0 направляет весь трафик в туннель. Если нужно исключить определённые подсети (например, локальные сервисы или торрент-трекеры), из списка AllowedIPs убирается соответствующий диапазон и добавляется статический маршрут через WAN.

Пример: весь трафик через VPN, кроме подсети 192.168.100.0/24 (локальный NAS):

ip route add 192.168.100.0/24 via 192.168.1.1 dev eth0

На OpenWrt это делается через /etc/config/network или через правила маршрутизации в LuCI. На Keenetic — через раздел «Маршрутизация» → «Статические маршруты».

Обратный сценарий — только часть трафика через VPN (например, определённый VLAN или конкретное устройство). Для этого создаётся отдельная таблица маршрутизации и правило ip rule, привязанное к адресу источника.

Kill switch: защита при обрыве туннеля​

Если туннель падает, трафик может пойти напрямую через WAN — это утечка. Kill switch блокирует исходящий трафик при отсутствии активного VPN-соединения.

На OpenWrt реализуется через firewall: разрешить исходящий трафик из LAN только через интерфейс wg0, запретить через eth0 (WAN). Если wg0 падает, пакеты не проходят.

## Разрешить LAN → wg0
iptables -A FORWARD -i br-lan -o wg0 -j ACCEPT
## Запретить LAN → WAN (кроме уже установленных)
iptables -A FORWARD -i br-lan -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i br-lan -o eth0 -j DROP

На Keenetic аналогичная логика настраивается через приоритеты подключений: если VPN-интерфейс назначен единственным шлюзом по умолчанию, при его недоступности трафик не пойдёт через резервный WAN.

Проверка результата​

После настройки нужно убедиться, что туннель работает и утечек нет:

1. Проверка IP-адреса. С любого устройства в домашней сети открыть https://2ip.ru или https://ifconfig.me. Показанный IP должен совпадать с адресом VPN-сервера, а не провайдера.
   
2. Проверка DNS. На https://browserleaks.com/dns или https://dnsleaktest.com убедиться, что резолвер принадлежит VPN-провайдеру или выбранному DoH-сервису, а не ISP.
   
3. Проверка WebRTC. На https://browserleaks.com/webrtc — WebRTC может раскрыть реальный IP даже при работающем VPN. На роутере это не лечится, но браузеры можно настроить на отключение WebRTC или использование proxy.
   
4. Трассировка. traceroute до внешнего хоста должен показывать первый хоп как VPN-сервер, а не шлюз провайдера.
   

Типичные ошибки​

• Забыт masquerade на VPN-интерфейсе. Пакеты из LAN уходят в туннель с приватными адресами 192.168.x.x, сервер их отбрасывает. Решение: включить NAT (masquerade) на wg0.
  
• MTU слишком высокий. WireGuard добавляет заголовок к каждому пакету. Если MTU на wg0 равен 1500, фрагментация может ломать соединения. Стандартное решение — MTU 1420 для WireGuard, 1400 для OpenVPN.
  
• DNS не перенаправлен. Устройства используют 8.8.8.8 напрямую, минуя туннель. Провайдер видит все запросы. Решение — принудительное перенаправление порта 53.
  
• Нет PersistentKeepalive. За NAT провайдера маппинг UDP-порта истекает через 30–120 секунд. Без keepalive туннель «засыпает» и восстанавливается только при входящем пакете. Значение 25 секунд покрывает большинство NAT.
  
• Конфликт подсетей. Если VPN-сервер выдаёт адрес из подсети 192.168.1.0/24, а локальная сеть роутера тоже 192.168.1.0/24, маршрутизация ломается. Решение — сменить подсеть LAN или попросить провайдера другой диапазон.
  

Производительность​

Шифрование на роутере нагружает CPU. WireGuard использует ChaCha20-Poly1305 и работает в ядре, что даёт высокую скорость даже на слабых устройствах. Ориентиры:

• Роутеры на MediaTek MT7621 (MIPS, ~880 MHz): 50–80 Мбит/с через WireGuard.
  
• Роутеры на Qualcomm IPQ (ARM Cortex-A53): 150–300 Мбит/с.
  
• x86-мини-ПК (J4125, N5105): 500+ Мбит/с.
  

OpenVPN в userspace обычно даёт в 2–3 раза меньшую пропускную способность на том же железе из-за контекстных переключений и TLS-handshake.

Если скорость критична, а роутер слабый, варианты: аппаратное ускорение (если прошивка поддерживает offload для VPN), переход на x86-платформу или использование WireGuard вместо OpenVPN.

Источники​

• WireGuard: fast, modern, secure VPN tunnel