OpenVPN-клиент на UniFi Gateway: подключение к своему серверу, маршрут и проверка

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

Если OpenVPN-сервер уже работает, подключение можно перенести с отдельных компьютеров на шлюз UniFi. Для этого шлюз должен сначала поднять туннель по файлу .ovpn, а затем получить отдельное правило маршрутизации, которое определяет, какие устройства отправляют трафик через туннель. Ниже по шагам разобраны подготовка, импорт профиля, маршрут для одного тестового устройства, проверка внешнего IP, DNS и IPv6 и поведение при обрыве.

Убедитесь, что у вас шлюз с OpenVPN-клиентом

По официальной инструкции Ubiquiti, OpenVPN-клиент есть в шлюзах линеек Next-Gen UniFi Gateway и UniFi Cloud Gateway. Речь именно о шлюзе, через который офис или дом выходит в интернет. Точка доступа UniFi, даже управляемая из того же приложения, VPN-клиентом не является. Возможности старых USG и устройств EdgeRouter нужно сверять отдельно, по документации к конкретной модели.

Пункты меню и набор полей зависят от версии приложения UniFi Network и прошивки шлюза. Поэтому перед началом запишите обе версии. Названия разделов в этой статье приведены для Network 9.3 и 9.4. В других версиях они могут отличаться.

Подготовьте профиль и выясните способ авторизации

Нужен клиентский профиль OpenVPN, выданный для вашего сервера. Для выхода в интернет обычно используется конфигурация с интерфейсом TUN, в которой сертификат удостоверяющего центра, клиентский сертификат и ключ встроены прямо в файл. Если профиль ссылается на внешние файлы вроде ca.crt или client.key, попросите у администратора единый файл со встроенными блоками. Импорт в UniFi рассчитан на один загружаемый профиль.

Перед импортом откройте файл в текстовом редакторе и найдите основные строки. Ниже пример структуры. Адрес взят из документационного диапазона, ключи заменены заглушками:

client
dev tun
proto udp
remote 203.0.113.10 1194
remote-cert-tls server
<ca>
-----BEGIN CERTIFICATE-----
EXAMPLE-CA-CERTIFICATE-PLACEHOLDER
-----END CERTIFICATE-----
</ca>
<cert>
EXAMPLE-CLIENT-CERTIFICATE-PLACEHOLDER
</cert>
<key>
EXAMPLE-PRIVATE-KEY-PLACEHOLDER
</key>

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

Дальше выясните, как сервер узнаёт клиента. Есть два основных варианта:

• Только сертификат. Клиент предъявляет сертификат и ключ из профиля, поля логина и пароля в UniFi остаются пустыми.
• Сертификат и учётная запись. Сервер дополнительно запрашивает VPN-логин и пароль. Признак такого профиля — строка auth-user-pass. Эти данные выдаёт администратор VPN-сервера.

VPN-логин не имеет отношения к паролю root на VPS, паролю от панели хостинга или учётной записи администратора UniFi. Если сервер не просит учётные данные, поля оставляют пустыми. Подставлять туда другие пароли бесполезно: это лишь раскладывает лишний секрет по системам, где ему нечего делать.

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

Учтите и ограничения самого профиля. Корпоративный сервер может разрешать подключение только отдельным устройствам, выдавать адреса из диапазона, который пересекается с вашей локальной сетью, или запрещать выход в интернет через туннель. Прежде чем отправлять в туннель целую сеть, уточните у администратора, допустимо ли это. Если сервер ваш, его можно развернуть на VPS MAATRIX, выбрав OpenVPN при установке, и сразу выпустить отдельный профиль для шлюза. Локацию выбирайте по задаче и измеренной задержке. Доступность конкретных зарубежных сервисов зависит ещё и от их собственных правил, поэтому смена точки выхода не гарантирует, что любой сервис заработает.

Сделайте резервную копию и запишите исходное состояние

Сохраните резервную копию конфигурации UniFi и работайте из локальной сети, а не через удалённый доступ, который зависит от шлюза. Проверьте, что время на шлюзе установлено верно: от него зависит проверка сроков действия сертификатов.

Выберите одно тестовое устройство, например ноутбук, и убедитесь, что его шлюзом по умолчанию служит UniFi. Пока туннеля нет, запишите с этого ноутбука три значения: внешний IPv4, внешний IPv6, если он есть, и результат DNS-теста. Позже результаты будет с чем сравнивать.

Сверьте адресацию. Подсеть локальной сети, например 192.168.1.0/24, не должна совпадать с подсетью, которую сервер выдаёт VPN-клиентам. При пересечении часть адресов окажется недоступной, причём без понятных сообщений об ошибке.

Импортируйте профиль в UniFi Network

В приложении UniFi Network откройте Settings → VPN → VPN Client, создайте подключение типа OpenVPN и загрузите файл .ovpn. Дайте подключению понятное имя, например OpenVPN-FR-Office. Логин и пароль введите только если сервер использует учётные записи. Затем примените настройки.

Если интерфейс отказывается принимать файл, запишите точный текст ошибки. Клиент OpenVPN в шлюзе поддерживает определённый набор директив, и он зависит от версии прошивки. Директива, которую понимает настольный клиент, может оказаться для шлюза неизвестной. Правильный путь — получить у администратора профиль, совместимый с вашим клиентом. Удалять строки, связанные с сертификатами и TLS, ради успешной загрузки нельзя.

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

Создайте маршрут для тестового устройства

Поднятый туннель сам по себе не меняет путь трафика. Ubiquiti прямо указывает, что после подключения нужно создать отдельный Traffic Route. Где он находится, зависит от версии Network:

• в Network 9.4 — Settings → Policy Table → Create New Policy, тип Route;
• в Network 9.3 — Settings → Policy Engine → Policy-Based Routes → Create Route.

В правиле укажите:

1. Interface — созданное OpenVPN-подключение.
2. Source — только тестовый ноутбук.
3. Destination — Any, чтобы через туннель шёл весь внешний трафик устройства.
4. Kill Switch — включите, если при отказе туннеля устройство не должно выходить в интернет напрямую через провайдера.

Назначение поля Kill Switch и порядок применения правил описаны в документации UniFi по маршрутизации на основе политик. Kill Switch задаётся в самом правиле маршрута, а не в настройках VPN-клиента. Поэтому после сохранения откройте правило ещё раз и убедитесь, что переключатель действительно включён.

Проверьте, нет ли других правил для того же устройства или его сети: правило, стоящее выше, может перехватить трафик. На первом этапе направлять в туннель весь трафик проще, чем перечислять отдельные домены. У многих сервисов авторизация, загрузка файлов и основное приложение работают на разных адресах. Позже такие устройства можно вынести в отдельную VLAN и назначить маршрут ей целиком.

Проверьте внешний IP, DNS и IPv6

Внешний IPv4

Откройте на ноутбуке сервис проверки IP. Адрес должен совпадать с внешним адресом VPN-сервера, а не провайдера. Если туннель на шлюзе поднят, а адрес прежний, проблема в маршруте: неверный источник, другое правило с более высоким приоритетом или ноутбук выходит в сеть не через UniFi. Затем проверьте нужное приложение целиком: вход в аккаунт, обычную операцию и загрузку небольшого несекретного файла. Новый IP подтверждает только то, что маршрут работает. Работает ли само приложение, показывает этот функциональный тест.

DNS

Выясните, какой DNS-сервер получает ноутбук и через какой интерфейс идут запросы. Браузер со встроенным DNS-over-HTTPS, системные настройки и настройки шлюза могут указывать на разные резолверы. На время проверки оставьте одну понятную схему, например системный DNS через шлюз.

Онлайн-тест DNS показывает, какой резолвер обработал запрос. Путь запроса до этого резолвера он не показывает. Если в результате видно имя крупного публичного резолвера или вашего провайдера, это ещё не означает утечку: запрос мог дойти до него через туннель. Чтобы делать выводы, сопоставьте настройки DNS на ноутбуке и шлюзе, маршрут до адреса резолвера и, при возможности, журнал или захват трафика на WAN-интерфейсе. Если позже понадобятся правила маршрутизации по доменам, клиенты должны пользоваться DNS через UniFi Gateway. Собственный DoH в браузере такую схему обходит.

IPv6

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

Размер пакета

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

Разберите ошибки по журналу

Сообщения в журнале подключения обычно указывают, на каком этапе произошёл сбой.

Ошибку сертификата устраняют, исправляя время, сроки или цепочку доверия. Отключение проверки только скрывает сообщение и снимает защиту от подмены сервера. Если сервер слушает UDP, перевод профиля на TCP не поможет: транспорт должен совпадать с обеих сторон. Значения директив сверяйте с руководством OpenVPN 2.6, но помните, что клиент в шлюзе может поддерживать не все из них.

Для обращения в поддержку подготовьте модель шлюза, версии Network и прошивки, время ошибки и фрагмент журнала, из которого удалены ключи, пароли и лишние адреса. Закрытый ключ для разбора проблемы не нужен.

Проверьте поведение при обрыве туннеля

Чтобы проверить Kill Switch, разорвите туннель по-настоящему: например, ненадолго остановите службу OpenVPN на своём тестовом сервере, не трогая правило в UniFi. На корпоративном сервере такие действия согласуйте с администратором.

Пока туннель лежит, откройте с тестового ноутбука новые адреса, которые раньше не посещались, и обновите страницу проверки IP с принудительной загрузкой без кеша. Страница, уже открытая в браузере или взятая из кеша, о доступе в сеть ничего не говорит. При включённом Kill Switch новые внешние соединения должны перестать устанавливаться. Если прямой выход разрешён, проверка IP должна показать адрес провайдера. После запуска службы туннель должен восстановиться, а внешний адрес снова смениться на адрес сервера.

Если у шлюза несколько WAN-подключений, повторите проверку при переключении на резервный канал. Поведение правил при смене WAN стоит увидеть своими глазами, а не выводить из настроек.

Откатите настройку или расширьте её на другие устройства

Для отката отключите или удалите правило маршрута вместе с Kill Switch, затем остановите VPN-клиент и убедитесь, что ноутбук снова получает адрес провайдера. Если что-то пошло не так глубже, восстановите сохранённую резервную копию.

Когда тестовое устройство работает стабильно, добавляйте остальные небольшими группами или через отдельную VLAN и после каждого шага повторяйте проверку IP, DNS и IPv6. Запишите, какой профиль используется, какое поведение при обрыве выбрано и в какой версии Network всё настраивалось. Если OpenVPN не обязателен, сравните этот вариант с WireGuard на UniFi Gateway. Обзор других роутеров и протоколов есть в материале о VPN на роутере для всего дома.