L2L IPSEC VPN

[sidsoft]

Здравствуйте!
Хочу решить вопрос в ситуации когда из одного места имеющего всего одного провайдера(один белый IP-адрес 172.0.0.1), нужно построить L2L IPSEC VPN с разными провайдерами.
Если я строю туннель с одним провайдером (по схеме соединение с IP-адреса 172.0.0.1 на IP-адрес 202.0.0.1) то всё хорошо, всё работает, проблем нет, а вот как построить туннель и "гнать" трафик через другое оборудование (по схеме с IP-адреса 172.0.0.1 на IP-адрес 102.0.0.1) которое подключено к другому провайдеру?

[xvo]

Создаете на сервере ещё один аккаунт (можно наверное и без этого, но так логичнее).
Снимаете на сервере галку "One Session Per Host".
Коннектитесь клиентом на второй IP.

[sidsoft]

Создаете на сервере ещё один аккаунт (можно наверное и без этого, но так логичнее).
Снимаете на сервере галку "One Session Per Host".
Коннектитесь клиентом на второй IP.

В качестве двух IPSEC серверов с IP-адресами 202.0.0.1 и 102.0.0.1 (см.схему) установлены CISCO ASA. Внутренняя подсеть для них общая (10.10.1.0/24)... При подключении с IP-адреса 172.0.0.1 на IP-адрес 202.0.0.1 для микротика создаётся туннель и правила, что если соединение происходит с точки 172.0.0.1 на точку 202.0.0.1 то туннелируется IP-адрес микротика подсети 192.168.100.0/24 и обратно соответственно 10.10.1.0/24, пинги и прочие сервисы доступны, всё ОК... а как быть если подключение происходит с точки 172.0.0.1 на 102.0.0.1... Я так понимаю, что необходимо получить для микротика "другой туннельный" IP-адрес, например 192.168.122.28/30 и этот адрес я так думаю надо masquerade или "нечто иное". Вот в этом у меня и проблема.

[xvo]

Зачем маскарад?
Добавляете просто ещё пару маршрутов: на микротике через туннельный адрес второго сервера, на втором сервере - до сети за микротиком по аналогии с тем, как оно на первом сервере.

Ну а уж какой маршрут держать активным или оба сразу - это уже сами решайте.

[sidsoft]

Зачем маскарад?
Добавляете просто ещё пару маршрутов: на микротике через туннельный адрес второго сервера, на втором сервере - до сети за микротиком по аналогии с тем, как оно на первом сервере.

Ну а уж какой маршрут держать активным или оба сразу - это уже сами решайте.

Здравствуйте!
Тестировал ваш способ, но это не принесло плодов.
Суть проблемы в том, что если при обычных обстоятельствах, когда маршрутизатор MIKROTIK с IP-адресом 172.0.0.1 "строит" успешный IPSEC L2L туннель с CISCO ASA c IP-адресом 202.0.0.1 то всё хорошо, две подсети (за MIKROTIK и ASA) друг друга "видят", маршрут из подсети CISCO ASA прописан такой, что если компьютер с IP-адресом 10.10.1.100 подсети за CISCO ASA запросила компьютер с IP-адресом 192.168.100.100 находящийся в подсети за MIKROTIK, то пакеты пойдут следовательно через CISCO ASA с IP-адресом 202.0.0.1 на маршрутизатор MIKROTIK с IP-адресом 172.0.0.1.
Но случилась проблема, у CISCO ASA с IP-адресом 202.0.0.1 пропал Интернет, MIKROTIK "построил" туннель IPSEC L2L с "соседним" CISCO ASA c IP-адресом 102.0.0.1. Вот тут и вся проблема: у CISCO ASA с IP-адресом 202.0.0.1 в конфигурации прописан маршрут статический на подсеть MIKROTIK, 192.168.100.0/24, вот строчка из конфигурации CISCO ASA с IP-адресом 202.0.0.1:
route outside 192.168.100.0 255.255.255.0 172.0.0.1
Т.к. маршруты в сети передаются по OSPF то и свитч в подсети CISCO ASA 10.10.1.0/24 так же видит маршрут к подсети MIKROTIK 192.168.100.0/24 через CISCO ASA у которого уже нет Интернета. Соответственно Две подсети не видят друг друга, хотя туннель построен через соседний CISCO ASA с IP-адресом 102.0.0.1
Пробовал метрики на свитче подсети 10.10.1.0/24 прописывать, НО положительных результатов я не добился.
Тут то я и подумал, как бы "замаскарадить" второе соединение IPSEC L2L.
Подскажите пожалуйста.

