@Sergx0

Почему происходит разрыв/переподключение IPsec туннеля на 2 фазе?

Здравствуйте!

С моей стороны имеется шлюз:
Ubuntu 14.04.6 LTS (GNU/Linux 3.13.0-170-generic x86_64)
Linux strongSwan U5.1.2/K3.13.0-170-generic
Интернет: белый статический IP адрес XXX.XXX.XXX.XXX на eth0
Локалка: 192.168.1.0/24 на eth1

С другой стороны, из того что мне известно:
Шлюз Check Point
Интернет: Белый статический IP адрес YYY.YYY.YYY.YYY
Локалка: 192.168.2.0/24

Согласовали с администратором удаленного шлюза настройки, подняли IPsec в туннельном режиме, настройки соединения с моей стороны:
ipsec.conf
# ipsec.conf - strongSwan IPsec configuration file

# basic configuration

config setup
	# strictcrlpolicy=yes
	# uniqueids = no
        charondebug="cfg 2, dmn 2, ike 2, net 2"


conn XXX-YYY
      ikelifetime=86400s
      keylife=3600s
      keyexchange=ikev1
      dpdaction=restart
      dpddelay=35s
      dpdtimeout=300s
      fragmentation=yes
      left=XXX.XXX.XXX.XXX
      leftsubnet=192.168.1.0/24
      leftsourceip=XXX.XXX.XXX.XXX
      leftid=XXX.XXX.XXX.XXX
      right=YYY.YYY.YYY.YYY
      rightsubnet=192.168.2.0/24
      rightsourceip=YYY.YYY.YYY.YYY
      rightid=YYY.YYY.YYY.YYY
      ike=aes128-aes256-modp2048
      esp=md5
      aggressive=no
      type=tunnel
      authby=secret
      auto=start

ipsec.secrets
%any %any : PSK "asdasdasdasdasdasdasdasdasdasdasd"

