маршрутизация ipsec

[grifin.ru]

Кто хорошо понимает как оно работает, проясните пожалуйста

Пакет пройдет через IP-SEC туннель, если марштутизаторы на конце туннеля не имеют дефолтного маршрута ?

Пакет пришел из одной серой сети (например 10.10.10.0/24) в другую (например 10.10.10.1/24) между марштутизаторами не интернет а своя серая маршрутизируемая  сеть ( пусть например адреса маршрутизаторов 192.168.1.1/24 и 192.168.2.1.24), между этими сетями жесткий firewall и настроенная только на нужное таблица маршрутизации). Пакет из сетей 10.10. никогда не попадет и не знает маршрута до сети 192.168 и наоборот.

Однако на том уровне модели OSI, на котором работает IPSEC - пакеты инкапсулируются в туннель и уже адрес другого конца туннеля  отправляющему маршрутизатору уже известен.

Поскольку полиси IPSEC проверяются после Routing Decision и после firewall chain forward, значит ли это что в моей схеме до IPSECа дела даже не дойдтет, а вернет в лучшем случае no route to the host ?

 

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

[azhur]

3 часа назад, grifin.ru сказал:

Поскольку полиси IPSEC проверяются после Routing Decision и после firewall chain forward, значит ли это что в моей схеме до IPSECа дела даже не дойдтет, а вернет в лучшем случае no route to the host ?

Про какое устройство идёт речь?

[grifin.ru]

Про микротик пока и про циску потом. Не думаю что базовая логика там как-то различается )

[ShyLion]

5 hours ago, grifin.ru said:

Кто хорошо понимает как оно работает, проясните пожалуйста

Пакет пройдет через IP-SEC туннель, если марштутизаторы на конце туннеля не имеют дефолтного маршрута ?

Пакет пришел из одной серой сети (например 10.10.10.0/24) в другую (например 10.10.10.1/24) между марштутизаторами не интернет а своя серая маршрутизируемая  сеть ( пусть например адреса маршрутизаторов 192.168.1.1/24 и 192.168.2.1.24), между этими сетями жесткий firewall и настроенная только на нужное таблица маршрутизации). Пакет из сетей 10.10. никогда не попадет и не знает маршрута до сети 192.168 и наоборот.

Однако на том уровне модели OSI, на котором работает IPSEC - пакеты инкапсулируются в туннель и уже адрес другого конца туннеля  отправляющему маршрутизатору уже известен.

Поскольку полиси IPSEC проверяются после Routing Decision и после firewall chain forward, значит ли это что в моей схеме до IPSECа дела даже не дойдтет, а вернет в лучшем случае no route to the host ?

 

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

1. Пакеты ни о каких маршрута не "знают". Маршруты знают маршрутизаторы и конечные устройства.

2. Голый IPSec работает по такому принципу - изначальный пакет, следующий по маршруту, перехватывается на исходящем интерфейсе, согласно таблицы маршрутизации. Затем шифруется согласно политике и отаправляется в зашифрованом виде на удаленный хост, настроеный в политике. Там расшифровывается и входит в общий процесс маршрутизации.

 

[kuterye]

Для Микротика, судя по IPsec Encryption/Decryption, так и есть. Так что пакет из сети 10.10.10.0/24 должен знать как попасть в 10.10.10.1/24 и без IPSEC. Осталось решить, как это сделать без "левых" маршрутов. Интересно, подойдет ли маршрут с type blackhole?

  У циски может быть своя магия. Так что

Edited May 22, 2019 by kuterye

[ShyLion]

45 minutes ago, kuterye said:

Для Микротика, судя по IPsec Encryption/Decryption, так и есть. Так что пакет из сети 10.10.10.0/24 должен знать как попасть в 10.10.10.1/24 и без IPSEC. Осталось решить, как это сделать без "левых" маршрутов. Интересно, подойдет ли маршрут с type blackhole?

  У циски может быть своя магия. Так что

У циски точно также.

Поэтому в голом виде ипсек на роутерах используют только вынуждено, когда надо подружиться с чужим оборудованием, которое не циско-роутер.

