IKEv2 단편화와 인증서 체인 문제 구분하기

터널은 사무실 네트워크에서는 작동했지만 집에서는 멈췄고, 로그는 첫 교환이 완료된 뒤 아무 일도 일어나지 않았음을 보여 줍니다. 이 패턴은 자격 증명이 아니라 인증 교환을 가리킵니다. 인증서 체인은 그 메시지를 이전 것보다 훨씬 크게 만들고, 큰 데이터그램을 싫어하는 경로는 그것을 조용히 버립니다. 서로 다른 두 가지 단편화 메커니즘이 관련되어 있으며, 어느 쪽을 보고 있는지 아는 것이 해결책을 결정합니다.

두 가지 단편화 메커니즘, 하나의 증상

IKEv2에는 RFC 7383에 정의된 자체 단편화 확장이 있으며, 보호된 IKE 메시지를 더 작은 IKE 메시지로 나눕니다. 두 피어가 그 기능을 협상하고, 메시지는 IP 계층이 아니라 IKE 구현에 의해 다시 조립됩니다.

일반 IP 단편화는 실패 방식이 다른 별개의 메커니즘입니다. 피어 사이의 라우터가 큰 데이터그램을 단편화하거나, 그것을 버리고 송신자에게 결코 도달하지 못할 수 있는 ICMP 메시지를 돌려보냅니다. 어떤 네트워크는 단편을 조용히 버리고, 어떤 중간 장치는 첫 단편만 처리하고 나머지는 처리하지 않습니다. 애플리케이션 관점에서 세 경우는 똑같아 보입니다.

NAT 통과는 세 번째 변수를 더합니다. ESP가 UDP로 감싸지면서 바깥 패킷이 커지지만 4500 포트의 평범한 UDP 트래픽처럼 보이기 때문입니다. UDP를 잘 통과시키는 경로도 더 이상 들어가지 않는 데이터그램에서는 실패할 수 있습니다.

실패한 교환을 읽으십시오

오류가 아니라 전환을 찾으십시오. 첫 교환이 전송되고 응답된 뒤 아무것도 없는 로그는 다음 메시지가 결코 완료되지 않았음을 알려 줍니다. 로그 수준을 일시적으로 높이고 양쪽 피어에서 보고된 크기를 비교하십시오.

확인하려는 것은 응답자가 요청을 아예 보았는지 여부입니다. 시작자가 무언가를 보냈는데 응답자에게 그 기록이 없다면 문제는 전달입니다. 응답자가 요청을 분석하고 거부했다면 문제는 인증서 자체이며, 단편화는 주의를 흐트러뜨리는 것입니다. 그 구분은 타임아웃 메시지 한 페이지보다 값집니다.

인증서가 아니라 경로를 바꾸십시오

같은 클라이언트, 같은 인증서, 같은 구성을 다른 네트워크에서 시험하십시오. 모바일 핫스팟이 보통 가장 저렴한 두 번째 경로이며, 사무실 링크와 이름만 다른 것이 아니라 실제로 다릅니다.

두 번째 경로에서 핸드셰이크가 완료되면 인증서 체인은 정상이고 첫 번째 경로가 변수입니다. 두 경로에서 똑같이 실패하면 네트워크 시험을 멈추고 메시지 자체를 보십시오. 그 한 번의 비교로 가능한 설명의 약 절반이 사라집니다.

무엇이든 편집하기 전에 교환을 측정하십시오

체인의 크기와 경로의 크기를 구하십시오. 두 숫자 모두 핸드셰이크가 보낼 수 있는 것을 제한하며, 둘 다 측정 비용이 저렴합니다:

openssl crl2pkcs7 -nocrl -certfile chain.pem | openssl pkcs7 -print_certs -noout | grep -c subject
ls -l chain.pem
ping -M do -s 1400 198.51.100.7
ip -s link show eth0 | sed -n '1,6p'

처음 두 개는 인증서 수와 파일 크기를 알려 주며, 이는 인증 메시지가 얼마나 커질지에 대한 합리적인 지표입니다. ping 검사는 그 크기의 데이터그램이 경로를 통과하는지 알려 주고, 인터페이스 카운터는 당신 쪽에서 단편이 버려졌는지 보여 줍니다. Windows에서는 do-not-fragment 플래그와 명시적 페이로드 크기를 사용하는 ping이 동등한 검사입니다.

성공할 때까지 검사를 아래로 반복하십시오. 통과하는 가장 큰 크기가 그 경로의 실무 예산이며, 공개된 어떤 기본값보다 유용합니다.

실제로 깨진 계층을 고치십시오

경로가 큰 데이터그램을 버린다면 양쪽 피어에서 IKE 단편화를 켜고, 확장이 단지 제안된 것이 아니라 협상되었는지 확인하십시오. 경로가 IP 수준에서 단편을 잘못 처리한다면 수정은 그곳이나 바깥 인터페이스의 MTU에 속하며, 인증서 저장소가 아닙니다.

체인이 불필요하게 길다면 피어가 실제로 필요로 하는 중간 인증서까지 줄이십시오. 클라이언트가 이미 신뢰하는 루트를 제거하는 것은 합리적인 정리이고, 중간 인증서를 제거하는 것은 그렇지 않으며, 메시지를 줄이려고 검증을 끄는 것은 전달 문제를 보안 문제와 맞바꾸는 일입니다.

어떤 메커니즘을 바꿨는지, 그 뒤 핸드셰이크가 어땠는지 적어 두십시오. 다음 발생은 보통 같은 증상으로 다른 네트워크에서 일어나며, 그 메모가 두 시간을 십 분으로 바꿉니다.