iptables-save
*mangle
:PREROUTING ACCEPT [4822648:2854366635]
:INPUT ACCEPT [3219152:1821493584]
:FORWARD ACCEPT [1603049:1032789622]
:OUTPUT ACCEPT [3546772:1745389895]
:POSTROUTING ACCEPT [5104463:2775353165]
COMMIT
# Completed on Tue Feb 18 13:18:20 2020
# Generated by iptables-save v1.4.21 on Tue Feb 18 13:18:20 2020
*nat
:PREROUTING ACCEPT [179552:15735267]
:INPUT ACCEPT [208160:10860138]
:OUTPUT ACCEPT [80640:4841663]
:POSTROUTING ACCEPT [12:677]
-A PREROUTING ! -d 192.168.1.0/24 -i eth1 -p tcp -m multiport --dports 80 -j REDIRECT --to-ports 3128
-A PREROUTING ! -d 192.168.1.0/24 -i eth1 -p tcp -m multiport --dports 443 -j REDIRECT --to-ports 3129
-A PREROUTING -p tcp -m tcp --dport 1194 -j DNAT --to-destination 192.168.1.52:1194
-A PREROUTING -p tcp -m tcp --dport 3389 -j DNAT --to-destination 192.168.2.225:3389
-A PREROUTING -p tcp -m tcp --dport 934 -j DNAT --to-destination 192.168.1.1:934
-A PREROUTING -p tcp -m tcp --dport 1723 -j DNAT --to-destination 192.168.1.2:1723
-A POSTROUTING -s 192.168.1.0/24 -o eth0 -m policy --dir out --pol ipsec -j ACCEPT
-A POSTROUTING -s 192.168.1.0/24 ! -d 192.168.1.0/24 -j SNAT --to-source XXX.XXX.XXX.XXX
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
# Completed on Tue Feb 18 13:18:20 2020
# Generated by iptables-save v1.4.21 on Tue Feb 18 13:18:20 2020
*filter
:INPUT DROP [72256:7049702]
:FORWARD DROP [35554:2221204]
:OUTPUT ACCEPT [3546772:1745391766]
-A INPUT -i eth0 -p icmp -j ACCEPT
-A INPUT -p esp -j ACCEPT
-A INPUT -p udp -m udp --dport 4500 -j ACCEPT
-A INPUT -p udp -m udp --dport 500 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 934 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -j DROP
-A INPUT -i eth0 -p tcp -m tcp --dport 81 -j DROP
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m multiport --dports 80 -j ACCEPT
-A INPUT -p tcp -m multiport --dports 3128:3130 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -s 127.0.0.1/32 -j ACCEPT
-A INPUT -s 192.168.1.1/32 -j ACCEPT
-A INPUT -s 192.168.1.0/24 -i eth1 -p tcp -m multiport --dports 53 -m conntrack --ctstate NEW -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j ACCEPT
-A INPUT -s 192.168.1.0/24 -i eth1 -p tcp -m multiport --dports 934 -m conntrack --ctstate NEW -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j ACCEPT
-A INPUT -s 192.168.1.0/24 -i eth1 -p icmp -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 1194 -j ACCEPT
-A INPUT -i eth1 -p tcp -m tcp --dport 3389 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 934 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 1723 -j ACCEPT
-A INPUT -j ULOG
-A FORWARD -s 192.168.1.0/24 -p icmp -j ACCEPT
-A FORWARD -s 192.168.1.120/32 -j DROP
-A FORWARD -s 192.168.1.102/32 -j DROP
-A FORWARD -s 192.168.1.103/32 -j DROP
-A FORWARD -s 192.168.1.60/32 -j DROP
-A FORWARD -s 192.168.1.67/32 -j DROP
-A FORWARD -s 192.168.1.81/32 -j DROP
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -p tcp -m tcp --dport 1194 -j ACCEPT
-A FORWARD -p tcp -m tcp --dport 3389 -j ACCEPT
-A FORWARD -p tcp -m tcp --dport 934 -j ACCEPT
-A FORWARD -p tcp -m tcp --dport 1723 -j ACCEPT
-A FORWARD -i eth0 -o eth1 -p tcp -m multiport --dports 25,110,143,465,631,993,995,5121,6900 -j ACCEPT
-A FORWARD -i eth1 -o eth0 -p tcp -m multiport --dports 25,110,143,465,631,993,995,5121,6900 -j ACCEPT
-A FORWARD -i eth0 -o eth1 -p udp -m multiport --dports 25,53,110,143,465,631,993,995,5121 -j ACCEPT
-A FORWARD -i eth1 -o eth0 -p udp -m multiport --dports 25,53,110,143,465,631,993,995,5121 -j ACCEPT
-A FORWARD -s 192.168.1.101/32 -o eth0 -j ACCEPT
-A FORWARD -s 192.168.1.101/32 -o eth0 -j ACCEPT
-A FORWARD -s 192.168.1.7/32 -o eth0 -j ACCEPT
-A FORWARD -s 192.168.1.7/32 -o eth0 -j ACCEPT
-A FORWARD -s 192.168.1.2/32 -o eth0 -j ACCEPT
-A FORWARD -s 192.168.1.2/32 -o eth0 -j ACCEPT
-A FORWARD -s 192.168.1.5/32 -o eth0 -j ACCEPT
-A FORWARD -s 192.168.1.5/32 -o eth0 -j ACCEPT
-A FORWARD -j ULOG
COMMIT

Сети друг дуга видят, пакеты бегают, всё работает:
ipsec statusall
Status of IKE charon daemon (strongSwan 5.1.2, Linux 3.13.0-170-generic, x86_64):
  uptime: 59 minutes, since Feb 13 18:41:17 2020
  malloc: sbrk 2433024, mmap 0, used 352080, free 2080944
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 22
  loaded plugins: charon test-vectors aes rc2 sha1 sha2 md4 md5 random nonce x509 revocation constraints pkcs1 pkcs7 pkcs8 pkcs12 pem openssl xcbc cmac hmac ctr ccm gcm attr kernel-netlink resolve socket-default stroke updown eap-identity addrblock
Virtual IP pools (size/online/offline):
  YYY.YYY.YYY.YYY: 1/0/0
