Два канала L2TP/IPSec в один адрес

[Ca6ko]

И если на клиенте дефолтный маршрут смотрит в одну сторону, а src-address - в другую, то IPSEC устанавливается по дефолтному маршруту, ...

На клиенте разные шлюзы для разных src-address и IPSEC идет по разным маршрутам, специально допилили эту функцию.

[Vadik7]

Коллеги, большое спасибо за информацию.
А можно ли сделать два просто L2TP соединения, через которые потом инкапсулировать IPSec?

[xvo]

Можно. Но никакой особой разницы, с точки зрения упрощения конфигурации.
Ко всему прочему лишний оверхед.

[Erik_U]

И если на клиенте дефолтный маршрут смотрит в одну сторону, а src-address - в другую, то IPSEC устанавливается по дефолтному маршруту, ...

На клиенте разные шлюзы для разных src-address и IPSEC идет по разным маршрутам, специально допилили эту функцию.

Спасибо. А в какой версии, не подскажете? И где устанавливаются разные шлюзы для разных src-address?

В Long-term прошивке изменений нет. Все по прежнему.

P.S. Версию нашел. До лонг-терма эти изменения не добрались.
Вы уверены, что изменения работают именно так, как вы описываете? Вы это тестировали?

Потому, что интерфейс L2TP никак не влияет на маршрутизацию. Маршрутизация по прежнему определяется таблицей. Такого понятия, как "дефолт для интерфейса" не появилось.
То, что добавили - указание адреса источника - должно работать в двумя внешними адресами в одной сети (с одним дефолтным шлюзом). В этом случае будет работать гладко. С разными операторами не будет.

[xvo]

В Long-term прошивке изменений нет. Все по прежнему.

P.S. Версию нашел. До лонг-терма эти изменения не добрались.

Я вам так сразу и написал.

Вы уверены, что изменения работают именно так, как вы описываете? Вы это тестировали?

Потому, что интерфейс L2TP никак не влияет на маршрутизацию. Маршрутизация по прежнему определяется таблицей. Такого понятия, как "дефолт для интерфейса" не появилось.
То, что добавили - указание адреса источника - должно работать в двумя внешними адресами в одной сети (с одним дефолтным шлюзом). В этом случае будет работать гладко. С разными операторами не будет.

Оно и не отвечает за маршрутизацию.
А отвечает именно за то, за что вы беспокоились - что IPSec и L2TP будут создаваться с разных адресов.
То есть то, что уже давно было для GRE (с полем local-address), они добавили и в l2tp-клиента (в виде поля src-address).
И оно работает именно так, как и должно.
А за маршрутизацию вы отвечаете сами.
Что я до вас уже вторую страницу пытаюсь донести.

[Erik_U]

Оно и не отвечает за маршрутизацию.
А отвечает именно за то, за что вы беспокоились - что IPSec и L2TP будут создаваться с разных адресов.
То есть то, что уже давно было для GRE (с полем local-address), они добавили и в l2tp-клиента (в виде поля src-address).
И оно работает именно так, как и должно.

Ну вот ситуация.

Есть интерфейс 1 с адресом 1 и дефолтным маршрутом за этим интерфейсом гейт1.
Есть интерфейс 2 с адресом 2. Дефолтный маршрут по прежнему Гейт1 за интерфейсом 1.

Как микротик узнает, куда посылать пакеты с интерфейса2 с адресом2?

Хотя-бы на примере трейса. Сами посмотрите. Идет по дефолтному с любого адреса.

А за маршрутизацию вы отвечаете сами.
Что я до вас уже вторую страницу пытаюсь донести.

Я вам об этом вторую страницу кричу.
Ну покажите, если знаете, как сделать маршрутизацию до одного и того же адреса через разные маршруты средствами микротика.
Если у него трейс с любого адреса все равно идет по дефолтному маршруту.

Вам об этом ТС пишет. Он поставил эти соурсы. Но не создается 2 туннеля, потому, что на сервере IPSEC видит не локальный адрес интерфейса клиента, а серый адрес, с которого оператор выпустил пакет, и они одинаковые, потому, что пакеты выпускаются по дефолтному маршруту.

[xvo]

Несколько таблиц маршрутизации отменили?

На выбор:
- mangle routing mark
- mangle route
- route rule

ТС пишет, что у него "трафик покрашен", то есть предполагается уже работающий на оба канала микротик.
И я сразу написал ровно то, чего не хватает: src-address для l2tp.
И дополнительно правила route rule, чтобы то, для чего src-address жестко задан, не скатывалось в основную таблицу маршрутизации даже при падении одного из каналов.

Если же мультиван не настроен, то само собой его надо предварительно настроить.

Сервер никогда не видит серых адресов.
Для него все пакеты, политики и т. д. приходят с белых адресов, в которые натит провайдер.

[Erik_U]

Если вы уверены, что IPSEC начнет работать от src в настройках L2TP (спасибо огромное, не знал, что это сделали),
осталось выяснить нюанс с динамическими адресами.
Включая сброс зависших IPSEC соединений при смене серого IP, от которого клиент в интернете присутствует. И перекраску, если красили по SRC.

[xvo]

Да, оно работает именно так, как надо.

И решать там уже тоже ничего не надо, я решение написал в первом же ответе:
1) Прибиваем с помощью route rule соединения к нужным таблицам, чтобы туннели никогда не устанавливались через основную таблицу.
2) Добавляем в dhcp-клиентов lease-скрипты, которые при смене адреса будут выключать туннель, обновлять все упоминания о src-address, включать обратно.
При таком подходе ничего не залипает.

[Erik_U]

А OSPF?

Локальная задача - задействовать для стабильности 2 канала VPN, накинув на них OSPF.

Тут во-первых он лишь условно работоспособен на Stable прошивках. А на LT прошивках нет SRC у L2TP.
А во вторых, OSPF умеет работать только с одной таблицей маршрутизации.
А вы ему хотите на Stable дать 2 (или 3?) таблицы, да еще и обновлять скриптами и их, и манглы. Да он на Stable за 2 недели без перезагрузки становится неработоспособным и без этих фокусов. Сразу отрабатывает потерю любого канала любым способом - гашением интерфейса, выключением коробочки, вытаскиванием пачкорда, кабеля питания, всеми доступными способами отрабатывает. А через 2 недели работы при реальном пропадании канала не отрабатывает. А после перезагрузки - снова отрабатывает.

Честное слово. Мы уже времени на обсуждение потратили больше, чем стоимость второго микротика для классического решения вопроса.