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

wireguard site to site mikrotik
Быстрый ответ
Чтобы поднять WireGuard site-to-site между MikroTik (RouterOS 7) и VPS на Linux:
  • На VPS: установи WireGuard, создай интерфейс wg0, пропиши peer с публичным ключом MikroTik и AllowedIPs = адрес туннеля + локальная подсеть за MikroTik
  • На MikroTik: создай WireGuard-интерфейс, добавь IP, добавь peer с ключом VPS и AllowedIPs = адрес туннеля + подсеть VPS
  • На VPS: включи ip_forward, добавь iptables FORWARD + MASQUERADE если нужен выход в интернет
  • На MikroTik: добавь статический маршрут через WireGuard-интерфейс, разреши UDP-порт в firewall
  • Если MikroTik за CG-NAT — используй PersistentKeepalive = 25 на стороне MikroTik, Endpoint указывай только на VPS

Туннель поднимается за 15-20 минут. RouterOS 7.1 и выше, Ubuntu/Debian на 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 минут на практике.

%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#ffffff',
    'primaryTextColor': '#1e293b',
    'primaryBorderColor': '#94a3b8',
    'lineColor': '#64748b',
    'fontSize': '15px',
    'fontFamily': 'ui-sans-serif, system-ui, sans-serif'
  },
  'flowchart': {'curve': 'linear', 'nodeSpacing': 50, 'rankSpacing': 50}
}}%%
flowchart LR
    A["LAN: 192.168.10.0/24"] --> B["MikroTik wg0: 10.0.0.2/30"]
    B -->|"UDP 51820 / зашифровано"| C["VPS wg0: 10.0.0.1/30"]
    C --> D["VPS LAN / Docker / сервисы"]
    style A fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
    style B fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
    style C fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d
    style D fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d

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

Сторона WireGuard IP Локальная сеть Роль
VPS (Ubuntu) 10.0.0.1/30 — Responder (принимает подключение)
MikroTik 10.0.0.2/30 192.168.10.0/24 Initiator (инициирует из-за NAT)

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

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

Компонент Минимум Проверено
RouterOS 7.1 7.14, 7.15, 7.16
Ubuntu (VPS) 20.04 LTS 22.04, 24.04
Debian (VPS) 11 (Bullseye) 12 (Bookworm)
WireGuard (ядро Linux) kernel 5.6+ встроен в Ubuntu 20.04+
wireguard-tools 1.0.20200319 1.0.20210914

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

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

Порты и firewall

Порт Протокол Направление Назначение Открыт снаружи
51820 UDP входящий на VPS WireGuard туннель Да
51820 UDP входящий на MikroTik WireGuard (опционально) Если нет CG-NAT
22 TCP входящий на VPS SSH управление Рекомендуется ограничить по IP

Настройка 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

Важно: AllowedIPs у peer
В секции [Peer] (MikroTik) указывай AllowedIPs = 10.0.0.2/32, 192.168.10.0/24. Первый адрес — это WireGuard IP MikroTik. Второй — локальная подсеть за MikroTik. Именно это позволит трафику из 192.168.10.0/24 ходить через туннель.

# /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)

PersistentKeepalive - почему это критично
Если MikroTik за NAT или CG-NAT — без PersistentKeepalive туннель будет падать через несколько минут простоя. NAT-таблица на провайдерском оборудовании протухает, и VPS теряет маршрут к MikroTik. PersistentKeepalive = 25 секунд — стандартное значение, держит сессию живой.

/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 через интернет напрямую.

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

%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#ffffff',
    'primaryTextColor': '#1e293b',
    'primaryBorderColor': '#94a3b8',
    'lineColor': '#64748b',
    'fontSize': '15px',
    'fontFamily': 'ui-sans-serif, system-ui, sans-serif'
  },
  'flowchart': {'curve': 'linear', 'nodeSpacing': 50, 'rankSpacing': 50}
}}%%
flowchart TD
    A["Хост 192.168.10.100"] -->|"dst: 172.16.0.5"| B["MikroTik - проверка маршрутов"]
    B -->|"dst: 172.16.0.0/24 via wg-tunnel"| C["WireGuard шифрование"]
    C -->|"UDP 51820 encrypted"| D["VPS - wg0 расшифровка"]
    D -->|"ip_forward + FORWARD accept"| E["Сервис на 172.16.0.5"]
    E -->|"ответ"| D
    D -->|"UDP 51820 encrypted"| C
    C --> B
    B --> A
    style A fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
    style B fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
    style C fill:#f8fafc,stroke:#f97316,stroke-width:2px,color:#c2410c
    style D fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d
    style E fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d

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

На 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 через туннель.

%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#ffffff',
    'primaryTextColor': '#1e293b',
    'primaryBorderColor': '#94a3b8',
    'lineColor': '#64748b',
    'fontSize': '15px',
    'fontFamily': 'ui-sans-serif, system-ui, sans-serif'
  },
  'flowchart': {'curve': 'linear', 'nodeSpacing': 50, 'rankSpacing': 50}
}}%%
flowchart TD
    A["Трафик из LAN"] --> B["Проверка маршрутов"]
    B -->|"ISP доступен - distance=1"| C["ISP Gateway"]
    B -->|"ISP недоступен - distance=2"| D["WireGuard -> VPS"]
    C --> E["Интернет"]
    D --> E
    style A fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
    style B fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
    style C fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d
    style D fill:#f8fafc,stroke:#f97316,stroke-width:2px,color:#c2410c
    style E fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d

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

Протокол Сложность настройки Производительность Стабильность за NAT RouterOS поддержка
WireGuard Низкая Высокая Хорошая (keepalive) RouterOS 7+
IPsec IKEv2 Высокая Высокая Хорошая RouterOS 6+
L2TP/IPsec Средняя Средняя Плохая за CG-NAT RouterOS 6+
OpenVPN Средняя Низкая (user-space) Хорошая (TCP mode) RouterOS 7+
EoIP + IPsec Средняя Средняя Средняя RouterOS (только MikroTik-MikroTik)

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, версию RouterOS, провайдера (CG-NAT или белый IP), и что именно видишь в wg show и /interface wireguard peers print. Разберёмся.

Источники

Андрей Анатольевич
Author: Андрей Анатольевич

Руководитель ИТ / Кризис-менеджер 25 лет в IT: от инженера в МегаФоне до руководителя отдела. Знаю, как выглядит бардак: нестабильные сети, устаревшая инфраструктура, конфликты в команде, раздутые сроки. Помогаю бизнесу выходить из кризиса: навожу порядок в легаси, стабилизирую то, что разваливается, выстраиваю прогнозируемые процессы. Не раз возвращал к жизни ИТ-структуры — знаю цену хаосу. 📍 Ищу проект для полной реорганизации / стабилизации. 📬 Telegram: @over_dude ✉️ mail@it-apteka.com

Оставайтесь на связи

Рецепты от IT-боли. Без воды, без рекламы, без маркетинговой шелухи.

Подписаться на IT-Аптеку →

Мы ВКонтакте

IT-Аптека — советы, новости и помощь рядом.

Вступить в группу ВКонтакте →
Поделитесь:

Похожие записи

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Прокрутить вверх