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

StrongSwan 5.6.2 и xl2tp 1.3.12 в Ubuntu 18.04 SA установлены, но нет трафика

После обновления strongSwan и xl2tpd до последних версий, доступных для Ubuntu, я столкнулся с проблемой ESP и AH в L2TP.

Конфигурация сервера:

Interface for generating traffic

ens224: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.219.1 netmask 255.255.255.252 broadcast 192.168.219.3

ppp0 interface created by xl2tpd

ppp0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 192.168.231.1 netmask 255.255.255.255 destination 192.168.231.2

Конфигурация клиента:

Interface for generating traffic

ens224: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.219.5 netmask 255.255.255.252 broadcast 192.168.219.7

ppp0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 192.168.231.2 netmask 255.255.255.255 destination 192.168.231.1

когда я начинаю пинговать от клиента к серверу [192.168.219.5 -> 192.168.219.1] на клиенте, у меня 100% потеря.

tcpdump со стороны клиента для IPSec ESP:

11:53:39.729306 Out ethertype IPv4 (0x0800), length 100: 192.168.231.2 > 192.168.219.1: ICMP echo request, id 8318, seq 27, length 64
11:53:39.735978 In ethertype IPv4 (0x0800), length 100: 192.168.219.1 > 192.168.231.2: ICMP echo reply, id 8318, seq 27, length 64
11:54:07.956148 Out ethertype IPv4 (0x0800), length 938: 192.168.231.2.500 > 192.168.231.1.500: isakmp: parent_sa ikev2_init[I]
11:54:07.967355 In ethertype IPv4 (0x0800), length 82: 192.168.231.1.500 > 192.168.231.2.500: isakmp: parent_sa ikev2_init[R]
11:54:07.973795 Out ethertype IPv4 (0x0800), length 1130: 192.168.231.2.500 > 192.168.231.1.500: isakmp: parent_sa ikev2_init[I]
11:54:07.992232 In ethertype IPv4 (0x0800), length 531: 192.168.231.1.500 > 192.168.231.2.500: isakmp: parent_sa ikev2_init[R]
11:54:08.017478 Out ethertype IPv4 (0x0800), length 1296: 192.168.231.2.4500 > 192.168.231.1.4500: NONESP-encap: isakmp: child_sa ikev2_auth[I]
11:54:08.017518 Out ethertype IPv4 (0x0800), length 1264: 192.168.231.2.4500 > 192.168.231.1.4500: NONESP-encap: isakmp: child_sa ikev2_auth[I]
11:54:08.042533 In ethertype IPv4 (0x0800), length 1296: 192.168.231.1.4500 > 192.168.231.2.4500: NONESP-encap: isakmp: child_sa ikev2_auth[R]
11:54:08.042751 In ethertype IPv4 (0x0800), length 992: 192.168.231.1.4500 > 192.168.231.2.4500: NONESP-encap: isakmp: child_sa ikev2_auth[R]
11:54:08.773279 Out ethertype IPv4 (0x0800), length 168: 192.168.231.2 > 192.168.231.1: ESP(spi=0xca9bd294,seq=0x1), length 132
11:54:09.796992 Out ethertype IPv4 (0x0800), length 168: 192.168.231.2 > 192.168.231.1: ESP(spi=0xca9bd294,seq=0x2), length 132

tcpdump со стороны сервера для IPSec ESP

11:53:40.661518 In ethertype IPv4 (0x0800), length 100: 192.168.231.2 > 192.168.219.1: ICMP echo request, id 8318, seq 27, length 64
11:53:40.661547 Out ethertype IPv4 (0x0800), length 100: 192.168.219.1 > 192.168.231.2: ICMP echo reply, id 8318, seq 27, length 64
11:54:08.892269 In ethertype IPv4 (0x0800), length 938: 192.168.231.2.500 > 192.168.231.1.500: isakmp: parent_sa ikev2_init[I]
11:54:08.893831 Out ethertype IPv4 (0x0800), length 82: 192.168.231.1.500 > 192.168.231.2.500: isakmp: parent_sa ikev2_init[R]
11:54:08.907962 In ethertype IPv4 (0x0800), length 1130: 192.168.231.2.500 > 192.168.231.1.500: isakmp: parent_sa ikev2_init[I]
11:54:08.918575 Out ethertype IPv4 (0x0800), length 531: 192.168.231.1.500 > 192.168.231.2.500: isakmp: parent_sa ikev2_init[R]
11:54:08.952164 In ethertype IPv4 (0x0800), length 1296: 192.168.231.2.4500 > 192.168.231.1.4500: NONESP-encap: isakmp: child_sa ikev2_auth[I]
11:54:08.952427 In ethertype IPv4 (0x0800), length 1264: 192.168.231.2.4500 > 192.168.231.1.4500: NONESP-encap: isakmp: child_sa ikev2_auth[I]
11:54:08.968649 Out ethertype IPv4 (0x0800), length 1296: 192.168.231.1.4500 > 192.168.231.2.4500: NONESP-encap: isakmp: child_sa ikev2_auth[R]
11:54:08.968759 Out ethertype IPv4 (0x0800), length 992: 192.168.231.1.4500 > 192.168.231.2.4500: NONESP-encap: isakmp: child_sa ikev2_auth[R]
11:54:09.705686 In ethertype IPv4 (0x0800), length 168: 192.168.231.2 > 192.168.231.1: ESP(spi=0xca9bd294,seq=0x1), length 132
11:54:09.705686 In ethertype IPv4 (0x0800), length 100: 8.0.219.5 > 192.168.219.1: ICMP echo request, id 8318, seq 56, length 64
11:54:10.729687 In ethertype IPv4 (0x0800), length 168: 192.168.231.2 > 192.168.231.1: ESP(spi=0xca9bd294,seq=0x2), length 132
11:54:10.729687 In ethertype IPv4 (0x0800), length 100: 8.0.219.5 > 192.168.219.1: ICMP echo request, id 8318, seq 57, length 64