На роутерах делают тунельные интерфейсы, через которые уже все работает по человечески, включая все протоколы маршрутизации.

[grifin.ru]

13 часов назад, ShyLion сказал:

следующий по маршруту, перехватывается на исходящем интерфейсе, согласно таблицы маршрутизации.

Вот об этом и речь. В таблице маршрутизации нет маршрута, поэтому пакет, как я понимаю, до исходящего интерфейса просто не дойдет.

 

12 часов назад, ShyLion сказал:

На роутерах делают тунельные интерфейсы, через которые уже все работает по человечески, включая все протоколы маршрутизации.

На IPSEC тоже есть тунель-моде. Собственно про него и речь.

[kapydan]

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

На IPSEC тоже есть тунель-моде. Собственно про него и речь.

между tunnel mode и transport mode разница в инкапсуляции.

[grifin.ru]

23 минуты назад, kapydan сказал:

между tunnel mode и transport mode разница в инкапсуляции.

Что никак не противоречит сказанному выше и не дает ответа на вопрос "как красиво обойти". 

[grifin.ru]

15 часов назад, ShyLion сказал:

На роутерах делают тунельные интерфейсы, через которые уже все работает по человечески, включая все протоколы маршрутизации.

В этом случае мы в модель угроз добавляем опасность наличия уязвимости в транспортном протоколе. Тогда вообще нахрена IPSEC, проще OVPN использовать.

[ShyLion]

6 hours ago, grifin.ru said:

В этом случае мы в модель угроз добавляем опасность наличия уязвимости в транспортном протоколе. Тогда вообще нахрена IPSEC, проще OVPN использовать.

Чаво? Каких угроз? Каких уязвимостей? Заворачивается GRE в IPSec и все. Какие "угрозы" тут добавляются?

 

 

[ShyLion]

7 hours ago, grifin.ru said:

вообще нахрена IPSEC, проще OVPN использовать.

Так это не на каждой платформе есть, а где есть, там оно не всегда быстро работает. На том же тике, со слов местных гуру, OVPN одно ядро только использует. Для одного подключения может и сойдет.

 

 

8 hours ago, grifin.ru said:

Что никак не противоречит сказанному выше и не дает ответа на вопрос "как красиво обойти". 

Что мешает на своем роутере прописать маршрут в нужную сторону?

[kapydan]

ну если делать ipsec и gre, то проще всего, и правильнее, будет настроить фазу 1 и 2 и применить их на gre. либо настроить крипто-карту, если нет необходимости/желания, ширфовать весь трафик в туннель.

 

а прописать маршрут можно статикой. если брать циску - то у такого маршрута можно еще и дистанцию изменить.

[zoro]

В 22.05.2019 в 20:09, grifin.ru сказал:

Вот об этом и речь. В таблице маршрутизации нет маршрута, поэтому пакет, как я понимаю, до исходящего интерфейса просто не дойдет.

Если на вашей стороне А, нет информации в таблице маршрутизации о сети которая расположена за/на_маршрутизаторе Б, и нет дефолтного маршрутизатора, то пакет уйдет в славный dev/NULL , и в зависимости от политики маршрутизатора и вида пакета маршрутизатор или просто промолчит или в ответ выкинет что маршрут не доступен...

 

Если на вашей стороне А есть в таблице маршрутизации информация про то что нужная сеточка находится в "Конце туннеля" который установлен между А и Б, а маршрутизатор Б не знает про это, тогда пакет дойдет до маршрутизатора Б(будет зашифрован, обработан со всеми почестями)  он или пойдет в ДефолтРоут маршрутизатора Б, или если его нет- то пакет уйдет в славный dev/NULL , и в зависимости от политики маршрутизатора и вида пакета маршрутизатор или просто промолчит или в ответ выкинет что маршрут не доступен...

Обойти? Практически не как, Люди старались что бы мусор гнобить и убивать... Старались делать динамические протоколы маршрутизации, делали возможность фильтрации маршрутизации, А вы просто так взять и обойти...