WireGuard Site-to-Site между MikroTik и VPS: пошаговая настройка

Зачем это нужно и когда L2TP наконец умирает

L2TP/IPsec на MikroTik работает. Работало в 2012-м, работает сейчас. Вопрос только в том, сколько времени ты тратишь на его капризы: согласование фаз, MTU-проблемы, падение при смене IP, портянки политик в конфиге. WireGuard решает всё это одним интерфейсом и 20 строками конфига.

Конкретные сценарии где это нужно прямо сейчас:

• Офис-1 и Офис-2 нужно объединить в одну L3-сеть, у одного из них CG-NAT от провайдера
• Домашняя сеть с MikroTik и VDS в Европе — нужен единый адресный пространство
• Белый IP на VPS используется как точка входа, а за MikroTik сидят сервисы которые надо пробросить
• Failover: основной канал падает, трафик переключается на резервный через туннель

В статье разберём схему MikroTik (RouterOS 7) — VPS (Ubuntu/Debian). Это самый частый запрос. Принципы те же если у тебя два MikroTik — просто VPS заменяется вторым роутером с RouterOS.

Что понадобится: MikroTik с RouterOS 7.1+, VPS с публичным IP, 15-20 минут и доступ по SSH к обоим устройствам.

Как работает WireGuard site-to-site: разбор схемы

WireGuard — это L3-туннель. Никакого «моста» между сетями нет — только маршрутизация. Каждый хост на каждой стороне видит другую сторону как обычную IP-сеть, просто трафик идёт через зашифрованный UDP-туннель.

Самая важная концепция которую нужно понять до начала: AllowedIPs в WireGuard — это одновременно ACL и таблица маршрутизации. Трафик для адресов из AllowedIPs идёт через туннель к этому peer. Трафик от peer принимается только если источник совпадает с его AllowedIPs. Если это не уложилось в голове сейчас — уложится через 10 минут на практике.

Адресный план который используется в статье — зафиксируй для себя:

Почему /30 а не /24 для туннеля: это правило хорошего тона для point-to-point линков. Два адреса, никакого лишнего пространства. Если хочешь подключить несколько peer — бери /24 или /29.

Системные требования

На момент публикации актуальна RouterOS 7.16. Перед настройкой проверь свежие релизы на mikrotik.com/download.

WireGuard на MikroTik доступен только в RouterOS 7. Если у тебя RouterOS 6 — обнови. Процедура обновления через 6.49 stable -> 7.x описана в официальной документации MikroTik.

Порты и firewall

Настройка VPS (Ubuntu/Debian): сторона сервера

Шаг 1. Установка WireGuard

На Ubuntu 20.04 и выше WireGuard встроен в ядро. Нужны только инструменты.

apt update && apt install wireguard wireguard-tools -y

Проверь что модуль загружен:

lsmod | grep wireguard

Если пусто — загрузи вручную:

modprobe wireguard

Шаг 2. Генерация ключей VPS

Каждый WireGuard-интерфейс имеет пару ключей: приватный (никуда не уходит) и публичный (отдаётся peer-у). Генерируй их так:

# Создаём директорию с правильными правами
install -m 0700 -d /etc/wireguard

# Генерируем ключи
wg genkey | tee /etc/wireguard/server_private.key | wg pubkey > /etc/wireguard/server_public.key

# Проверяем
cat /etc/wireguard/server_private.key
cat /etc/wireguard/server_public.key

Публичный ключ VPS понадобится при настройке MikroTik. Скопируй его сейчас — потом будешь искать.

Шаг 3. Создание конфига wg0.conf

# /etc/wireguard/wg0.conf

[Interface]
PrivateKey = 
Address = 10.0.0.1/30
ListenPort = 51820
# Включаем форвардинг и NAT при поднятии интерфейса
PostUp = sysctl -w net.ipv4.ip_forward=1
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT
PostUp = iptables -A FORWARD -o wg0 -j ACCEPT
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT
PostDown = iptables -D FORWARD -o wg0 -j ACCEPT

[Peer]
# MikroTik
PublicKey = 
AllowedIPs = 10.0.0.2/32, 192.168.10.0/24
# Endpoint не указываем - MikroTik сам подключится
# PersistentKeepalive не нужен на стороне VPS

