Настройка VPN-клиента OpenVPN на Mikrotik

MAATRIX

Если у вас уже есть OpenVPN-сервер и нужно завести через него не отдельное устройство, а весь офис или дом целиком — логично подключить сам роутер Mikrotik в качестве клиента. RouterOS умеет это из коробки, но процесс не очевиден: сертификаты импортируются по отдельности, часть привычных опций OpenVPN здесь отсутствует, а «зелёный» статус интерфейса ещё ничего не гарантирует. Разберём по шагам — от файлов на сервере до проверки, что трафик реально идёт через туннель.

Что получится в итоге

• На роутере появляется виртуальный интерфейс (ovpn-to-server), который живёт постоянно и сам поднимается после разрывов и перезагрузки.
• Трафик локальной сети — весь или только выбранных устройств — уходит на сервер и выходит в интернет с его IP. На самих устройствах настраивать нечего: телефоны, телевизоры и приставки видят обычный Wi-Fi.
• DNS-запросы идут туда же, куда трафик, а не к провайдеру — иначе смысл туннеля теряется наполовину.
• В схеме «офис — сервер — офис» удалённые подсети видны как обычные маршруты, внутренние сервисы доступны по локальным адресам.

Чего не будет — чуда с производительностью: OpenVPN на младших Mikrotik шифрует программно и упирается в одно ядро, так что на слабом железе стоит заранее сравнить его с WireGuard-клиентом на Mikrotik.

Словарь: что означают все эти слова

Что подготовить на сервере

RouterOS не умеет проглотить единый .ovpn-файл — содержимое придётся разложить по отдельным файлам: ca.crt, client.crt, client.key. При схеме easy-rsa (как в установке OpenVPN на Ubuntu 24.04) они лежат в ~/openvpn-ca/pki/. Для роутера выпустите отдельный сертификат — как делать это пачкой, показано в разборе клиентских сертификатов easy-rsa.

scp ca.crt client.crt client.key admin@192.168.88.1:
grep -E "^(port|proto|cipher|data-ciphers|auth|tls-crypt|tls-auth|comp-lzo|compress)" /etc/openvpn/server.conf

Вторая команда показывает всё, что придётся повторить на роутере. Ограничения RouterOS, о которых молчат:

• Сжатие не поддерживается. Есть comp-lzo/compress на сервере — уберите их для этого клиента или поднимите ему отдельный инстанс на другом порту.
• tls-auth / tls-crypt. Поддержка общего ключа зависит от ветки RouterOS: посмотрите, есть ли поле в параметрах интерфейса вашей сборки. Нет поля — к серверу с tls-crypt не подключиться.
• Протокол. В шестой ветке клиент умел только TCP, UDP появился в седьмой. Нет поля protocol — вы на TCP, и это повод обновиться.
• Push-опции игнорируются. Маршруты и DNS, раздаваемые сервером через push, RouterOS не применяет — всё прописывается руками. Это и есть частая причина недоумения «на ноутбуке работает, на роутере нет».

Импорт сертификатов в RouterOS

Порядок важен: сначала сертификат, затем ключ.

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

Вывод читаем по флагам — это ключевой момент шага:

• K у client.crt — приватный ключ подхватился. Нет флага — подключения не будет; обычно .key импортировали раньше .crt: удалите оба и повторите.
• T у ca.crt — сертификату доверяем. Нет — выставьте вручную.
• E — срок истёк: либо сертификат правда просрочен, либо у роутера сбились часы.

Отдельная ловушка: при импорте RouterOS переименовывает сертификаты, добавляя суффикс — обычно выходит ca.crt_0 и client.crt_0. Дальше подставляйте фактические имена из /certificate print, иначе будет no such item:

/certificate set ca.crt_0 trusted=yes

Если позже клиент падает на рукопожатии — виноват чаще всего этот шаг; логика диагностики та же, что в разборе ошибки TLS handshake failed.

Создание OVPN-клиента

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

В Winbox то же самое: PPP → Interface → «+» → OVPN Client, вкладка Dial Out.

• cipher и auth обязаны совпадать с сервером. Если на сервере AES-256-GCM, а на роутере старый дефолт вроде blowfish128, согласования не будет, а в логе появится невнятный разрыв. При GCM целостность данных проверяет сам шифр, но auth участвует в контрольном канале — держите совпадающим.
• user и password. При аутентификации только по сертификатам логин не проверяется, но RouterOS требует непустое user — впишите любое. Если на сервере включена проверка логина, укажите реальную пару.
• verify-server-certificate=yes. По умолчанию выключено, и это плохо: без проверки роутер подключится к любому серверу с любым сертификатом. Включайте после того, как ca.crt импортирован и доверен.
• add-default-route=no. Маршруты лучше прописать вручную: так понятно, что происходит с трафиком, и вы не теряете управление роутером в момент подключения.