Listening IP addresses:
  XXX.XXX.XXX.XXX
  192.168.111.1
Connections:
     XXX-YYY:  XXX.XXX.XXX.XXX...YYY.YYY.YYY.YYY  IKEv1
     XXX-YYY:   local:  [XXX.XXX.XXX.XXX] uses pre-shared key authentication
     XXX-YYY:   remote: [YYY.YYY.YYY.YYY] uses pre-shared key authentication
     XXX-YYY:   child:  192.168.1.0/24 === 192.168.2.0/24 TUNNEL
Security Associations (1 up, 0 connecting):
     XXX-YYY[12]: ESTABLISHED 4 minutes ago, XXX.XXX.XXX.XXX[XXX.XXX.XXX.XXX]...YYY.YYY.YYY.YYY[YYY.YYY.YYY.YYY]
     XXX-YYY[12]: IKEv1 SPIs: d1a95eb5e2361ab3_i abddab29cc4424f4_r*, pre-shared key reauthentication in 23 hours
     XXX-YYY[12]: IKE proposal: AES_CBC_128/HMAC_MD5_96/PRF_HMAC_MD5/MODP_2048
     XXX-YYY{1}:  REKEYING, TUNNEL, expires in 48 seconds
     XXX-YYY{1}:   192.168.1.0/24 === 192.168.2.0/24


Далее каждые 35 секунд (dpddelay=35s) в syslog спам следующих сообщений:
...
charon: 03[NET] received packet: from YYY.YYY.YYY.YYY[500] to XXX.XXX.XXX.XXX[500]
charon: 10[NET] received packet: from YYY.YYY.YYY.YYY[500] to XXX.XXX.XXX.XXX[500] (188 bytes)
charon: 10[IKE] received retransmit of request with ID 995476868, but no response to retransmit
charon: 03[NET] waiting for data on sockets
...

Спустя 5 минут (dpdtimeout=300s) 2 фаза прерывается, несмотря на заданный keylife=3600s. Соединение моментально поднимается. Для служб вроде RDP не критично, дело до таймаута не доходит, но если происходит копирование файла между подсетями, то соответственно копирование прерывается.

В логе так же присутствует "gate charon: 10[IKE] no matching CHILD_SA config found", т.е. насколько я понимаю демон ругается на то, что какие то настройки между клиентом и сервером не совпадают, не понятно тогда почему 5 минут соединение держится.

Ниже по ссылке syslog с полным циклопом от запуска IPsec до разрыва.
Пожалуйста, укажите в какую сторону копать!
https://pastebin.com/UCjZtukD
  • Вопрос задан
  • 104 просмотра
Пригласить эксперта
Ответы на вопрос 2
CityCat4
@CityCat4
У тролля даже мозги - и то каменные!
то, что expires in 48 seconds - это так и должно быть? Чему равно policy? strict, obey? Могу еще посоветовать отрубить нахрен dpd - у меня от него толку не было от слова совсем.

Ну и вот я сразу ошибку вижу:
received NO_PROPOSAL_CHOSEN error notify

Если это лог, снятый с Вашей стороны, то та сторона сообщает Вам, что нет у нее шифронаборов, соответствующих хотя бы одному из тех, что есть у вас в предложении (proposal). Настройте соединение так, чтобы принять настройки которые отдаст та сторона - и шифронаборы и время соединения - хотя бы чтобы убедиться, что с этим чекпойнтом вообще в принципе возможно увязаться.
Ответ написан
@Sergx0 Автор вопроса
Сейчас пообщался с администратором чекпоинта, как выяснилось статус соединения с с текущей прошивкой (75.20) "Не подключено", при этом мою сеть он видит. Ранее тестировали туннель с другим чекпоинтом на 77 прошивке и там такого бага не было. Я так полагаю, чекпоинт в рамках установленных таймингов (dpd) пытается соединиться (хотя соединение уже установлено), дропает через 5 минут, соединяется и все по кругу. К тому же вчера поднял туннель с теми же настройками strongswana до домашнего роутера, все работает идеально. Видимо нужно ждать когда обновят чекпоинт.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы