grifin.ru Posted August 28 · Report post ПОдскажеите пожалуйста, кто знает, как поведет себя роутер (в данном случае микротик) с настроенным IPSec туннелем, в случае когда удаленный пир недоступен. Предположим упал провайдер, соединение порвалось, IPSec сдох, что будет с пакетом, который удовлетворяет условиям Policy ? Он будет дропнут, пойдет по таблице маршрутизации, как будто никакого полиси и нет или с ним еще что-то случится ? Вопрос имеет практическое значение, при падении туннеля хотелось бы зароутить его на резервный рядом стоящий роутер по таблице маршрутизации (уже безо всякого IPSec'а или, как вариант, отправить через IPSec на другой (резервный) пир. Нашел на просторах сети мануал, в котором по netwatch скриптом выключались и выключались те или иные политики, но какое-то костыльное решение, не хочу скрипты городить. В идеале написать бы несколько policy с одинаковыми настройками но разными указанными пирами, расположить в нужном порядке, роутер пусть сам найдет первый жвой из списка, а если не нашел, то пусть отправит пакет в таблицу маршрутизации. Скажите мне что оно так и работает ) Share this post Link to post Share on other sites
alexgreat Posted August 28 · Report post tcpdump в руки и вперёд. не? Share this post Link to post Share on other sites
zhenya` Posted August 28 · Report post сделайте route basec ipsec vpn и не парьте мозг. Share this post Link to post Share on other sites
ShyLion Posted August 28 · Report post https://wiki.mikrotik.com/wiki/Manual:IP/IPsec#Profiles DPD - Dead peer detection Share this post Link to post Share on other sites
VolanD666 Posted August 28 · Report post Поднимите два eoip туннеля, объедините из в ЛАГ (active-backup). На них же можно и ip-sec включить. Share this post Link to post Share on other sites
grifin.ru Posted August 28 · Report post 4 ответа, и никто так и не сказал как оно работает ( DPD это понятно, вопрос в том как будут обрабатываться пакеты, удовлетворяющие политикам мертвых пиров. Share this post Link to post Share on other sites
kt Posted August 28 · Report post пойдет в неработающий туннель и там дропнется. Share this post Link to post Share on other sites
user71 Posted August 28 · Report post @grifin.ru ипсек это полика шифрования. если политика есть - оно шифрует, нет - не шифрует. За отправку туда\сюда ипсек не отвечает, за это отвечают роуты. Если у вас настроен ипсек в тунельном режиме тогда ипсек через модконфиг назначает ипы ну и маршруты добавляются соотвествено. В транспорт мод можно добавить мануальную политику discard после шифрования, тогда оно либо шифруется либо дропается. роутбазе ипсек в микротиках нереализован увы. Но можно поднять л2тп ипсек. Share this post Link to post Share on other sites
jffulcrum Posted August 28 · Report post 8 часов назад, grifin.ru сказал: Предположим упал провайдер, соединение порвалось, IPSec сдох, что будет с пакетом, который удовлетворяет условиям Policy ? Он будет дропнут, пойдет по таблице маршрутизации, как будто никакого полиси и нет или с ним еще что-то случится ? Пока живо SA, пакет будет затянут в политику, зашифрован и поставлен в очередь. Как SA протух (DPD или истечет session key lifetime, а нового ключа по IKE не прилетело) - применяться политика не будет, а вся имеющаяся очередь канет в лету. Из этого печаль с подъемом второго туннеля после падения основного - пока живо прежнее SA, новое SA работать не будет (при использовании той же политики). Share this post Link to post Share on other sites
grifin.ru Posted August 28 · Report post 4 часа назад, jffulcrum сказал: Как SA протух (DPD или истечет session key lifetime, а нового ключа по IKE не прилетело) - применяться политика не будет Если на это можно рассчитывать то это, наверное, устроит. Но вверху коллеги пишут что: 4 часа назад, kt сказал: пойдет в неработающий туннель и там дропнется. Где же правда ? Share this post Link to post Share on other sites
jffulcrum Posted August 28 · Report post Смотря как настроено. Предположим, у нас транспортный режим, шифруется payload, на L3! Все NAT, routing decision уже сделаны! Роутер матчит пакеты к SA - есть матч и SA живое - payload зашифрован - пакет возвращается на L3 и идет в очередь на исходящий интерфейс. Он может быть жив, может быть мертв - это уже не дело IPSEC. В туннельном режиме иная картина. Тут IPSEC по сути заменяет собой L3 целиком. Для роутера пока живо SA - жив и туннель. Даже если пакетам уже физически некуда уходить. Share this post Link to post Share on other sites
grifin.ru Posted August 28 · Report post Да похрен, перерыв в обслуживании равный времени DPD допустИм, насколько я понимаю через DPD interval SA будет уже мертв. Будет оно работать в режиме отказоустойчивости с временем лага равному DPD Interval ? Режим туннельный. PS. Про ситуацию когда канал скорее мертв, но еще жив (отдельные пакеты пропускает но работать не может) упоменать не стоит, за качеством следит другой алгоритм и некачественный аплинк просто будет переведен в DOWN пока не исправится. Share this post Link to post Share on other sites
grifin.ru Posted August 31 · Report post А вот еще у меня вопрос появился, не могу найти вменяемый ответ. Во время выпуска сертификатов для IPSEC насколько я поню необходимо задавать ip адрес в соответсвующем поле запроса на сертификат. Как и кем осуществляется проверка соответствия IP сертификата и IP адреса пакета ? И вообще какого IP адреса ? До IPSEC преобразования (с вытаскиванием из туннеля) или после ? Share this post Link to post Share on other sites
grifin.ru Posted September 2 · Report post Никто не знает что ли ? ) Share this post Link to post Share on other sites
jffulcrum Posted September 2 · Report post В 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) Share this post Link to post Share on other sites
grifin.ru Posted September 2 · Report post 50 минут назад, jffulcrum сказал: Только если у вас идет подключение по IP Вот тут непонятно, подключение в любом случае идет по IP, просто в некоторых случаях сначала DNS ресолвится в IP. В случае проверки DNS, происходит ресолв этого DNS и сравнение отресолвленного IP адресом из IP Заголовка ? 58 минут назад, jffulcrum сказал: DNS-имен достаточно. Тогда нужно еще обеспечить достоверность ответов DNS сервера. Share this post Link to post Share on other sites
jffulcrum Posted September 2 · Report post 13 минут назад, grifin.ru сказал: В случае проверки DNS, происходит ресолв этого DNS и сравнение отресолвленного IP адресом из IP Заголовка ? Нет. DNS-имя, к которому идет подключение, сверяется с полем CN сертификата сервера, если там нет полного совпадения - смотрится еще SAN. IP вообще никому не интересен при работе через DNS. Если же идет подключение именно по IP, то сверяется IP с атрибутом ipaddress в поле SAN сертификата сервера. Это если клиент понимает этот атрибут в принципе - даже у Cisco с этим были нехилые проблемы. Share this post Link to post Share on other sites
jffulcrum Posted September 2 · Report post Надо просто понимать, что в IPsec все идет в несколько этапов (фаз), и на каждой делается что-то свое. Сертификаты,как и PSK, как и EAP, работают на первой фазе, чтобы клиент и сервер убедились, что попали куда надо. Дальше уже идет согласование собственно шифрования -ключи, алгоритмы, политики, что каждый умеет, как обмениваемся, туннель/транспорт и все такое. Тут уже никакая инфа с предыдущего этапа не нужна, разве что сервер запомнит какие-то атрибуты клиента для матчинга политики. Share this post Link to post Share on other sites
DAF Posted September 2 · Report post Года 2 назад экспериментировал со связкой IPIP+IPsec и настроил тоннель между 2-мя микротиками, оба были с белой статикой, и оба за НАТ-ом. Один мтик был в DMZ, на втором вроде 500 порт пробрасывал.Тоннель работал очень стабильно, но потом надобность отпала, конфиги в *.rsc не сохранились (netinstall-ом всё снёс после печально известной winbox-уязвимости). Решил вот восстановить тоннель, но чёт не получается. Не может ли это быть связано с изменениями в ipsec в последних версиях? Сейчас версия long-tem 6.44.5 Share this post Link to post Share on other sites
jffulcrum Posted September 2 · Report post Да, с IPSEC кое-что переделывали в 6.45, в Винбоксе теперь больше закладок :) Share this post Link to post Share on other sites
DAF Posted September 3 · Report post Кажется понял в чём дело: *) conntrack - fixed GRE protocol packet connection-state matching (CVE-2014-8160); IPIP ведь использует 47 протокол? Share this post Link to post Share on other sites
jffulcrum Posted September 3 · Report post Да, GRE теперь надо прямо разрешать в input в firewall Share this post Link to post Share on other sites