Статус — /interface ovpn-client print detail и /log print where topics~"ovpn". При успехе у интерфейса флаг R (running), в логе строка о соединении и выданном адресе внутри VPN-подсети.

Маршрутизация, NAT и firewall

Поднятый туннель — ещё не работающий VPN: надо объяснить роутеру, что в него отправлять.

Весь трафик через сервер. Маршрут по умолчанию через новый интерфейс; шлюз провайдера не удаляйте, оставьте с худшим приоритетом:

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

Второе правило обязательно, если адрес сервера задан доменом: иначе после разрыва роутер не разрезолвит сервер, чтобы переподключиться — DNS-то теперь внутри упавшего туннеля.

Site-to-site. Только нужные подсети: /ip route add dst-address=10.8.0.0/24 gateway=ovpn-to-server.

NAT. Чтобы локальные адреса выходили наружу через туннель:

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

Для site-to-site этот masquerade, наоборот, вреден: сети должны видеть реальные адреса друг друга, иначе из удалённого офиса все хосты выглядят одним IP.

Firewall. Правила RouterOS строгие по умолчанию, и трафик через новый интерфейс режется:

/ip firewall filter add chain=forward in-interface-list=LAN out-interface=ovpn-to-server action=accept
/ip firewall filter add chain=forward connection-state=established,related action=accept

Классический симптом здесь: интерфейс running, пинг до сервера внутри туннеля идёт, а до ресурсов за ним нет. Почти всегда это маршрут или firewall — подробный разбор в статье OpenVPN подключается, но нет сети.

DNS: половина работы, о которой забывают

Даже когда весь трафик уходит в туннель, DNS-запросы часто идут к провайдеру: клиенты получают DNS по DHCP, а роутер пересылает их туда, куда указано в его собственных настройках. Трафик зашифрован, а список сайтов виден.

/ip dns set servers=10.8.0.1 allow-remote-requests=yes
/ip dhcp-server network set [find] dns-server=192.168.88.1
/ip firewall nat add chain=dstnat in-interface-list=LAN protocol=udp dst-port=53 action=redirect to-ports=53

Роутер ходит за резолвом внутрь туннеля, клиентам раздаёт себя, а третье правило заворачивает тех, кто прописал DNS вручную. Как убедиться, что утечки нет — в материале про проверку и закрытие DNS leak.

Проверка результата: зелёный статус ещё ничего не значит

Самая частая ошибка на финише — увидеть running и решить, что готово. Статус говорит лишь о том, что интерфейс поднялся; трафик при этом может идти мимо. Проверяйте по уровням, не перескакивая.

1. Соединение установлено. Флаг R, строка в логе, адрес внутри туннеля: /interface ovpn-client monitor ovpn-to-server once.

2. Пакеты ходят по туннелю. /ping 10.8.0.1 interface=ovpn-to-server count=5 — пинг именно через интерфейс туннеля. Не отвечает — смотрите firewall и маршруты на сервере.

3. Роутер выходит через сервер. /tool traceroute 8.8.8.8 — первым хопом должен быть адрес внутри туннеля, а не шлюз провайдера.

4. Внешний IP реально сменился. Проверяется не с роутера, а с компьютера в локальной сети: 2ip.ru или whoer.net. Виден IP сервера — заворот работает; виден провайдерский — не так настроены маршрут или NAT. Что смотреть и почему страна иногда определяется неверно — в статье как проверить IP и страну после туннеля.

5. DNS не утекает. Там же — dnsleaktest.com, расширенный тест. В списке резолверов должен быть ваш сервер. Появилось имя домашнего провайдера — трафик анонимен, а запросы нет.

6. Нет разрывов под нагрузкой. Запустите длинный пинг и параллельно качайте крупный файл: провалы на десятки секунд означают перегруз CPU или проблему с MTU. Скорость измеряйте iperf3 и у себя — чужие цифры для вашего канала ничего не значат.

Только после шестого пункта можно считать, что настроено.

Типичные грабли

MTU и фрагментация. Симптом узнаваемый: мессенджеры и мелкие сайты летают, а крупные страницы, загрузки и HTTPS-панели зависают на середине и отваливаются по таймауту. Туннель добавляет заголовки, полноразмерный пакет перестаёт помещаться в канал и режется на части, а ICMP-сообщения, которыми машины договариваются о размере, по дороге кто-то выбрасывает. Лечится снижением MTU и, надёжнее, MSS clamping:

/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, мобильный оператор, IPv6-инкапсуляция) и подбирается измерением — методика в разборе подбора MTU и фрагментации. Учтите: clamping лечит только TCP, для видеозвонков и игр по UDP важен корректный MTU.

Часы роутера. Mikrotik без батарейки после отключения питания стартует с датой из прошивки, и сертификат выглядит просроченным. Включите NTP (/system ntp client set enabled=yes servers=ru.pool.ntp.org), иначе каждое отключение света будет ломать туннель.

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

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

Правило ставится ниже разрешающих: сначала убедитесь, что не блокируете доступ к самому роутеру. Логика выключателя на других платформах — в материале про kill switch для VPN.

Автозапуск после перезагрузки. Интерфейс сохраняется в конфигурации и поднимается сам. Ломается в двух случаях: сбитые часы и невозможность разрезолвить домен сервера, когда DNS роутера смотрит внутрь ещё не поднятого туннеля. Второе лечится маршрутом-исключением или IP вместо домена в connect-to.

Сертификаты. Кроме суффикса _0 и флага K есть две мины: формат PKCS12 вместо PEM (RouterOS его не примет) и один client.crt сразу на роутере и ноутбуке — подключения начнут выбивать друг друга.

Фишки, о которых редко пишут

Заворачивайте по источнику, а не всё подряд. Через VPN редко нужен весь дом: практичнее пометить конкретные устройства — телевизор и ноутбук через сервер, остальное напрямую. И CPU свободнее, и банк-клиенты не ругаются на вход из другой страны:

/ip firewall address-list add list=via-vpn address=192.168.88.50
/ip firewall mangle add chain=prerouting src-address-list=via-vpn \
  action=mark-routing new-routing-mark=to-vpn passthrough=no
/ip route add dst-address=0.0.0.0/0 gateway=ovpn-to-server routing-mark=to-vpn

Netwatch против «зависшего» туннеля. OVPN-клиент иногда остаётся в running, хотя пакеты уже не ходят — обычно после смены IP у провайдера. Пересоздание соединения по потере пинга:

/tool netwatch add host=10.8.0.1 interval=30s \
  down-script="/interface ovpn-client disable ovpn-to-server; :delay 3s; /interface ovpn-client enable ovpn-to-server"

Включайте лог на время отладки. Тема ovpn по умолчанию не пишется, и вы отлаживаете вслепую: /system logging add topics=ovpn action=memory. Потом снимите — постоянная запись на флеш её изнашивает.

Меняйте по одному параметру за раз. Сначала поднимите туннель в минимальной конфигурации и только потом включайте verify-server-certificate, MSS clamping и kill switch: иначе непонятно, что сломалось. Заработало — сразу /export file=working-vpn.

Производительность OpenVPN на слабых моделях

OpenVPN в RouterOS шифрует программно, в один поток и на большинстве моделей без аппаратного ускорения. WireGuard реализован эффективнее и лучше использует многоядерность.

Конкретных цифр здесь намеренно нет: пропускная способность зависит от версии RouterOS, шифра, MTU и того, чем ещё занят роутер. Чужие бенчмарки ничего не значат — измерьте у себя. /system resource monitor под нагрузкой покажет главное: ядро уперлось в 100% — вот и потолок.

Что можно сделать, не уходя с OpenVPN:

• UDP вместо TCP. Поверх TCP при потерях получается «TCP в TCP»: два уровня повторов накладываются, и скорость обваливается непропорционально.
• Более лёгкий шифр. AES-128-GCM на слабом CPU обычно быстрее AES-256-GCM.
• Проверить firewall. Длинные цепочки правил и очереди QoS едят CPU и маскируют настоящую причину — методика в статье VPN медленно работает: диагностика по шагам.
• Сравнить с альтернативами. На той же коробке поднимается IKEv2-клиент, который на многих моделях ускоряется аппаратно; развёрнутое сравнение — в материале WireGuard или OpenVPN.

Симптом → причина → что делать

Шпаргалка команд RouterOS

# --- Сертификаты ---
/certificate print                                  # флаги: K = ключ привязан, T = доверен, E = истёк
/certificate import file-name=ca.crt passphrase=""  # сначала .crt, потом .key
/certificate set ca.crt_0 trusted=yes               # пометить CA доверенным

# --- Интерфейс ---
/interface ovpn-client monitor ovpn-to-server once  # текущий статус
/interface ovpn-client disable ovpn-to-server       # перезапуск: выключить...
/interface ovpn-client enable ovpn-to-server        # ...и включить обратно
/interface ovpn-client set ovpn-to-server max-mtu=1400

# --- Диагностика ---
/log print where topics~"ovpn"                      # что говорит клиент
/ping 10.8.0.1 interface=ovpn-to-server count=5     # пинг именно через туннель
/system resource monitor                            # загрузка CPU под нагрузкой
/interface monitor-traffic ovpn-to-server           # реальный трафик в интерфейсе

# --- Маршруты, firewall, служебное ---
/ip route print where gateway=ovpn-to-server        # маршруты через туннель
/ip firewall filter print
/system ntp client set enabled=yes servers=ru.pool.ntp.org
/export file=working-vpn                            # бэкап рабочей конфигурации

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