Короткий ответ

Пока /interface wireguard peers не показывает свежий last-handshake, маршруты и ping в 10.10.10.0/24 бесполезны. Сверьте: зеркальность ключей (чужой public-key у peer), listen-port и endpoint-port, UDP accept в input на WAN, и что endpoint за NAT не обязан инициировать первым без persistent-keepalive. Не путайте отсутствие handshake с «туннель есть, LAN не маршрутизируется» — второе это маршруты site-to-site.

Симптомы и как отличить

last-handshakeping 10.10.10.2Куда
никогданетключи, UDP, endpoint
естьнетallowed-address, route, filter forward, FastTrack
естьда, LAN за peer нетмаршруты/allowed
моргаетморгаетkeepalive, NAT timeout, неверный endpoint

IPsec «не поднимается» — другая статья: IKEv2/Phase1, не WG.

Возможные причины

  1. В peer вставлен свой public вместо чужого, или private утёк в peer (peer хранит только public).
  2. listen-port=13231, а клиент стучится на 51820.
  3. Нет filter input UDP dst-port listen-port на ether1.
  4. Endpoint — серый IP без проброса; обе стороны за NAT и никто не шлёт keepalive.
  5. allowed-address слишком узкий: handshake с IP не из списка дропается на уровне WG.
  6. Часы сильно в будущем/прошлом редко ломают WG (это скорее IPsec), но NTP всё равно нужен для логов.
  7. Дубли listen-port с другим туннелем.

Диагностика

/interface wireguard print
/interface wireguard peers print
/ip address print where interface=wg0
/ip firewall filter print stats where chain=input
/ip firewall nat print

Смотрите listen-port, public-key интерфейса (это ваш ключ, его отдают peer'у). У peer — public-key партнёра, endpoint-address, current-endpoint-address, last-handshake.

Счётчики input UDP на порту WG должны расти при попытке. Если нет — пакет не доходит (NAT провайдера, неверный WAN, filter раньше).

/ping 10.10.10.2 interface=wg0 count=5

Ping без handshake всегда мёртв.

Клиент (пример Linux) должен иметь зеркальный [Peer] PublicKey= роутера.

Решение

Сценарий A. Ключи

На MikroTik:

/interface wireguard
print
/interface wireguard peers
print detail

Сгенерировать заново, если была путаница:

/interface wireguard add name=wg0 listen-port=13231

Новый интерфейс — новая пара ключей. Старый peer на клиенте обновить. Не публикуйте private-key в тикет.

Сценарий B. Firewall UDP

Выше drop input:

/ip firewall filter
add chain=input action=accept protocol=udp dst-port=13231 in-interface=ether1 comment=wg

Это не WinBox. Порт 13231 не заменяет закрытие 8291. Для нескольких WAN — in-interface-list=WAN.

Сценарий C. NAT и keepalive

На стороне за NAT:

/interface wireguard peers
set [find interface=wg0] persistent-keepalive=25s endpoint-address=203.0.113.10 endpoint-port=13231

Публичный endpoint — тот, куда проброшен UDP, часто 203.0.113.10. Если MikroTik сам за NAT провайдера, проброс на CPE оператора обязателен, либо endpoint на другой стороне.

Сценарий D. Адреса и allowed-address

/ip address add address=10.10.10.1/24 interface=wg0
/interface wireguard peers
set [find] allowed-address=10.10.10.2/32

Для site-to-site allowed-address должен включать LAN партнёра, например 10.10.10.2/32,192.168.10.0/24. Иначе handshake с 10.10.10.2 есть, а 192.168.10.0 отбрасывается WG.

Forward и FastTrack: исключения до fasttrack, см. отдельную статью.

Как проверить, что проблема устранена

/interface wireguard peers print

last-handshake секунды, не пусто. Ping 10.10.10.2. С LAN — по политике: либо только туннель, либо LAN-LAN после маршрутов. Повтор после 2 минут простоя (NAT mapping).

Если не помогло

  • Handshake есть, трафик нет: allowed-address, маршруты, FastTrack.
  • MTU: уменьшите mtu на wg0 (например 1420) при PPPoE.
  • CGNAT у LTE: входящий endpoint на мобильной стороне не взлетит; инициируйте с LTE исходящим keepalive.
  • Конфликт с другим WG на том же порту.

Профилактика

  • Схема ключей в парольнице, не в Telegram.
  • Keepalive на всех NAT-сторонах.
  • Мониторинг last-handshake.
  • Отдельный порт, не 51820, снижает шум, не заменяет filter.

Endpoint за CGNAT, MTU и почему handshake «есть на секунду»

Если обе стороны за NAT и ни у кого нет проброса UDP, туннель живёт только пока обе инициируют. persistent-keepalive=25s нужен на стороне без белого IP. LTE CGNAT: входящий endpoint на телефонной стороне не взлетит; белый должен быть у офиса 203.0.113.10, телефон инициирует сам.

Проверьте, что filter input считает UDP на listen-port именно с WAN, а не с bridge. Если WG слушаете на 13231, а клиент шлёт на 51820, counters на 13231 будут нулевые — это не «ключи», это порт.

MTU: при PPPoE на WAN пакеты WG с внутренним TCP 1500 фрагментируются или дропаются. Поставьте на wg0 MTU 1420 (подбирайте) и при необходимости clamp MSS в mangle. Симптом: ping мелкий проходит, SMB нет, handshake при этом живой.

Не NAT'ьте site-to-site LAN в wg0 masquerade без нужды: сломаете обратный маршрут. Road warrior, которому нужен интернет офиса — отдельный srcnat out-interface=ether1 для адресов 10.10.10.0/24, не путать с LAN-LAN.

FAQ

Нужен ли NAT masquerade на wg0?

Для выхода в интернет через туннель (road warrior) — srcnat out-interface=wg0 на клиентской LAN, не на хабе без нужды. Для site-to-site обычно не NAT'ьте LAN в WG.

Можно ли 0.0.0.0/0 в allowed-address на хабе?

На peer road-warrior да, если это default через туннель. На хабе для peer с 0.0.0.0/0 захватите весь интернет в этого peer — обычно ошибка.

listen-port на обеих сторонах одинаковый?

Не обязательно. Endpoint-port клиента = listen-port сервера. Локальный listen клиента может быть другим.

WireGuard в ROS 7 vs 6?

В 6 его не было в таком виде. Не копируйте синтаксис сторонних прошивок. Только /interface wireguard.

Нужно ли IPsec policy вместе с WG?

Нет. Это разные стеки. Не накладывайте.

Нужно ли пробрасывать UDP WG, если MikroTik сам за NAT оператора?

Да, на CPE оператора: destination UDP listen-port на 203.0.113.10 (или какой белый вам выдали) должен попадать на ether1 роутера. Без этого входящий handshake с интернета не дойдёт, останется только исходящий с keepalive. Двойной NAT без проброса и без инициативы «серой» стороны — вечная тишина в last-handshake. Не путайте проброс WG с пробросом 8291: UDP туннеля можно (и нужно) слушать на WAN, WinBox — нет.