Сделайте второй маршрут без маркировки с большей метрикой и проверку на доступность первого. Тогда в случае отвала тик днс будет резолвить через второй.
В идеале проверку делать рекурсивными маршрутами, ну или можете использовать нетвотч.
Если во второй никогда нельзя пускать основную массу, то можете просто явно указать это в маскарадинге. Ну и в фаерволе можно порезать подсеть или наоборот сделать исключение.
например так:
/ip route
add check-gateway=ping comment=yota distance=1 gateway=77.88.8.1
add check-gateway=ping comment=lte2_check distance=2 gateway=8.8.4.4
add comment=yota-check distance=1 dst-address=77.88.8.1/32 gateway=109.XXX.XX.XX scope=10
add comment=megafon-check distance=2 dst-address=8.8.4.4/32 gateway=10.X.XXX.X scope=10
/ip firewall filter
add action=drop chain=output dst-address=8.8.4.4 out-interface=vlan_yota
add action=drop chain=output dst-address=77.88.8.1 out-interface=vlan-megafon
Только важно эти адреса как днсы не использовать конечно же.
Мне не понятно желание не давать второй канал самому тику полностью.
Два провайдера, без резервирования и балансировки
-
yarvelov
- Сообщения: 92
- Зарегистрирован: 15 июл 2018, 02:08
Ну так используйте публичные днс.mrrc писал(а): ↑30 сен 2020, 21:39 Что-то я пока не очень врубаюсь, если честно.
Во второй канал принудительно направляются либо подсети целиком, либо избирательно отдельные локальные адреса пользователей по мере необходимости, список корректируемый и управляется через адрес лист, чтобы весьма удобно позволяет управлять выпуском нужного рабочего места через обособленный канал второго провайдера.
Так быть может это было бы более простым и надежным решением? Никаких возражений нет, чтобы именно сам тик (его сервисы) могли использовать оба канала от обоих провайдеров.
В IP -> DNS занесены по два адреса DNS от каждого провайдера. Но наверняка доступ из сети одного провайдера к адресам DNS второго запрещен и наоборот соответственно.
И маршруты дефолтные оба с разными метриками и проверкой.
А принудительное направление так и останется с маркировками и метками.
-
yarvelov
- Сообщения: 92
- Зарегистрирован: 15 июл 2018, 02:08
ну что мешает проверить их пингом, например эти https://dns.yandex.ru/mrrc писал(а): ↑30 сен 2020, 22:16Наверное так.
Только насколько публичные будут быcтры по отклику.
Только как выше упоминал, когда падает канал первого провайдера, зачастую шлюз его остается доступным, в вот дальше и адреса DNS уже нет.Код: Выделить всё
/ip route add comment="Route to ether3_WAN_200M" distance=1 gateway=IP_GW_ISP2 routing-mark=\ ether3_WAN_200M add check-gateway=ping comment="Main WAN route" distance=1 gateway=IP_GW_ISP1 add distance=2 gateway=IP_GW_ISP2
вот из-за того что проверка доступности шлюза провайдера не дает гарантий проверки и делают рекурсивные маршруты пример которых я дал выше.
Иногда вовсе не отвечает гейтвей на icmp в тех же лте сетях.
Можно еще проверять некий адрес в инете вроде 8.8.8.8 и опускать маршрут используя netwatch. В прочем рекурсивные маршруты именно внешний адрес и проверяют, на мой взгляд механизм намного лучше, чем c применением netwatch.
Конечно же это все требует блокировки проверяемых внешних адресов в фаерволе, пример так же выше.