Обрати внимание: Endpoint для MikroTik не прописан. VPS ждёт входящего подключения. MikroTik инициирует сессию сам, и WireGuard запомнит его адрес автоматически. Это важно при CG-NAT — у MikroTik может не быть постоянного публичного IP.

Запусти интерфейс и добавь в автозапуск:

systemctl enable wg-quick@wg0
systemctl start wg-quick@wg0

# Проверяем статус
systemctl status wg-quick@wg0

Шаг 4. ip_forward на постоянной основе

PostUp через sysctl работает до перезагрузки. Чтобы форвардинг сохранялся:

echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
sysctl -p

Шаг 5. Firewall на VPS

Открой UDP 51820 в UFW или iptables. Если используешь UFW:

ufw allow 51820/udp comment "WireGuard"
ufw reload

Если UFW не используешь и у тебя чистый iptables:

iptables -A INPUT -p udp --dport 51820 -j ACCEPT
# Не забудь сохранить правила (iptables-persistent или netfilter-persistent)
apt install iptables-persistent -y
netfilter-persistent save

Настройка MikroTik (RouterOS 7): сторона клиента

Шаг 1. Создание WireGuard-интерфейса

Открой Terminal в Winbox или подключись по SSH. Выполни:

/interface wireguard add name=wg-tunnel listen-port=51820

MikroTik сгенерирует ключи автоматически. Посмотри публичный ключ — он нужен для конфига VPS:

/interface wireguard print

В выводе найди строку public-key=. Скопируй значение — это публичный ключ MikroTik который надо вставить в wg0.conf на VPS.

Шаг 2. Назначение IP-адреса

/ip address add address=10.0.0.2/30 interface=wg-tunnel

Шаг 3. Добавление peer (VPS)

/interface wireguard peers add \
  interface=wg-tunnel \
  public-key="" \
  endpoint-address= \
  endpoint-port=51820 \
  allowed-address=10.0.0.1/32,0.0.0.0/0 \
  persistent-keepalive=25s

Подожди — здесь allowed-address=10.0.0.1/32,0.0.0.0/0 это полный туннель (весь трафик через VPS). Если нужен только доступ к подсети VPS а не выход в интернет — замени на конкретные подсети:

/interface wireguard peers add \
  interface=wg-tunnel \
  public-key="" \
  endpoint-address= \
  endpoint-port=51820 \
  allowed-address=10.0.0.1/32,172.16.0.0/24 \
  persistent-keepalive=25s

Где 172.16.0.0/24 — подсеть которая живёт за VPS и к которой нужен доступ.

Шаг 4. Статический маршрут

AllowedIPs в MikroTik работает иначе чем в Linux wg-quick. На Linux wg-quick автоматически добавляет маршруты из AllowedIPs. MikroTik этого не делает — маршруты надо добавить вручную.

# Маршрут к VPS (WireGuard IP)
/ip route add dst-address=10.0.0.1/32 gateway=wg-tunnel

# Если нужен доступ к подсети за VPS (например, Docker-сети)
/ip route add dst-address=172.16.0.0/24 gateway=wg-tunnel

Если хочешь гнать весь трафик через VPS — добавь default route с большей метрикой (distance) чем основной:

/ip route add dst-address=0.0.0.0/0 gateway=wg-tunnel distance=2

Шаг 5. Firewall на MikroTik

Стандартный firewall RouterOS блокирует туннель. Нужно разрешить входящий UDP на порт WireGuard и форвардинг через туннельный интерфейс.

# Разрешаем входящий WireGuard (UDP 51820)
/ip firewall filter add \
  action=accept \
  chain=input \
  protocol=udp \
  dst-port=51820 \
  comment="WireGuard input" \
  place-before=1

# Разрешаем форвардинг через wg-tunnel
/ip firewall filter add \
  action=accept \
  chain=forward \
  in-interface=wg-tunnel \
  comment="WireGuard forward in" \
  place-before=1

/ip firewall filter add \
  action=accept \
  chain=forward \
  out-interface=wg-tunnel \
  comment="WireGuard forward out" \
  place-before=1

