ioangrozniy
@ioangrozniy

Что нужно настроить что бы проходит трафик из ipsec за mikrotik?

Настраиваю ipsec Mikritik-DFL260e.
Сетка за DFL видна со стороны сетки за микротом, а вот сетка за микротом не видна (кроме самого микрота).
Я понимаю что дело где то в маршутизации на микроте "зарыто", однако не доходит где именно.
Товарищи спецы, подскажите пожалуйста.
  • Вопрос задан
  • 1883 просмотра
Решения вопроса 1
Во всем виновато правило firewall на клиентах, блокирующее подключение из второй сети.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 1
CityCat4
@CityCat4
Внимание! Изменился адрес почты!
Если вопрос касается "чистого" IPSec, то:
- в нем нет маршрутизации, как таковой. Вся информация заложена в SAD и SPD. SPD - это закладка Policies в окне IPSec, SAD - закладка Installed SAs, она формируется динамически.
Что здесь нужно помнить:
IPSec проходит файрволл два раза. Для четкого понимания, как это все фурычет - всегда рекомендую вот эту картинку.
Разберем на пример моего домашнего роутера (RB450G), где 1.1.1.1 - мой внешний IP, 2.2.2.2 - внешний IP удаленной сети. Моя подсетка - 10.54.2.0/24, удаленная - 10.54.1.0/24
Самое первое - это настройка политик (policy). Именно политика решает - нужно данный пакет шифровать или нет?
/ip ipsec proposal
add auth-algorithms="" enc-algorithms=aes-256-gcm lifetime=1h name=proposal1
/ip ipsec policy
add comment="To Cat's Home main VPN" dst-address=10.54.1.0/24 proposal=proposal1 sa-dst-address=\
    2.2.2.2 sa-src-address=1.1.1.1 src-address=10.54.2.0/24 tunnel=yes

Что сделали:
Добавили proposal1, в котором в качестве алгоритма шифрования выбран ASES256 со счетчиком Галуа . Поскольку он самоаутентифицирующийся, отдельного алгоритма аутентификации задавать не надо. Замена ключей шифрования через каждый час.
Задали политику, согласно которой все пакеты в сеть 10.,54.1.0/24 от 10.54.2.0/24 будут превращены в пакеты протокола ESP от IP 1.1.1.1 до IP 2.2.2.2. Собственно это и есть наша "таблица маршрутизации".
/ip ipsec peer
add address=2.2.2.2/32 auth-method=rsa-signature certificate=\
    "RB2011 cert (SHA256) with key" comment="To Cat's Home main VPN" dpd-interval=\
    disable-dpd enc-algorithm=aes-256 hash-algorithm=sha256 lifetime=2h nat-traversal=no \
    proposal-check=strict remote-certificate="RB450G cert (SHA256)"

Что сделали:
Добавили пира - удаленный сервер. Аутентификация по сертификатам, шифрование AES256, повторный обмен ключами через 2 ч.
Теперь нужно настроить файрволл. Потому что как нарисовано на картинке, пакеты IPSec проходят его два раза.
Предположим я на компе с адресом 10.54.2.1 набираю команду "ping 10.54.1.1".
Пакет проходит таблицы mangle prerouting, nat prerouting, mangle forward, filter forward (и вот тут, если у Вас строгая фильтрация и нет правила, разрешающего трафик от 10.54.2.0/24 на 10.54.1.0/24, он и помрет), mangle postrouting, nat postrouting и уже готов отправиться на default gateway, но в этот момент ведро проверяет его по SPD - а не надо ли его зашифровать и переотправить? Ага, пакет подпадает под политику, значит мы его шифруем и преобразовываем. И пакет icmp от 10.54.2.1 на 10.54.1.1 шифруется и упаковывается в пакет esp от 1.1.1.1 на 2.2.2.2!
Вот здесь надо не забыть подстраховаться от NAT. Дело в том, что когда пакет проходил nat postrouting, общее правило
/ip firewall nat
add action=src-nat chain=srcnat out-interface=ether6 to-addresses=1.1.1.1

заменило IP источника, чтобы "обратный адрес" был уникальным и теперь пакет не подходит под политику. А не подходит под политику - не будет зашифрован, а пойдет по общим правилам маршрутизации. А default gateway роутера повертит пакет, повертит - да и скажет "ты кто такой? Давай, до свидания".
Чтобы избежать этого, нужно указать не трогать пакеты, к которым применима политика IPSec - пусть проходят за NAT неизменными, все равно их шифровать:
add chain=srcnat comment="Does not touch IPSec ESP packets to avoid break packets checksum" \
    ipsec-policy=out,ipsec log-prefix="NAT avoid" out-interface=ether6

Пошифрованный пакет ведро снова ренижектит в сетевой стек, он снова - уже в своем новом качестве - проходит mangle output, nat output, filter output (и вот тут, если нет разрешения на трафик в сторону 2.2.2.2 или на протокол esp, он и помрет), mangle postrouting, nat postrouting - и отправляется в тырнет на удаленную точку.

Предоплагаем, что с другой стороны роутер настроен таким же образом, то есть у него есть и своя SPD и свой список пиров. Что произойдет, когда пакет будет получен:
пакет пройдет mangle prerouting, nat prerouting, mangle input, filter input (и , если трафик от 1.1.1.1 или протокол esp не разрешен, то тут и помрет)...и уже готов к передаче на более верхние уровни OSI, но тут ведро проверяет - а не нужно ли его расшифровать? (и вот тут, если контрольная сумма не сходится - он и помрет). Если пакет подпадает под политику - он будет расшифрован и превратится из esp-пакета от 1.1.1.1 к 2.2.2.2 в icmp пакет от 10.54.1.1 к 10.54.2.1 - и будет заново помещен в сетевой стек. И заново пойдет mangle prerouting, nat prerouting, mangle forward, filter forward (и вот тут, если не разрешен трафик от 10.54.2.0/24 к 10.54.1.0/24 он и помрет), mangle postrouting, nat postrouting - и наконец-то попадет на выходной интерфейс туда, где у нас подключен 10.54.2.1.
Таблица маршрутизации (та, что в ведре) - не использовалась, весь трафик для роутеров выглядит локальным :)
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы