Всем привет! У меня возникла такая проблема. Недавно обновил VPN у клиента с IPsec на Wireguard и заметил серьезные улучшения. Главный офис подключён к двум интернет-каналам: один с статическим, другой с динамическим IP. Филиалы работают с динамическими IP. Главный офис: ISP1 — динамический 100/30 Мбит/с, ISP2 — статический 50/50 Мбит/с. Понятно, почему у них настроен баланс нагрузки с помощью PCQ, и почему хочется, чтобы ISP1 был маршрутом по умолчанию с наименьшей стоимостью.
А теперь самое сложное. Подключения Wireguard приходят через ISP2 (потому что статический IP), но не устанавливаются, если у ISP1 ниже стоимость маршрута. То есть, если шлюз по умолчанию — ISP1, исходящий трафик уходит оттуда, и Wireguard не работает. Ссылка на диаграмму обработки mangle:
Что я пробовал сделать для решения:
Mangle, пометка соединений. Входящие подключения через ISP2 помечаются, но так как UDP-ответ Wireguard — фактически новое соединение, он выходит через DG (шлюз по умолчанию).
Mangle, output, mark connection/routing. В диаграмме всё не очень ясно, но при выходе из bridge decision интерфейс и исходный IP уже выбран, то есть из шлюза по умолчанию. Не получается менять маршрутизацию с помощью output/mark routing/lookup только в таблице с маркировкой маршрутизации.
Политическая маршрутизация/правила маршрутизации. Создавать правило поиска в таблице ISP2 по совпадению dst-address работает. Но не потому, что меняется маршрут, а потому что изначальное решение маршрутизации было правильным. К сожалению, филиалы все с динамическими IP, поэтому нельзя добавить статичные маршруты.
Mangle, добавление dst-address в список. Можно легко добавить IP филиалов в списки адресов, но их не применить в правилах маршрутизации, например.
Src-Nat. По диаграмме вывод идет через NAT, поэтому я пробовал src-nat на адрес ISP2. Вроде логично — “заменить src IP в заголовке на адрес ISP2”. Но нет, маршрут уже выбран, вне зависимости от src-address в пакете.
Я понимаю, что немногие используют возможности RouterOS для умного управления трафиком, и если уж используют, то либо это компании из Fortune 500, либо сети с повсеместными статическими публичными IP, а не такие тупые проблемы, как эта. Но кто-то сталкивался с подобным?
Мне кажется, что «политическая маршрутизация» — расплывчатый термин, который в RouterOS включает mangle/mark route, и что «корректировка маршрутизации» из диаграммы должна работать так:
Bridge decision, lookup main table, выход через ISP1
----------> raw, track, mangle, nat, filter
----------> новая маркировка маршрута, lookup заново в таблице ISP2
----------> выход на интерфейс ISP2
Спасибо, что прочитали и разделили мою боль =)
А теперь самое сложное. Подключения Wireguard приходят через ISP2 (потому что статический IP), но не устанавливаются, если у ISP1 ниже стоимость маршрута. То есть, если шлюз по умолчанию — ISP1, исходящий трафик уходит оттуда, и Wireguard не работает. Ссылка на диаграмму обработки mangle:
Что я пробовал сделать для решения:
Mangle, пометка соединений. Входящие подключения через ISP2 помечаются, но так как UDP-ответ Wireguard — фактически новое соединение, он выходит через DG (шлюз по умолчанию).
Mangle, output, mark connection/routing. В диаграмме всё не очень ясно, но при выходе из bridge decision интерфейс и исходный IP уже выбран, то есть из шлюза по умолчанию. Не получается менять маршрутизацию с помощью output/mark routing/lookup только в таблице с маркировкой маршрутизации.
Политическая маршрутизация/правила маршрутизации. Создавать правило поиска в таблице ISP2 по совпадению dst-address работает. Но не потому, что меняется маршрут, а потому что изначальное решение маршрутизации было правильным. К сожалению, филиалы все с динамическими IP, поэтому нельзя добавить статичные маршруты.
Mangle, добавление dst-address в список. Можно легко добавить IP филиалов в списки адресов, но их не применить в правилах маршрутизации, например.
Src-Nat. По диаграмме вывод идет через NAT, поэтому я пробовал src-nat на адрес ISP2. Вроде логично — “заменить src IP в заголовке на адрес ISP2”. Но нет, маршрут уже выбран, вне зависимости от src-address в пакете.
Я понимаю, что немногие используют возможности RouterOS для умного управления трафиком, и если уж используют, то либо это компании из Fortune 500, либо сети с повсеместными статическими публичными IP, а не такие тупые проблемы, как эта. Но кто-то сталкивался с подобным?
Мне кажется, что «политическая маршрутизация» — расплывчатый термин, который в RouterOS включает mangle/mark route, и что «корректировка маршрутизации» из диаграммы должна работать так:
Bridge decision, lookup main table, выход через ISP1
----------> raw, track, mangle, nat, filter
----------> новая маркировка маршрута, lookup заново в таблице ISP2
----------> выход на интерфейс ISP2
Спасибо, что прочитали и разделили мою боль =)
