패킷 캡처에서 첫 IKEv2 교환을 읽는 방법

세션 중간에 뜬 캡처가 IKEv2 추적을 잡음처럼 보이게 하는 흔한 이유입니다. 녹음을 시작할 때 양쪽은 이미 키를 갱신하거나 암호화된 페이로드를 교환하고 있기 때문입니다. 대신 새로운 연결 시도에서 시작하세요. 그러면 파일의 첫 메시지가 협상을 여는 메시지가 됩니다. 아래 읽기 순서는 이를 전제로 하며, 패킷이 원격 측에 대해 아무것도 증명하지 못하게 되는 지점을 표시합니다. 이 단계를 건너뛰면 정상 동작하는 터널이 차단된 포트로 진단됩니다.

개시 교환을 보고 있는지 확인하세요

IKEv2 협상은 IKE_SA_INIT, 교환 유형 34, 메시지 ID 0으로 시작합니다. 개시자는 영이 아닌 SPI를 고르고, 응답자의 SPI는 그 첫 요청에서 영이고 응답에서는 영이 아닙니다. 이 세 가지 사실이 새 시도와 키 갱신, 또는 캡처 맨 위에 우연히 놓인 IKE_AUTH 메시지를 구분합니다.

헤더 필드는 읽을 수 있고, 제안·키 교환·nonce 페이로드도 마찬가지입니다. 읽을 수 있다는 것이 인증되었다는 뜻은 아닙니다. 이 시점에 어느 쪽도 신원을 증명하지 않았고, Diffie-Hellman 개인 값은 회선에 절대 나타나지 않습니다.

디코드 창을 스크롤하는 대신 필드를 표로 출력하세요. 재전송과 맞지 않는 SPI가 열에서 분명해집니다.

tshark -r ike.pcapng -Y "isakmp" -T fields -e frame.number -e ip.src -e udp.srcport -e isakmp.exchangetype -e isakmp.messageid -e isakmp.initiator_spi -e isakmp.responder_spi

출력은 쌍으로 읽습니다. 메시지 ID 0인 요청 뒤에 같은 ID와 영이 아닌 응답자 SPI를 지닌 응답이 오면 하나의 교환입니다. 요청이 재전송되어 세 번 나타나도 마찬가지입니다. 같은 요청 세 개는 로그인 세 번이 아니며, 그렇게 취급하는 것이 바로 클라이언트가 루프를 돈다고 결론짓는 방식입니다. 사실은 그저 참을성 있을 뿐입니다. 메시지 ID로, 그다음 타임스탬프로 정렬하면 대화 전체가 짧은 시도 목록으로 줄어듭니다.

성공을 읽기 전에 거부를 읽으세요

응답이 자동으로 진전은 아닙니다. 응답자는 cookie 알림으로 답하고 개시자가 다시 시도하기를 기대할 수 있고, 대신 받아들일 그룹을 지목하는 INVALID_KE_PAYLOAD로 답할 수도 있습니다. 둘 다 제대로 된 IKE 메시지로 도착하며, 패킷만 세는 필터에는 둘 다 끝난 교환처럼 보입니다.

알림 페이로드를 열고 무엇보다 유형을 먼저 읽으세요. cookie 챌린지는 응답자가 위조된 출발지 주소를 막고 있다는 뜻이며, 클라이언트는 cookie를 붙여 다시 보내야 합니다. 유효하지 않은 그룹은 두 제안이 맞지 않는다는 뜻이고, 한쪽 구성이 바뀌기 전에는 아무리 재시도해도 달라지지 않습니다.

암호화된 신원과 인증 페이로드를 나르는 것은 두 번째 교환인 IKE_AUTH뿐입니다. 따라서 완료된 IKE_SA_INIT은 양쪽이 알고리즘과 유도된 키에 합의했다는 것만 알려 주고, 자격 증명이 받아들여질지에 대해서는 아무것도 알려 주지 않습니다. 그곳에도 메시지가 두 개 있으며, 세션 키 없이는 둘 다 불투명합니다.

4500 포트는 하나의 프로토콜이 아닙니다

보통 UDP 500이 개시 교환을 나릅니다. NAT 탐지가 실행되면 IKE는 4500으로 옮겨 가고 각 메시지 앞에 영으로 채운 네 바이트의 비 ESP 표시를 붙입니다. 같은 포트의 캡슐화된 ESP는 반대로 영이 아닌 ESP SPI로 시작하며, 한 바이트 NAT keepalive는 다른 일이 없을 때 나타나는 세 번째 형태입니다.

포트만 맞추는 필터는 셋을 모두 섞습니다. 그래서 "4500에 트래픽이 있다"는 말로는 거의 아무것도 정해지지 않습니다. 원격 측에 대해 결론을 내리기 전에 프로토콜별로 보기를 나누세요.

tshark -r ike.pcapng -Y "udp.port == 4500 && isakmp" -T fields -e frame.number -e isakmp.exchangetype
tshark -r ike.pcapng -Y "udp.port == 4500 && !isakmp" -T fields -e frame.number -e esp.spi

침묵은 관측 지점을 설명합니다

응답이 없는 요청이 확립하는 것은 정확히 하나입니다. 그 캡처 지점에서는 응답이 나타나지 않았다는 것입니다. 필터링, 응답을 다른 곳으로 보내는 경로, 도달할 수 없는 응답자, 제안을 싫어하는 응답자 모두 같은 빈 결과를 내며, 일반적인 UDP 탐침으로는 구분되지 않습니다.

ICMP 도달 불가는 다른 종류의 증거입니다. 그 안에 인용된 패킷을 읽고 어느 장비가 보냈는지 확인하세요. 라우터의 관리적 거부는 원격 측의 인증된 오류가 아닙니다.

tshark -r ike.pcapng -Y "icmp.type == 3" -T fields -e frame.number -e ip.src -e icmp.code

읽을 수 있는 범위에서 같은 시도를 서버 측 로그와 대조하세요. 요청이 도착했는지, 서비스가 응답했는지, 응답이 어디서 멈췄는지. 이 세 가지 답이 경로 문제인지 정책 문제인지를 알려 주며, 자격 증명을 네 번째로 교체하는 것보다 비용이 적습니다.