Прошу помощи у сведущих. Настроил MultiWAN с двумя провайдерами 1-й провайдер Обит, шлюз 2.2.2.1, внешний IP 2.2.2.2 2-й провайдер Ростелеком, шлюз 192.168.100.1, IP - 192.168.100.2 У Ростелекома стоит у нас в серверной EchoLife HG8120H GPON Terminal, на котором висит внешний статичный IP Конфигурация работает, но есть одно НО... Если Ростелеком отключает интернет, резервирование канала не происходит, поскольку шлюз 192.168.100.1 доступен Вопрос Как изловчится в данной конфигурации, чтобы происходило резервирование? Мои настройки RouterOS 6.43.7 /interface list add name=list-WAN /interface list member add interface=wan_main list=list-WAN add interface=wan_reserv list=list-WAN /ip address add address=192.168.1.4/24 interface=bridge_local network=192.168.1.0 add address=2.2.2.2/28 interface=wan_reserv network=2.2.2.0 add address=192.168.100.2/24 interface=wan_main network=192.168.100.0 /ip dns set allow-remote-requests=yes max-udp-packet-size=512 servers=8.8.8.8,77.88.8.1 /ip firewall nat add action=masquerade chain=srcnat out-interface=wan_main add action=masquerade chain=srcnat out-interface=wan_reserv /ip firewall mangle add action=mark-connection chain=prerouting connection-mark=no-mark in-interface=wan_main new-connection-mark=con-WAN1 add action=mark-connection chain=prerouting connection-mark=no-mark in-interface=wan_reserv new-connection-mark=con-WAN2 add action=mark-routing chain=prerouting connection-mark=con-WAN1 in-interface-list=!list-WAN new-routing-mark=WAN1 add action=mark-routing chain=prerouting connection-mark=con-WAN2 in-interface-list=!list-WAN new-routing-mark=WAN2 add action=mark-routing chain=output connection-mark=con-WAN1 new-routing-mark=WAN1 add action=mark-routing chain=output connection-mark=con-WAN2 new-routing-mark=WAN2 add action=mark-connection chain=forward connection-mark=no-mark new-connection-mark=con-WAN1 out-interface=wan_main passthrough=yes add action=mark-connection chain=forward connection-mark=no-mark new-connection-mark=con-WAN2 out-interface=wan_reserv passthrough=yes add action=mark-routing chain=prerouting connection-mark=con-WAN1 in-interface-list=!list-WAN new-routing-mark=WAN1 passthrough=yes add action=mark-routing chain=prerouting connection-mark=con-WAN2 in-interface-list=!list-WAN new-routing-mark=WAN2 passthrough=yes /ip route add distance=1 gateway=192.168.100.1 routing-mark=WAN1 add distance=1 gateway=2.2.2.1 routing-mark=WAN2 add distance=1 gateway=192.168.100.1,2.2.2.1 add check-gateway=ping distance=100 gateway=2.2.2.1 add check-gateway=ping distance=100 gateway=192.168.100.1
https://c2n.me/3YJ7mMx https://c2n.me/3YJ7H7P https://c2n.me/3YJ8aOL https://c2n.me/3YJ9mik У меня это выглядит вот так на отработку отказа уходит 20+ секунд при отсутствии пинга на ОБА тестовых сайта т.е. при обрыве канала проблема не с одним тестовым сайтом а с двумя независимыми сразу - скорее это проблема с каналом инета ... и переходим на резервный маршрут с метрикой 2 при отказе 2х тестовых маршрутов рекурсивный ложится тоже
То есть надо добавить маршруты, так? Public DNS Google 8.8.8.8 Yandex 77.88.8.1 /ip route add dst-address=8.8.8.8 gateway=192.168.100.1 scope=10 add dst-address=77.88.8.1 gateway=2.2.2.1 scope=10 add distance=1 gateway=8.8.8.8 routing-mark=WAN1 check-gateway=ping add distance=2 gateway=77.88.8.1 routing-mark=WAN1 check-gateway=ping
Лучше выбрать такие сайты для проверки куда пользователи скорее всего никогда не пойдут Google и Yandex технически эту роль могут исполнить, но когда на них начнет идти трафик пользователей могут быть проблемы эти сайты придется привязать к каналу правилом (это нужно чтоб через чужой канал не уходил трафик проверки когда ляжет основной канал - нужно чтоб сайт был недоступен пока не работает WAN1 несмотря на то что инет через WAN2 есть), и когда произойдет переключение а у вас кто-то будет ломиться на яндекс днс а он директивно идет по правилу Ip route rules на отключенный сейчас канал ... получим проблему Лучше что-то менее часто используемое в нашем регионе В вашем варианте add distance=1 gateway=8.8.8.8 routing-mark=WAN1 check-gateway=ping add distance=2 gateway=77.88.8.1 routing-mark=WAN1 check-gateway=ping кроме того - если в маркированных таблицах маршрут будет не найден он пойдет искать через главную таблицу маршрутизации (main) а там работает при отказе первого - второй маршрут через Wan2 и он покажет что тестовый сайт доступен - маршрут для первого канала останется живым т.к. тестовые площадки достижимы Нужно направлять трафик тестовых сайтов директивно в /IP Route Rules с указанием искать только (LookUP Only in table) Wan* Это не позволит уйти в основную таблицу маршрутизации и сделает тестовый сайт недоступным пока не оживет соответствующий канал
Пытался настроить только для WAN1 ya.ru - 87.250.250.242 Отключил маршрут /ip route add check-gateway=ping disabled=yes distance=100 gateway=192.168.100.1 Добавил вместо него другие /ip route add distance=1 gateway=87.250.250.242 routing-mark=WAN1 check-gateway=ping add check-gateway=ping distance=100 dst-address=87.250.250.242/32 gateway=192.168.100.1 scope=10 И добавил правило /ip route rule add action=lookup-only-in-table dst-address=87.250.250.242/32 table=WAN1 Но при отключении оптики Ростелекома, видно, что пакеты пытаются идти через шлюз 192.168.100.1, который стоит у нас в серверной В чём может быть проблема?
судя по тому что вы работаете с правилом для маркированных пакетов с маркировкой routing-mark=WAN1 это правило будет работать если в mangle пакет пропустят через соответствующее правило маркировки в ином случае будет работать таблица Main для не маркированного трафика а в ней может быть какой-то маршрут через второго провайдера и есть шанс что пакет не заглядывал в правило маркировки и на него оно не повлияло Почему не сработало правило /ip route rule add action=lookup-only-in-table dst-address=87.250.250.242/32 table=WAN1 не знаю ответить пока не готов могу с маленькой вероятностью предположить что те пакеты что видит второй шлюз идут не с микротика а через микротик из другого источника - но это не более чем гадание и предположение и еще .. во избежании какой-то путаницы - я не стал бы абсолютно точно одинаково именовать маркировки в разных местах (table=WAN1 routing-mark=WAN1 ) мало ли где неверно интерпретируется и ищи потом корень проблемы пока не посинеешь - хоть буковку но префикс разный я бы воткнул
Если называть по разному (table=WAN1 routing-mark=WAN1), то маршрут становится неактивным add distance=1 gateway=87.250.250.242 routing-mark=WAN1 check-gateway=ping Заработало в такой конфиурации /ip route add distance=1 gateway=87.250.250.242,2.2.2.1 add distance=1 gateway=87.250.250.242 routing-mark=WAN1 check-gateway=ping add check-gateway=ping distance=100 dst-address=87.250.250.242/32 gateway=192.168.100.1 scope=10 /ip route rule add action=lookup-only-in-table interface=wan_main dst-address=87.250.250.242/32 table=WAN1 Вам премного благодарен
да это я ушами прохлопал, действительно то что я написал на тему роутингмарка и таблицы они названы одинаково автоматически т.к. название таблицы автоматом создается из роутингмарка а я не досмотрел и недодумал ... признаю - ошибся .. бывает в том что у Вас получилось и есть рекурсивный маршрут для таблицы Main образованный первой и третьей строкой а вторая строка обслуживает обращения с маркировкой но тоже рекурсивно замечательно что заработало но у меня небыло указано интерфейса в route rules, приму к сведению - попробую проверить
