Как перенаправить запроса на IP адрес через другой шлюз?
Приветствую. Имеем роутер Mikrotik RB951Ui-2nd, с двумя провайдерами через ether1 и lte(условном wan1 и wan2) и подключенным к нему клиентом. Периодически клиент делает запросы на удаленный сервер с IP 172.18.24.10 (к примеру). Подскажите, пожалуйста, как сделать так, чтобы клиент постоянно выходил в интернет через WAN1, но как только необходимо сделать запрос на удаленный сервер, использовал WAN2, и после получения ответа, продолжал использовать с WAN1?Использовать WAN1 для соединения с сервером не могу по причине определенных ограничений.
Маркировка траффика
Фаерволл
Добавить ip к которому ломится в адрес лист
Промаркировать этот запрос
В меню routes прописать маршрут на этот ip, указать шлюз, указать маркер. При необходимости указать С какого ip надо обработать запрос
А что именно нужно в фаерволле? В нате lte должен быть выше wan? Адрес лист добавил ip, маркировку сделал обращение именно к данному ip. В routes прописать, что to: данный ip, шлюз указывать lte или ip шлюза? А что значит указать с какого ip обработать запрос?
mike89klein, видимо Вы не почитали доки на эту функцию
У меня дома такая задача - я хочу чтоб на залоченные сайты домашняя локалка лезла через VPN. Сделано вот так
Добалены домены в адрес лист. Так же добавлена подсеть локалки(можно и отдельный IP добавить локальный, Вам же с КОНКРЕТНОЙ машины надо через LTE выходить, либо всю локалку впихнуть если с любой машины)
Далее сделана маркировка трафф - для запроса из локалки только
И роутес - перенаправление на ВПН. У меня указан шлюз в VPN сети, Вы можете указать просто интерфейс LTE
Вам нужен маршрут до вашего сервера через шлюз второго провайдера
Типа такого
/ip route
add dst-address=x.x.x.x/32 gateway=y.y.y.y
Где x.x.x.x адрес сервера, y.y.y.y адрес шлюза второго провайдера.
Также нужно не забыть настроить nat для wan2.
Возможно стоит заблокировать трафик до сервера через wan1 в фаерволе, чтобы при недоступности wan2 трафик не пошел через wan1.
mike89klein, по идее оба варианта достаточно производительные. Но безусловно routing mark будет работать медленнее.
В отдельных случаях routing mark предпочтительнее, поскольку позволяет сделать более сложную логику, но не в случае маршрутизации на небольшое кол-во узлов или подсетей.