Настройка OpenVPN-клиента на MikroTik: подключаем роутер к существующему серверу

MAATRIX · ОБНОВЛЕНО 24 ОКТЯБРЯ 2026

Сервер OpenVPN уже работает, ноутбуки и телефоны к нему подключаются. Теперь к нему нужно подключить сам MikroTik, чтобы через туннель выходили устройства домашней или офисной сети без собственного VPN-клиента: телевизор, приставка, рабочие компьютеры. RouterOS умеет это штатно, но у её реализации OpenVPN есть особенности. Если не учитывать их заранее, легко потерять пару вечеров на разборе логов.

Статья написана для RouterOS 7. В шестой ветке клиент OpenVPN заметно беднее: нет UDP, нет GCM-шифров, нет импорта профиля. Если роутер ещё на шестой версии, разумнее начать с обновления. Набор параметров и внутри седьмой ветки менялся от релиза к релизу, поэтому сверяйте команды со своей версией и её changelog. Все адреса ниже демонстрационные: сервер 203.0.113.10, VPN-подсеть 10.8.0.0/24 с сервером на 10.8.0.1, локальная сеть 192.168.88.0/24, роутер 192.168.88.1. Это согласованный учебный пример, а не конфигурация, которую можно вставить в любой роутер без правок.

Что выяснить на сервере до начала

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

grep -E "^(port|proto|cipher|data-ciphers|auth|tls-crypt|tls-auth|comp-lzo|compress|allow-compression)" /etc/openvpn/server.conf

Путь к файлу зависит от установки: на многих системах конфиг лежит в /etc/openvpn/server/. Запишите порт, протокол, шифры данных и алгоритм auth. Их придётся повторить на роутере.

Отдельно посмотрите на сжатие. RouterOS сжатие в OpenVPN не поддерживает. Если на сервере включены comp-lzo или compress, MikroTik либо не подключится, либо соединение будет обрываться сразу после рукопожатия. Сжатие в OpenVPN к тому же давно считается небезопасным, так что лучше всего отключить его на сервере. Если этого нельзя сделать из-за старых клиентов, поднимите для роутера отдельный экземпляр сервера на другом порту.

Ключ дополнительной защиты (tls-auth или tls-crypt) отключать ради роутера не нужно. tls-auth обычно проходит при импорте полного .ovpn-профиля. Поддержка tls-crypt появилась в более поздних релизах седьмой ветки: в описаниях изменений называют 7.17, но проверьте это по changelog своей версии. Если нужного поля нет в Winbox, функция всё равно может быть доступна через импорт профиля. Если же ваша версия не поддерживает механизм, который использует сервер, обновите RouterOS. Ослаблять защиту сервера, к которому подключаются и другие клиенты, нельзя.

И последнее: выпустите для роутера собственный клиентский сертификат. Когда один сертификат используется одновременно на ноутбуке и на MikroTik, подключения выбивают друг друга. Включённый на сервере duplicate-cn эту проблему маскирует, зато потом нельзя отозвать доступ у одного конкретного устройства.

Перенос и импорт сертификатов

Есть два пути. Самый простой — загрузить готовый .ovpn-профиль в Files и импортировать его:

/interface ovpn-client import-ovpn-configuration file-name=client.ovpn skip-cert-import=no

Если сервер дополнительно проверяет логин и пароль, у команды есть параметры для них. Импорт не гарантирует, что RouterOS поймёт каждую директиву профиля, поэтому после него посмотрите лог и проверьте получившийся интерфейс в /interface ovpn-client print detail. Особенно важны проверка серверного сертификата, маршруты и DNS. О них речь пойдёт ниже.

Второй путь — ручная настройка, она нагляднее. Скопируйте на роутер три файла: сертификат центра сертификации, клиентский сертификат и его ключ. Если сервер собирали на easy-rsa, они обычно лежат в каталоге pki.

scp ca.crt client.crt client.key admin@192.168.88.1:

Затем импортируйте их. Сначала сертификаты, потом ключ:

/certificate import file-name=ca.crt passphrase=""
/certificate import file-name=client.crt passphrase=""
/certificate import file-name=client.key passphrase=""
/certificate print

