Основная идея в том, чтобы НАПРАВЛЯТЬ ИСХОДЯЩИЙ LAN-ТРАФИК ЧЕРЕЗ КОНКРЕТНЫЙ WAN-IP НАСТРОЙКА МАРШРУТОВ ПО УМОЛЧАНИЮ
dst-address=0.0.0.0/0 gwy=wan1-gwy table=main distance=1 check-gateway=ping
dst-address=0.0.0.0/0 gwy=wan2-gwy table=main distance=2 check-gateway=ping
dst-address=0.0.0.0/0 gwy=wan3-gwy table=main distance=3 check-gateway=ping
Теперь можно использовать этот подход с distance, чтобы направить всех пользователей через 1, если 1 не работает — они пойдут через 2, а если 2 не работает — через 3. Для конкретных подсетей, чтобы обойти это, можно использовать и следующие правила!
ИЛИ
Если каждый WAN-IP нужен только для своей подсети LANSUBNET и резервирование не нужно, тогда…
dst-address=0.0.0.0/0 gwy=wan1-gwy table=main distance=1
dst-address=0.0.0.0/0 gwy=wan2-gwy table=main distance=1
dst-address=0.0.0.0/0 gwy=wan3-gwy table=main distance=1
Возьмём второй вариант, у нас есть подсети А, В, С:
А идёт через 1, В — через 2, С — через 3.
Первый шаг — нужно создать 3 таблицы:
/routing table add name=use-WAN1 fib
/routing table add name=use-WAN2 fib
/routing table add name=use-WAN3 fib
Второй шаг — добавить по 3 дополнительных маршрута к основным:
add dst-address=0.0.0.0/0 gwy=WAN1-gwy table=use-WAN1
add dst-address=0.0.0.0/0 gwy=WAN2-gwy table=use-WAN2
add dst-address=0.0.0.0/0 gwy=WAN3-gwy table=use-WAN3
Далее три правила маршрутизации:
add src-address=subnetA action=lookup-only-in-table table=use-WAN1
add src-address=subnetB action=lookup-only-in-table table=use-WAN2
add src-address=subnetC action=lookup-only-in-table table=use-WAN3
Если хочется, чтобы подсеть могла уйти через другой WAN, если её основной недоступен, поменяйте action на action=lookup — тогда роутер пойдёт в основную таблицу и посмотрит, есть ли другие доступные маршруты.
+++++++++++++++++++++++++++++++++++++++++++++++++++++
Стоит отметить, что используя distance, можно заставить всех пользователей уходить через WAN1 и тогда не понадобится никаких дополнительных маршрутов, таблиц или правил для подсетей, которым нужен именно этот маршрут. Но если не хочется, чтобы подсети переключались друг на друга в режиме аварийного резерва, то distance не нужен.
Мне нравится этот способ — он более эффективен и полезен, но в каждом случае есть свои нюансы.
+++++++++++++++++++++++++++++++++++++++++++++++++++++
Ещё момент: это НЕ покрывает случаи, когда важен и входящий, и исходящий трафик одновременно. Если трафик приходит на определённый WAN, а правила на исходящий трафик настроены иначе, может возникнуть конфликт. Поэтому, чтобы контролировать трафик в обе стороны, лучше использовать mangle, чтобы определить входящий трафик на конкретном WAN и гарантировать, что он уйдёт с того же WAN.
Последнее: будьте осторожны, направляя LAN-пользователей по вышеописанному методу. Если, например, LAN-подсеть A должна ещё обращаться к подсети B внутри сети, этого не получится, потому что трафик будет вынужден выходить через WAN1. Если нужен внутренний трафик между подсетями, просто добавьте ДО (важен порядок!) правил маршрутизации для локальных маршрутов перед правилами WAN.
Например:
add dst-address=subnetA action=lookup-only-in-table table=main {все подсети должны иметь доступ к LAN A}
add src-address=subnetA action=lookup-only-in-table table=use-WAN1
add src-address=subnetB action=lookup-only-in-table table=use-WAN2
add dst-address=subnetB src-address=subnetC action=lookup-only-in-table table=main {подсеть C должна иметь доступ к подсети B}
add src-address=subnetC action=lookup-only-in-table table=use-WAN3
note1: если внимательно, src-address=subnetC в последнем правиле не особо нужен, так как расположение правил уже ограничит его влияние подсетью C.
note2: не забывайте про корректные правила firewall.
