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

Живой туннель (WG handshake или IPsec SA) не равен маршрутизации LAN. Нужны: (1) WG allowed-address / IPsec policy на удалённую сеть, (2) /ip route на эту сеть в туннель, (3) filter forward между bridge и wg0/ipsec, (4) отсутствие masquerade на этот трафик. Ошибка «добавить 0.0.0.0/0 в туннель» убивает выход офиса в интернет через ether1.

Локальная LAN 192.168.88.0/24 должна остаться connected на bridge. Не рисуйте default в VPN, если не делаете full-tunnel осознанно.

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

Ping 10.10.10.2 (адрес WG peer) ок, ping 192.168.10.10 (хост за peer) нет. Или traceroute к 192.168.10.10 идёт на 203.0.113.1 — нет маршрута, пакет уходит в default WAN.

ЖивоМертвоСлой
нет handshake/SAвсёсначала WG / IPsec
ping point-to-pointLANallowed/policy/route
LAN pingSMB/RDPWindows firewall, не MikroTik
то да то нетFastTrackFastTrack

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

  1. Нет /ip route dst-address=192.168.10.0/24 gateway=wg0 (WG) или policy IPsec не покрывает dst.
  2. allowed-address только /32 пира.
  3. masquerade out-interface=wg0 или общий masquerade без out-interface подменил src, ответ не вернулся.
  4. Filter forward drop из LAN в wg0.
  5. На удалённой стороне нет зеркального маршрута назад в 192.168.88.0/24.
  6. Policy routing отправил LAN в другую таблицу.
  7. VLAN: хост не в той сети, которой вы маршрутизируете.

Диагностика

/ip route print
/ip route print where dst-address=192.168.10.0/24
/interface wireguard peers print
/ip ipsec policy print
/ip firewall nat print
/ip firewall filter print stats where chain=forward

С роутера:

/ping 192.168.10.10 src-address=192.168.88.1 count=5

Без src-address ping уйдёт с WAN IP 203.0.113.10 и часто легитимно дропнется на той стороне.

Torch на wg0 на секунду: виден ли ICMP. Если на wg0 тишина — маршрута/policy нет. Если пакет вышел и нет ответа — дальняя сторона или NAT.

Решение

Сценарий A. WireGuard site-to-site

На площадке A (192.168.88.0/24):

/interface wireguard peers
set [find interface=wg0] allowed-address=10.10.10.2/32,192.168.10.0/24
/ip route add dst-address=192.168.10.0/24 gateway=wg0

На B — зеркало на 192.168.88.0/24. Filter:

/ip firewall filter
add chain=forward action=accept in-interface=bridge out-interface=wg0
add chain=forward action=accept in-interface=wg0 out-interface=bridge

Выше FastTrack.

NAT: не маскарадить в 192.168.10.0/24. Если есть общий masquerade без matchers — сузьте out-interface-list=WAN.

Сценарий B. IPsec policy tunnel

Маршрут часто не нужен отдельно: policy перехватывает по селектору. Но connected/default не должны быть «шире» так, чтобы пакет ушёл в WAN до policy. Проверьте ipsec-policy в filter и что masquerade не трогает dst 192.168.10.0/24.

Зеркальные policy обязательны. level=unique vs require — не меняйте без нужды.

Сценарий C. Не сломать LAN

Никогда не добавляйте dst-address=192.168.88.0/24 gateway=wg0 на той же площадке, где эта сеть connected. Получите чёрную дыру своей LAN.

Full-tunnel для филиала: default в VPN только на филиале, на хабе — NAT в интернет и маршруты обратно. Это отдельный дизайн.

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

Ping хоста в чужой LAN с src-address своей LAN. Traceroute не идёт на ISP gateway. С двух сторон. Интернет в 192.168.88.0/24 как раньше: ping 1.1.1.1 жив. Counters на forward accept в wg0 растут.

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

  • Windows отвечает только на ping, не на SMB: профиль сети Public, не маршруты.
  • Асимметрия: туда WG, обратно WAN — firewall stateful дроп. Смотрите routing marks.
  • MTU: ping -f большого размера, clamp MSS.
  • Филиал за LTE CGNAT: исходящий туннель ок, входящие сети всё равно требуют правильных allowed/routes.

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

  • Схема префиксов без пересечений.
  • Interface-list VPN, filter по спискам.
  • NAT только WAN list.
  • Документ: какие сети в туннеле.
  • Тест после каждой новой сети: интернет офиса + ping чужой LAN.

Зеркало маршрутов и проверка src-address с обоих концов

Покажите себе три ping с площадки A:

/ping 10.10.10.2 count=3
/ping 192.168.10.1 src-address=192.168.88.1 count=3
/ping 192.168.10.1 count=3

Первый проверяет point-to-point. Второй — LAN-LAN с правильным источником. Третий без src часто уходит с 203.0.113.10 и легитимно дропается политикой B. На B должны быть зеркальные allowed-address/policy и маршрут в 192.168.88.0/24. Односторонний «мы добавили сеть у себя» — классика тикета.

Пересечение RFC1918: две 192.168.88.0/24 не развести статикой. Либо перенумерация, либо временный srcnat в уникальный пул внутри туннеля с документированием как долг. Не рисуйте 0.0.0.0/0 в WG allowed на хабе офиса: рискуете утащить default и уронить выход в интернет через ether1.

Filter forward LAN↔wg0 держите выше drop и выше FastTrack. После добавления сети повторите ping и проверку интернета офиса — регресс NAT ловят чаще, чем «туннель не поднялся».

FAQ

Нужен ли BGP для двух сетей?

Нет. Статики достаточно. BGP — когда площадок много.

/ip route gateway=10.10.10.2 vs gateway=wg0?

Для WG обычно gateway=wg0 (интерфейсный маршрут). Point-to-point адрес тоже можно, если он в allowed и есть /32. Не мешайте оба конфликтующих маршрута.

Почему ping с роутера есть, с ПК нет?

src IP роутера в allowed/policy, ПК нет; или filter только для local. Проверяйте с ПК.

Можно ли NAT 192.168.88.0/24 в 10.10.10.1 при пересечении LAN?

Да, как костыль: srcnat в уникальный пул. Это хуже перенумерации, но спасает миграцию. Не делайте это молча.

VLAN 10 на bridge и «сеть не ходит в VPN»?

Хост может быть в другой L2. Сначала VLAN filtering, потом VPN.

Почему traceroute в чужую LAN идёт на шлюз провайдера?

Нет маршрута/policy на 192.168.10.0/24, пакет берёт default 203.0.113.1. На WG добавьте allowed-address чужой LAN и /ip route в wg0. На IPsec проверьте зеркальную policy. masquerade без out-interface-list=WAN может подменить src в туннель — тогда даже при маршруте ответ не найдёт хозяина. Проверка: torch на wg0 при ping с src-address=192.168.88.1. Если на wg0 тишина — lookup не туда. Если пакет вышел и нет ответа — дальняя сторона.