Переход на IPSec AH:

Клиент:

11:56:45.057757 Out ethertype IPv4 (0x0800), length 938: 192.168.231.2.500 > 192.168.231.1.500: isakmp: parent_sa ikev2_init[I]
11:56:45.068383 In ethertype IPv4 (0x0800), length 82: 192.168.231.1.500 > 192.168.231.2.500: isakmp: parent_sa ikev2_init[R]
11:56:45.075626 Out ethertype IPv4 (0x0800), length 1130: 192.168.231.2.500 > 192.168.231.1.500: isakmp: parent_sa ikev2_init[I]
11:56:45.095453 In ethertype IPv4 (0x0800), length 531: 192.168.231.1.500 > 192.168.231.2.500: isakmp: parent_sa ikev2_init[R]
11:56:45.117129 Out ethertype IPv4 (0x0800), length 1296: 192.168.231.2.4500 > 192.168.231.1.4500: NONESP-encap: isakmp: child_sa ikev2_auth[I]
11:56:45.117185 Out ethertype IPv4 (0x0800), length 1264: 192.168.231.2.4500 > 192.168.231.1.4500: NONESP-encap: isakmp: child_sa ikev2_auth[I]
11:56:45.142557 In ethertype IPv4 (0x0800), length 1296: 192.168.231.1.4500 > 192.168.231.2.4500: NONESP-encap: isakmp: child_sa ikev2_auth[R]
11:56:45.142567 In ethertype IPv4 (0x0800), length 976: 192.168.231.1.4500 > 192.168.231.2.4500: NONESP-encap: isakmp: child_sa ikev2_auth[R]
11:56:45.309776 Out ethertype IPv4 (0x0800), length 148: 192.168.231.2 > 192.168.231.1: AH(spi=0xc140b026,seq=0x1): 192.168.219.5 > 192.168.219.1: ICMP echo request, id 8318, seq 209, length 64 (ipip-proto-4)
11:56:46.340981 Out ethertype IPv4 (0x0800), length 148: 192.168.231.2 > 192.168.231.1: AH(spi=0xc140b026,seq=0x2): 192.168.219.5 > 192.168.219.1: ICMP echo request, id 8318, seq 210, length 64 (ipip-proto-4)
11:56:47.364966 Out ethertype IPv4 (0x0800), length 148: 192.168.231.2 > 192.168.231.1: AH(spi=0xc140b026,seq=0x3): 192.168.219.5 > 192.168.219.1: ICMP echo request, id 8318, seq 211, length 64 (ipip-proto-4)

Сервер:

11:56:45.999222 In ethertype IPv4 (0x0800), length 938: 192.168.231.2.500 > 192.168.231.1.500: isakmp: parent_sa ikev2_init[I]
11:56:46.000323 Out ethertype IPv4 (0x0800), length 82: 192.168.231.1.500 > 192.168.231.2.500: isakmp: parent_sa ikev2_init[R]
11:56:46.016453 In ethertype IPv4 (0x0800), length 1130: 192.168.231.2.500 > 192.168.231.1.500: isakmp: parent_sa ikev2_init[I]
11:56:46.027356 Out ethertype IPv4 (0x0800), length 531: 192.168.231.1.500 > 192.168.231.2.500: isakmp: parent_sa ikev2_init[R]
11:56:46.059588 In ethertype IPv4 (0x0800), length 1296: 192.168.231.2.4500 > 192.168.231.1.4500: NONESP-encap: isakmp: child_sa ikev2_auth[I]
11:56:46.059840 In ethertype IPv4 (0x0800), length 1264: 192.168.231.2.4500 > 192.168.231.1.4500: NONESP-encap: isakmp: child_sa ikev2_auth[I]
11:56:46.074470 Out ethertype IPv4 (0x0800), length 1296: 192.168.231.1.4500 > 192.168.231.2.4500: NONESP-encap: isakmp: child_sa ikev2_auth[R]
11:56:46.074522 Out ethertype IPv4 (0x0800), length 976: 192.168.231.1.4500 > 192.168.231.2.4500: NONESP-encap: isakmp: child_sa ikev2_auth[R]
11:56:46.249345 In ethertype IPv4 (0x0800), length 148: 192.168.231.2 > 192.168.231.1: AH(spi=0xc140b026,seq=0x1): 192.168.219.5 > 192.168.219.1: ICMP echo request, id 8318, seq 209, length 64 (ipip-proto-4)
11:56:46.249345 In ethertype IPv4 (0x0800), length 100: 8.0.219.5 > 192.168.219.1: ICMP echo request, id 8318, seq 209, length 64
11:56:47.280994 In ethertype IPv4 (0x0800), length 148: 192.168.231.2 > 192.168.231.1: AH(spi=0xc140b026,seq=0x2): 192.168.219.5 > 192.168.219.1: ICMP echo request, id 8318, seq 210, length 64 (ipip-proto-4)
11:56:47.280994 In ethertype IPv4 (0x0800), length 100: 8.0.219.5 > 192.168.219.1: ICMP echo request, id 8318, seq 210, length 64
11:56:48.305921 In ethertype IPv4 (0x0800), length 148: 192.168.231.2 > 192.168.231.1: AH(spi=0xc140b026,seq=0x3): 192.168.219.5 > 192.168.219.1: ICMP echo request, id 8318, seq 211, length 64 (ipip-proto-4)


[lns L2TPserver]
ip range = 192.168.231.2 - 192.168.231.254
local ip = 192.168.231.1
require chap = no
refuse pap = yes
require authentication = no
ppp debug = yes
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes
lac = 88.134.0.0 - 88.134.254.254
lac = 100.70.0.0 - 100.70.254.254



[lac L2TPserver]
;lns = 192.168.21.33
lns = 100.80.1.252
redial = yes
redial timeout = 5
local ip = 192.168.231.2
require chap = no
require authentication = no
ppp debug = yes
pppoptfile = /etc/ppp/options.xl2tpd.client
require pap = no
autodial = yes
name = cpe
length bit = yes

Конфигурация IPSec на сервере

keyexchange=ikev2
auto=add
left=%any
leftid=192.168.231.1
leftsubnet=192.168.219.0/30
leftcert=vpnHostCert_192.168.231.1.der
leftsendcert=always
right=%any
rightcert=VPNclientESPL2TPCert.der
rightsourceip=192.168.219.5/32
rightsubnet=192.168.219.4/30
mobike=no

Конфигурация IPSec на клиенте

conn l2tp-ikev2-rw-esp
right=192.168.231.1
rightid=%192.168.231.1
rightsubnet=192.168.219.0/30
rightauth=pubkey
leftsourceip=%config
leftauth=pubkey
leftcert=VPNclientESPL2TPCert.der
leftsubnet=192.168.219.4/30
auto=start

Клиент

root@vsrv-bicab-2u:/home/VPN# ip ro get 192.168.219.1
192.168.219.1 via 192.168.231.1 dev ppp0 table 220 src 192.168.219.5 uid 0
cache

Сервер

root@vsrv-bicab-1u:/home/VPN# ip ro get 192.168.219.5
192.168.219.5 via 192.168.231.2 dev ppp0 table 220 src 192.168.219.1 uid 0
cache

Проблема в том, что 8.0.219.x, которого не было до обновления.

В ядре Linux 4.15, которое поставляется Ubuntu 18.04, есть известная ошибка, из-за которой IP-адрес изменяется таким образом.

Это было вызвано 5efec5c655dd ("xfrm: Fix eth_hdr (skb) -> h_proto, чтобы отразить внутреннюю версию IP") и позже был исправлен с помощью 87cdf3148b11 («xfrm: Убедитесь, что заголовок MAC существует перед перезаписью eth_hdr (skb) -> h_proto»), который был частью исходных текстов ядра 4.16.

Это исправление, по-видимому, никогда не переносилось на 4.15 (оно не является частью linux-4.15.y стабильная ветка), и разработчики пакета ядра Ubuntu тоже не добавили его. Вы можете уведомить разработчиков ядра об отсутствии резервного порта в стабильную версию (через список рассылки netdev) и / или сообщить об ошибке с разработчиками Ubuntu.