Juniper SSG 550M을 사용하는 Debian Jessie의 StrongSwan 5.2.1 - 짧은 연결 수명

Juniper SSG 550M을 사용하는 Debian Jessie의 StrongSwan 5.2.1 - 짧은 연결 수명

Juniper 박스에 대한 지속적인 VPN 연결을 설정하려고 합니다. 그러나 일부 구성 오류가 있습니다. StrongSwan 서비스를 시작했을 때 터널이 열려 있었고 모든 트래픽이 정상이었습니다. 그러나 몇 초 동안 트래픽이 없으면 연결이 끊어지고 서비스를 다시 시작해야 합니다. 백그라운드에서 VPN 대상 IP 주소에 대해 무한 핑 루프를 실행하면 연결이 계속 존재합니다. 우리는 이것이 일종의 연결 유지 관련 문제라고 생각합니다. 가능한 구성 불일치를 본 사람이 있습니까?

사양 시트 - 두 사이트 모두 다음 IPSec 설정에 동의합니다.

1단계(키 교환):
암호화 {3DES, AES256}: AES256
데이터 무결성 {MD5, SHA1, SHA2}: SHA256
Diffie-Hellman {MD5, SHA1, SHA2}: 5
IKE SA 재협상 {sec}: 86400

2단계(데이터 전송):
IPSec: ESP
암호화 {3DES, AES256}: AES256
데이터 무결성 {MD5, SHA1, SHA2}: SHA256
PFS: 예
Diffie-Hellman: 5
SA 수명 {sec}: 3600
IP 압축: 아니요

관련 구성 파일은 다음과 같습니다.

ipsec.conf:

config setup
  charondebug="ike 4, knl 4, cfg 4, net 4, esp 4, dmn 4,  mgr 4"
conn %default
  type=tunnel
  authby=secret
  ikelifetime=86400
  lifetime=3600
  keyexchange=ikev1
  compress=no
  dpdaction=restart
  dpddelay=10s
  dpdtimeout=500s
conn otto-105-183
  also=otto
  rightsubnet=10.108.105.183/32
conn otto-100-34
  also=otto
  rightsubnet=10.108.100.34/32
conn otto-100-35
  also=otto
  rightsubnet=10.108.100.35/32
conn otto
  auto=start
  ike=aes256-sha2_256-modp1536!
  esp=aes256-sha2_256-modp1536!
  left=%defaultroute
  leftsubnet=10.107.54.33/32
  leftfirewall=yes
  right=my_public_IP_address  ; redacted

Charon.conf:

charon {
    keep_alive = 20s
    crypto_test {
    }
    host_resolver {
    }
    leak_detective {
    }
    processor {
        priority_threads {
        }
    }
    start-scripts {
    }
    stop-scripts {
    }
    tls {
    }
    x509 {
    }
}

답변1

VPN 연결 끊김 및 연결 끊김은 (종종) 시간 초과 협상 문제인 것 같습니다.

장치의 dpd 시간 초과를 변경하는 것이 좋습니다VPN 양쪽 끝30초까지. 둘 다 동일한 값을 가져야 합니다.

Linux 측에서 정의하는 것으로 충분합니다.

dpdtimeout=30s

어떤 경우에는 제3자 하드웨어를 다룰 때 더 낮은 데드 피어 시간 제한을 선택하는 것이 내 경험상 더 성공적인 것 같습니다.

~에서데드 피어 감지에 대해 알아보기

DPD(Dead Peer 감지)는 네트워크 장치에서 다른 피어 장치의 현재 존재 및 가용성을 확인하는 데 사용되는 방법입니다.
장치는 암호화된 IKE 1단계 알림 페이로드를 피어(RU-THERE 메시지)에 보내고 피어로부터 DPD 승인(RU-THERE-ACK 메시지)을 기다리는 방식으로 DPD 인증을 수행합니다. RU-THERE 메시지는 장치가 지정된 DPD 간격 내에 피어로부터 트래픽을 수신하지 않는 경우에만 전송됩니다. 장치가 이 간격 내에 피어로부터 RU-THERE-ACK 메시지를 수신하면 해당 피어는 활성 상태로 간주됩니다. 장치가 터널의 피어로부터 트래픽을 수신하면 해당 터널에 대한 RU-THERE 메시지 카운터를 재설정하여 새 간격을 시작합니다. 장치가 이 시간 내에 RU-THERE-ACK 메시지를 수신하지 못하면 피어는 죽은 것으로 간주됩니다.

관련 정보