Как подключить OpenWrt к OpenVPN-серверу и пустить через него всю домашнюю сеть

MAATRIX · Обновлено 24 октября 2026

Файл .ovpn, который на телефоне импортируется в одно касание, роутеру с OpenWrt не даёт полной картины. В профиле есть адрес сервера и сертификаты. В нём нет указаний, каким сетевым интерфейсом станет туннель, в какую зону firewall он попадёт и каким устройствам разрешено им пользоваться. В этой статье по шагам разберём, как задать всё это в LuCI, а затем проверить внешний IP, DNS, IPv6 и поведение сети при обрыве соединения.

Схема простая: OpenWrt уже установлен и работает, есть одна локальная сеть LAN и один провайдер. Роутер подключается клиентом к OpenVPN-серверу на VPS, а устройства в LAN выходят в интернет через этот туннель без собственного VPN-клиента. Удалённый доступ к домашней сети снаружи, например к NAS, устроен по-другому, и здесь он не рассматривается. Если у вас Xiaomi AX3000T или Redmi AX6000, сначала уточните точную модель и аппаратную ревизию по материалу о совместимости Xiaomi/Redmi и подготовке OpenWrt. Для этих моделей есть отдельное руководство: OpenVPN на Xiaomi AX3000T и Redmi AX6000.

Подготовьте доступ, резервную копию и профиль

Понадобятся доступ к LuCI, свежая резервная копия настроек (System → Backup / Flash Firmware) и рабочий клиентский профиль. Для роутера удобнее выпустить отдельный профиль, а не использовать тот, что уже стоит на телефоне. Если сервер разворачивается специально для этой задачи, лучше взять новый VPS. Переустановка ОС на машине с работающими приложениями удалит их данные.

Локация VPS определяет, из какой страны сервисы увидят ваш трафик. От смены IP не меняются требования сервиса к аккаунту и списку поддерживаемых регионов, поэтому нужный сервис стоит проверить отдельно, когда туннель уже заработает.

Проверьте файл .ovpn, ничего не удаляя из защиты

Откройте копию профиля в текстовом редакторе. Нужно убедиться, что это объединённый файл: адрес сервера в строке remote, протокол и порт, а сертификаты и ключи встроены в сам файл блоками <ca>, <cert>, <key>, а также <tls-auth> или <tls-crypt>, если сервер их использует. Если вместо блоков указаны пути к файлам на чужом компьютере, попросите у администратора сервера объединённый профиль.

Директивы remote-cert-tls server и verify-x509-name, CA-сертификат и ключи tls-auth/tls-crypt оставьте в файле, даже если импорт или подключение сначала завершаются ошибкой. Они подтверждают, что роутер разговаривает с вашим сервером, а не с посредником. Почему это важно, объясняет документация OpenVPN: проверка сертификата сервера и атака «человек посередине». Транспорт тоже не меняйте: если в профиле proto udp, сервер слушает UDP на указанном порту, и переход на TCP со стороны клиента ничего не исправит.

Логин и пароль нужны, только если в профиле есть директива auth-user-pass, то есть сервер действительно требует такой авторизации. Профили с сертификатной авторизацией, как у OpenVPN-серверов MAATRIX, обходятся без них. Пароль от личного кабинета или root-пароль VPS в поля VPN-клиента вводить нельзя.

Установите пакеты OpenVPN для своей версии OpenWrt

Набор пакетов один и тот же: openvpn-openssl и luci-app-openvpn. Пакетный менеджер зависит от выпуска. Начиная с OpenWrt 25.12 используется apk, в 24.10 и более ранних используется opkg. Подробности есть в заметках к выпуску 25.12. Выполняйте команды только для своей версии и не подключайте репозитории другого выпуска. Ветка 24.10 старше, поэтому при новой установке ориентируйтесь на актуальную поддерживаемую версию для вашей модели.

OpenWrt 25.12 и новее

apk update
apk add openvpn-openssl luci-app-openvpn

OpenWrt 24.10

opkg update
opkg install openvpn-openssl luci-app-openvpn

Без консоли то же самое делается в System → Software: обновите список пакетов и установите оба пакета. После установки выйдите из LuCI и войдите снова. В меню должен появиться раздел VPN → OpenVPN. Названия пунктов меню в разных версиях LuCI могут немного отличаться.

Создайте экземпляр OpenVPN из профиля

В VPN → OpenVPN найдите загрузку файла конфигурации, задайте имя экземпляра, например maatrix, и импортируйте .ovpn. Официальное описание этого шага есть в руководстве OpenVPN client using LuCI.

Откройте редактирование созданного экземпляра и замените строку dev tun на фиксированное имя устройства:

dev tun_maatrix

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

Добавьте интерфейс для туннеля

В Network → Interfaces создайте интерфейс ovpn_maatrix с протоколом Unmanaged и устройством tun_maatrix. Пока OpenVPN не запущен, такого устройства нет в выпадающем списке, поэтому впишите имя вручную в поле пользовательского устройства. Unmanaged означает, что OpenWrt не будет запрашивать адрес по DHCP: адрес туннелю назначает сам процесс OpenVPN.

Создайте зону firewall и разрешите LAN выход в туннель

В Network → Firewall добавьте новую зону ovpn со следующими параметрами:

• Covered networks: ovpn_maatrix;
• Input: Reject, Output: Accept, Forward: Reject;
• Masquerading и MSS clamping: включены;
• Allow forward from source zones: lan.

Masquerading нужен потому, что обычный клиентский профиль рассчитан на один адрес клиента в VPN-сети. Сервер ничего не знает о вашей домашней подсети, и с NAT он видит весь трафик от адреса роутера. MSS clamping снижает риск проблем с крупными пакетами в туннеле. Разрешать пересылку из ovpn в lan не нужно: ответы на запросы домашних устройств проходят как часть уже установленных соединений.

Интерфейс туннеля должен входить только в эту зону. Если одновременно добавить его в WAN, проверять настройки станет сложнее, а для запрета обхода, о котором речь пойдёт ниже, нужна именно отдельная зона. Входящие соединения из WAN не открывайте: клиенту OpenVPN они не нужны. Как сети привязываются к зонам, описано в обзоре firewall OpenWrt.

Направьте трафик в туннель и сохраните маршрут к серверу

Чтобы весь IPv4-трафик пошёл через VPN, клиент должен применить директиву:

redirect-gateway def1

Её может присылать сервер, или она уже записана в профиле. Если её нет ни там, ни там, добавьте эту строку в конфигурацию экземпляра. Если в профиле есть route-nopull или фильтры, отбрасывающие маршруты сервера, профиль, вероятно, делался для доступа к отдельной сети, и сначала уточните его назначение у администратора.

Вариант def1 не удаляет основной маршрут по умолчанию. Он добавляет два более узких маршрута, 0.0.0.0/1 и 128.0.0.0/1, через туннель, а к самому VPN-серверу оставляет путь через прежний шлюз провайдера. Без этого исключения зашифрованные пакеты попытались бы уйти внутрь собственного туннеля. Описание директивы есть в руководстве OpenVPN 2.6. Если на роутере уже работают policy routing или несколько WAN, этих настроек может не хватить: существующие правила способны отправить пакеты в другие таблицы маршрутизации.

Подготовьте DNS и время до запуска туннеля

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

Проще всего, когда в строке remote указан числовой IP сервера, как в профилях MAATRIX. Тогда для подключения DNS вообще не нужен. Если в профиле доменное имя, роутер должен суметь разрешить его через провайдера до старта туннеля. Это нужно учесть и позже, при ограничении DNS-запросов в WAN.

Для времени в System → System → Time Synchronization включите NTP-клиент и добавьте сервер с числовым адресом, например 162.159.200.1 из документации Cloudflare. Затем в Network → Routing создайте для него статический маршрут /32 через WAN: при Ethernet-подключении укажите шлюз провайдера, при PPPoE выберите интерфейс подключения без шлюза. Если шлюз выдаётся по DHCP и меняется, маршрут придётся обновлять. После перебоя с питанием роутер выставит часы через провайдера, а не будет ждать туннеля, которому эти часы нужны для запуска.

DNS для домашних устройств задайте явно. Опции DNS, присланные сервером OpenVPN, на Linux не всегда автоматически попадают в системный резолвер. В Network → DHCP and DNS укажите в DNS forwardings резолвер, доступный через ваш сервер, например 1.1.1.1, или внутренний DNS, если его выдал администратор VPN. Включите Ignore resolve file, чтобы dnsmasq не брал DNS провайдера. Клиенты в LAN по-прежнему должны получать адрес роутера в качестве DNS.

Решите, что делать с IPv6

Директива redirect-gateway def1 касается только IPv4. Если провайдер выдаёт IPv6, а профиль VPN рассчитан только на IPv4, устройства продолжат открывать IPv6-сайты напрямую через провайдера. В таком случае отключите для LAN раздачу IPv6: Router Advertisement, DHCPv6 и делегирование префикса. Интерфейс WAN6 можно выключить, если он обслуживает только эту сеть. После изменений переподключите клиентские устройства, чтобы они забыли старые IPv6-адреса.

