Как я могу захватывать пакеты IPSEC на моем VPN-сервере?

Я использую VPN-сервер strongSwan (U5.3.5 / K4.4.0-62-generic) на Ubuntu 16.04.

Обычно, когда я хочу проверить трафик на сервере, я просто запускаю что-то вроде следующего:

tcpdump -ni eth0 "tcp port 80" -w log.pcap

Однако на VPN-сервере это мне не очень помогает. Я ловлю только "обычный" трафик, а не IPSEC. Я полагаю, это потому, что IPSEC работает на один уровень ниже TCP. Но я все же хотел бы захватить несколько пакетов для проверки в Wireshark.

Как я могу этого добиться?

Фильтр с tcp port 80 никогда не захватит ESP, поскольку особенно протокол (протокол IP 50) не tcp (IP-протокол 6) и никогда не будет соответствовать этому фильтру.

Для Linux это схематический и его несколько мест с xfrm (Модуль преобразования IPsec и др.) Помогают понять, как обрабатываются пакеты IPsec.

С левой стороны (входящая) копия каждого полученного пакета отправляется на ответвители AF_PACKET (например, tcpdump) и достигает уровня протокола, где он декодируется и зацикливается как простой текст с новый копия, отправленная на ответвители AF_PACKET: tcpdump захватит два пакета для каждого входящего пакета IPsec, достигающего интерфейса, а затем успешно расшифрованного. Таким образом, команда OP по-прежнему будет захватывать расшифрованную версию пакета как трафик TCP, а не как ничего.

Поскольку ESP можно инкапсулировать для NAT-T, он может поступать либо как чистый ESP, либо как ESP, инкапсулированный (обычно) в порт UDP 4500.

С правой стороны (исходящий), поскольку пакет уже зашифрован xfrm до достижения AF_PACKET tcpdump может видеть только зашифрованный результат и не может видеть текстовую версию. Здесь команда OP ничего не захватила бы. Точно так же он может быть отправлен как чистый ESP или инкапсулирован в 4500 / UDP.

Итак, в конце концов, это должно захватить зашифрованный трафик IPsec в обоих направлениях:

tcpdump -n -s0 -p -i eth0 -w log.pcap esp or udp port 4500

с небольшим количеством не-ESP IKE-трафика, также захваченного на 4500 / UDP, как описано там, который можно легко отфильтровать (значение поля SPI равно 0), если это действительно необходимо, даже во время захвата с помощью этого фильтра: 'esp or (udp port 4500 and udp[8:4] != 0)'.

Ноты:

в редко используемом случае транспортного режима с AH + ESP входящий пакет будет пакетом AH, а не пакетом ESP (ah or можно добавить перед tcpdumpфильтр, который также учитывает этот случай)
в теме IPsec в Linux, иногда пакет может снова зацикливаться в стеке маршрутизации, когда включено сжатие и получен несжатый (обычно короткий) пакет. Есть последствия, на этот раз для брандмауэра, описано там. Не повлияет tcpdump.