Policy routing работает неправильно: сверить routing table и connection-mark

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

В RouterOS 7 policy routing — это связка: /routing table с fib, маршруты с routing-table=, mangle mark-connection затем mark-routing (new-routing-mark совпадает с именем таблицы). Если таблицы нет в FIB, mark бесполезен. Если mark-routing стоит в prerouting, а FastTrack уже вынул established — mark не применится к продолжению сессии. NAT должен masquerade на том out-interface, куда ушла маркированная таблица.

Не рисуйте второй default в main «для проверки» с тем же distance — это уже ECMP, не policy.

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

Хост 192.168.88.50 должен выходить через LTE, бухгалтерский VLAN — через ether1 203.0.113.10. Фактически все идут в ether1, или наоборот «интернет пропал» только у маркированных.

Failover двух default в main — соседняя статья, не mangle.

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

1. Таблица создана без fib.
2. new-routing-mark=via-lte, таблица названа lte — имена не совпали.
3. Только mark-routing без mark-connection: каждый пакет классифицируется заново, ответы ломаются.
4. FastTrack выше по смыслу обходит mangle.
5. passthrough=no слишком рано оборвал цепь mangle.
6. NAT только на ether1, пакеты вышли в lte1 без srcnat.
7. Routing rule /routing rule конфликтует с mangle (оба валидны, не дублируйте вслепую).

Диагностика

/routing table print
/ip route print
/ip route print where routing-table=via-lte
/ip firewall mangle print stats
/ip firewall connection print where src-address="192.168.88.50"

В connection должны быть marks, которые вы задали. Проверка таблиц:

/ip route add dst-address=0.0.0.0/0 gateway=198.51.100.1 routing-table=via-lte

(пример; шлюз LTE/второго ISP свой). Если gateway unreachable, таблица не спасёт.

Lookup с роутера:

/ip route print detail where dst-address=0.0.0.0/0

Тест с ПК из address-list. Torch на ether1 vs lte1.

Решение

Сценарий A. Каркас ROS 7

/routing table add name=via-lte fib
/ip route add dst-address=0.0.0.0/0 gateway=198.51.100.1 routing-table=via-lte

Mangle (prerouting):

/ip firewall mangle
add chain=prerouting src-address=192.168.88.50 action=mark-connection new-connection-mark=to-lte passthrough=yes
add chain=prerouting connection-mark=to-lte action=mark-routing new-routing-mark=via-lte passthrough=no

Для трафика с самого роутера нужна цепь output, не только prerouting.

NAT:

/ip firewall nat
add chain=srcnat connection-mark=to-lte action=masquerade out-interface=lte1

Плюс обычный masquerade на ether1 для остальных.

Сценарий B. FastTrack

Исключите маркированные коннекты из FastTrack (как VPN): accept/mark path полный. Либо не FastTrack'айте connection-mark=to-lte. Иначе policy routing «работает только на первый пакет».

Сценарий C. Routing rules вместо mangle

/routing rule
add src-address=192.168.88.50/32 action=lookup table=via-lte

Проще для «весь хост в таблицу», хуже для «только HTTP». Не смешивайте rule и mangle на одни пакеты без схемы.

Не ломайте LAN: не маркируйте dst-address=192.168.88.0/24 в via-lte — локальный трафик уйдёт на LTE.

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

С 192.168.88.50 внешный сервис «что видит IP» показывает адрес LTE, не 203.0.113.10. С обычного ПК — 203.0.113.10. Ping шлюза LAN жив. После 10 минут сессии IP не «перепрыгивает» (connection-mark держится).

/ip firewall mangle print stats
/ip route print where routing-table=via-lte

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

• LTE даёт серый IP и входящие сессии невозможны — это CGNAT, не mark.
• Нужен failover маркированной таблицы: отдельный check-gateway в той таблице, см. failover-статью.
• VPN+policy: сначала исключения FastTrack, потом marks.
• WinBox с роутера «не туда»: output mangle.

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

• Имена таблиц = имена marks.
• Комментарии и address-list, не размазанные IP в пяти правилах.
• Тест двух хостов после каждого изменения mangle.
• Backup до policy routing.

Таблица без FIB, output chain и трафик самого роутера

/routing table add name=via-lte без fib даёт имя, в которое mark-routing как будто пишется, но dataplane lookup не идёт в эту таблицу. Всегда fib. Имя таблицы и new-routing-mark — строка один в один, без пробелов и смены регистра.

Пинг с RouterOS (/ping 1.1.1.1) идёт цепью output, не prerouting. Политика «этот VLAN в LTE» не обязана влиять на сам роутер. Если NTP и upgrade должны идти в ISP1, не маркируйте output в via-lte. Если DNS роутера должен резолвить через тот же выход, что клиенты — отдельное правило output с connection-mark.

LAN-to-LAN: в prerouting исключите dst-address=192.168.88.0/24 и адреса VPN, иначе визит к файловому серверу уедет на LTE и умрёт. passthrough=no на mark-routing обрывает дальнейший mangle — ставьте его после всех нужных mark-connection.

Входящий dstnat на втором WAN требует, чтобы ответные пакеты ушли тем же интерфейсом: mark по in-interface в начале prerouting. Иначе ECMP/main default унесёт reply в ether1, и сессия с 203.0.113.10 vs LTE «ломается через раз».

FAQ

routing-mark в ROS 7 это таблица?

Да, new-routing-mark ссылается на /routing table. Старый v6 mental model почти тот же, но таблицы явные с fib.

Нужен ли mark в prerouting и forward?

Обычно prerouting для транзита клиентов. Forward mark-routing часто лишний, если prerouting уже поставил.

Почему ICMP идёт правильно, TCP нет?

Conntrack: первое соединение замаркали, FastTrack остальное унёс; или mss/NAT. Смотрите connection print по протоколам.

Можно ли PCC вместо connection-mark?

PCC — для ECMP-баланса, не для «этот VLAN всегда ISP2». Для sticky VLAN — mark, не PCC.

dstnat на WAN2 и policy?

Входящий на lte1 должен отвечать через lte1: connection-mark на in-interface=lte1 в prerouting/input. Иначе ответ уйдёт в ether1 и сессия умрёт.

Можно ли маркировать только dst-port 443 и пустить остальное в main?

Да: connection-mark по protocol=tcp dst-port=443 плюс mark-routing в таблицу с default через нужный WAN. Остальной трафик останется в main. Не забудьте NAT на том же выходе для маркированных коннектов и исключение FastTrack для connection-mark. DNS и UDP 443 (QUIC) иначе уедут другим путём, и «сайт открывается криво». Тестируйте и TCP, и HTTP/3. LAN-dst исключайте, иначе 443 к внутреннему серверу уйдёт на LTE.