Как починить client-domain TCP через IPSec?

Question

[Юрий Попов]

Приветствую.

Решил перелезть с OpenVPN на IKEv2, заодно заведя туда же свои устройства от фруктовой компании.

Сертификаты от OpenVPN подошли замечательно, соединение (с определёнными проблемами, но всё же) установилось. Теперь к проблемам.

Конфигурация следующая: на сервере (он же роутер в домашнюю сеть) есть интерфейс br-local (192.168.x.1/24), с настроенным DHCP. Strongswan настроен использовать его же, клиенты получают IP в той же подсети, и всё хорошо. Теперь я с клиента (ноутбук) стучусь... да много куда, до домашнего компьютера, до виртуалок на том же сервере, и т.д. - всё хорошо. Ping 192.168.x.1 проходит. DIG рапортует, что DNS использует тот же - 192.168.x.1 (ответы получает, в том числе про локальные ресурсы).

Теперь вопрос. Какого Ктулху в этой идиллии не работает TCP до 192.168.x.1? Ни SSH, ни HTTP(S)... ничего.
В wireshark вижу пакеты, которые уходят по адресу. В tcpdump вижу, что они принимаются. В логах серверов вижу запросы. А вот куда уходит трафик "обратно" - никак не пойму. Может, в /dev/null, может в lo, но уж точно не клиенту.

/etc/ipsec.conf

config setup
	# strictcrlpolicy=yes
	# uniqueids = no

conn %default
  dpdaction=clear
  dpddelay=35s
  dpdtimeout=300s

  fragmentation=yes
  rekey=no
  compress=yes
  mobike=yes

  keyexchange=ikev2
  ike=...
  esp=...

conn phoenix
  left=%any
  leftauth=pubkey
  leftsubnet=0.0.0.0/0
  leftsourceip=%config
  leftcert=vpn-server.crt
  leftid=@REDACTED
  leftsendcert=always
  leftfirewall=yes

  right=%any
  rightsourceip=%dhcp
  rightca=REDACTED
  rightdns=192.168.x.1,8.8.8.8,8.8.4.4

conn phoenix-pubkey
  also=phoenix
  auto=add

conn phoenix-pubkey-noxauth
  also=phoenix
  rightauth2=xauth-noauth
  auto=add

conn phoenix-eap
  also=phoenix
  eap_identity=%identity
  rightauth=eap
  auto=add

conn phoenix-eap-tls
  also=phoenix
  eap_identity=%identity
  rightauth=eap-tls
  auto=add

/etc/iptables/rules.v4

*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1:136]
-A INPUT -i br-local -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i wan -p udp -m udp --dport 500 -j ACCEPT
-A INPUT -i wan -p udp -m udp --dport 4500 -j ACCEPT
-A INPUT -i wan -p esp -j ACCEPT
-A INPUT -m policy --dir in --pol ipsec --proto esp -j ACCEPT
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
COMMIT

*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 192.168.x.0/24 -m policy --dir out --pol ipsec -j ACCEPT
-A POSTROUTING -j MASQUERADE
COMMIT

*mangle
:PREROUTING ACCEPT [375:162632]
:INPUT ACCEPT [57:8507]
:FORWARD ACCEPT [318:154125]
:OUTPUT ACCEPT [43:6847]
:POSTROUTING ACCEPT [361:160972]
-A FORWARD -p tcp -m policy --pol ipsec --dir in --syn -m tcpmss --mss 1361:1536 -j TCPMSS --set-mss 1360
-A FORWARD -p tcp -m policy --pol ipsec --dir out --syn -m tcpmss --mss 1361:1536 -j TCPMSS --set-mss 1360
COMMIT

Answer 1

[CityCat4]

Здесь полная схема прохождения пакетов через iptables, в том числе на ней указаны места, где выполняется шифрование/дешифровка пакетов (этот момент обычно опускается). ВАЖНО! Проверка на соответствие политики и расшифровка делается ядром исключительно на основе SAD и SPD, без использования чего-либо еще.

Что можно сделать.

Со стороны линуха посмотреть статистику XFRM - преобразователя пакетов при шифровке-расшифровке:
# cat /proc/net/xfrm_stat

Если счетчик любой ошибки растет - это жжж неспроста. У меня например, была ситуация, когда микротик не вязался с Strongswan из-за хэша SHA256 - у микротика какая-то своя, особенная реализация - два микротика вяжутся без проблем, а вот микротик и strongswan катеорически отказывались. При этом постоянно рос счетчик XfrmInStateProtoError - пакет принимался, но при расшифровке возникала ошибка и его просто отбрасывали, как поврежденный.

Есть еще полезная команда swanctl -l, показывающая состояние соединения.