[xvo]

Туннели нельзя перестраивать не через свой выход.
Должно быть два туннеля, каждый через свой сервер: канал упал, туннель тоже должен лежать, вместе с маршрутом через него.
Тогда OSPF подтянет второй маршрут.
Поднимется канал, поднимется туннель - OSPF перестроится обратно.
(Это если вариант с резервированием).

Если же использовать ECMP, то при падении какого-то одного туннеля он перестанет быть ECMP, останется просто обычный маршрут через живой туннель.

[sidsoft]

Туннели нельзя перестраивать не через свой выход.
Должно быть два туннеля, каждый через свой сервер: канал упал, туннель тоже должен лежать, вместе с маршрутом через него.
Тогда OSPF подтянет второй маршрут.
Поднимется канал, поднимется туннель - OSPF перестроится обратно.
(Это если вариант с резервированием).

Если же использовать ECMP, то при падении какого-то одного туннеля он перестанет быть ECMP, останется просто обычный маршрут через живой туннель.

Подскажите пожалуйста, есть ли в сети интернет ссылки на примеры? Я например задавал в поисковиках запросы вида:
Туннель IPSEC VPN через два канала
И вариации на данную тему, но в ответах выводится масса не то что нужно, что то вроде балансировка каналов и т.п.

[xvo]

Не думаю, что получится найти пример прямо под вашу ситуацию.

Вообще, получается, что основная проблема в том, что маршрут продолжает существовать даже при падении туннеля.
Кстати почему? Даже если он не добавляется через конфиг ipsec, а просто статически, он бы должен становиться unreachable при падении провайдера? Или там нет никакой проверки шлюза?

[sidsoft]

Не думаю, что получится найти пример прямо под вашу ситуацию.

Вообще, получается, что основная проблема в том, что маршрут продолжает существовать даже при падении туннеля.
Кстати почему? Даже если он не добавляется через конфиг ipsec, а просто статически, он бы должен становиться unreachable при падении провайдера? Или там нет никакой проверки шлюза?

На CISCO ASA с IP-адресом 202.0.0.1 проверка шлюза не ведется по причине того, в данное оборудование входят VPN-каналы других провайдеров (их в оборудовании 4), да и порой ситуации "курьёзные" случаются, так например у CISCO ASA с IP-адресом 202.0.0.1 "пигуется" весь Интернет кроме MIKROTIK-а с IP-адресом 172.0.0.1. Конечно это не часто бывает, но за последние пару лет раз 5 наверное было. С чем связаны подобные "невозможные" казалось бы случаи, провайдеры мне не поясняют, но пост-фактум "само" начинает "работать".
А в основном Вы правы, маршрут продолжает "жить" даже при падении туннеля.
Да, и кстати, может есть ссылка на пример "Как заставить "умереть" маршрут при падении туннеля на CISCO ASA"?

[xvo]

Так вам надо "убить" не маршрут до основного шлюза, а только тот самый статический маршрут до подсети микротика.
На микротиках достаточно было бы повесить на него check-gateway=ping.
В принципе что-то аналогичное должно быть и на Cisco.
Если маршрут умрет - первая циска перестанет отдавать его по OSPF и как минимум эта проблема разрешится. На свитч уже будет будет прилетать маршрут только от второй циски, (который в обычное время видимо с большей метрикой), и все пойдет по нему.