Полноценный IPv6 через VPN требует адресации и маршрутизации на стороне сервера. Дописать одну директиву в готовый IPv4-профиль для этого недостаточно.

Запустите туннель и посмотрите журнал

Включите автозапуск экземпляра и запустите его в VPN → OpenVPN. Журнал доступен в Status → System Log, а в консоли его удобно смотреть так:

logread -e openvpn
ip address show dev tun_maatrix

В журнале должна появиться запись о завершённой инициализации, а у tun_maatrix — адрес. Затем проверьте маршруты. В примере ниже 203.0.113.10 — документационный адрес, вместо него подставьте реальный IPv4 своего VPS:

ip -4 route
ip -4 route get 203.0.113.10
ip -4 route get 198.51.100.20

Маршрут к серверу должен идти через WAN-интерфейс, а к произвольному внешнему адресу — через tun_maatrix.

Проверьте результат с домашнего устройства

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

1. Внешний IPv4 на любом сервисе определения адреса должен совпадать с адресом VPS.
2. Сайты должны открываться по именам. DNS-тест покажет резолвер, который в итоге обработал запрос. Название резолвера само по себе не доказывает утечку и не говорит, каким путём шёл запрос. Сверяйте результат с тем, что указано в DNS forwardings, и с маршрутом к этому адресу.
3. IPv6-тест должен показать либо отсутствие IPv6, либо адрес, который выдаёт ваш VPN. Адреса домашнего провайдера там быть не должно.

Запретите выход в обход туннеля и проверьте обрыв

Пока в firewall разрешена пересылка lan → wan, при падении туннеля устройства тихо переключатся на прямой выход через провайдера. Для доступности это удобно, но защиты от утечки не даёт.

Строгий вариант делается так: в настройках зоны lan уберите wan из разрешённых направлений пересылки и оставьте ovpn. Гостевые сети, отдельные VLAN и собственные правила проверьте по отдельности: изменение основной LAN на них не распространяется.

DNS-запросы самого роутера через пересылку LAN не проходят. Чтобы при упавшем туннеле они не уходили провайдеру, в Network → Firewall → Traffic Rules добавьте правило: источник — сам роутер (output), назначение — wan, протоколы TCP и UDP, порты 53 и 853, действие Reject. Если ваш OpenVPN-сервер слушает порт 53 или 853, сначала создайте выше этого правила разрешение для исходящих соединений роутера к IPv4 VPS по нужному протоколу и порту, иначе блокировка остановит сам туннель. Если в remote указано доменное имя, учтите, что после этого правила роутер не сможет разрешить его через провайдера. Правило не затрагивает DoH на порту 443 и другие службы роутера: для них нужны свои правила.

Теперь проверьте поведение при обрыве. Остановите экземпляр OpenVPN и откройте с ноутбука новое соединение, например сайт, который вы ещё не посещали, или проверку IP в приватном окне. Страница, загруженная из кеша, ничего не докажет. Интернет должен перестать работать, а LuCI — остаться доступным. После повторного запуска туннеля снова проверьте внешний IP.

Разберите типичные сбои

Ошибки TLS при подключении чаще всего связаны со временем на роутере, сертификатами или несовпадением параметров с сервером. Подробный разбор есть в статье OpenVPN: TLS handshake failed. Если туннель поднялся, а внешний IP не изменился, проверьте маршруты def1 и привязку LAN к зоне ovpn. Если IP сменился, но сайты не открываются по именам, ищите причину в DNS forwardings и в доступности выбранного резолвера через туннель. Обрывы только на крупных загрузках обычно указывают на MTU/MSS или потери пакетов. Проверку сертификатов они не затрагивают, и отключать её не нужно.

Перед строгой проверкой обрыва учтите таблицу установленных соединений и flow offloading: изменение пересылки LAN → WAN не обязательно сразу остановит уже существующие сеансы. Для проверки начните новые соединения с тестового устройства, а при необходимости временно отключите ускорение потоков и завершите его старые сеансы. Отдельно проверьте IPv6 и собственные запросы роутера.

Верните прежний интернет при необходимости

Откат делается из LAN: остановите экземпляр OpenVPN, верните пересылку lan → wan, удалите правило блокировки DNS и восстановите прежние настройки DNS и IPv6. Профиль и резервную копию сохраните, чтобы позже вернуться к настройке.

Если OpenVPN для вашей задачи не подходит, на OpenWrt можно настроить и другие протоколы: WireGuard или AmneziaWG. Сравнение вариантов для разных роутеров собрано в обзоре VPN на роутере для всего дома.