ppp source interface

Окей, снова вернулся к этой проблеме и вообще ничего не получается - кроме настройки статических маршрутов к пункту назначения. Вот краткий обзор того, что я пытаюсь сделать: по сути, это Mikrotik с двумя шлюзами, использующий ECMP и позволяющий L2TP/PPTP-соединения извне. Туннель отваливается и переподключается каждый раз, когда ECMP меняет маршрут до конечной точки туннеля. Ответы от Mikrotik к l2tp-клиенту приходят с адреса альтернативного шлюза, что нарушает безопасность и разрывает туннель. Я думаю, что это происходит для l2tp/ipsec исключительно потому, что udp/1701 не долго отслеживается в таблице соединений, поэтому таблица соединений истекает по тайм-ауту и выбирает следующий шлюз. PPTP, возможно, не сталкивается с этой проблемой, потому что это tcp/gre и находится в таблице дольше. Было бы лучше посоветовать клиентам использовать 10.30.1.1 в качестве конечной точки туннеля, чтобы они получали избыточность обоих соединений. Я хочу, чтобы ответные пакеты приходили с 10.30.1.1, но выходили через любой шлюз. Простое NAT обычно этим занимается, однако, поскольку MT генерирует туннель и нельзя настроить выходной NAT, я не могу этого достичь. Непонятно, сработало бы вообще это решение. Как можно заставить Mikrotik привязать свой ppp/l2tp/pptp-сервер к определенному IP, чтобы я мог заставить его использовать один IP? Я не могу прописывать статические маршруты для одного шлюза для каждого удаленного назначения, особенно если они динамические адреса. РЕШЕНИЕ – заставить RouterOS использовать один и тот же исходный IP на протяжении всего времени существования туннеля… не уверен, насколько это легко реализовать. Спасибо всем.

pptp и l2tp используют src-address исходящего интерфейса, и при использовании нескольких интерфейсов это меняется в середине сеанса туннеля и разрывает его. Я только что проверил с pptp, и у него схожие проблемы. Нам нужна настройка, похожая на ipsec (SA-SRC-ADDRESS), которая позволит задавать туннелю конкретный исходный адрес; loopback, внутренний интерфейс и т.д. pptp немного лучше, потому что он находится в таблице соединений дольше, и ecmp работает хорошо, однако — вы не можете подключиться к 10.30.1.1 (или к ip-адресу на loopback), потому что ответ не приходит с этого ip-адреса. Пожалуйста, добавьте pref-src или tunnel-src-address к ppp-туннельным адаптерам — или что-то подобное, чтобы достичь того же эффекта. Я думаю, что если l2tp/pptp-сервер слушает на всех ip-адресах, то ему просто следует использовать локальный ip-адрес, к которому он подключен, на протяжении всего сеанса. Supout был взят, и если вам он нужен, я могу отправить его по электронной почте… хотя, думаю, это не проблема конфигурации. Спасибо, Sam.

С помощью routing-test можно использовать “set-prefsrc=” для dynamic-in, connected-in и для любой цепочки "in" в протоколах маршрутизации. –Eric