[grifin.ru]

ПОдскажеите пожалуйста, кто знает, как поведет себя роутер (в данном случае микротик) с настроенным IPSec туннелем, в случае когда удаленный пир недоступен.

Предположим упал провайдер, соединение порвалось, IPSec сдох, что будет с пакетом, который удовлетворяет условиям Policy ? Он будет дропнут, пойдет по таблице маршрутизации, как будто никакого полиси и нет или с ним еще что-то случится ?

Вопрос имеет практическое значение, при падении туннеля хотелось бы зароутить его на резервный рядом стоящий роутер по таблице маршрутизации (уже безо всякого IPSec'а или, как вариант, отправить через IPSec на другой (резервный) пир.

Нашел на просторах сети мануал, в котором по netwatch скриптом выключались и выключались те или иные политики, но какое-то костыльное решение, не хочу скрипты городить. В идеале написать бы несколько policy с одинаковыми настройками но разными указанными пирами, расположить в нужном порядке, роутер пусть сам найдет первый жвой из списка, а если не нашел, то пусть отправит пакет в таблицу маршрутизации. Скажите мне что оно так и работает )

[alexgreat]

tcpdump в руки и вперёд. не?

[zhenya`]

сделайте route basec ipsec vpn и не парьте мозг.

[ShyLion]

https://wiki.mikrotik.com/wiki/Manual:IP/IPsec#Profiles

DPD - Dead peer detection

[VolanD666]

Поднимите два eoip туннеля, объедините из в ЛАГ (active-backup). На них же можно и ip-sec включить.

[grifin.ru]

4 ответа, и никто так и не сказал как оно работает (

 

DPD это понятно, вопрос в том как будут обрабатываться пакеты, удовлетворяющие политикам мертвых пиров.

[kt]

пойдет в неработающий туннель и там дропнется.

[user71]

@grifin.ru ипсек это полика шифрования. если политика есть - оно шифрует, нет - не шифрует. За отправку туда\сюда ипсек не отвечает, за это отвечают роуты. Если у вас настроен ипсек в тунельном режиме тогда ипсек через модконфиг назначает ипы ну и маршруты добавляются соотвествено. В транспорт мод можно добавить мануальную политику discard после шифрования, тогда оно либо шифруется либо дропается. роутбазе ипсек в микротиках нереализован увы. Но можно поднять л2тп ипсек.

[jffulcrum]

8 часов назад, grifin.ru сказал:

Предположим упал провайдер, соединение порвалось, IPSec сдох, что будет с пакетом, который удовлетворяет условиям Policy ? Он будет дропнут, пойдет по таблице маршрутизации, как будто никакого полиси и нет или с ним еще что-то случится ?

Пока живо SA, пакет будет затянут в политику, зашифрован и поставлен в очередь. Как SA протух (DPD или истечет session key lifetime, а нового ключа по IKE не прилетело) - применяться политика не будет, а вся имеющаяся очередь канет в лету.

 

Из этого печаль с подъемом второго туннеля после падения основного - пока живо прежнее SA, новое SA работать не будет (при использовании той же политики).

[grifin.ru]

4 часа назад, jffulcrum сказал:

Как SA протух (DPD или истечет session key lifetime, а нового ключа по IKE не прилетело) - применяться политика не будет

Если на это можно рассчитывать то это, наверное, устроит.

Но вверху коллеги пишут что:

4 часа назад, kt сказал:

пойдет в неработающий туннель и там дропнется.

Где же правда ?

[jffulcrum]

Смотря как настроено. Предположим, у нас транспортный режим, шифруется payload, на L3! Все NAT, routing decision уже сделаны! Роутер матчит пакеты к SA - есть матч и SA живое - payload зашифрован - пакет возвращается на L3 и идет в очередь на исходящий интерфейс. Он может быть жив, может быть мертв - это уже не дело IPSEC.

 

В туннельном режиме иная картина. Тут IPSEC по сути заменяет собой L3 целиком. Для роутера пока живо SA - жив и туннель. Даже если пакетам уже физически некуда уходить.

[grifin.ru]

Да похрен, перерыв в обслуживании равный времени DPD допустИм, насколько я понимаю через DPD interval SA будет уже мертв. Будет оно работать в режиме отказоустойчивости с временем лага равному DPD Interval ? Режим туннельный.

PS. Про ситуацию когда канал скорее  мертв, но еще жив (отдельные пакеты пропускает но работать не может) упоменать не стоит, за качеством следит другой алгоритм и некачественный аплинк просто будет переведен в DOWN пока не исправится.

[grifin.ru]

А вот еще у меня вопрос появился, не могу найти вменяемый ответ.

Во время выпуска сертификатов для IPSEC насколько я поню необходимо задавать ip адрес в соответсвующем поле запроса на сертификат.

Как и кем осуществляется проверка соответствия IP сертификата и IP адреса пакета ?

И вообще какого IP адреса ? До IPSEC преобразования (с вытаскиванием из туннеля) или после ?

[grifin.ru]

Никто не знает что ли ? )

[jffulcrum]

В 29.08.2019 в 02:15, grifin.ru сказал:

Будет оно работать в режиме отказоустойчивости с временем лага равному DPD Interval ? Режим туннельный.

В туннельном режиме IPSEC и есть L3. Если DPD настроен - туннель умрет. Нет такого, чтобы туннель recycle при подключении с другого интерфейса/IP и т.д., туннель сначала должен умереть, потом поднимается новый.

 

В 01.09.2019 в 00:00, grifin.ru сказал:

Во время выпуска сертификатов для IPSEC насколько я поню необходимо задавать ip адрес в соответсвующем поле запроса на сертификат.

Только если у вас идет подключение по IP. Делать так можно, если это Site-to-Site, и оба устройства от одного вендора. Для клиентов - огребете геморроя (особливо от старой винды и старой Андрюшки). DNS-имен достаточно.

 

В 01.09.2019 в 00:00, grifin.ru сказал:

Как и кем осуществляется проверка соответствия IP сертификата и IP адреса пакета ?

Клиентом

 

В 01.09.2019 в 00:00, grifin.ru сказал:

И вообще какого IP адреса ?

Публичного, к которому идет запрос IKE (еще на фазе 1)

[grifin.ru]

50 минут назад, jffulcrum сказал:

Только если у вас идет подключение по IP

Вот тут непонятно, подключение в любом случае идет по IP, просто в некоторых случаях сначала DNS ресолвится в IP. 

В случае проверки DNS, происходит ресолв этого DNS и сравнение отресолвленного IP адресом из IP Заголовка ?

 

58 минут назад, jffulcrum сказал:

DNS-имен достаточно.

Тогда нужно еще обеспечить достоверность ответов DNS сервера.

[jffulcrum]

13 минут назад, grifin.ru сказал:

В случае проверки DNS, происходит ресолв этого DNS и сравнение отресолвленного IP адресом из IP Заголовка ?

 

Нет.  DNS-имя, к которому идет подключение, сверяется с полем CN сертификата сервера, если там нет полного совпадения - смотрится еще SAN. IP вообще никому не интересен при работе через DNS. Если же идет подключение именно по IP, то сверяется IP с атрибутом ipaddress в поле SAN сертификата сервера. Это если клиент понимает этот атрибут в принципе - даже у Cisco с этим были нехилые проблемы.

[jffulcrum]

Надо просто понимать, что в IPsec все идет в несколько этапов (фаз), и на каждой делается что-то свое. Сертификаты,как и PSK, как и EAP, работают на первой фазе, чтобы клиент и сервер убедились, что попали куда надо. Дальше уже идет согласование собственно шифрования -ключи, алгоритмы, политики, что каждый умеет, как обмениваемся, туннель/транспорт и все такое. Тут уже никакая инфа с предыдущего этапа не нужна, разве что сервер запомнит какие-то атрибуты клиента для матчинга политики.

[DAF]

Года 2 назад экспериментировал со связкой IPIP+IPsec и настроил тоннель между 2-мя микротиками, оба были с белой статикой, и оба за НАТ-ом.

Один мтик был в DMZ, на втором вроде 500 порт пробрасывал.Тоннель работал очень стабильно, но потом надобность отпала, конфиги в *.rsc не сохранились (netinstall-ом всё снёс после печально известной winbox-уязвимости).

Решил вот восстановить тоннель, но чёт не получается. Не может ли это быть связано с изменениями в ipsec в последних версиях? Сейчас версия long-tem 6.44.5

[jffulcrum]

Да, с IPSEC кое-что переделывали в 6.45, в Винбоксе теперь больше закладок :)

[DAF]

Кажется понял в чём дело:

*) conntrack - fixed GRE protocol packet connection-state matching (CVE-2014-8160);

IPIP ведь использует 47 протокол?

[jffulcrum]

Да, GRE теперь надо прямо разрешать в input в firewall