Настройка IPsec site-to-site VPN MikroTik

Кратко IPsec site-to-site VPN на MikroTik шифрует трафик между двумя целыми сетями — головным офисом и филиалом, NOC и площадкой с вышкой, — так что хосты в каждой LAN обращаются к другой сети как к локальной. В этом руководстве настраиваются оба роутера на RouterOS v7: пир IKEv2, identity с общим ключом, proposal для Фазы 2, политика туннеля, правило обхода NAT, на котором спотыкается большинство первых попыток, а также правила файрвола и проверки, подтверждающие, что туннель поднялся.

Что такое IPsec site-to-site VPN на MikroTik?

IPsec site-to-site VPN на MikroTik — это постоянный шифрованный туннель между двумя роутерами, который объединяет две отдельные LAN в одну маршрутизируемую сеть на уровне L3, причём ни один из роутеров не выставляет порт управления в интернет. В отличие от клиентских VPN вроде WireGuard или OpenVPN, где подключается одно устройство администратора, туннель site-to-site работает постоянно и связывает подсеть с подсетью: каждый хост за Роутером A автоматически достаёт до любого разрешённого хоста за Роутером B. IPsec здесь подходит лучше всего, потому что это открытый стандарт, поддерживаемый практически всеми производителями роутеров и файрволов, он работает в ядре RouterOS и даёт хорошую пропускную способность, а на MikroTik встроен изначально — устанавливать дополнительные пакеты не нужно.

Туннель строится за два согласования. Фаза 1 (IKE) аутентифицирует роутеры друг перед другом и поднимает защищённый канал; Фаза 2 (IPsec) согласует ключи, которыми и шифруется ваш трафик. Если обе фазы совпадают на обоих концах, туннель поднимается; расхождение хотя бы в одном алгоритме — и всё молча ломается. Именно поэтому шаги ниже держат обе стороны симметричными.

Что нужно перед началом

Понадобятся два роутера MikroTik на RouterOS v7, у каждого — публичный IP-адрес или рабочее DDNS-имя, и две непересекающиеся подсети LAN. В руководстве используются 192.168.10.0/24 на Site A и 192.168.20.0/24 на Site B. Если обе площадки сидят на 192.168.88.0/24, маршрутизация невозможна — сначала переадресуйте одну сторону. IPsec очень чувствителен к расхождению часов, поэтому включите NTP на обоих роутерах заранее: если концы разъедутся по времени, security association истекут и туннель будет постоянно падать.

Уже на десятке площадок следить за такой мелочью становится утомительно. Когда у вас парк устройств, MKController даёт одну консоль, где можно проверить версию RouterOS и источник времени на каждом роутере до переключения туннеля, — не придётся заходить на каждое устройство только ради этой проверки.

Шаг 1: Создание профиля IKE и пира

На Site A задайте профиль Фазы 1 и направьте пира на публичный адрес Site B:

/ip ipsec profile add name=to-siteB hash-algorithm=sha256 \
    enc-algorithm=aes-256 dh-group=modp2048 lifetime=1d

/ip ipsec peer add name=siteB address=<SITE_B_PUBLIC_IP>/32 \
    profile=to-siteB exchange-mode=ike2

dh-group=modp2048 — это Diffie-Hellman Group 14, разумное современное значение по умолчанию. exchange-mode=ike2 выбирает IKEv2: он быстрее и надёжнее устаревшего режима main/IKEv1. Оба конца должны использовать одинаковые параметры профиля и один и тот же режим обмена.

Шаг 2: Добавление identity (общий ключ)

/ip ipsec identity add peer=siteB auth-method=pre-shared-key \
    secret="<long-random-shared-secret>"

Используйте длинный случайный секрет и храните его так же, как SSH-ключ, — не в переписке в чате. Один и тот же секрет прописывается на обоих роутерах.

Шаг 3: Определение proposal для Фазы 2

/ip ipsec proposal add name=to-siteB auth-algorithms=sha256 \
    enc-algorithms=aes-256-cbc pfs-group=modp2048

Perfect Forward Secrecy (pfs-group) означает, что при каждой смене ключей используется свежий ключевой материал, поэтому скомпрометированный ключ никогда не раскроет прошлый трафик. Как и в Фазе 1, алгоритмы должны совпадать на обоих концах.

Шаг 4: Создание политики туннеля

Политика говорит RouterOS, какой трафик шифровать: из локальной LAN в удалённую.

