+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

IPsec не работает без маршрута ядра для сети назначения

IPsec не работает без маршрута ядра для сети назначения, RouterOS

patrick7

Guest

30.10.2015 20:39:00

Привет! Нашёл проблему в реализации IPsec у MikroTik. Сценарий такой:
Локация 1 — CCR1009-8G-1S-1S+ с полной таблицей BGP, без маршрута по умолчанию, приватная сеть 10.64.136.0/22
Локация 2 — RB750GL со статическим IP, маршрут по умолчанию, приватная сеть 10.64.12.0/22

Если настроить IPsec, оно не работает. Если с Локации 1 пинговать:
/ping 10.64.12.1 src-address=10.64.136.1
то получаем «No route to host». Если то же самое сделать с машины за маршрутизатором на Локации 1, приходит ответ «ICMP destination net unreachable». На Локации 2 пакеты не доходят.

Если пинговать с Локации 2:
/ping 10.64.136.1 src-address=10.64.12.1
то всё виснет — «Timed out». Пакеты доходят до Локации 1.

Выяснил, что MikroTik отбрасывает все пакеты с назначением, по которым нет маршрутов в ядре. Поскольку IPsec работает через политики, а не через маршруты ядра, политика IPsec не срабатывает. На Локации 2 такой проблемы нет из-за наличия маршрута по умолчанию.

На Локации 1 я решил это грязным хаком:
/interface bridge add name=br-loopback
/ip route add dst-address=10.0.0.0/8 gateway=br-loopback

Кто-нибудь может это подтвердить? Политики IPsec должны применяться ДО маршрутизации, и не должно быть «ICMP destination net unreachable», если для пакетов есть соответствующая политика IPsec.

Уже открыл тикет в саппорт MikroTik.
С уважением, Патрик

SiB

Guest

18.05.2022 08:49:00

Zacharias пишет: Для меня стало сюрпризом, что IPSec не создает собственный интерфейс VDI, а требует от нас маршрут до Destination Enc. domain... Лол. Я всегда думал, что Enc.Domain работает как внутренний скрытый статический маршрут и не использует локальные... но пакетный поток — это всегда на первом месте. Спасибо этому посту, я нашел решение и для других — графическое представление: Надеюсь, это поможет кому-то с этой GUI-версией или с любым другим активным интерфейсом, который должен всегда работать.

pe1chl

Guest

18.05.2022 09:50:00

Вот как IPsec «должен был работать». Помню, в начале, когда Linux только появлялся, реализация IPsec создавалa виртуальные устройства, на которые можно было ссылаться при настройке маршрутизации и файрвола. Но в какой-то момент эта конкретная реализация в Linux была заброшена, и вместо неё приняли стандартный пакет «racoon». Вместе с этим пропали те виртуальные устройства, и началось то странное поведение, что мы наблюдаем сейчас. Но, например, в Cisco IOS тогда всё было точно так же. Позже большинство дистрибутивов Linux отказались от racoon и перешли на *swan, но способ применения политик и маршрутов остался прежним. А потом Cisco изобрели VTI, будто это что-то новое. Теперь все хотят именно это. Мне кажется, так и должно было быть изначально — намного понятнее и проще. А в Linux так и было. Пока кто-то не заявил, что это неправильно.

Larsa Guest	#4 0 18.05.2022 19:16:00 Да, ты напомнил мне об этой белой книге, которая вышла всего 18 лет назад, помнишь? «Будущее IPsec на Linux» Кена Бэнтофта.

pe1chl

Guest

18.05.2022 19:24:00

Ха! Я даже не знал, что это (до сих пор) существует. Там показаны все эти «войны», а также проблема, которую мы до сих пор видим в RouterOS. Но, насколько я понимаю, RouterOS сейчас использует *swan. Так что это тоже было переработано, чтобы работать в том самом нелогичном стиле, который сейчас принят. Должен быть какой-то большой замысел.

lelo

Guest

09.03.2016 20:59:00

Привет, Патрик! По поводу схемы прохождения пакетов: если во время выбора маршрута нет допустимого пути, пакет будет отброшен. Даже если после маршрутизации есть действующая политика IPsec. Так что, если у тебя нет подходящего маршрута для сети назначения, трафик в которую должен шифроваться через политику IPsec, нужно такой маршрут создать. Выбранный интерфейс назначения/исходящий при выборе маршрута теоретически не имеет значения, так как пакет будет перехвачен политикой IPsec, зашифрован, и будет создан новый IP-заголовок. Это верно для большинства случаев.

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

- маршрут по умолчанию, указывающий на WAN-интерфейс,
- PPTP-туннель, работающий поверх WAN, с частными адресами на концах туннеля,
- IPsec-пиры, работающие через этот PPTP-туннель.

Моя удалённая сетевая подсеть — 192.168.7.0, для неё есть политика IPsec, но нет выделенного маршрута в таблице маршрутизации. Теоретически, исходящий интерфейс, выбранный при определении маршрута, должен быть WAN (маршрут по умолчанию).

Сегодня я настроил правило логирования в таблице NAT, потому что боялся, что если будет выбран WAN-интерфейс, применится правило masquerade (как для исходящего трафика в Интернет), что изменит исходный IP и политика IPsec не сработает. Но этого не произошло.

И вот что я увидел в логах из правила логирования как исходящий интерфейс? Угадай… PPTP-туннель — то есть правильный исходящий интерфейс для уже зашифрованного пакета и IPsec-пира. Мое правило логировало трафик из локальной сети (192.168.1.0) в удалённую (192.168.7.0), значит, в момент срабатывания правило поймало не зашифрованный IPsec-пакет, а пакет до шифрования.

И теперь... кто-нибудь объясните, как это возможно? Почему исходящий интерфейс — не дефолтный WAN, а правильный интерфейс для IPsec-трафика? Процесс выбора маршрута каким-то магическим образом предвидит следующий выбор маршрута/интерфейса после шифрования IPsec? Откуда маршрутизатор об этом знает?

Что мы видим в схеме прохождения пакетов — так политика IPsec идёт после маршрутизации и постобработки. Учитывается ли вообще список политик IPsec во время выбора маршрута? Это странное поведение, оно приятное, но не соответствует логике прохождения пакета... Я не понимаю этого.

Я даже делал специальное правило с действием Accept в таблице NAT порядком раньше masquerade, чтобы избежать изменения исходного адреса, но теперь вижу, что это не нужно — ведь исходящий интерфейс выбирается правильный, который будет использоваться после IPsec-шифрования.

Пожалуйста, кто-нибудь из гуру MikroTik или разработчиков, развейте мои сомнения...

Zacharias Guest	#7 0 21.12.2019 18:36:00 Хотя это старый пост, но если кто-то столкнётся с той же ситуацией, можно просто создать шлюз по умолчанию к несуществующей в реальности сети (конечно, должен быть интерфейс, настроенный на ту же подсеть). Это не имеет значения, главное — чтобы пакет не отбрасывался из-за невозможности маршрутизации...

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры