Зачем при настройке IPsec IKEv2 в Mikrotik требуется задать IP Pool?

Question

[TmpUser13]

В тестовой среде настраиваю Site to Site VPN между "филиалами"
Настраиваю туннель на основе GRE Over IPsec

Задал все необходимые адреса:
WAN (внешняя сеть)
Головной офис:
172.30.30.4
Филиал:
172.20.20.4

LAN:
10.100.80.0/24 - Головной офис
10.200.80.0/24 - Филиал

GRE:
192.168.10.1/30 - Головной офис
192.168.10.2/30 - Филиал

Смутило, что IPSec туннель поднимается только при создании пула IP-адресов и его привязке к Mode Configs




Филиал получает данный IP адрес, что видно роутере головного офиса.


Но зачем вообще нужен это пул, если он не используется при общении двух филиалов по туннелю?
Данный IP прописывается только на одной стороне (филиал). Он почему-то назначается на интерфейс с внешней сетью и прописывается в таблице маршрутизации:


При этом, на роутере головного офиса адрес из данной подсети нигде не фигурирует (кроме ip-пула и вкладки ipsec - active peers).

Я расшифровал заголовки ESP в Wireshark между филиалами, но нигде не увидел, что данный адрес используется.

Почему вообще этот IP-адрес (Dynamic address) требуется для поднятия туннеля, но при этом он не используется при взаимодействии филиалов?

Comments

[Drno]

потому что сети работают на основе адресов..

Answer 1

[CityCat4]

Ты сделал что-то не то или использовал не ту инструкцию. При настройке головной-филиал не нужно:
- GRE
- Динамических адресов

Мастер-филиал - это стандартная настройка через политики. Скринов делать не буду, набросаю командами:

# 10.4.1.0/24 - филиал
# 10.4.2.0/24 - мастер
# 1.1.1.1 - белый IP филиала
# 2.2.2.2 - белый IP мастера
# в данном случае аутентификация по сертификатам, но она легко меняется на PSK
# На другом микротике перевернуть все зеркально
# Политики
/ip ipsec policy
add comment="To main VPN" dst-address=10.4.2.0/24 peer="Server room VPN" proposal=\
    proposal1 src-address=10.4.1.0/24 tunnel=yes
# Напарники (peers)
/ip ipsec peer
add address=2.2.2.2/32 comment="To main VPN" exchange-mode=ike2 name=\
    "Server room VPN" profile=profile_5
# Предложения (proposals)
/ip ipsec proposal
add auth-algorithms="" enc-algorithms=aes-256-gcm lifetime=1h name=proposal1
(выглядит немного странно, но Galua Counter Mode самоаутентифицирующися режим)
# Профили (profiles)
/ip ipsec profile
add dh-group=ecp256,modp2048,modp1024 dpd-interval=disable-dpd enc-algorithm=aes-256,aes-192 \
    hash-algorithm=sha256 lifetime=2h name=profile_5 proposal-check=strict
# Идентификация (identity)
add auth-method=digital-signature certificate="IPSec cert with key" comment=\
    "Identity for 10.4.2.0/24 network" match-by=\
    certificate peer="Server room VPN" remote-certificate="RB2011 IPSec cert"

That's all, folks! Больше ничего не надо. Ни GRE, ни маршрутов, никакого прочего огорода. Как система разберется куда слать пакеты? А она посмотрит в таблицу политик :)

А, ну правила конечно же нужны:

/ip firewall nat
add action=accept chain=srcnat comment=\
    "Does not touch IPSec ESP packets to avoid break packets checksum" ipsec-policy=out,ipsec \
    log-prefix="NAT avoid" out-interface=pppoe-out1
# Никогда не забываем это правило! Иначе швах, NAT ломает пакет, та сторона его не принимает
# out-interface конечно же свой
/ip firewall filter
add action=accept chain=input comment=IKE log-prefix=IKE/NAT-T port=500,4500 protocol=udp
add action=accept chain=input comment=ESP log-prefix=ESP protocol=ipsec-esp
add action=accept chain=output comment=IKE log-prefix=IKE/NAT-T port=500,4500 protocol=udp
add action=accept chain=output comment=ESP log-prefix=ESP protocol=ipsec-esp
add action=accept chain=forward dst-address=10.4.2.0/24 src-address=10.4.1.0/24
add action=accept chain=forward dst-address=10.4.1.0/24 src-address=10.4.2.0/24

Comments

[TmpUser13]

Спасибо за подробное разъяснение!
Я делал по аналогии с реальной конфигурацией, которая существует именно в таком виде в моей компании.

Головной и все филиалы соединяются через GRE over IPsec. Почему-то сетевик решил создать отдельно GRE-туннель и заруливать трафик туда через таблицу маршрутизации. В политиках IPSec одно простое правило, что если трафик идет в туннель, то пусть шифруется IPsec.

В данный момент сетевика уволили, поэтому четко уточнить, что и почему так реализовано - нет возможности.

[CityCat4]

TmpUser13, Ну, видимо какой мануал нашел, то и сделал. Я тоже поначалу перегрыз немало мануалов, но я начинал на FreeBSD, там IPSec довольно своеобразный, хочешь не хочешь - а разебершься

Answer 2

[Valentin Barbolin]

IPsec может работать в туннельном и транспортном режиме, ты включил туннельный режим. При использовании gre не надо отдельно настраивать IPsec , достаточно в gre поставить галочку IPsec и задать пароль, правила IPsec создадутся динамически.