Короткий ответ — делайте policy‑routing на MikroTik: пометить трафик локалки в mangle (только FORWARD из LAN), направить его в отдельную routing‑table, в этой таблице поставить primary‑маршрут через WireGuard‑peer и запасной через ваш WAN (distance=2). Исключите из маркировки IP сервера (192.168.88.4). Тогда: когда туннель жив — весь помеченный трафик уйдёт через WG, когда туннель умрёт — автоматически по запасному маршруту через WAN (fail‑open). IP‑forward/NAT на самом сервере не трогаем (см. замечание ниже).
Пример готовых команд (подставьте свои имена интерфейсов/адреса):
Параметры, которые нужно подставить:
- LAN‑мост/интерфейс: <LAN_BRIDGE> (например bridge или ether2)
- подсеть LAN: 192.168.88.0/24
- IP сервера в LAN: 192.168.88.4
- WireGuard‑peer (внутренний адрес на сервере в туннеле): <WG_PEER_IP> (например 10.10.10.1)
- шлюз провайдера (WAN‑gateway): <ISP_GW_IP>
Команды:
1) Создать отдельную таблицу маршрутизации:
```
/routing table add name=wg-route fib
```
2) Добавить два маршрута в эту таблицу: главный через WireGuard, запасной через WAN (fail‑open).
(вместо <WG_PEER_IP> и <ISP_GW_IP> подставьте реальные адреса)
```
/ip route add dst-address=0.0.0.0/0 gateway=<WG_PEER_IP> routing-table=wg-route distance=1 check-gateway=ping comment="Primary via WG"
/ip route add dst-address=0.0.0.0/0 gateway=<ISP_GW_IP> routing-table=wg-route distance=2 comment="Fail-open via WAN"
```
check-gateway=ping полезен, чтобы маршрут через WG считался недоступным, если peer перестаёт отвечать.
3) Исключить локальный сервер из маршрутизации через WG (первая mangle‑правило). Это правило должно стоять выше правила маркировки:
```
/ip firewall mangle add chain=prerouting in-interface=<LAN_BRIDGE> src-address=192.168.88.4 action=accept comment="Exclude local server from WG-routing"
```
4) Пометить остальной LAN‑трафик, чтобы он использовал таблицу wg-route:
```
/ip firewall mangle add chain=prerouting in-interface=<LAN_BRIDGE> src-address=192.168.88.0/24 action=mark-routing new-routing-mark=to-wg passthrough=yes comment="Route LAN via WG"
```
5) Связать метку маршрутизации с таблицей:
(в RouterOS метки маршрутизации и таблицы связываются через запись маршрута. У нас таблица уже есть — нужно чтобы записи были в ней. При использовании mark-routing MikroTik будет искать маршруты в таблице wg-route. Для уверенности можно добавить роут в основной таблице как обычно; но выше мы уже задали маршруты в wg-route.)
(проверка)
```
/ip route print where routing-table=wg-route
/ip firewall mangle print
```
Пояснение логики:
- Правило mangle помечает форвард‑пакеты от устройств LAN и заставляет систему смотреть не в main table, а в wg‑table.
- В wg‑table есть основной маршрут через WireGuard (distance=1). Он работает при живом туннеле.
- Если WG недоступен (check-gateway=ping не отвечает) — маршрут считается недоступным и используется запасной маршрут через WAN (distance=2) — это и есть желаемое fail‑open.
- Ранее добавленное правило с src=192.168.88.4 «accept» не даст пометке примениться к серверу — он будет идти по основной таблице и выходить напрямую через WAN.
ВАЖНОЕ замечание о NAT/IP‑forwarding на сервере
- Если ваша цель — чтобы сервер «просто проксировал» трафик на уровне приложения (vless/ SOCKS/ HTTP‑proxy и т.п.), то серверу достаточно принимать соединения и совершать исходящие подключения от своего приложения — IP‑forwarding и маскарадинг не нужны.
- Но если вы хотите реализовать «полноценный full‑tunnel», т.е. чтобы сервер действовал как L3‑шлюз (приём инкапсулированного трафика и прокс/пересылка IP‑пакетов без изменения), то серверу нужен ip_forward и/или NAT (маскарадинг) для корректной работы исходящего интернета для частных адресов. На Keenetic вероятно работала другая логика (transparent proxy / устройство, которое само делало NAT) — поэтому там не нужно было включать форвардинг на целевом сервере. Убедитесь, какой именно режим у вас в 3x‑ui: proxy (в приложении) или full L3‑gateway.
- Если вы действительно хотите, чтобы сервер делал NAT (маскараду) — включите ip_forward и настройте masquerade на нём, либо делайте MASQUERADE на самом MikroTik (но тогда MikroTik уже делает NAT, и схема отличается).
Отладка:
- Смотрите /tool sniffer / torch, проверяйте, что к клиенту применена routing‑mark (в /ip firewall mangle print stats) и что пакеты уходят на <WG_PEER_IP>.
- Проверяйте состояние маршрутов: /ip route print detail routing-table=wg-route
- Для отлова проблем временно поставьте в wg‑таблице только маршрут через WAN и смотрите как меняется поведение.
Если напишите точные имена интерфейсов, IP туннеля (адреса WG на Mikrotik и на сервере) — подготовлю конкретный конфиг с подстановкой ваших значений.