6.14. 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

출력이 비어 있거나 연결 이름이 인 항목이 표시되지 않으면 터널이 손상됩니다.

문제가 연결에 있는지 확인하려면 다음을 수행하십시오.

  1. vpn.example.com 연결을 다시 로드합니다.

    # ipsec auto --add vpn.example.com
    002 added connection description "vpn.example.com"
  2. 다음으로 VPN 연결을 시작합니다.

    # ipsec auto --up vpn.example.com

방화벽 관련 문제

가장 일반적인 문제는 IPsec 끝점 중 하나 또는 끝점 간의 라우터에 있는 방화벽이 모든 인터넷 키 교환 (IKE) 패킷을 삭제하는 것입니다.

  • 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 버전으로 인해 응답 없이 원격 끝점에서 요청을 삭제할 수도 있습니다. 이는 모든 IKE 패킷을 삭제하는 방화벽과 동일합니다.

  • IKEv2의 일치하지 않는 IP 주소 범위 예(트래픽 선택기 - TS)

    # 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_UNACCEPTABLE
  • IKEv1의 일치하지 않는 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 proposal
  • IKEv1에서 PreSharedKeys (PSK)를 사용하는 경우 양쪽이 동일한 PSK에 배치되지 않으면 전체 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:500
  • IKEv2에서 mismatched-PSK 오류로 인해 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 1380

NAT(네트워크 주소 변환)

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 로그

기본적으로 syslog 프로토콜을 사용하는 Libreswan 로그입니다. journalctl 명령을 사용하여 IPsec과 관련된 로그 항목을 찾을 수 있습니다. 로그에 대한 해당 항목이 pluto IKE 데몬에서 전송되므로 "pluto" 키워드를 검색합니다. 예를 들면 다음과 같습니다.

$ journalctl -b | grep pluto

ipsec 서비스에 대한 실시간 로그를 표시하려면 다음을 수행합니다.

$ journalctl -f -u ipsec

기본 로깅 수준에서 구성 문제가 표시되지 않는 경우 /etc/ipsec.conf 파일의 구성 설정 섹션에 plutodebug=all 옵션을 추가하여 디버그 로그를 활성화합니다.

디버그 로깅은 많은 항목을 생성하며 journald 또는 syslogd 서비스는 syslog 메시지를 제한할 수 있습니다. 전체 로그를 확인하려면 로깅을 파일로 리디렉션합니다. /etc/ipsec.conf 를 편집하고 config setup 섹션에 logfile=/var/log/pluto.log 를 추가합니다.

추가 리소스