(Пере)распределить маршрут IPSec через OSPF, RouterOS
BrianHiggins
Guest
0
16.11.2021 22:15:00
Должен быть простой ответ... У меня есть конкретная среда, с которой я работаю: есть IPSec туннель от основного маршрутизатора к сети, управляемой третьей стороной (туннель работает отлично). Также есть ещё 5 маршрутизаторов, подключённых по OSPF к тому же основному маршрутизатору. Вся связь работает, кроме распространения маршрута для сети IPSec. Я застрял на том, как распределить маршрут к удалённой сети IPSec через OSPF. Я могу добавить статический маршрут на удалённых маршрутизаторах (к основному через их существующие подключения), и все соединения будут работать правильно, но никак не могу понять, как раздать маршрут, подключённый через IPSec, удалённым маршрутизаторам именно через OSPF.
tdw
Guest
0
14.03.2022 00:57:00
IPsec обычно основан на политиках, поэтому все, что соответствует политикам, перехватывается для обработки. Подробнее о политиках IPsec можно узнать по ссылке . Он не основан на маршрутах, поэтому маршруты не подлежат перераспределению. Некоторые производители используют виртуальные интерфейсы, например Cisco VTI. В Mikrotik можно использовать GRE или IPIP туннели с IPsec, чтобы обеспечить похожую функциональность.
eduplant
Guest
0
14.03.2022 05:46:00
Пересмотрев это, я думаю, что неправильно понял ситуацию — будто у тебя два роутера, которыми ты управляешь, расположены по разным концам L3-провайдера посередине. Я прикрепил кое-какой неаккуратный набросок в MSPaint моего второго варианта прочтения, чтобы убедиться, правильно ли я понял, прежде чем продолжать. Это префикс x.x.x.x/x с другой стороны IPsec-соединения, который ты пытаешься добавить в OSPF? И было бы здорово уточнить, используется ли здесь простой IPsec с ручной политикой или же что-то другое, например L2TP/GRE/IPIP поверх него.
SiB
Guest
0
14.03.2022 09:37:00
Насколько я знаю, но не тестировал в RouterOS, в мире Cisco используют правило на "главном роутере" вида /ip route add dst-address=x.x.x.x/x gateway=(eth2 или IP@eth2). С RouterOS всегда возникают такие проблемы. Пока что можно попробовать некоторые обходные решения: *) SNAT&DNAT, чтобы пропускать трафик между одним IPSec и другим IPSec/роутером — это не ваш случай. *) Добавить слой, например GRE поверх IPSec, и использовать маршрут через GRE как интерфейс. Это можно распределять. *) Добавить ещё один маленький роутер — SPOF, который занимается IPSec и находится между ними, тогда ваш "главный роутер" делает обычный маршрут и может его распределять.
cpbruton
Guest
0
27.03.2022 19:17:00
Раньше я делал это так: добавлял loopback (bridge) интерфейс, добавлял статические маршруты для удалённой сети, затем распространял эти статические маршруты через OSPF. IPsec перехватывает трафик, когда активна соответствующая политика. Если IPsec-туннель не работает, маршрут всё равно распространяется — если это для вас проблема, то, возможно, можно написать скрипт (включать/выключать статический маршрут на основе пинга до другой стороны туннеля).
SiB
Guest
0
27.03.2022 22:40:00
cpbruton пишет: Можешь дать больше подробностей? Например: Локальный src.address в локальном enc.domain — 192.168.10.0/24. Удалённый dst.address в удалённом enc.domain — 192.168.20.0/24. Целевая удалённая подсеть, которой нет в enc.domain ни одного из сайтов: 192.168.21.0/24. bridge-lo с каким IP? Маршрут к 192.168.21.0/24 через что?
cpbruton
Guest
0
28.03.2022 22:05:00
Представим ситуацию: R1 — маршрутизатор с OSPF (один из пяти), подключён к сети 192.168.10.0/24 R2 — основной маршрутизатор R3 — сторонний маршрутизатор, подключён к сети 192.168.30.0/24
Между R2 и R3 настроен чистый IPsec-туннель. Цель — распространить маршрут к сети 192.168.30.0/24 на R1 через OSPF. Но мы не можем запускать протоколы маршрутизации между R2 и R3. Поэтому R2 должен работать с IPsec в режиме туннеля (не транспорта) и иметь политику шифрования трафика с src-address 192.168.10.0/24 и dst-address 192.168.30.0/24. Предположим, что на R3 настроена зеркальная (обратная) политика.
Поскольку мы не можем получить OSPF-маршрут с R3, нам нужно сгенерировать его на R2. Сначала создаём интерфейс loopback с именем bridge-lo.
Дальше есть два варианта:
Вариант 1: Добавляем статический маршрут к 192.168.30.0/24 через интерфейс bridge-lo и настраиваем OSPF на перераспределение статических маршрутов с типом 1. В этом случае не нужно назначать IP-адрес интерфейсу bridge-lo. В ROSv6 это выглядит так: /ip route add dst-address=192.168.30.0/24 gateway=bridge-lo /routing ospf instance set 0 redistribute-static=as-type-1
Вариант 2: Назначаем интерфейсу bridge-lo любой IP из сети 192.168.30.0/24 и добавляем его как пассивный интерфейс в OSPF. На ROSv6: /ip address add address=192.168.30.1/24 interface=bridge-lo /routing ospf interface add interface=bridge-lo passive=yes /routing ospf network add network=192.168.30.0/24 area=backbone
По сути, мы обманываем R2, заставляя его думать, что у него есть путь в 192.168.30.0/24 через интерфейс — либо через статический маршрут, либо как через напрямую подключённую сеть. Но этот трафик никогда реально не попадёт на loopback-интерфейс — вместо этого его заберёт политика IPsec и пересылает в туннель к R3.
eduplant
Guest
0
31.03.2022 10:36:00
Я бы поставил на то, что это не сработает, но на самом деле срабатывает. Согласно опубликованным диаграммам работы пакетов [1], пакет, который должен пройти через туннель, встречает решение о маршрутизации (2.) ещё до того, как дойдёт до решения по IPsec-политике (5.). Мне как-то даже в голову не приходило, что это решение о маршрутизации на самом деле неважно, если для пакета вообще есть какой-то действующий маршрут. Пакеты, которые совпадают с политикой, всегда повторно проходят через второе решение о маршрутизации (7.), поэтому первое — это скорее формальность.
Тем не менее, третий вариант из двух, которые предложил @cpbruton, — это статический маршрут для целевой сети с next-hop, равным IP-адресу IPsec-пира. Этот статический маршрут затем перераспределяется в OSPF. С точки зрения реальной маршрутизации это так же сомнительно, но зато он позволяет избежать использования loopback (который у вас, скорее всего, и так есть), а ещё автоматически становится недействительным, если рекурсивное разрешение next-hop не удаётся (например, все пути для туннелированного трафика мертвы). Когда маршрут становится недействительным, он автоматически удаляется из базы данных OSPF. Очевидно, что это лишь немного лучше, потому что бывает куча случаев, когда туннель сломан, хотя пир IPsec всё ещё доступен, но это уже хоть какое-то начало. Вот как это выглядит:
Не сумев оставить всё как есть, я также опробовал четвёртый, более «проклятый» вариант, который ещё лучше обрабатывает сбои. Для этого нужно установить 1) статический маршрут до адреса удалённого роутера (10.3.0.1/32) с next-hop, равным IP-адресу IPsec-пира, и 2) статический маршрут до целевой сети (10.3.0.0/24) с next-hop 10.3.0.1 и опцией check-gateway=ping. При этом придётся «поиграться» с target-scope у маршрута №2, потому что иначе он никогда не станет активным (он зависит от маршрута №1, который по умолчанию имеет scope 30). Делая так, если 10.3.0.1 становится недоступным по ICMP (лучший индикатор падения туннеля), маршрут 10.3.0.0/24 становится недействительным.
Единственная проблема в этом случае — если вы всё ещё просто «загружаете» redistribute-static=as-type-1, то в базу OSPF попадёт маршрут 10.3.0.1/32, который вам, возможно, вообще не нужен и не нужен. В моём случае я просто повысил scope у 10.3.0.1/32 до значения выше всех остальных (скажем, 40), а у маршрута 10.3.0.0/24 указал рекурсивный target-scope равным 40. Затем добавил фильтр маршрутов для chain=ospf-out, который отфильтровывает все маршруты с scope 40 и пропускает всё остальное. Вариантов реализации может быть много, но этот показался мне наименее рискованным с точки зрения сторонних эффектов.
В общем, несмотря на существенную задержку от check-gateway=ping до обнаружения сбоя и последующих рекурсивных инвалидизаций маршрутов и изменений в OSPF, это вроде как работает. Главный вывод — по возможности использовать OSPF-over-GRE-over-IPsec-transport-mode, чтобы не связываться с этой вознёй. Но если нет — может, эта схема поможет.
У меня такая же проблема. Есть ли способ распределить это через OSPF?
eduplant
Guest
0
13.03.2022 23:37:00
Вы пробовали тип сети NBMA, статических соседей OSPF и статические маршруты для соседей? Всё, что использует широковещательные приветствия в любом направлении, не сработает из-за туннелей и промежуточных маршрутизируемых хопов. Пока обе стороны IPsec региона могут определить, как отправить уникаст к своему статическому соседу OSPF, не должно иметь значения, что между ними. (Если только маршрутизатор третьей стороны в туннеле не фильтрует протокол IP 89…) Честно говоря, я этого не тестировал, но как доберусь до лаборатории, попробую проверить. Может быть, есть какое-то ограничение, о котором я забыл. Перечитывая вопрос, я даже не уверен, что правильно понял топологию. Смотрите ниже.
