|
|
|
Перейти в группу новостей:
|
|
|
| Тема |
strongswan, IPSec, ESP transport mode |
| Написал |
Alexei <webmaster@microsoft.com> |
| Дата |
6 ноября 2020 в 21:51:40 |
| Группа новостей |
kraft.os.linux |
Всем привет.
Я экспериментирую с IPSec и strongswan 5.9.0 на ArchLinux с systemd
(запуск сервиса посредством старта charon-systemd и далее swanctl), ядро
Linux 5.9.
Мой случай для примера предполагает настройку IPSec в транспортном
режиме ESP между двумя хостами в локальной сети. Далее буду называть их
host_a - его адрес 198.51.100.1/24 и host_b - его адрес 198.51.100.2/24.
Я предполагаю также настроить strongswan так, чтобы шифрованию
подвергались только TCP-соединения, инициированные с host_a в сторону
host_b: host_a:any -> host_b:5001; согласование параметров шифрования
протоколом IKEv2, создание SA только при инициировании TCP-соедниения.
На host_a используется конфиг для swanctl (secrets не показан, так как
не имеет смысла в примере):
connections {
conn_phase1_to_b {
remote_addrs = 198.51.100.2
local { --skip-- }
remote { --skip-- }
children {
phase2_to_b {
mode = transport
start_action = trap
close_action = trap
remote_ts = 198.51.100.2/32[tcp/5001]
}
}
encap = no
mobike = no
version = 2
pull = no
unique = keep
}
}
На host_b конфиг идентичный, но развернутый в стороны host_a:
connections {
conn_phase1_to_a {
remote_addrs = 198.51.100.1
local { --skip-- }
remote { --skip-- }
children {
phase2_to_a {
mode = transport
start_action = trap
close_action = trap
local_ts = 198.51.100.2/32[tcp/5001]
}
}
mobike = no
encap = no
pull = no
version = 2
unique = keep
}
}
Эта конфигурация работает.
Например, после старта сервиса strongswan, можно увидеть две
установлинные policy (на host_a, например), ip xfrm policy show, лишнее
скрыто:
src 198.51.100.1/32 dst 198.51.100.2/32 proto tcp dport 5001
dir out priority 366912 ptype main
tmpl src 0.0.0.0 dst 0.0.0.0
proto esp reqid 1 mode transport
src 198.51.100.2/32 dst 198.51.100.1/32 proto tcp sport 5001
dir in priority 366912 ptype main
tmpl src 0.0.0.0 dst 0.0.0.0
proto esp reqid 1 mode transport
По видимому, это две ловушки, призванные начать согласование параметров
ESP по протоколу IKEv2 при попытке хождния трафика по описанным
правилам: назову первую ловушку policy_X, вторую - policy_Y.
Дейсвительно, если отправить пакет TCP host_a:any -> host_b:5001, то
тогда меняется значение, выводимое ip xfrm policy show:
src 198.51.100.1/32 dst 198.51.100.2/32 proto tcp dport 5001
dir out priority 366911 ptype main
tmpl src 0.0.0.0 dst 0.0.0.0
proto esp spi 0xc469cd4c reqid 1 mode transport
src 198.51.100.2/32 dst 198.51.100.1/32 proto tcp sport 5001
dir in priority 366911 ptype main
tmpl src 0.0.0.0 dst 0.0.0.0
proto esp reqid 1 mode transport
Для исходящей policy_X сменился priority и она стала ассоциирована с esp
spi 0xc469cd4c. Входящая policy_Y осталась неиспользованной.
Если поглядеть вывод ip xfrm state show, то видно две ESP SPI, у одной
ID как раз такой, 0xc469cd4c:
src 198.51.100.1 dst 198.51.100.2
proto esp spi 0xc469cd4c reqid 1 mode transport
replay-window 0
aead rfc4106(gcm(aes))
0x9714586eb83fcbf6446bb0e7a2ca408473d03c73 128
anti-replay context: seq 0x0, oseq 0x9f1b, bitmap 0x00000000
sel src 198.51.100.1/32 dst 198.51.100.2/32
src 198.51.100.2 dst 198.51.100.1
proto esp spi 0xc9e9d3aa reqid 1 mode transport
replay-window 32
aead rfc4106(gcm(aes))
0xbe5edf6a4a3c6310b3d1611437efb0560fd8427c 128
anti-replay context: seq 0x510c, oseq 0x0, bitmap 0xffffffff
sel src 198.51.100.2/32 dst 198.51.100.1/32
В связи с этим вопросы, на которые надеюсь, кто-нибудь сможет ответить:
1. Зачем нужна вторая policy_Y, если после согласования параметров ESP и
настройкой ESP SA, она остаётся неассоциированной ни с каким ESP ?
Я пробовал инициировать TCP-соединение в обратном направлении
host_b:5001 -> host_a:any, но и в этом случае наблюдаемый эффект похож
на описываемый выше. Я также пробовал отключить strongswan на host_b и
снова инициировать TCP-соединение в обратном направлении host_b:5001 ->
host_a:any без IPSec, надеясь на то, что на host_a сработает ловушка
policy_Y, но нет: просто ничего не происходит, TCP пакеты теряются.
Можно ли настроить strongswan так, чтобы вторая неиспользующаяся
policy_Y не устанавливалась ?
2. Имеется ли возможность настроить на TCP соединение не две ESP SA,
действующих каждая в своём направлении, а одну ? Например, экзотический
случай, когда мне нужно применить шифрование только в одном направлении ?
Спасибо.
| |
|
|