Если ключ зашифрован паролем, укажите его в passphrase. В выводе print смотрите на флаги. У клиентского сертификата должен быть флаг K: он означает, что приватный ключ привязан. Если флага нет, чаще всего ключ импортировали раньше сертификата. Удалите обе записи и повторите импорт в правильном порядке. Флаг T у CA означает доверие, без него проверка сервера не пройдёт. Флаг E говорит, что срок действия истёк. Сначала проверьте часы роутера, и только потом сам сертификат.

При импорте RouterOS обычно добавляет к имени суффикс, и получается что-то вроде ca.crt_0 и client.crt_0. Дальше используйте именно фактические имена из print, иначе получите ошибку no such item. Если у CA нет доверия, выставьте его вручную:

/certificate set ca.crt_0 trusted=yes

Пока вы здесь, включите NTP. У многих моделей MikroTik нет часов с батарейкой. После отключения питания роутер стартует с неверной датой, сертификаты выглядят недействительными, и туннель не поднимается:

/system ntp client set enabled=yes servers=pool.ntp.org

Создание интерфейса

Пример рассчитан на сервер с UDP, AES-256-GCM и SHA256 без tls-auth/tls-crypt. Если на сервере включён один из этих механизмов, создавайте интерфейс импортом профиля, как описано выше.

/interface ovpn-client add name=ovpn-to-server \
    connect-to=203.0.113.10 port=1194 protocol=udp \
    mode=ip user=router1 password="" \
    cipher=aes256-gcm auth=sha256 \
    certificate=client.crt_0 \
    verify-server-certificate=yes \
    add-default-route=no route-nopull=yes use-peer-dns=no \
    disabled=no

Что здесь заменить и зачем это нужно:

• connect-to, port, protocol должны совпадать с сервером. UDP предпочтительнее: при потерях пакетов TCP поверх TCP заметно проседает.
• mode=ip соответствует dev tun на сервере. Режим ethernet (tap) нужен, только если сервер работает в tap-режиме и вам действительно нужен мост на канальном уровне.
• cipher и auth должны совпадать с настройками сервера. При несовпадении в логе обычно видно только невнятный разрыв.
• user в некоторых версиях не может быть пустым. При аутентификации только по сертификату впишите любое значение. Если сервер проверяет логин, укажите настоящую пару.
• certificate — фактическое имя клиентского сертификата из /certificate print.
• verify-server-certificate=yes оставляйте включённым с первого подключения. CA должен быть доверенным. Надёжнее всего, когда адрес или имя в connect-to совпадает с CN/SAN серверного сертификата. Если проверка не проходит, разбирайтесь с часами, цепочкой доверия и именем сервера, а не отключайте её.
• add-default-route=no, route-nopull=yes, use-peer-dns=no означают, что маршруты и DNS вы зададите сами. Так понятно, куда идёт трафик, и управление роутером не пропадёт в момент подключения.

В Winbox это же находится в PPP → Interface → «+» → OVPN Client.

Проверка самого туннеля

До маршрутизации стоит убедиться, что соединение установлено:

/interface ovpn-client monitor ovpn-to-server once
/log print where topics~"ovpn"
/ping 10.8.0.1 interface=ovpn-to-server count=5

В monitor должен быть статус connected и адрес из VPN-подсети, в логе — сообщение об успешном подключении. Пинг до сервера внутри туннеля проходит, только если сервер не блокирует ICMP. Если по логам кажется, что подключение есть, а пинга нет, сначала проверьте firewall на сервере. На время отладки можно сохранять подробный лог в оперативной памяти и потом удалить это правило:

/system logging add topics=ovpn action=memory

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

Вариант 1: весь трафик сети через сервер

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

/ip route print detail where dst-address=0.0.0.0/0

Затем добавьте маршрут до сервера через ваш реальный шлюз. При PPPoE в качестве шлюза можно указать интерфейс, например pppoe-out1:

/ip route add dst-address=203.0.113.10/32 gateway=ВАШ_WAN_ШЛЮЗ comment="vpn server via WAN"

Если адрес шлюза выдаётся провайдером по DHCP и может меняться, статический маршрут однажды перестанет работать. Это стоит учитывать. Если в connect-to указано доменное имя, а не IP, роутер должен суметь разрешить его до поднятия туннеля. Самое простое решение — указать IP или добавить статическую запись в /ip dns static.

