Назад | Перейти на главную страницу

IPSec в IPSec с strongswan

У меня есть сервер, подключенный к удаленному LAN1 через туннель IPSec. Теперь я хочу настроить второй туннель для LAN2, который подключен к маршрутизатору в LAN1, поэтому мне нужно создать туннель Ipsec внутри существующего туннеля ipsec:

LAN0 -- server -- internet -- GW1 -- LAN1 -- GW2 -- LAN2
            ====== IPSEC1 =====
           ============ IPSEC2 ================

IPSEC1 работает нормально, я могу пинговать GW2, но IPSEC2 не работает. Я не могу изменить конфигурацию GW1, но у меня есть полный контроль над сервером и GW2. В журнале с сервера я вижу:

sending packet: from (server)[500] to (GW2)[500] (420 bytes)
sending retransmit 2 of request message ID 0, seq 1

То же самое и на GW2. Я могу пинговать обе стороны, но пакеты IPSec не передаются. ipsec.conf на сервере:

left=%defaultroute
leftid=serverip(from LAN0)
leftsubnet=LAN0/24
right=GW2
rightsubnet=LAN2/24

на GW2:

left=GW2
leftid=GW2
leftsubnet=LAN2/24
right=server(from LAN0)
rightid=%any
rightsubnet=LAN0/24

Что случилось ?

Это невозможно из коробки, потому что strongSwan устанавливает политики обхода на свои сокеты UDP, поэтому трафик IKE исключается из любой обработки IPsec. Поэтому GW2 недоступен, поскольку сообщения IKE не будут отправляться через IPSEC1 но их пытаются отправить напрямую.

Есть вариант (charon.plugins.kernel-netlink.port_bypass), что приводит к установке обычных политик для порта / протокола вместо политик сокетов для исключения трафика IKE. Если вы согласовываете дополнительные селекторы трафика между server и GW1 для IP-адресов server и GW2 плюс протокол и порты (UDP 500/4500) можно было бы туннелировать трафик IKE (поскольку IP-адреса указаны, эти политики должны быть более конкретными и, следовательно, иметь более высокий приоритет, чем политики обхода). Я никогда не пробовал этого, поэтому не уверен, работает ли это (могут быть другие проблемы в ядре при обработке таких вложенных туннелей).

Другой подход (также непроверенный) может заключаться в использовании XFRM интерфейсы с явным маршрутом, который направляет пакеты в GW2 через интерфейс XFRM, связанный с IPSEC1 (это может даже работать с политиками сокетов).