6.14. IPsec 구성 문제 해결

VPN 연결 문제는 종종 엔드포인트 간 구성이 일치하지 않기 때문에 발생합니다.

IPsec 연결이 설정되었는지 확인하려면 다음을 입력합니다.

ipsec trafficstatus

# ipsec trafficstatus
006 #8: "vpn.example.com"[1] 192.0.2.1, type=ESP, add_time=1595296930, inBytes=5999, outBytes=3231, id='@vpn.example.com', lease=198.51.100.1/32

성공적인 연결을 위해 명령은 연결 이름과 세부 정보가 있는 항목을 표시합니다. 출력이 비어 있으면 터널이 설정되지 않습니다.

엔드포인트 또는 중간 경로의 방화벽이 인터넷 키 교환 버전 2(IKEv2) 패킷을 삭제하면 ipsec up 명령이 시간 초과되고 반복된 재전송 메시지가 표시됩니다.

181 "vpn.example.com"[1] 192.0.2.2 #15: initiating IKEv2 IKE SA
181 "vpn.example.com"[1] 192.0.2.2 #15: STATE_PARENT_I1: sent v2I1, expected v2R1
010 "vpn.example.com"[1] 192.0.2.2 #15: STATE_PARENT_I1: retransmission; will wait 0.5 seconds for response
010 "vpn.example.com"[1] 192.0.2.2 #15: STATE_PARENT_I1: retransmission; will wait 1 seconds for response
010 "vpn.example.com"[1] 192.0.2.2 #15: STATE_PARENT_I1: retransmission; will wait 2 seconds for response
...

181 "vpn.example.com"[1] 192.0.2.2 #15: initiating IKEv2 IKE SA
181 "vpn.example.com"[1] 192.0.2.2 #15: STATE_PARENT_I1: sent v2I1, expected v2R1
010 "vpn.example.com"[1] 192.0.2.2 #15: STATE_PARENT_I1: retransmission; will wait 0.5 seconds for response
010 "vpn.example.com"[1] 192.0.2.2 #15: STATE_PARENT_I1: retransmission; will wait 1 seconds for response
010 "vpn.example.com"[1] 192.0.2.2 #15: STATE_PARENT_I1: retransmission; will wait 2 seconds for response
...

tcpdump 유틸리티를 사용하여 트래픽을 캡처하고 IKE 또는 IPsec 패킷이 방화벽에 의해 삭제되는지 확인할 수 있습니다. 예를 들면 다음과 같습니다.

tcpdump -i <interface> -n -n esp or udp port 500 or udp port 4500 or tcp port 4500

# tcpdump -i <interface> -n -n esp or udp port 500 or udp port 4500 or tcp port 4500

tcpdump 는 IKE 프로토콜이 암호화되므로 다른 유형의 IPsec 문제를 진단하는 데 제한된 사용입니다.

VPN 연결은 일치하는 인터넷 키 교환(IKE) 버전, 알고리즘, IP 주소 범위 또는 PSK(사전 공유 키)로 끝점이 구성되지 않은 경우 실패합니다. 불일치를 식별하는 경우 문제를 해결하기 위해 두 끝점에 설정을 조정해야 합니다.

암호화 및 캡슐화 프로세스는 패킷 크기를 늘립니다. 패킷은 일반적으로 1500바이트인 네트워크의 최대 전송 단위(MTU)를 초과하면 패킷이 조각됩니다. 이로 인해 조각이 손실되고 원래 패킷을 다시 조립할 수 없는 간헐적인 연결 오류가 발생할 수 있습니다. 일반적인 원인은 ping과 같은 작은 패킷(예: ping이 올바르게 작동하지만 SSH 세션과 같은 큰 패킷)이 로그인 후 정지된다는 것입니다.

문제를 해결하려면 구성 파일에 mtu=1400 옵션을 추가하여 터널의 MTU를 낮추십시오.

IPsec 호스트가 NAT 라우터로 작동하는 경우 IPsec 터널에 대해 의도한 패킷에 NAT를 잘못 적용할 수 있습니다. 예를 들어 IPsec 암호화를 적용하기 전에 패킷의 소스 IP 주소가 masquerade 규칙에 의해 변환되면 패킷의 소스 소스가 더 이상 IPsec 정책과 일치하지 않으며 Libreswan은 네트워크를 통해 암호화되지 않은 상태로 보냅니다.