Теперь о приоритетах. Маршрут, полученный по DHCP или PPPoE, обычно имеет distance 1. Если добавить маршрут через VPN тоже с distance 1, получится два равноценных маршрута, и поведение будет совсем не тем, что ожидалось. Надёжнее понизить приоритет провайдерского маршрута, не удаляя его. Делайте это, подключившись к роутеру со стороны локальной сети: DHCP-клиент при изменении может кратковременно переподключиться.

# если WAN получает адрес по DHCP:
/ip dhcp-client set [find interface=ether1] default-route-distance=10
# если WAN — PPPoE:
/interface pppoe-client set pppoe-out1 default-route-distance=10

Имя интерфейса замените на своё. Проверьте, что после этого интернет работает, а маршрут /32 до сервера активен. Только потом добавляйте маршрут через туннель:

/ip route add dst-address=0.0.0.0/0 gateway=ovpn-to-server distance=1 comment="default via vpn"

Чтобы локальные адреса могли выходить в интернет через сервер, нужна трансляция адресов в сторону туннеля:

/ip firewall nat add chain=srcnat out-interface=ovpn-to-server action=masquerade

Учтите, что при обрыве туннеля маршрут через него становится неактивным, и трафик сам уходит через провайдера. Иногда именно это и нужно: интернет не пропадает, если сервер недоступен. Если же выход в обход VPN недопустим, запретите пересылку из локальной сети напрямую в WAN:

/ip firewall filter add chain=forward in-interface-list=LAN out-interface-list=WAN \
    action=drop comment="no direct exit"

Правило должно стоять выше разрешающих правил в цепочке forward и выше правила FastTrack. Расположение проверьте через /ip firewall filter print и при необходимости переместите правило командой move. Подключение самого роутера к серверу это правило не затрагивает: оно проходит через цепочку output, а не forward. Минус тоже очевиден: пока туннель лежит, у сети не будет интернета. Чтобы временно выйти напрямую, правило отключают вручную.

Если вместо полного туннеля нужно связать сети двух офисов, логика другая. Добавляются только маршруты к удалённым подсетям, например /ip route add dst-address=10.20.0.0/24 gateway=ovpn-to-server, а masquerade в сторону туннеля обычно не нужен: сети должны видеть реальные адреса друг друга.

Вариант 2: через VPN идут только выбранные устройства

Часто через сервер нужно пускать не всю сеть, а один телевизор или ноутбук. Остальной трафик идёт напрямую, роутер меньше нагружен шифрованием, а банковские приложения не реагируют на вход из другой страны. В этом сценарии маршрут по умолчанию в основной таблице остаётся провайдерским. Не добавляйте маршрут 0.0.0.0/0 через туннель в main и не меняйте distance WAN-маршрута. Маршрут /32 до сервера здесь не обязателен, потому что основная таблица и так ведёт к нему через провайдера.

Создайте отдельную таблицу маршрутизации с маршрутом по умолчанию через туннель и правила выбора таблицы:

/routing table add fib name=to-vpn
/ip route add dst-address=0.0.0.0/0 gateway=ovpn-to-server routing-table=to-vpn
/routing rule add dst-address=192.168.88.0/24 action=lookup-only-in-table table=main
/routing rule add src-address=192.168.88.50/32 action=lookup-only-in-table table=to-vpn

Правила проверяются по порядку. Первое оставляет локальный трафик внутри сети, второе отправляет всё остальное от 192.168.88.50 в туннель. Если у вас есть другие локальные подсети (гостевая сеть, VLAN, IoT), добавьте для них такие же правила с table=main выше правила для устройства. Иначе выбранное устройство перестанет их видеть. Уже существующие правила маршрутизации тоже могут сработать раньше. NAT нужен тот же, что и в первом варианте:

/ip firewall nat add chain=srcnat out-interface=ovpn-to-server action=masquerade

FastTrack здесь важен. Соединения, которые попали в FastTrack, обходят большую часть обработки, и policy routing с ними работает ненадёжно. Выбранные устройства лучше исключить из FastTrack. Удобнее всего сделать это через список адресов, в который вы добавите те же адреса, что и в правила маршрутизации:

/ip firewall address-list add list=via-vpn address=192.168.88.50
/ip firewall filter add chain=forward connection-state=established,related \
    src-address-list=via-vpn action=accept comment="via-vpn: skip fasttrack"
/ip firewall filter add chain=forward connection-state=established,related \
    dst-address-list=via-vpn action=accept comment="via-vpn: skip fasttrack"

Оба правила нужно переместить выше правила с action=fasttrack-connection. Они принимают только уже установленные соединения, новые по-прежнему проходят через ваши обычные правила.

Если туннель упал, маршрут в таблице to-vpn становится неактивным. При lookup-only-in-table пакет не должен уходить в основную таблицу. Но это поведение стоит проверить на своей версии, а не принимать на веру. Для гарантии добавьте явный запрет и поставьте его выше разрешающих правил forward:

/ip firewall filter add chain=forward src-address-list=via-vpn out-interface-list=WAN \
    action=drop comment="via-vpn: no direct exit"

Здесь запрет ограничен списком адресов. Вариант вроде out-interface=!ovpn-to-server для всей LAN заденет и трафик между локальными сетями.

Firewall: где должны стоять разрешения

В стандартной конфигурации RouterOS пересылка из LAN наружу обычно уже разрешена. Если же у вас строгий набор правил с запретом в конце, понадобится явное разрешение в сторону туннеля:

/ip firewall filter add chain=forward in-interface-list=LAN out-interface=ovpn-to-server action=accept

Добавлять его стоит, только если трафик действительно блокируется, и ставить перед запрещающим правилом. Правило в самом конце цепочки, после drop, ни на что не повлияет. Типичная картина: интерфейс поднят, сервер внутри туннеля пингуется, а ресурсы за ним недоступны. Почти всегда причина в маршруте или firewall, а не в самом OpenVPN.

DNS и IPv6

Туннель защищает трафик, но список посещаемых сайтов может по-прежнему уходить провайдеру через DNS. В полном туннеле достаточно направить собственные запросы роутера к резолверу, до которого он доходит через VPN. Устройствам в DHCP нужно раздавать адрес роутера:

/ip dns set servers=10.8.0.1 allow-remote-requests=yes
/ip dhcp-server network set [find where address=192.168.88.0/24] dns-server=192.168.88.1

10.8.0.1 подходит, только если на сервере действительно работает DNS-резолвер. Иначе укажите внешний резолвер, и запросы к нему пойдут маршрутом по умолчанию, то есть через туннель. При allow-remote-requests=yes убедитесь, что входящие запросы на порт 53 с WAN блокируются: в стандартной конфигурации это делает цепочка input, но если вы её меняли, проверьте. Проверьте также DNS-серверы, которые роутер получает динамически от провайдера: они отображаются в /ip dns print. У DHCP- и PPPoE-клиента можно отключить их приём (use-peer-dns=no).

Если на устройствах вручную прописаны чужие DNS-серверы, обычные запросы можно перехватить на роутер:

/ip firewall nat add chain=dstnat in-interface-list=LAN protocol=udp dst-port=53 \
    action=redirect to-ports=53

Для TCP добавляется такое же правило с protocol=tcp. Ни одно из них не затрагивает DNS-over-HTTPS и DNS-over-TLS, которые используют браузеры и некоторые приложения.

Во втором варианте ситуация другая. Сам роутер выходит в интернет через провайдера, поэтому его кэширующий DNS тоже ходит туда. Для выбранных устройств разумнее не отправлять запросы через роутер, а выдать им резолвер, до которого они дойдут по своей таблице, то есть через туннель. Это можно сделать через отдельную DHCP-аренду с нужной DNS-опцией или настройкой на самом устройстве. Общий redirect порта 53 в этом сценарии вернёт их запросы на роутер, учитывайте это.

С IPv6 тоже нужно разобраться отдельно. Если провайдер выдаёт IPv6, а туннель передаёт только IPv4, устройства спокойно ходят в интернет по IPv6 напрямую, и успешный тест IPv4-адреса этого не покажет. Если весь трафик должен идти через VPN, отключите раздачу IPv6 в локальную сеть или запретите пересылку IPv6 из LAN в WAN:

/ipv6 firewall filter add chain=forward in-interface-list=LAN out-interface-list=WAN action=drop

Отключение раздачи адресов обычно работает аккуратнее: при одном только запрете приложения сначала пытаются достучаться по IPv6 и ждут таймаута.

MTU и зависающие страницы

Если мессенджеры работают, а крупные страницы и загрузки зависают на середине, скорее всего, пакеты не помещаются в туннель после добавления заголовков. Помогает уменьшение MTU интерфейса и подстройка MSS для TCP:

/interface ovpn-client set ovpn-to-server max-mtu=1400
/ip firewall mangle add chain=forward protocol=tcp tcp-flags=syn action=change-mss \
    new-mss=clamp-to-pmtu out-interface=ovpn-to-server

1400 — только отправная точка. Подходящее значение зависит от канала: PPPoE, мобильный оператор и дополнительная инкапсуляция у провайдера уменьшают допустимый размер пакета. Подбирать его нужно измерением. Подстройка MSS помогает только TCP, а для UDP-трафика, например видеозвонков, важен правильный MTU.

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

Проверку лучше проводить по уровням и с того устройства, трафик которого должен идти через VPN, а не только с роутера. В полном туннеле /tool traceroute 8.8.8.8 на самом роутере должен показать первым хопом адрес из VPN-подсети. Во втором варианте трассировка с роутера пойдёт через провайдера, и это правильно: проверять нужно с выбранного устройства.

Дальше откройте на клиенте любой сервис определения внешнего IP. Должен отображаться адрес сервера. Если виден провайдерский адрес, проверьте маршрут, его distance и NAT. Затем проверьте DNS тестом на утечки. В результатах может оказаться внешний резолвер, который вы сами выбрали, а не VPS. Это не ошибка, если запрос до него идёт через туннель. Отдельно убедитесь, что устройство не получает IPv6-доступ напрямую.

Затем выключите туннель (/interface ovpn-client disable ovpn-to-server) и проверьте с тестового устройства, что происходит с новыми соединениями: интернет должен либо пропасть, либо пойти напрямую, в зависимости от того, что вы выбрали. Включите туннель обратно. Последняя проверка — длинный пинг одновременно со скачиванием большого файла. Провалы и обрывы под нагрузкой указывают на MTU или на нехватку процессора.

Когда всё работает, сохраните конфигурацию командой /export file=working-vpn и отдельно сохраните сертификаты и ключ в надёжном месте. В экспорт они не попадают.

Если что-то не работает

Разрыв на этапе рукопожатия обычно означает несовпадение cipher/auth, включённое на сервере сжатие или ключ tls-auth/tls-crypt, который клиенту не передали. Ошибки проверки сертификата связаны с часами, отсутствием доверия к CA или несовпадением имени сервера. Если туннель не поднимается после отключения питания, проверьте NTP и разрешение имени сервера: роутер не может разрешить домен через туннель, который ещё не поднялся. Иногда интерфейс числится подключённым, а трафик не идёт, обычно после смены внешнего адреса у провайдера. Для начала поможет ручное выключение и включение интерфейса. Автоматизировать это стоит только после того, как вы разберётесь в причине.

Меняйте по одному параметру за раз. Тогда по логу видно, что именно повлияло на результат.

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

На младших моделях MikroTik OpenVPN шифрует программно и опирается в основном на одно ядро. Потолок скорости определяет процессор, а не тариф. Конкретная цифра зависит от модели, версии RouterOS, шифра, MTU и всего, чем ещё занят роутер, поэтому измерять нужно у себя, например iperf3 до сервера. Во время теста откройте /system resource monitor: если загрузка процессора упирается в потолок, вы нашли ограничение. Улучшить ситуацию может UDP вместо TCP, AES-128-GCM вместо AES-256-GCM при согласии сервера и сокращение длинных цепочек firewall и очередей. Если скорости всё равно не хватает, имеет смысл сравнить на том же роутере WireGuard или IKEv2. OpenVPN оправдан прежде всего тогда, когда этого требует уже существующий сервер.

Если своего сервера пока нет, его можно развернуть на VPS. В MAATRIX есть виртуальные серверы с root-доступом в нескольких локациях, на них можно поднять OpenVPN или WireGuard под свою схему и подключить к нему MikroTik так, как описано выше.