IPSec или L2TP IPSec?

Question

[glmonarch]

Всем добрый вечер! Коллеги, когда для построения туннеля нужно использовать связку L2TP IPsec, а когда достаточно только IPSec?
Например, что лучше использовать в ситуации когда нужно объединить два офиса (с двух сторон Mikrotik) и почему?

Answer 1

[Никита Сизов]

Если у вас только два офиса и в каждом только один провайдер, можно и IPSec в туннельном режиме.
Но я бы делал GRE-туннель с заворачиванием трафика в IPSec. Бонусы - прозрачная маршрутизация в одной таблице (в политики можно не смотреть), возможность подключения динамической маршрутизации, возможность построения отказоустойчивой структуры.
Например, если у вас в одном из офисов два провайдера, у вас будет два туннеля. Если один из провайдеров сломается, протокол динамической маршрутизации направит трафик в резервный туннель. В результате у вас будет отказоустойчивый канал между офисами с практически незаметным переключением при отказе.
На чистых туннелях IPSec такое сделать непросто, если вообще возможно.
А если у вас будет три офиса, это вообще маст хэв :)

Вот пример конфига.

router 1:
---создаем GRE-туннель
/interface gre
add !keepalive local-address=***router 1 WAN IP*** name=gre1 remote-address=***router 2 WAN IP***

--- и ip-адрес к нему
/ip address
add address=10.10.10.1/30 interface=gre1 network=10.10.10.0/30

---(политика согласования IKE у меня сделана на сертификатах, у вас может быть на pre-shared key - это каждый выбирает для себя; главное, чтобы с обеих сторон было одинаково)
/ip ipsec peer
add address=***router 2 WAN IP***/32 auth-method=rsa-signature certificate=cert-vpn dh-group=modp768 dpd-interval=10s dpd-maximum-failures=3 enc-algorithm=aes-256 \
local-address=***router 1 WAN IP*** nat-traversal=no passive=yes remote-certificate=cert-endpoint

--- политика шифрования трафика GRE от нас в удаленный офис
/ip ipsec policy
set 0 disabled=yes
add dst-address=***router 2 WAN IP***/32 level=unique proposal=***ваша политика шифрования*** protocol=gre sa-dst-address=***router 2 WAN IP*** sa-src-address=***router 1 WAN IP*** src-address=\
***router 1 WAN IP***/32

--- и прописываем статический маршрут в удаленную сеть
/ip route add distance=1 dst-address=***подсеть второго офиса*** gateway=10.10.10.2

---Еще может понадобиться сделать правило firewall для обмена трафиком GRE между офисами:
/ip firewall filter
add chain=input comment="GRE from other office" dst-address=***router 1 WAN IP*** src-address=***router 2 WAN IP*** protocol=gre

router 2 - настройки отображаются зеркально:

/interface gre
add !keepalive local-address=***router 2 WAN IP*** name=gre1 remote-address=***router 1 WAN IP***

/ip address
add address=10.10.10.2/30 interface=gre1 network=10.10.10.0/30

/ip ipsec peer
add address=***router 1 WAN IP***/32 auth-method=rsa-signature certificate=cert-vpn dh-group=modp768 dpd-interval=10s dpd-maximum-failures=3 enc-algorithm=aes-256 \
local-address=***router 2 WAN IP*** nat-traversal=no passive=yes remote-certificate=cert-endpoint

/ip ipsec policy
set 0 disabled=yes
add dst-address=***router 1 WAN IP***/32 level=unique proposal=***ваша политика шифрования*** protocol=gre sa-dst-address=***router 1 WAN IP*** sa-src-address=***router 2 WAN IP*** src-address=\
***router 2 WAN IP***/32

/ip route add distance=1 dst-address=***подсеть первого офиса*** gateway=10.10.10.1

/ip firewall filter
add chain=input comment="GRE from other office" dst-address=***router 2 WAN IP*** src-address=***router 1 WAN IP*** protocol=gre

Comments

[glmonarch]

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

[glmonarch]

Собрал стенд по Вашему рецепту. На промежуточном роутере вижу лишь GRE-трафик и периодические попытки обмена ISAKMP по 500/UDP. При этом installed-sa не появляются. В чем могут быть грабли?

