5.15. IPsec VPN 구성 문제 해결
IPsec VPN 구성과 관련된 문제는 여러 가지 주요 이유로 발생합니다. 이러한 문제가 발생하면 문제의 원인이 다음 시나리오에 해당하는지 확인하고 해당 솔루션을 적용할 수 있습니다.
기본 연결 문제 해결
VPN 연결에 대한 대부분의 문제는 관리자가 구성 옵션과 일치하지 않는 엔드포인트를 구성한 새로운 배포에서 발생합니다. 또한 작동 중인 구성은 새로 호환되지 않는 값 때문에 갑자기 작동을 중지할 수 있습니다. 이는 관리자가 구성을 변경한 결과일 수 있습니다. 또는 관리자가 암호화 알고리즘과 같은 특정 옵션에 대해 다양한 기본값을 사용하여 펌웨어 업데이트 또는 패키지 업데이트를 설치할 수 있습니다.
IPsec VPN 연결이 설정되었는지 확인하려면 다음을 수행하십시오.
# 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=100.64.13.5/32출력이 비어 있거나 연결 이름이 인 항목이 표시되지 않으면 터널이 손상됩니다.
문제가 연결에 있는지 확인하려면 다음을 수행하십시오.
vpn.example.com 연결을 다시 로드합니다.
# ipsec auto --add vpn.example.com 002 added connection description "vpn.example.com"다음으로 VPN 연결을 시작합니다.
# ipsec auto --up vpn.example.com
방화벽 관련 문제
가장 일반적인 문제는 IPsec 엔드포인트 중 하나 또는 엔드포인트 사이의 라우터에 있는 방화벽이 모든 IKE(Internet Key Exchange) 패킷을 삭제하는 것입니다.
IKEv2의 경우 다음 예제와 유사한 출력은 방화벽에 문제가 있음을 나타냅니다.
# ipsec auto --up vpn.example.com 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 ...IKEv1의 경우 시작 명령의 출력은 다음과 같습니다.
# ipsec auto --up vpn.example.com 002 "vpn.example.com" #9: initiating Main Mode 102 "vpn.example.com" #9: STATE_MAIN_I1: sent MI1, expecting MR1 010 "vpn.example.com" #9: STATE_MAIN_I1: retransmission; will wait 0.5 seconds for response 010 "vpn.example.com" #9: STATE_MAIN_I1: retransmission; will wait 1 seconds for response 010 "vpn.example.com" #9: STATE_MAIN_I1: retransmission; will wait 2 seconds for response ...
IPsec을 설정하는 데 사용되는 IKE 프로토콜은 암호화되므로 tcpdump 도구를 사용하여 제한된 문제 하위 집합만 해결할 수 있습니다. 방화벽이 IKE 또는 IPsec 패킷을 삭제하는 경우 tcpdump 유틸리티를 사용하여 원인을 찾을 수 있습니다. 그러나 tcpdump 는 IPsec VPN 연결의 다른 문제를 진단할 수 없습니다.
eth0인터페이스에서 VPN과 암호화된 모든 데이터의 협상을 캡처하려면 다음을 수행합니다.# tcpdump -i eth0 -n -n esp or udp port 500 or udp port 4500 or tcp port 4500
일치하지 않는 알고리즘, 프로토콜 및 정책
VPN 연결에서는 엔드포인트에 IKE 알고리즘, IPsec 알고리즘 및 IP 주소 범위가 일치해야 합니다. 불일치가 발생하면 연결에 실패합니다. 다음 방법 중 하나를 사용하여 일치하지 않는 경우 알고리즘, 프로토콜 또는 정책을 조정하여 수정합니다.
원격 엔드포인트가 IKE/IPsec을 실행 중이 아닌 경우 이를 나타내는 ICMP 패킷이 표시됩니다. 예를 들면 다음과 같습니다.
# ipsec auto --up vpn.example.com ... 000 "vpn.example.com"[1] 192.0.2.2 #16: ERROR: asynchronous network error report on wlp2s0 (192.0.2.2:500), complainant 198.51.100.1: Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)] ...일치하지 않는 알고리즘의 예:
# ipsec auto --up vpn.example.com ... 003 "vpn.example.com"[1] 193.110.157.148 #3: dropping unexpected IKE_SA_INIT message containing NO_PROPOSAL_CHOSEN notification; message payloads: N; missing payloads: SA,KE,Ni일치하지 않는 IPsec 알고리즘의 예:
# ipsec auto --up vpn.example.com ... 182 "vpn.example.com"[1] 193.110.157.148 #5: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=AES_GCM_16_256 integ=n/a prf=HMAC_SHA2_256 group=MODP2048} 002 "vpn.example.com"[1] 193.110.157.148 #6: IKE_AUTH response contained the error notification NO_PROPOSAL_CHOSEN일치하는 버전과 일치하지 않으면 응답 없이 원격 엔드포인트가 요청을 삭제할 수도 있었습니다. 이는 모든 IKE 패킷을 삭제하는 방화벽과 동일합니다.
IKEv2 (Traffic Selectors - TS)의 일치하지 않는 IP 주소 범위의 예:
# ipsec auto --up vpn.example.com ... 1v2 "vpn.example.com" #1: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=AES_GCM_16_256 integ=n/a prf=HMAC_SHA2_512 group=MODP2048} 002 "vpn.example.com" #2: IKE_AUTH response contained the error notification TS_UNACCEPTABLEIKEv1의 일치하지 않는 IP 주소 범위의 예:
# ipsec auto --up vpn.example.com ... 031 "vpn.example.com" #2: STATE_QUICK_I1: 60 second timeout exceeded after 0 retransmits. No acceptable response to our first Quick Mode message: perhaps peer likes no proposalIKEv1에서 PreSharedKeys ()를 사용할 때 양쪽이 동일한 에 배치되지 않으면 전체 IKE 메시지가 읽을 수 없게 됩니다.
# ipsec auto --up vpn.example.com ... 003 "vpn.example.com" #1: received Hash Payload does not match computed value 223 "vpn.example.com" #1: sending notification INVALID_HASH_INFORMATION to 192.0.2.23:500IKEv2에서 불일치- 오류로 인해 AUTHENTICATION_FAILED 메시지가 표시됩니다.
# ipsec auto --up vpn.example.com ... 002 "vpn.example.com" #1: IKE SA authentication request rejected by peer: AUTHENTICATION_FAILED
최대 전송 단위
IKE 또는 IPsec 패킷을 차단하는 방화벽 이외의 네트워킹 문제의 가장 일반적인 원인은 암호화된 패킷의 증가된 패킷 크기와 관련이 있습니다. 최대 전송 단위(MTU)보다 큰 네트워크 하드웨어 조각 패킷(예: 1500바이트). 종종 조각이 손실되고 패킷이 다시 집계되지 않습니다. 이로 인해 작은 규모의 패킷을 사용하는 ping 테스트가 작동하지만 다른 트래픽이 실패하면 간헐적인 오류가 발생합니다. 이 경우 SSH 세션을 설정할 수 있지만 원격 호스트에 'ls -al /usr' 명령을 입력하여 바로 터미널이 중지됩니다.
이 문제를 해결하려면 터널 구성 파일에 mtu=1400 옵션을 추가하여 MTU 크기를 줄입니다.
또는 TCP 연결의 경우 MSS 값을 변경하는 iptables 규칙을 활성화합니다.
# iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
이전 명령에서 시나리오의 문제를 해결하지 않으면 set-mss 매개변수에 더 작은 크기를 직접 지정합니다.
# iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1380NAT(네트워크 주소 변환)
IPsec 호스트가 NAT 라우터 역할을 할 때 실수로 패킷을 다시 매핑할 수 있습니다. 다음 예제 구성은 문제를 보여줍니다.
conn myvpn
left=172.16.0.1
leftsubnet=10.0.2.0/24
right=172.16.0.2
rightsubnet=192.168.0.0/16
…주소가 172.16.0.1인 시스템에는 NAT 규칙이 있습니다.
iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
주소 10.0.2.33의 시스템이 패킷을 192.168.0.1로 보내는 경우 라우터는 IPsec 암호화를 적용하기 전에 소스 10.0.2.33을 172.16.0.1로 변환합니다.
그런 다음 소스 주소가 10.0.2.33인 패킷이 더 이상 conn myvpn 설정과 일치하지 않으며 IPsec은 이 패킷을 암호화하지 않습니다.
이 문제를 해결하려면 라우터의 대상 IPsec 서브넷 범위에 대해 NAT를 제외하는 규칙을 삽입합니다. 예를 들면 다음과 같습니다.
iptables -t nat -I POSTROUTING -s 10.0.2.0/24 -d 192.168.0.0/16 -j RETURN
커널 IPsec 하위 시스템 버그
예를 들어 버그로 인해 IKE 사용자 공간과 IPsec 커널이 동기화 해제되는 경우 커널 IPsec 하위 시스템이 실패할 수 있습니다. 이러한 문제를 확인하려면 다음을 수행합니다.
$ cat /proc/net/xfrm_stat
XfrmInError 0
XfrmInBufferError 0
...이전 명령의 출력에 0이 아닌 값은 문제가 있음을 나타냅니다. 이 문제가 발생하면 새 지원 케이스를 열고 해당 IKE 로그와 함께 이전 명령의 출력을 연결합니다.
Libreswan 로그
Libreswan 로그는 기본적으로 syslog 프로토콜을 사용합니다. journalctl 명령을 사용하여 IPsec과 관련된 로그 항목을 찾을 수 있습니다. 로그에 대한 해당 항목은 pluto IKE 데몬에 의해 전송되므로 "pluto" 키워드를 검색합니다. 예를 들면 다음과 같습니다.
$ journalctl -b | grep pluto
ipsec 서비스에 대한 실시간 로그를 표시하려면 다음을 수행합니다.
$ journalctl -f -u ipsec
기본 로깅 수준에 설정 문제가 표시되지 않으면 /etc/ipsec.conf 파일의 config setup 섹션에 plutodebug=all 옵션을 추가하여 디버그 로그를 활성화합니다.
디버그 로깅은 많은 항목을 생성하며, journald 또는 syslogd 서비스 속도에 따라 syslog 메시지가 제한될 수 있습니다. 전체 로그가 있는지 확인하려면 로깅을 파일로 리디렉션합니다. /etc/ipsec.conf를 편집하고 config setup 섹션에 logfile=/var/log/pluto.log를 추가합니다.
추가 리소스
- 로그 파일을 사용하여 문제 해결
-
tcpdump(8)및ipsec.conf(5)도움말 페이지. - firewalld 사용 및 구성
