6.14. IPsec 구성 문제 해결

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

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

# 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

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

방화벽 관련 문제로 인한 IPsec 연결 오류를 진단합니다.

엔드포인트 또는 중간 경로의 방화벽이 인터넷 키 교환 버전 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
...

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

# 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(사전 공유 키)로 끝점이 구성되지 않은 경우 실패합니다. 불일치를 식별하는 경우 문제를 해결하기 위해 두 끝점에 설정을 조정해야 합니다.

최대 전송 단위(MTU) 문제로 인한 간헐적인 IPsec 연결 오류를 진단합니다. 암호화는 패킷 크기를 증가시켜 패킷이 더 큰 데이터 전송에서 볼 때 종종 네트워크의 MTU를 초과할 때 조각화 및 손실될 수 있습니다.

일반적인 원인은 ping과 같은 작은 패킷(예: ping이 올바르게 작동하지만 SSH 세션과 같은 큰 패킷)이 로그인 후 정지된다는 것입니다. 문제를 해결하려면 구성 파일에 mtu=1400 옵션을 추가하여 터널의 MTU를 낮추십시오.

IPsec 호스트가 NAT 라우터 역할을 할 때 발생하는 NAT 충돌을 해결합니다. 잘못된 NAT 애플리케이션은 암호화 전에 소스 IP 주소를 변환하여 네트워크를 통해 패킷이 암호화되지 않은 상태로 전송될 수 있습니다.

예를 들어 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

VPN 터널이 설정되었지만 트래픽 흐름이 없는 경우 커널 수준 IPsec 문제를 해결합니다. 이 경우 커널의 IPsec 상태를 검사하여 터널 정책 및 암호화 키가 올바르게 설치되었는지 확인합니다.

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

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

# 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
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 데몬과 동기화가 손실될 수 있습니다. 이로 인해 협상된 보안 연결과 실제 IPsec 정책 시행 사이에 불일치가 발생하여 보안 네트워크 통신이 중단될 수 있습니다.

커널 수준 오류를 확인하려면 변환(XFRM) 통계를 표시합니다.

# cat /proc/net/xfrm_stat

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

IPsec 서비스 이벤트 및 문제를 진단하고 해결하기 위해 Libreswan 로그를 표시합니다. ipsec 서비스의 저널에 액세스하여 연결 상태 및 잠재적인 문제에 대한 통찰력을 얻습니다.

저널을 표시하려면 다음을 입력합니다.

# journalctl -xeu ipsec

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

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

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