Параметр place-before=1 вставляет правило перед первым существующим. Это критично — firewall RouterOS обрабатывает правила сверху вниз, и drop-правила по умолчанию идут в начале списка.

Шаг 6. NAT на MikroTik (если локальная сеть должна выходить через VPS)

Если хосты за MikroTik должны выходить в интернет через VPS — добавь masquerade:

/ip firewall nat add \
  chain=srcnat \
  out-interface=wg-tunnel \
  action=masquerade \
  comment="Masquerade through WireGuard"

Без этого правила ответный трафик с VPS не будет знать куда возвращаться — у хостов в 192.168.10.0/24 нет маршрута к VPS через интернет напрямую.

Архитектура полного потока трафика

Проверка: туннель живой или нет

На VPS

# Статус интерфейса и handshake
wg show

# Должно быть:
# latest handshake: X seconds/minutes ago
# transfer: X received, X sent

Если в строке latest handshake нет значения вообще — MikroTik ещё не подключился. Если handshake был, но давно — проверь PersistentKeepalive.

# Проверка маршрутизации с VPS до MikroTik WG IP
ping 10.0.0.2

# Проверка доступности хоста за MikroTik
ping 192.168.10.1

На MikroTik

# Проверка статуса peer
/interface wireguard peers print

# Посмотри поле "last-handshake" - если есть время, туннель жив

# Пинг до VPS WireGuard IP
/ping 10.0.0.1

# Проверка таблицы маршрутов
/ip route print where gateway=wg-tunnel

Хорошая проверка site-to-site — traceroute с хоста в локальной сети до адреса на стороне VPS. Если первый хоп — MikroTik, второй — 10.0.0.1 (VPS WireGuard IP), а третий — целевой хост, всё работает правильно.

# С MikroTik
/tool traceroute 172.16.0.5

Осложнения: что идёт не так и как чинить

Ошибка: туннель поднялся, пинги до 10.0.0.1 есть, но до 192.168.10.x с VPS не добраться

Причина: на VPS нет маршрута до 192.168.10.0/24, или блокирует iptables FORWARD. AllowedIPs в wg0.conf на VPS для MikroTik peer должен включать подсеть 192.168.10.0/24.

# Проверяем что в AllowedIPs у peer на VPS
wg show wg0 allowed-ips

# Должно быть: 10.0.0.2/32 192.168.10.0/24

# Проверяем FORWARD правила
iptables -L FORWARD -n -v | grep wg0

Ошибка: нет handshake — туннель не поднимается

Причина: чаще всего UDP 51820 заблокирован на VPS файрволом или у облачного провайдера в Security Group. Также бывает неверный публичный ключ.

# Проверяем слушает ли WireGuard на порту
ss -ulnp | grep 51820

# С внешней машины проверяем доступность порта
nc -zu  51820 && echo "open" || echo "closed"

# На VPS смотрим в лог
journalctl -u wg-quick@wg0 -n 50

Ошибка: туннель работает, но падает каждые 3-5 минут

Причина: MikroTik за NAT, PersistentKeepalive не настроен. NAT-сессия на провайдерском оборудовании закрывается по таймауту.

# На MikroTik - проверяем и исправляем keepalive
/interface wireguard peers print
/interface wireguard peers set 0 persistent-keepalive=25s

Ошибка: MTU проблемы — большие пакеты теряются, маленькие проходят

Симптом: ping проходит, TCP-сессии зависают, HTTPS не открывается. Классика WireGuard через провайдерский NAT или PPPoE.

WireGuard добавляет 60 байт оверхеда. При стандартном MTU 1500 на физическом интерфейсе WireGuard-пакет не влезает если провайдер режет фрейм.

# Устанавливаем MTU явно на MikroTik
/interface wireguard set wg-tunnel mtu=1420

# Или через MSS clamping (мягче, без ручного MTU)
/ip firewall mangle add \
  chain=forward \
  protocol=tcp \
  tcp-flags=syn \
  in-interface=wg-tunnel \
  action=change-mss \
  new-mss=1360 \
  passthrough=yes