이 문제를 해결하려면 NAT에서 IPsec 서브넷 간 트래픽을 제외하는 방화벽 규칙을 추가합니다. 이 규칙은 POSTROUTING 체인의 시작 부분에 삽입하여 일반 NAT 규칙보다 먼저 처리되도록 해야 합니다.

nft add table ip nat
nft add chain ip nat postrouting { type nat hook postrouting priority 100 \; }
nft add rule ip nat postrouting ip saddr 192.0.2.0/24 ip daddr 198.51.100.0/24 return

# nft add table ip nat
# nft add chain ip nat postrouting { type nat hook postrouting priority 100 \; }
# nft add rule ip nat postrouting ip saddr 192.0.2.0/24 ip daddr 198.51.100.0/24 return

일반적인 문제는 VPN 터널이 성공적으로 설정된 것처럼 보이지만 트래픽이 통과되지 않는 경우입니다. 이 경우 커널의 IPsec 상태를 검사하여 터널 정책 및 암호화 키가 올바르게 설치되었는지 확인할 수 있습니다.

이 프로세스에는 다음 두 가지 구성 요소를 확인하는 작업이 포함됩니다.

먼저 SPD에 올바른 정책이 있는지 확인합니다.

ip xfrm policy

# ip xfrm policy
src 192.0.2.1/32 dst 10.0.0.0/8
	dir out priority 666 ptype main
	tmpl src 198.51.100.13 dst 203.0.113.22
		proto esp reqid 16417 mode tunnel

출력에는 왼쪽subnet 및 rightsubnet 매개변수와 일치하는 정책이 포함되어 있어야 합니다. 트래픽에 대한 정책이 표시되지 않으면 Libreswan이 커널 규칙을 생성하지 못하고 트래픽이 암호화되지 않습니다.

정책이 존재하는 경우 SAD에 해당 키 세트가 있는지 확인합니다.

ip xfrm state

# ip xfrm state
src 203.0.113.22 dst 198.51.100.13
	proto esp spi 0xa78b3fdb reqid 16417 mode tunnel
	auth-trunc hmac(sha1) 0x3763cd3b... 96
	enc cbc(aes) 0xd9dba399...

정책이 존재하지만 동일한 reqid 를 가진 해당 상태가 없는 경우 일반적으로 인터넷 키 교환(IKE) 협상에 실패했습니다. 두 VPN 엔드 포인트가 일련의 키에 동의할 수 없었습니다.

자세한 진단을 위해 명령 중 하나와 함께 -s 옵션을 사용합니다. 이 옵션은 커널에서 특정 규칙으로 패킷을 처리하는지 확인하는 데 도움이 될 수 있는 트래픽 카운터를 추가합니다.

드문 경우지만 커널의 IPsec 하위 시스템의 결함으로 인해IKE(Internet Key Exchange) 사용자 공간 데몬과 동기화가 손실될 수 있습니다. 이러한 동기화 해제로 인해 협상된 보안 연결과 커널 내의 IPsec 정책의 실제 시행 간의 불일치가 발생할 수 있으므로 보안 네트워크 통신이 중단될 수 있습니다. 커널 수준 오류를 확인하려면 변환(XFRM) 통계를 표시합니다.

cat /proc/net/xfrm_stat

# cat /proc/net/xfrm_stat

XfrmInError 와 같은 출력의 카운터 중 하나가 0이 아닌 값을 표시하는 경우 커널 하위 시스템에 문제가 있음을 나타냅니다. 이 경우 지원 케이스 를 열고 해당 IKE 로그와 함께 명령의 출력을 연결합니다.

Libreswan은 이벤트를 저널에 기록합니다. ipsec 서비스의 저널을 표시하려면 다음을 입력합니다.

journalctl -xeu ipsec

# journalctl -xeu ipsec

기본 로깅 수준이 충분한 세부 정보를 제공하지 않는 경우 /etc/ipsec.conf 파일의 config setup 섹션에 다음 설정을 추가하여 포괄적인 디버그 로깅을 활성화합니다.

plutodebug=all
logfile=/var/log/pluto.log

plutodebug=all
logfile=/var/log/pluto.log

디버그 로깅은 많은 항목을 생성할 수 있으므로 메시지를 전용 로그 파일로 리디렉션하면 journald 및 systemd 서비스가 메시지를 속도가 제한되지 않을 수 있습니다.