[Никита Сизов]

glmonarch: покажите конфиг обоих роутеров?

[Никита Сизов]

glmonarch: С одинаковой адресацией - нет, нельзя. Или можно, но через большие грабли. Для реализации бродкаст-домена в микротике есть EoIP (ethernet over IP). Насколько я знаю, это проприетарная реализация на базе того же GRE, но детально я с ним не разбирался, т.к. не люблю делать сетки с единой адресацией. Потом концов не выловить, если что.

[Никита Сизов]

glmonarch: и еще, насчет стенда. keepalive на gre лучше включить. У меня выключен, т.к. его роль играет ospf hello, но у вас его нет.

[Никита Сизов]

glmonarch: возможно, не смогу сегодня посмотреть ваш конфиг. Для начала добейтесь работы туннеля без IPSec. Шифрование можно позже настроить.

[glmonarch]

Все получилось. Прикладываю конфиг стенда. Прошу покритиковать, если что не так. О том, что IPsec встал я сужу по мониторингу с серединного роутера, который находится в топологии между роутером 1 и роутером 2.

Роутер 1 имеет интерфейсы:

WAN: 10.10.10.2
LAN: 192.168.100.1

Роутер 2 имеет интерфейсы:

WAN: 10.20.20.2
LAN: 192.168.200.1

Соответственно, за роутером 1 находится сеть 192.168.100.0/24, за роутером 2 находится сеть 192.168.200.0/24.

Создаем GRE туннель:

Конфиг router 1:

interface gre add name=gre1 remote-address=10.20.20.2 local-address=10.10.10.2
ip address add address=172.16.1.1/30 interface=gre1
ip route add dst-address=192.168.200.0/24 gateway=172.16.1.2

Конфиг router 2:

interface gre add name=gre1 remote-address=10.10.10.2 local-address=10.20.20.2
ip address add address=172.16.1.2/30 interface=gre1
ip route add dst-address=192.168.100.0/24 gateway=172.16.1.1

Создаем IPsec туннель:

Router 1:

/ip ipsec peer
add address=10.20.20.2/32 exchange-mode=aggressive secret=test

/ip ipsec policy
add dst-address=192.168.200.0/24 sa-dst-address=10.20.20.2 sa-src-address=\
10.10.10.2 src-address=192.168.100.0/24 tunnel=yes

Router 2:

/ip ipsec peer
add address=10.10.10.2/32 exchange-mode=aggressive passive=yes secret=test

/ip ipsec policy
add dst-address=192.168.100.0/24 sa-dst-address=10.10.10.2 sa-src-address=\
10.20.20.2 src-address=192.168.200.0/24 tunnel=yes

Таблица маршрутизации роутера 1:

# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 A S 0.0.0.0/0 10.10.10.1 1
1 ADC 10.10.10.0/24 10.10.10.2 ether3 0
2 ADC 172.16.1.0/30 172.16.1.1 gre1 0
3 ADC 172.26.13.0/24 172.26.13.242 ether1 0
4 ADC 192.168.100.0/24 192.168.100.1 ether2 0
5 A S 192.168.200.0/24 172.16.1.2 1

Таблица маршрутизации роутера 2:

# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 A S 0.0.0.0/0 10.20.20.1 1
1 ADC 10.20.20.0/24 10.20.20.2 ether2 0
2 ADC 172.16.1.0/30 172.16.1.2 gre1 0
3 ADC 172.26.13.0/24 172.26.13.244 ether1 0
4 A S 192.168.100.0/24 172.16.1.1 1
5 ADC 192.168.200.0/24 192.168.200.1 ether3 0

Однако, есть вопрос - при пинге из сети 192.168.100.0/24 в сеть 192.168.200.0/24 на серединном роутере я вижу IPsec - это ОК. И периодически проскакивает GRE с WAN router 1 на WAN router 2 - нормально ли это? И если да, то как это объяснить, ведь GRE по идее "завернуть" в IPsec? Спасибо.

[Никита Сизов]

