Разбор всех основных VPN-протоколов на RouterOS: когда применять WireGuard, IPsec, L2TP и EoIP, и где они ломаются.
МикроТик умеет почти всё, что умеют маршрутизаторы в пять раз дороже. Но именно с VPN (виртуальными частными сетями) это ощущается острее всего: RouterOS (операционная система роутеров MikroTik) поддерживает с десяток протоколов, у каждого своя ниша, свои подводные камни, своя история. Кто-то ставит WireGuard (современный протокол VPN) за пять минут и доволен. Кто-то три дня разбирается с IPsec (протоколом шифрования трафика) и так и не понимает, почему туннель (виртуальный канал между двумя точками сети) поднялся, но трафик через него не идёт.
Эта статья — не реклама MikroTik и не агитация за конкретный протокол. Это разбор того, что реально работает, когда применять каждый вариант, и где обычно ломается.
Причин несколько, и они совсем разные по сценарию.
Первая — удалённый доступ к домашней сети. Уехал в командировку, понадобился файл с NAS (сетевого хранилища) — VPN позволяет попасть в домашнюю сеть так, будто ты сидишь рядом с роутером.
Вторая — объединение двух физически разных сетей в одну. Два офиса, или офис и дом, или два NAS в разных городах — всё это решается site-to-site туннелем. Машины видят друг друга по локальным адресам, как в одной сети.
Третья — шифрование трафика при выходе в интернет. Менее актуально для домашнего MikroTik, но в некоторых сценариях — например, при работе через ненадёжный канал — полезно.
Четвёртая — лабораторные и учебные задачи. MikroTik с его богатой поддержкой протоколов удобен для экспериментов.
RouterOS поддерживает:
Тут небольшой нюанс в терминологии. В контексте RouterOS «туннель» — это более широкое понятие, чем «VPN». VPN обычно подразумевает аутентификацию, шифрование и управление доступом. Туннель — просто механизм инкапсуляции (упаковки) пакетов одного протокола внутрь другого.
EoIP (Ethernet over IP — туннель Ethernet-кадров поверх IP-сети, проприетарный протокол MikroTik) — туннель, но не VPN. Он прозрачно переносит Ethernet-трафик между двумя точками, но сам по себе не шифрует ничего. GRE (Generic Routing Encapsulation — универсальный механизм инкапсуляции маршрутизируемых пакетов) — то же самое.
Когда нужно шифрование — EoIP и GRE комбинируют с IPsec. Получается что-то вроде трёхслойного пирога: Ethernet → GRE → IPsec.
WireGuard в RouterOS — пожалуй, лучшее, что MikroTik добавил за последние годы. Простой, быстрый, минималистичный протокол с современной криптографией. На RouterOS 7 работает нативно, дополнительно устанавливать ничего не нужно.
Но — важная оговорка. WireGuard доступен только в RouterOS 7. На RouterOS 6 его нет, и не будет. Если у тебя старый RouterBOARD на шестой версии — или обновляйся (если железо поддерживает), или смотри в сторону L2TP/IPsec.
Никакой установки. Интерфейс создаётся командой:
bash/interface wireguard add name=wg0 listen-port=13231 mtu=1420
Порт — по умолчанию 51820, но я использую 13231, чтобы не светить очевидным портом. MTU (Maximum Transmission Unit — максимальный размер пакета) 1420 — стандарт для WireGuard поверх большинства провайдеров, работает без фрагментации.
После создания интерфейса RouterOS автоматически генерирует пару ключей. Публичный ключ нужен для настройки пиров (peer — участников соединения).
bash/interface wireguard print
Публичный ключ виден в поле public-key. Скопируй, он понадобится при настройке клиента.
Адрес интерфейсу назначается отдельно. Для туннельной сети выбирают подсеть, которой нет в локальной сети — например, 10.20.0.0/24:
bash/ip address add address=10.20.0.1/24 interface=wg0
На клиентской стороне — допустим, это Linux или другой MikroTik — создаётся аналогичный интерфейс, генерируется своя пара ключей, и публичный ключ клиента идёт на сервер.
Пример настройки клиента на Linux (через wg-quick):
ini[Interface]
PrivateKey = КЛИЕНТСКИЙ_ПРИВАТНЫЙ_КЛЮЧ
Address = 10.20.0.2/24
DNS = 10.20.0.1 # опционально, если хочешь гнать DNS через туннель
[Peer]
PublicKey = ПУБЛИЧНЫЙ_КЛЮЧ_СЕРВЕРА
Endpoint = ВАШ_ВНЕШНИЙ_IP:13231
AllowedIPs = 10.20.0.0/24, 192.168.88.0/24 # ⚠️ укажи свою домашнюю подсеть
PersistentKeepalive = 25
PersistentKeepalive — важно для клиентов за NAT (трансляцией адресов). Без него туннель может «засыпать» через несколько минут бездействия.
На RouterOS добавляем пира (клиента):
bash/interface wireguard peers add \
interface=wg0 \
public-key="ПУБЛИЧНЫЙ_КЛЮЧ_КЛИЕНТА" \
allowed-address=10.20.0.2/32 \
comment="laptop-ivan"
allowed-address — это одновременно и маршрутизация, и фильтр. RouterOS будет принимать от этого пира только пакеты с адресом 10.20.0.2. Если указать 0.0.0.0/0 — пир получит доступ ко всему трафику сервера, в том числе к интернету через него. Удобно для road warrior (мобильного клиента), но подумай, нужно ли это.
Маршрут на домашнюю сеть у клиента появится автоматически через AllowedIPs. Если нужен только доступ к домашней подсети — указывай именно её, а не 0.0.0.0/0.
bash/interface wireguard peers print
Смотри на поле last-handshake. Если там время в пределах нескольких минут — туннель живой. Если never или давно — что-то не так.
Типичные проблемы:
input chain на MikroTik.allowed-address не совпадают.bash/ip firewall nat add chain=srcnat out-interface=ether1 \
src-address=10.20.0.0/24 action=masquerade \
comment="WireGuard NAT" # ⚠️ замени ether1 на свой WAN-интерфейс
L2TP/IPsec — это старая гвардия. Протокол поддерживается нативно в Windows, macOS, Android и iOS без установки дополнительного софта. Настроил сервер — клиент подключается встроенными средствами системы.
Это главное преимущество. И почти единственное, если честно. По скорости и современности WireGuard выигрывает. Но бывают ситуации, когда поставить дополнительный клиент невозможно или нежелательно — корпоративный ноутбук, чужое устройство, неподготовленный пользователь.
Включаем L2TP-сервер:
bash/interface l2tp-server server set enabled=yes use-ipsec=required ipsec-secret=СупервскийПароль default-profile=default
use-ipsec=required — обязательно. L2TP без IPsec гоняет трафик в открытом виде. Никогда не ставь disabled в продакшене.
Создаём профиль PPP (Point-to-Point Protocol — протокол двухточечного соединения) с параметрами сети:
bash/ppp profile add name=vpn-users local-address=10.10.0.1 remote-address=vpn-pool \
dns-server=192.168.88.1 use-compression=no use-encryption=yes
И пул адресов для клиентов:
bash/ip pool add name=vpn-pool ranges=10.10.0.10-10.10.0.50
Пользователи добавляются в базу PPP:
bash/ppp secret add name=ivan password=СложныйПароль service=l2tp profile=vpn-users
/ppp secret add name=maria password=ДругойПароль service=l2tp profile=vpn-users
Каждому пользователю можно назначить фиксированный адрес через local-address и remote-address прямо в записи секрета — удобно, если нужно знать, кто подключился с какого IP.
Windows 10/11. Сеть → VPN → Добавить VPN-подключение. Тип — L2TP/IPsec с общим ключом. Сервер — внешний IP MikroTik. Ключ IPsec — тот самый ipsec-secret. Логин и пароль — из PPP secrets. Одна тонкость: в Windows по умолчанию L2TP не работает за двойным NAT (двойной трансляцией адресов). Нужно добавить в реестр:
HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent
DWORD: AssumeUDPEncapsulationContextOnSendRule = 2
После — перезагрузка. Без этого твикия подключение часто виснет на «Проверке сети».
Android. Настройки → Сеть → VPN → Добавить. Тип L2TP/IPsec PSK. Всё аналогично. На Android 12+ нативный L2TP убрали из настроек, нужно устанавливать strongSwan (клиент VPN с открытым исходным кодом) или аналог.
iOS. Настройки → Основные → VPN → Добавить конфигурацию. Тип L2TP. Работает из коробки без танцев.
PSK (Pre-Shared Key — заранее согласованный ключ) — это не то же самое, что пароль пользователя. PSK аутентифицирует само устройство перед установкой туннеля, а пароль PPP — уже конкретного пользователя внутри него. Два уровня защиты.
PSK должен быть длинным и случайным. Не «company123», не «vpn2024» — генерируй через openssl rand -base64 32 или аналог. Хранить его нужно как секрет: кто знает PSK, тот может попытаться подключиться к серверу.
Задача: два роутера MikroTik, каждый в своей сети (допустим, офис и дом), нужно чтобы машины в обеих сетях видели друг друга напрямую. Клиент-серверная модель тут не подходит — нужен именно site-to-site.
IPsec в режиме туннеля — классическое решение для этой задачи. Работает без дополнительного ПО, поддерживается на обеих сторонах нативно, хорошо совместим с другим оборудованием (не только MikroTik).
Допустим:
1.2.3.4, локальная сеть 192.168.10.0/245.6.7.8, локальная сеть 192.168.20.0/24Начинаем со стороны A.
Proposal (набор алгоритмов шифрования):
bash/ip ipsec proposal add name=my-proposal auth-algorithms=sha256 enc-algorithms=aes-256-cbc pfs-group=modp2048
Не используй md5 и des — это антиквариат. SHA256 и AES-256 — минимальный разумный уровень на сегодня.
Peer (описание удалённой стороны):
bash/ip ipsec peer add name=site-b address=5.6.7.8 exchange-mode=ike2
IKEv2 (Internet Key Exchange version 2 — протокол обмена ключами второй версии) предпочтительнее IKEv1 — быстрее поднимается, стабильнее при смене сети.
Identity (аутентификация):
bash/ip ipsec identity add peer=site-b auth-method=pre-shared-key secret=ДлинныйСложныйКлюч
Policy (политика — что шифровать и куда):
bash/ip ipsec policy add src-address=192.168.10.0/24 dst-address=192.168.20.0/24 \
peer=site-b proposal=my-proposal tunnel=yes action=encrypt
На стороне B — зеркальная конфигурация: адреса src и dst меняются местами, peer указывает на 1.2.3.4.
IPsec policy обрабатывает шифрование, но маршрут на удалённую сеть нужно прописать отдельно. Без явного маршрута пакеты уйдут в дефолтный gateway, а не в туннель:
bash/ip route add dst-address=192.168.20.0/24 gateway=5.6.7.8 \
comment="Маршрут через IPsec в офис B" # ⚠️ проверь gateway
Самое частое — несовпадение proposal. Обе стороны должны договориться об одних алгоритмах. Если одна сторона предлагает AES-256, а другая принимает только AES-128 — туннель не поднимется. Диагностика:
bash/ip ipsec installed-sa print
Если список пустой — SA (Security Association — контекст безопасности) не согласованы, смотри логи:
bash/log print where topics~"ipsec"
Второе частое — firewall блокирует ESP (Encapsulating Security Payload — протокол шифрования нагрузки IPsec) или UDP 500/4500. В input chain нужны правила:
bash/ip firewall filter add chain=input protocol=udp dst-port=500 action=accept comment="IKE"
/ip firewall filter add chain=input protocol=udp dst-port=4500 action=accept comment="IPsec NAT-T"
/ip firewall filter add chain=input protocol=ipsec-esp action=accept comment="IPsec ESP"
Правила ставь выше дефолтного drop.
OpenVPN (система VPN с открытым исходным кодом) на MikroTik — это история с оговорками. Поддержка есть, но реализация в RouterOS ограниченная. Знай заранее:
Если есть выбор — бери WireGuard. OpenVPN на MikroTik имеет смысл, когда клиентская сторона жёстко требует именно этот протокол, или когда нужна совместимость с существующей PKI-инфраструктурой (Public Key Infrastructure — инфраструктурой открытых ключей).
Сертификаты создаются прямо в RouterOS:
bash# Корневой сертификат (Certificate Authority)
/certificate add name=CA common-name=CA days-valid=3650 key-size=2048 key-usage=key-cert-sign,crl-sign
/certificate sign CA
# Сертификат сервера
/certificate add name=server common-name=server days-valid=3650 key-size=2048 key-usage=digital-signature,key-encipherment,tls-server
/certificate sign server ca=CA
# Сертификат клиента
/certificate add name=client1 common-name=client1 days-valid=3650 key-size=2048 key-usage=tls-client
/certificate sign client1 ca=CA
Экспортируем для передачи клиенту:
bash/certificate export-certificate CA export-passphrase=""
/certificate export-certificate client1 export-passphrase="ПарольДляЭкспорта"
Файлы появятся в /Files. Скачай через Winbox (утилита управления MikroTik) или FTP.
bash/interface ovpn-server server set enabled=yes port=1194 mode=ip protocol=tcp \
certificate=server require-client-certificate=yes auth=sha1 cipher=aes256 \
default-profile=default-encryption
require-client-certificate=yes — клиент без валидного сертификата не подключится. Хорошая практика.
Если клиент — тоже MikroTik:
bash/interface ovpn-client add name=ovpn-to-server connect-to=1.2.3.4 port=1194 \
mode=ip protocol=tcp user=ovpn-user password=ПарольРРР certificate=client1 \
auth=sha1 cipher=aes256
Если клиент — Linux или Windows, нужен .ovpn-файл с сертификатами внутри. Собирается вручную, MikroTik не генерирует его автоматически — это ещё одно ограничение.
Вот честный список того, чего нет:
На практике в 2024–2025 году OpenVPN на MikroTik выбирают редко. Если тебе нужна именно сертификатная аутентификация — смотри на IKEv2/IPsec с сертификатами, там реализация лучше.
EoIP (Ethernet over IP) — проприетарный протокол MikroTik. Создаёт виртуальный Ethernet-канал между двумя устройствами поверх любой IP-сети. Главная особенность — прозрачность на уровне L2 (второго уровня сетевой модели, уровня передачи данных).
Это значит: можно взять два MikroTik в разных городах, поднять между ними EoIP-туннель, добавить оба конца в один бридж (bridge — виртуальный коммутатор) — и получить единый широковещательный домен. Клиенты в обеих точках получат адреса из одного DHCP (протокола автоматической выдачи адресов), увидят общие сетевые ресурсы, принтеры, мультикаст.
Звучит как магия, но есть цена: широковещательный трафик ходит через туннель целиком, что нагружает канал. На медленных линках — осторожно.
Сценарий применения в домашней инфраструктуре: есть дача или второй объект, на обоих стоит MikroTik, хочется чтобы оборудование умного дома (Zigbee-координаторы, NAS, камеры) видело друг друга как в одной сети. EoIP — одно из решений.
bash/interface eoip add name=eoip-to-site2 remote-address=5.6.7.8 tunnel-id=1
/interface bridge add name=bridge-unified
/interface bridge port add interface=eoip-to-site2 bridge=bridge-unified
/interface bridge port add interface=ether2 bridge=bridge-unified # ⚠️ локальный интерфейс
Tunnel ID должен совпадать на обеих сторонах. Это просто числовой идентификатор, не ключ безопасности.
GRE (Generic Routing Encapsulation) работает на уровне L3 (сетевом уровне, уровне маршрутизации) — в отличие от EoIP. Инкапсулирует IP-пакеты внутрь IP-пакетов. Проще в маршрутизации, нет широковещательного накладного расхода, совместим с оборудованием других производителей.
Сторона A:
bash/interface gre add name=gre-to-b remote-address=5.6.7.8 local-address=1.2.3.4
/ip address add address=172.16.1.1/30 interface=gre-to-b
Сторона B:
bash/interface gre add name=gre-to-a remote-address=1.2.3.4 local-address=5.6.7.8
/ip address add address=172.16.1.2/30 interface=gre-to-b
После этого добавляем маршруты:
bash# На стороне A — маршрут в сеть B через туннель
/ip route add dst-address=192.168.20.0/24 gateway=172.16.1.2
GRE сам по себе не шифрует трафик. Данные идут открытым текстом.
Классический приём: GRE даёт туннель с маршрутизацией, IPsec даёт шифрование. Вместе — зашифрованный туннель с нормальной маршрутизацией.
Добавляем IPsec поверх GRE — политику шифрования для трафика между внешними IP двух роутеров:
bash/ip ipsec policy add src-address=1.2.3.4 dst-address=5.6.7.8 protocol=gre \
proposal=my-proposal tunnel=no action=encrypt
tunnel=no — важно. Здесь используется transport mode (транспортный режим IPsec), а не tunnel mode, потому что туннель уже организован GRE.
Практический сценарий из жизни: два NAS с Synology (один дома, один у родителей), на обеих сторонах MikroTik, нужна репликация между NAS по локальным адресам.
Вариант 1 — GRE+IPsec: поднимаем зашифрованный туннель, прописываем маршруты, Synology Replication Service работает как в локальной сети. Максимальная скорость, минимальный оверхед.
Вариант 2 — EoIP+IPsec: оба NAS в одном бридже, один DHCP-сервер. Проще с точки зрения сетевой конфигурации NAS, но больше широковещательного трафика.
Вариант 3 — WireGuard site-to-site: MikroTik с одной стороны, Linux-роутер с другой. WireGuard нативно поддерживается на обеих платформах.
На практике, судя по тредам на 4PDA и MikroTik-форумах, для домашних сценариев с двумя MikroTik всё чаще выбирают WireGuard — проще в настройке и диагностике, чем EoIP+IPsec.
По умолчанию RouterOS принимает подключения на все порты со стороны WAN (внешнего интерфейса). Это проблема. Минимальный набор правил для input chain:
bash# Разрешаем установленные соединения
/ip firewall filter add chain=input connection-state=established,related action=accept
# Разрешаем с loopback
/ip firewall filter add chain=input in-interface=lo action=accept
# Разрешаем ICMP (для диагностики)
/ip firewall filter add chain=input protocol=icmp action=accept
# WireGuard
/ip firewall filter add chain=input protocol=udp dst-port=13231 action=accept comment="WireGuard"
# L2TP/IPsec
/ip firewall filter add chain=input protocol=udp dst-port=500,4500 action=accept comment="IKE/NAT-T"
/ip firewall filter add chain=input protocol=ipsec-esp action=accept comment="IPsec ESP"
# L2TP
/ip firewall filter add chain=input protocol=udp dst-port=1701 in-interface=!ether1 action=accept comment="L2TP (только изнутри)"
# Дроп всего остального с WAN
/ip firewall filter add chain=input in-interface=ether1 action=drop comment="Drop WAN" # ⚠️ ether1 — замени на свой WAN
Порядок правил критичен. Drop должен быть последним.
Отдельно — для VPN-трафика в forward chain: по умолчанию клиенты VPN могут ходить куда угодно внутри сети. Если нужна сегментация — добавляй правила явно.
bash/system logging add topics=ipsec action=memory
/system logging add topics=ppp action=memory
Смотреть:
bash/log print where topics~"ipsec"
/log print where topics~"ppp"
Активные PPP-сессии (L2TP):
bash/ppp active print
Активные IPsec SA:
bash/ip ipsec installed-sa print
WireGuard пиры и статус:
bash/interface wireguard peers print detail
Для долгосрочного мониторинга удобен The Dude (бесплатная система мониторинга сети от MikroTik) или интеграция с Prometheus+Grafana через SNMP (Simple Network Management Protocol — протокол управления сетевым оборудованием). MikroTik отдаёт метрики интерфейсов, в том числе VPN-туннелей, через SNMP из коробки.
Если туннель поднялся, но трафик не идёт — диагностика начинается с пинга с самого роутера (не с клиента):
bash/ping src-address=10.20.0.1 10.20.0.2
src-address важен — без него пакет может уйти не через туннельный интерфейс, а через WAN.
Трассировка:
bash/tool traceroute src-address=10.20.0.1 10.20.0.2
Если трассировка упирается в шлюз провайдера — проблема с маршрутизацией или firewall. Если доходит до конечного роутера, но дальше нет — проблема на принимающей стороне.
Packet sniffer (анализатор пакетов) — мощный инструмент:
bash/tool sniffer start interface=wg0 filter-ip-address=10.20.0.2
/tool sniffer print
/tool sniffer stop
Или то же самое через Winbox → Tools → Packet Sniffer, с выгрузкой в PCAP и анализом в Wireshark.
RouterOS — живой продукт. Критические уязвимости в IPsec и других VPN-компонентах периодически закрываются патчами. В 2023 году была серьёзная уязвимость в Winbox-протоколе (CVE, точный номер лучше уточни в официальном changelog на mikrotik.com). Без обновлений ты оставляешь дыры открытыми.
Обновление:
bash/system package update check-for-updates
/system package update download
/system reboot
Дополнительные практики:
/ip service set api disabled=yesbash/system ntp client set enabled=yes servers=pool.ntp.org
Последнее. Если ты строишь VPN-инфраструктуру для реальных задач (не для лаборатории) — сделай бэкап конфигурации до и после настройки. MikroTik экспортирует конфиг одной командой:
bash/export file=backup-$(system clock get date)
Файл появится в /Files. Скачай и храни отдельно от роутера.
Можно ли использовать WireGuard и L2TP одновременно на одном MikroTik? Да. Это разные интерфейсы, они не конфликтуют. Можно держать L2TP для старых устройств и WireGuard для всего нового.
Почему L2TP на Android 12 перестал работать? Google убрал нативный L2TP/IPsec из настроек Android 12. Нужен сторонний клиент — strongSwan (бесплатный, open source), он поддерживает IKEv2/IPsec и L2TP/IPsec.
Какой протокол выбрать для site-to-site между двумя MikroTik? WireGuard на RouterOS 7 — проще настраивать, легче диагностировать. IPsec — если нужна совместимость с другим оборудованием или RouterOS 6.
EoIP шифрует трафик? Нет. EoIP — чисто туннель без шифрования. Для шифрования нужно поверх добавлять IPsec.
RouterOS 6 или 7 — что выбрать для новых установок? RouterOS 7 для нового железа. На старых устройствах (hAP ac2, серия 941) проверь список поддерживаемых устройств на mikrotik.com — не всё железо поддерживает семёрку.