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

[Vadik7]

Добрый вечер.
Есть два Микротика. На одном из них заведено 2 провайдера, каждый с "серым" IP адресом. На втором - один "белый" IP (хост на VPS).
Глобальная задача - получить себе домой один "белый" IP адрес со стабильным подключением (нужен для записи в облако видео).
Локальная задача - задействовать для стабильности 2 канала VPN, накинув на них OSPF.

Что делаю. Поднимаю на втором Микротике L2TP сервер. Далее на первом микротике прописываю 2 VPN соединения в сторону второго.
При работе одного VPN поднимается канал, все нормально. При активации в этот момент второго VPN все падает. Если при этом я деактивирую первое подключение - то второе поднимется и все будет работать.

Вопрос - куда копать?
ЗЫ. На первом микроте каналы "покрашены".

[Erik_U]

Два канала L2TP/IPSec

Вы пытаетесь создать эти каналы через разных операторов.
У вас ничего не получится.
Потому, что сначала устанавливается шифрованное IPSEC соединение, а потом, внутри него поднимается L2TP.
Шифрованный IPSEC вы никак не покрасите. Потому, что оба устанавливаете на один и тот же внешний IP. И устанавливаться они будут всегда через шлюз по умолчанию.
Это один и тот же процесс, его невозможно покрасить в 2 цвета.

Дешевле всего использовать 2 микротика в точке с двумя операторами.

Или реальные IP купить для двух операторов в точке, где их два. Противоположную оставить с серым IP. И с серого устанавливать 2 VPN на 2 реальных. Тогда все разруливается само собой.

[xvo]

Два канала L2TP/IPSec

Вы пытаетесь создать эти каналы через разных операторов.
У вас ничего не получится.
Потому, что сначала устанавливается шифрованное IPSEC соединение, а потом, внутри него поднимается L2TP.
Шифрованный IPSEC вы никак не покрасите. Потому, что оба устанавливаете на один и тот же внешний IP. И устанавливаться они будут всегда через шлюз по умолчанию.
Это один и тот же процесс, его невозможно покрасить в 2 цвета.

Это не правда.
Прекрасно оно все делается.
Надо только добавить в настройки l2tp-клиента src-address и добавить в /ip route rules правила прибивающие соединения с каждого из адресов к своему соединению.

Если адреса динамические - добавить в dhcp-client'ов скрипты которые будут обновлять конфигурацию.

И да, на сервере не забыть снять галку "One session per host" и лучше использовать два разных аккаунта.

[Erik_U]

Это не правда.
Прекрасно оно все делается.
Надо только добавить в настройки l2tp-клиента src-address и добавить в /ip route rules правила прибивающие соединения с каждого из адресов к своему соединению.

Если адреса динамические - добавить в dhcp-client'ов скрипты которые будут обновлять конфигурацию.

И да, на сервере не забыть снять галку "One session per host" и лучше использовать два разных аккаунта.

Еще раз.
Сначала устанавливается соединение IPSEC.
Вы скриптом собираетесь править Policies в IPSEC?
Причем на сервере (на отвечающей стороне), а не на клиенте, где 2 оператора с динамическими IP, с которого устанавливается соединение? Будете на клиенте узнавать, с какого реального IP по каждому из операторов вы присутствуете в интернете (встроенный облачный клиент покажет только одного), передавать эту информацию волшебным образом на удаленный сервер, к которому только собираетесь подключиться, и еще отслеживать ситуацию периодически, т.к. операторы вполне себе динамически меняют распределение клиентов по внешним IP.
А на клиенте (у инициатора) IPSEC в принципе динамический. Все берет с удаленного сервера. Как вы его заставите в двух совершенно одинаковых случаях ходить через разные интерфейсы?

Вы про "неправду" сильно погорячились, по-моему.
Но я бы с удовольствием взглянул на вашу попытку реализации этой задачи. :)

[xvo]

Policy устанавливаются между парами адресов: на клиенте это два разных серых IP <-> IP сервера.
На сервере соответственно его IP <-> и какие-то два IP со стороны клиента.

Скрипты работают на клиенте и единственное, что делают - подправляют src-address в l2tp-клиентах и соответствующие route rules при получении другого адреса по dhcp.

Еще раз повторюсь, тут вообще никакой проблемы нет.
Оно всегда работало для белых IP и gre-туннелей, а теперь и отлично работает для l2tp - после того, как появился параметр src-address (это буквально с какой-то из 6.47, в 6.46 long-term'е этого нет).

Как именно реализовать - я написал:
1) src-address в l2tp-клиентах
2) route rule для каждого из адресов с lookup-only-in-table=
3) скрипт уже опционально, если адреса динамические

[Erik_U]

Policy устанавливаются между парами адресов: на клиенте это два разных серых IP <-> IP сервера.

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

[xvo]

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

Один L2TP-клиент создает пакеты с одним серым IP в качестве src-address, второй - со вторым, для первого один дефолтный маршрут, для второго второй, IPSec при создании Policy использует src-address исходного пакета.
Route rules на самом деле нужны только на случай падения одного из каналов, чтобы туннель никогда не строился через не своего провайдера. Если они оба активны, то все построится и по обычным mangle-правилам цепочки output.

На серверной стороне вообще никаких вопросов. Для него это все в любом случае выглядит как два совершенно независимых подключения с разных IP.

[Erik_U]

Один L2TP-клиент создает пакеты с одним серым IP в качестве src-address, второй - со вторым, для первого один дефолтный маршрут, для второго второй, IPSec при создании Policy использует src-address исходного пакета.
Route rules на самом деле нужны только на случай падения одного из каналов, чтобы туннель никогда не строился через не своего провайдера. Если они оба активны, то все построится и по обычным mangle-правилам цепочки output.

На серверной стороне вообще никаких вопросов. Для него это все в любом случае выглядит как два совершенно независимых подключения с разных IP.

Нет. Не так.
Посмотрите логи на сервере.
Сначала устанавливается соединение IPSEC. И никакая настройка src-address в L2TP клиенте на него не влияет. Пока IPSEC соединение не будет установлено, L2TP-клиент не начнет "создавать пакеты с одним серым IP в качестве src-address".
И если на клиенте дефолтный маршрут смотрит в одну сторону, а src-address - в другую, то IPSEC устанавливается по дефолтному маршруту, а L2TP не устанавливается, если шифрование обязательно. Если не обязательно - устанавливается, но не шифруется.

Можно рулить пакеты IPSEC. Но признаков для этого нет. src-address появится только после руления, а до руления есть dst-address, но он одинаковый у обоих.

[Erik_U]

Можно IPSEC с L2TP отрулить в одну сторону жестко, а во вторую сторону запустить OpenVPN, например.
Два IPSEC с L2TP по описанным условиям - по моему не решаемая сейчас задачка.

[xvo]

Нет. Не так.
Посмотрите логи на сервере.
Сначала устанавливается соединение IPSEC. И никакая настройка src-address в L2TP клиенте на него не влияет. Пока IPSEC соединение не будет установлено, L2TP-клиент не начнет "создавать пакеты с одним серым IP в качестве src-address".

А откуда IPSec'у "знать" на какой адрес вообще соединение устанавливать?
Из настроек L2TP. И оттуда же он видимо берет и свой адрес, при его наличии.

По большому счету, это тот случай когда мне не очень интересно знать точный механизм, почему оно работает таким образом, главное чтобы оно работало.
А оно работает.