glmonarch: Нет, не получилось. Но вышло прикольно )))
Вы построили чистый туннель IPSec, через который у вас и ходят пакеты между сетями. А GRE-туннель без всякого шифрования болтается сбоку. Через него время от времени ходят keepalive, которые вы видите на промежуточном роутере.
Дело в том, что политики IPSec обрабатываются раньше, чем таблица маршрутизации. А в политике у вас написано:
/ip ipsec policy
add dst-address=192.168.200.0/24 sa-dst-address=10.20.20.2 sa-src-address=\
10.10.10.2 src-address=192.168.100.0/24 tunnel=yes
первая ошибка - tunnel=yes. Нам нужен IPSec в транспортном режиме, tunnel=no
вторая - ошибка - нам не нужно шифровать пакеты, которые направляются в сеть 192.168.200.0/24. IPSec вообще ничего не знает о существовании этой сети. Нам нужно просто шифровать все пакеты GRE, которые направляются на роутер 2. Поэтому правильная политика такая:
/ip ipsec policy
add dst-address=10.20.20.2/32 protocol=gre sa-dst-address=10.20.20.2 sa-src-address=\
10.10.10.2 src-address=10.10.10.2/32 tunnel=no
не проверял, возможно, придется допилить.

[glmonarch]

Поправил. Теперь на промежуточном роутере виден IPsec (50) и изредка UDP по 500 порту (ISAKMP) между WAN-интерфейсами роутеров - это как я понимаю, верно? Вот конфиг для IPsec:

Router 1:

/ip ipsec peer
# Unsafe configuration, suggestion to use certificates
add address=10.20.20.2/32 exchange-mode=aggressive secret=test
/ip ipsec policy
add dst-address=10.20.20.2/32 protocol=gre sa-dst-address=10.20.20.2 \
sa-src-address=10.10.10.2 src-address=10.10.10.2/32

Router 2:

/ip ipsec peer
# Unsafe configuration, suggestion to use certificates
add address=10.10.10.2/32 exchange-mode=aggressive passive=yes secret=test
/ip ipsec policy
add dst-address=10.10.10.2/32 protocol=gre sa-dst-address=10.10.10.2 \
sa-src-address=10.20.20.2 src-address=10.20.20.2/32

Я попробовал оба варианта:

- туннельный режим (tunnel=yes)
- транспортный режим (tunnel=no)

В теории я знаю, что в туннельном режиме инкапсулируется и шифруется весь исходный IP пакет, а в транспортном лишь добавляются аутентификационные данные между заголовком исходного пакета и полем данных. Но я не могу интерпретировать эти теоретические знания в практическом применении к данному примеру.
Другими словами, почему в этом примере нужно использовать именно транспортный режим, а не туннельный? Только потому, что это избыточно т.к. у нас уже есть GRE-туннель? Или есть более веские причины? Спасибо.

[Никита Сизов]

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

[glmonarch]

Никита Сизов: Ясно. Благодарю за разъяснения.

Answer 2

[alegzz]

если нужно объединить офисы, то проще IPSec. L2TP использует транспортный режим работы IPSec, то есть для объединения сетей не очень подходит.

Comments

[glmonarch]

Спасибо. А в каких случаях нужна связка L2TP + IPSec?

[Дмитрий]

glmonarch: VPN для мобильных пользователей.

[alegzz]

glmonarch: хороший вопрос) лично я не представляю себе юзкейса, когда можно L2TP/IPSec, но нельзя IPSec в транспортном режиме.

[alegzz]

Дмитрий: нет, мобильные пользователи могут и IPSEC. причем даже xauth, если нравится uname/pass

[alegzz]

есть подозрение, что исторически у IPSec изначально была аутентефикация только PSK и по сертификатам, поэтому использовали L2TP/IPSec

[pezzak]

alegzz: правильное подозрение :)

The reason people use L2TP is due to the need to provide login mechanism to users. IPSec by itself is meant to by a tunneling protocol in a gateway-to-gateway scenario (there are still two modes, tunnel mode & transport mode). So vendors use L2TP to allow people to use their products in client-to-network scenario. So, they use L2TP only for logging and the rest of the session would be using IPSec. You have to take in consideration two other modes; pre-shared-keys vs. certificates.

seclists.org/basics/2005/Apr/139