Здравствуйте!
Хочу решить вопрос в ситуации когда из одного места имеющего всего одного провайдера(один белый 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) которое подключено к другому провайдеру?
L2L IPSEC VPN
-
- Сообщения: 4204
- Зарегистрирован: 25 фев 2018, 22:41
- Откуда: Москва
Создаете на сервере ещё один аккаунт (можно наверное и без этого, но так логичнее).
Снимаете на сервере галку "One Session Per Host".
Коннектитесь клиентом на второй IP.
Снимаете на сервере галку "One Session Per Host".
Коннектитесь клиентом на второй IP.
Telegram: @thexvo
-
- Сообщения: 5
- Зарегистрирован: 25 янв 2021, 14:49
В качестве двух 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 или "нечто иное". Вот в этом у меня и проблема.
-
- Сообщения: 4204
- Зарегистрирован: 25 фев 2018, 22:41
- Откуда: Москва
Зачем маскарад?
Добавляете просто ещё пару маршрутов: на микротике через туннельный адрес второго сервера, на втором сервере - до сети за микротиком по аналогии с тем, как оно на первом сервере.
Ну а уж какой маршрут держать активным или оба сразу - это уже сами решайте.
Добавляете просто ещё пару маршрутов: на микротике через туннельный адрес второго сервера, на втором сервере - до сети за микротиком по аналогии с тем, как оно на первом сервере.
Ну а уж какой маршрут держать активным или оба сразу - это уже сами решайте.
Telegram: @thexvo
-
- Сообщения: 5
- Зарегистрирован: 25 янв 2021, 14:49
Здравствуйте!xvo писал(а): ↑25 янв 2021, 17:30 Зачем маскарад?
Добавляете просто ещё пару маршрутов: на микротике через туннельный адрес второго сервера, на втором сервере - до сети за микротиком по аналогии с тем, как оно на первом сервере.
Ну а уж какой маршрут держать активным или оба сразу - это уже сами решайте.
Тестировал ваш способ, но это не принесло плодов.
Суть проблемы в том, что если при обычных обстоятельствах, когда маршрутизатор 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.
Подскажите пожалуйста.
-
- Сообщения: 4204
- Зарегистрирован: 25 фев 2018, 22:41
- Откуда: Москва
Туннели нельзя перестраивать не через свой выход.
Должно быть два туннеля, каждый через свой сервер: канал упал, туннель тоже должен лежать, вместе с маршрутом через него.
Тогда OSPF подтянет второй маршрут.
Поднимется канал, поднимется туннель - OSPF перестроится обратно.
(Это если вариант с резервированием).
Если же использовать ECMP, то при падении какого-то одного туннеля он перестанет быть ECMP, останется просто обычный маршрут через живой туннель.
Должно быть два туннеля, каждый через свой сервер: канал упал, туннель тоже должен лежать, вместе с маршрутом через него.
Тогда OSPF подтянет второй маршрут.
Поднимется канал, поднимется туннель - OSPF перестроится обратно.
(Это если вариант с резервированием).
Если же использовать ECMP, то при падении какого-то одного туннеля он перестанет быть ECMP, останется просто обычный маршрут через живой туннель.
Telegram: @thexvo
-
- Сообщения: 5
- Зарегистрирован: 25 янв 2021, 14:49
Подскажите пожалуйста, есть ли в сети интернет ссылки на примеры? Я например задавал в поисковиках запросы вида:xvo писал(а): ↑27 янв 2021, 15:27 Туннели нельзя перестраивать не через свой выход.
Должно быть два туннеля, каждый через свой сервер: канал упал, туннель тоже должен лежать, вместе с маршрутом через него.
Тогда OSPF подтянет второй маршрут.
Поднимется канал, поднимется туннель - OSPF перестроится обратно.
(Это если вариант с резервированием).
Если же использовать ECMP, то при падении какого-то одного туннеля он перестанет быть ECMP, останется просто обычный маршрут через живой туннель.
Туннель IPSEC VPN через два канала
И вариации на данную тему, но в ответах выводится масса не то что нужно, что то вроде балансировка каналов и т.п.
-
- Сообщения: 4204
- Зарегистрирован: 25 фев 2018, 22:41
- Откуда: Москва
Не думаю, что получится найти пример прямо под вашу ситуацию.
Вообще, получается, что основная проблема в том, что маршрут продолжает существовать даже при падении туннеля.
Кстати почему? Даже если он не добавляется через конфиг ipsec, а просто статически, он бы должен становиться unreachable при падении провайдера? Или там нет никакой проверки шлюза?
Вообще, получается, что основная проблема в том, что маршрут продолжает существовать даже при падении туннеля.
Кстати почему? Даже если он не добавляется через конфиг ipsec, а просто статически, он бы должен становиться unreachable при падении провайдера? Или там нет никакой проверки шлюза?
Telegram: @thexvo
-
- Сообщения: 5
- Зарегистрирован: 25 янв 2021, 14:49
На CISCO ASA с IP-адресом 202.0.0.1 проверка шлюза не ведется по причине того, в данное оборудование входят VPN-каналы других провайдеров (их в оборудовании 4), да и порой ситуации "курьёзные" случаются, так например у CISCO ASA с IP-адресом 202.0.0.1 "пигуется" весь Интернет кроме MIKROTIK-а с IP-адресом 172.0.0.1. Конечно это не часто бывает, но за последние пару лет раз 5 наверное было. С чем связаны подобные "невозможные" казалось бы случаи, провайдеры мне не поясняют, но пост-фактум "само" начинает "работать".xvo писал(а): ↑27 янв 2021, 16:48 Не думаю, что получится найти пример прямо под вашу ситуацию.
Вообще, получается, что основная проблема в том, что маршрут продолжает существовать даже при падении туннеля.
Кстати почему? Даже если он не добавляется через конфиг ipsec, а просто статически, он бы должен становиться unreachable при падении провайдера? Или там нет никакой проверки шлюза?
А в основном Вы правы, маршрут продолжает "жить" даже при падении туннеля.
Да, и кстати, может есть ссылка на пример "Как заставить "умереть" маршрут при падении туннеля на CISCO ASA"?
-
- Сообщения: 4204
- Зарегистрирован: 25 фев 2018, 22:41
- Откуда: Москва
Так вам надо "убить" не маршрут до основного шлюза, а только тот самый статический маршрут до подсети микротика.
На микротиках достаточно было бы повесить на него check-gateway=ping.
В принципе что-то аналогичное должно быть и на Cisco.
Если маршрут умрет - первая циска перестанет отдавать его по OSPF и как минимум эта проблема разрешится. На свитч уже будет будет прилетать маршрут только от второй циски, (который в обычное время видимо с большей метрикой), и все пойдет по нему.
На микротиках достаточно было бы повесить на него check-gateway=ping.
В принципе что-то аналогичное должно быть и на Cisco.
Если маршрут умрет - первая циска перестанет отдавать его по OSPF и как минимум эта проблема разрешится. На свитч уже будет будет прилетать маршрут только от второй циски, (который в обычное время видимо с большей метрикой), и все пойдет по нему.
Telegram: @thexvo