# На VPS
ip link set wg0 mtu 1420
# Или в wg0.conf добавить в [Interface]:
# MTU = 1420

Ошибка: MikroTik видит peer но маршрут не работает

Причина: правила firewall forward на MikroTik стоят ниже drop-правил по умолчанию.

# Смотрим порядок правил
/ip firewall filter print

# Accept-правила для wg-tunnel должны быть ДО drop-all
# Если они внизу - перемещаем вверх
/ip firewall filter move [find comment="WireGuard forward in"] destination=1

Ошибка: CG-NAT — у MikroTik нет публичного IP вообще

Это не ошибка, это особенность провайдера. Схема работает: MikroTik инициирует соединение к VPS, который всегда доступен по публичному IP. Endpoint прописывается только на стороне MikroTik. PersistentKeepalive = 25 обязателен. Проверь что на VPS в wg0.conf для MikroTik peer нет строки Endpoint — он там не нужен.

Сценарий с обоими MikroTik (без VPS)

Если оба устройства — MikroTik, один из которых с публичным IP — схема симметрична. Сторона с белым IP слушает на фиксированном порту. Сторона за NAT инициирует, использует PersistentKeepalive.

На обоих MikroTik создаёшь WireGuard интерфейс, обмениваешься публичными ключами, прописываешь peer. Никакого wg0.conf здесь нет — всё через RouterOS команды или Winbox.

Одна строка в кавычках убивает весь отдел в 9 утра понедельника. Это не метафора, это причина почему в production конфиги комментируют.

Failover: что делать если основной канал падает

WireGuard сам по себе не имеет failover — это просто туннель. Но RouterOS умеет переключать маршруты по доступности шлюза.

# Основной маршрут через ISP (distance=1)
/ip route add dst-address=0.0.0.0/0 gateway= distance=1 check-gateway=ping

# Резервный через WireGuard туннель (distance=2, поднимается при недоступности основного)
/ip route add dst-address=0.0.0.0/0 gateway=wg-tunnel distance=2

Параметр check-gateway=ping заставляет RouterOS периодически проверять доступность шлюза. Если ISP-шлюз не отвечает на ping — маршрут с distance=1 деактивируется и начинает работать distance=2 через туннель.

Альтернативы и когда их выбирать

WireGuard выбираем когда: одна из сторон Linux, нужна максимальная простота конфига, важна скорость, есть CG-NAT. IPsec IKEv2 остаётся актуальным если нужна совместимость с корпоративным оборудованием Cisco/Juniper или требуется сертифицированное шифрование.

Профилактика и мониторинг

Скрипт мониторинга туннеля на MikroTik

RouterOS позволяет поднять туннель автоматически через Scheduler. Скрипт проверяет доступность VPS и перезапускает WireGuard если peer не отвечает:

# Создаём скрипт
/system script add name="wg-check" source={
  :local pingResult [/ping 10.0.0.1 count=3 as-value]
  :if ($pingResult < 1) do={
    /log warning "WireGuard: VPS not reachable, restarting interface"
    /interface disable wg-tunnel
    :delay 3s
    /interface enable wg-tunnel
  }
}

# Добавляем в планировщик - запуск каждые 5 минут
/system scheduler add name="wg-monitor" interval=5m on-event=wg-check

Что бэкапить

На MikroTik обязательно экспортируй конфиг после настройки:

/export file=wg-config-backup
# Файл сохраняется в Files, скачай через Winbox или SCP

На VPS сохрани wg0.conf в надёжное место. Приватный ключ потерять нельзя - восстановить без него туннель не получится, придётся перегенерировать ключи на обеих сторонах.

Обновление конфига без потери туннеля

На VPS при изменении wg0.conf не нужно перезапускать интерфейс полностью - можно применить изменения горячо:

# Применяем изменения без разрыва туннеля
wg syncconf wg0 <(wg-quick strip wg0)

На MikroTik изменения в peers применяются сразу без перезапуска интерфейса.

Безопасность: что закрыть после настройки

Базовая безопасность которую игнорируют в 90% гайдов:

• Порт SSH на VPS - смени на нестандартный или закрой для всех кроме твоего IP
• fail2ban на VPS - защита от брутфорса SSH
• Приватный ключ WireGuard - права 600, читать может только root
• На MikroTik отключи Winbox и API на WAN-интерфейсе
• Ограничь доступ к RouterOS services только с wireguard или LAN интерфейса

# Права на приватный ключ VPS
chmod 600 /etc/wireguard/server_private.key
chmod 600 /etc/wireguard/wg0.conf

# fail2ban установка
apt install fail2ban -y
systemctl enable fail2ban
systemctl start fail2ban

# На MikroTik - отключаем лишние сервисы на WAN
/ip service set www disabled=yes
/ip service set api disabled=yes
/ip service set winbox address=192.168.10.0/24,10.0.0.0/30

FAQ

Почему wireguard site to site mikrotik не работает после настройки?

Чаще всего три причины. Первая - firewall на MikroTik: accept-правила для wg-tunnel стоят ниже drop-правил. Проверь порядок через /ip firewall filter print. Вторая - нет маршрута: MikroTik не добавляет маршруты автоматически из AllowedIPs, только Linux wg-quick это делает. Добавь маршрут вручную. Третья - неверные AllowedIPs: если на VPS в peer для MikroTik не прописана подсеть 192.168.10.0/24, трафик из этой сети будет отброшен.

Как проверить что wireguard туннель mikrotik работает правильно?

На MikroTik выполни /interface wireguard peers print - в поле last-handshake должно быть время не старше нескольких минут. Затем /ping 10.0.0.1 - должен пройти. С VPS выполни wg show - в поле latest handshake должно быть актуальное время. Если handshake есть но пинги до локальной сети не проходят - проблема в маршрутах или FORWARD-правилах.

Что делать если mikrotik за cgnat и нет белого ip?

Это стандартная схема для WireGuard. Белый IP нужен только на VPS. MikroTik инициирует подключение - не указывай Endpoint на стороне VPS, не прописывай статический Endpoint для MikroTik peer. PersistentKeepalive = 25 на MikroTik обязателен - без него NAT-сессия протухнет и туннель упадёт. VPS должен слушать на фиксированном порту UDP 51820.

Чем wireguard отличается от l2tp ipsec на mikrotik?

WireGuard - современный протокол с фиксированным набором криптографии (Curve25519, ChaCha20, Poly1305). Нет переговоров по алгоритмам, нет фаз IKE, нет SA. L2TP/IPsec сложнее в отладке, хуже работает за NAT, требует открытых UDP 500 и 4500 одновременно. WireGuard требует только одного UDP-порта. Производительность WireGuard выше за счёт работы в ядре Linux. Минус WireGuard: нет на RouterOS 6, и нет обфускации трафика из коробки.

Почему wireguard туннель падает каждые несколько минут?

Классический симптом CG-NAT или обычного NAT без keepalive. NAT-таблица на провайдерском оборудовании закрывает UDP-сессии по таймауту 2-5 минут. Решение: на MikroTik в настройках peer установи persistent-keepalive=25s. Это заставляет MikroTik отправлять keepalive-пакет каждые 25 секунд, поддерживая NAT-запись живой.

Как добавить второй офис к существующему wireguard туннелю?

На VPS в wg0.conf добавь новую секцию [Peer] с ключом второго MikroTik и его AllowedIPs. Обязательно убедись что AllowedIPs у разных peer не пересекаются - это запрещено в WireGuard. Выполни wg syncconf wg0 <(wg-quick strip wg0) чтобы применить без перезапуска. На втором MikroTik настройка идентична первому.

Итог

WireGuard site-to-site между MikroTik и VPS - это 20 минут работы против нескольких часов с IPsec. Ты получаешь зашифрованный L3-туннель, который живёт за CG-NAT, переживает смену IP на стороне MikroTik, и при необходимости работает как резервный канал при падении основного.

Ключевые точки где люди застревают: порядок правил в firewall MikroTik, ручное добавление маршрутов, PersistentKeepalive за NAT, и правильные AllowedIPs на обеих сторонах. Всё это разобрано выше.

Источники

• MikroTik официальная документация WireGuard
• Ubuntu Server - WireGuard site-to-site
• WireGuard официальный сайт