Проверка защищённого ESP-трафика и счётчиков¶
1. Передача данных с обеих сторон¶
На узле А:
На узле Б:
На испытанных VM оба направления дали 30/30 пакетов; средняя задержка порядка 3 мс только для данного виртуального стенда, не характеристика продукта. Счётчики in/out должны расти. Если соединение ESTABLISHED, но счётчики нулевые, проблема часто в маршруте, правилах INPUT/OUTPUT или выборе source IP.
2. Различаем внешний и внутренний пакеты¶
На физическом интерфейсе видны только IKE UDP 500 и зашифрованные ESP-in-UDP на 4500. На виртуальном ipsec0 после обработки kernel-libipsec виден исходный IP-трафик. Проверка при наличии tcpdump:
# Отдельный терминал, физический интерфейс:
tcpdump -ni eth0 'host 192.168.10.26 and (udp port 500 or udp port 4500)'
# На ipsec0 (содержимое защищённого трафика уже после обработки IPsec):
tcpdump -ni ipsec0 icmp
Не снимайте широкие дампы на сервере с пользовательскими данными. Для проверки фактического отсутствия утечки запрещённого защищённого IP полезно дополнительно контролировать физический интерфейс при отключённой SA.
3. Что проверять в swanctl --list-sas¶
IKEv2 ... ESTABLISHED
KUZNYECHIK_MGM_KTREE/PRF_HMAC_STREEBOG_512/GOST3410_512
CHILD_SA ... INSTALLED, TUNNEL-in-UDP, ESP:KUZNYECHIK_MGM_KTREE
in <spi> ... packets
out <spi> ... packets
NO_EXT_SEQ и GOST3410_512 в некоторых статусах ESP могут отражать формат вывода предложения при первоначальной установке/rekey — не сравнивайте текст статусов посимвольно. Сравнивайте фактически согласованный шифр, SPI, SA и трафик.
4. Если нет ответов¶
Проверьте по порядку: ip route get, ip -4 rule, ip route show table 220, правила iptables -L -n -v, адреса lo, ipsec0, журналы charon, реальный underlay до peer и обратные маршруты на втором узле. Диагностика.