/ip ipsec policy add peer=siteB tunnel=yes \
    src-address=192.168.10.0/24 dst-address=192.168.20.0/24 \
    proposal=to-siteB action=encrypt

Именно tunnel=yes делает схему site-to-site, а не host-to-host: исходные пакеты заворачиваются целиком, и две LAN общаются прозрачно.

Шаг 5: Правило обхода NAT (шаг, о котором все забывают)

Здесь ломается большинство первых попыток. На роутере уже есть правило masquerade, которое переписывает адрес источника исходящего трафика LAN. Если оно сработает раньше IPsec, удалённый конец получит пакеты с источником, который больше не совпадает с политикой, и отбросит их. Добавьте правило accept выше masquerade, чтобы трафик, идущий в туннель, обходил NAT:

/ip firewall nat add chain=srcnat action=accept place-before=0 \
    src-address=192.168.10.0/24 dst-address=192.168.20.0/24

place-before=0 ставит правило в самое начало цепочки srcnat, и это обязательно: правило обхода после masquerade не даёт ничего.

Шаг 6: Открытие файрвола и проверка

Разрешите порты IKE и NAT-T плюс протокол ESP в цепочке input, чтобы туннель мог установиться, — особенно если одна из площадок стоит за ещё одним NAT-устройством:

/ip firewall filter add chain=input protocol=udp dst-port=500,4500 action=accept
/ip firewall filter add chain=input protocol=ipsec-esp action=accept

Затем убедитесь, что туннель поднялся:

/ip ipsec active-peers print
/ip ipsec policy print

У здорового туннеля виден активный пир и политика, у которой ph2-state равен established. Быстрый ping с хоста одной LAN на хост другой подтверждает сквозную доступность.

Зеркальная настройка на Site B

Повторите все шаги на Site B с зеркальными адресами: пир указывает на публичный IP Site A, а политика и правило обхода NAT используют src-address=192.168.20.0/24 и dst-address=192.168.10.0/24. Профиль, proposal, секрет identity и режим IKEv2 остаются идентичными. Когда обе стороны совпадают, Фаза 1 и Фаза 2 завершаются и туннель поднимается.

Советы по безопасности и эксплуатации

Держите RouterOS обновлённым: в последних релизах выходили исправления, затрагивающие сверку сертификатов пиров в IPsec/IKEv2, так что туннель, работавший в прошлом квартале, стоит перепроверить после каждого обновления. Предпочитайте IKEv2 с PFS устаревшим значениям IKEv1 по умолчанию. Где возможно, по мере роста числа туннелей переходите с общего секрета на аутентификацию по сертификатам: одна утёкшая pre-shared key затрагивает все площадки, которые её используют. И пишите состояние туннеля туда, куда вы действительно смотрите: упавший канал site-to-site незаметен ровно до момента, когда кто-то попытается достучаться до удалённой LAN и не сможет.

В парке устройств туннель IPsec, тихо отвалившийся после рассинхронизации часов или моргания WAN, — именно тот отказ, который клиент замечает раньше вас. MKController закрывает этот пробел: он следит за каждым роутером через защищённый исходящий туннель, которому не нужны ни публичный IP, ни проброс портов на устройстве, хранит версионированные резервные копии конфигурации, чтобы можно было сравнить и восстановить рабочий блок IPsec после неудачной правки, и умеет заводить тикет по событию падения канала до того, как зазвонит телефон. По самой настройке туннеля: наше руководство по NAT на MikroTik объясняет правило masquerade, которое вы здесь обходите, а если нужно достучаться до одного роутера, а не объединить две LAN, посмотрите удалённое управление за CGNAT и наш разбор удалённого управления через WireGuard.

Соберите все туннели в одном месте

IPsec аккуратно связывает две площадки, но у растущего ISP или MSP быстро набираются десятки туннелей, ключей и правил файрвола, которые нужно держать в согласованном виде, и каждая ручная правка — шанс отрезать себе доступ к удалённой площадке. MKController создан именно для такого масштаба: централизованное управление парком, безопасный удалённый доступ без открытых портов, история конфигураций и резервные копии, а также массовое применение изменений файрвола и политик по всему парку, так что шаблон туннеля раскатывается один раз, а не перенабирается на каждом роутере. Операторы, работающие с MikroTik в масштабе, используют его, чтобы вместо потерянного дня в SSH по устройствам тратить несколько кликов на изменение.

Начните бесплатный пробный период MKController