IKEv2는 UDP 500과 4500 중 어느 포트로 데이터를 보낼까?

방화벽에서 UDP 500을 열면 터널이 협상을 시작하지만, 그 뒤로 연결이 트래픽을 전달하지 못합니다. 포트 목록은 틀린 것이 아니라 불완전했습니다. IKEv2는 한 소켓에서 시작해 많은 실제 배포에서 다른 소켓으로 이어지며, 페이로드는 포트조차 아닐 수 있습니다. 단계를 순서대로 읽으면 어떤 규칙이 빠졌는지 알 수 있습니다.

두 포트, 두 가지 역할

IKEv2는 UDP 500에서 키 교환으로 시작하며, 여기서 양측이 인증하고 터널을 위한 보안 연관을 수립합니다. 그다음의 데이터 경로는 별개 문제입니다. 포트가 아니라 IP 프로토콜 번호인 네이티브 ESP이거나, 4500에서 UDP로 캡슐화된 트래픽일 수 있습니다. 방화벽 검토에서 이 둘을 구분하는 것이 협상되는 터널과 실제로 동작하는 터널의 차이이며, 한 소켓은 제어를, 다른 소켓은 페이로드를 나릅니다.

그래서 500만 허용하는 규칙은 협상은 성공하는데 유용한 것이 아무것도 이어지지 않는, 프로토콜 계열 전체에서 가장 혼란스러운 증상을 만듭니다. 상태에는 피어가 보이고 로그에는 설정된 IKE SA가 보이는데도 애플리케이션은 계속 시간 초과가 납니다. 빠진 권한은 방금 성공한 흐름과 다른 흐름에 속합니다.

4500은 왜 존재하는가

많은 NAT 장비가 TCP나 UDP 이외의 프로토콜을 전달하지 못하고, 일부는 ESP의 무결성 검사를 깨뜨리는 방식으로 주소를 다시 씁니다. ESP를 UDP 안에 캡슐화하면 두 문제가 모두 해결되지만, 추가 헤더와 허용해야 할 두 번째 포트가 필요합니다. 바로 이 캡슐화가 두 번째 포트가 존재하는 이유입니다.

NAT가 감지되면 IKE 자체도 4500으로 옮겨가 모든 트래픽이 변환기를 거치는 한 경로를 공유합니다. ESP가 아닌 네 바이트 표식이 그 소켓에서 제어 메시지와 데이터를 구분합니다. 이 전환은 프로토콜의 결정이지 관리자의 선호가 아닙니다.

소스 포트가 바뀌는 곳

변환기가 클라이언트의 소스 포트를 다시 쓸 수 있으므로 서버에서 보이는 튜플이 클라이언트의 튜플과 일치하지 않습니다. 규칙이 무시된다고 결론 내리기 전에 모든 NAT 홉의 양쪽을 보세요. 클라이언트에서만 문제를 찾으면 올바르게 보이면서도 실패하는 규칙을 만들 수 있습니다.

MOBIKE를 지원하는 구현은 NAT가 감지되지 않아도 4500으로 옮겨갈 수 있고, 일부 배포는 그 경로를 의도적으로 강제합니다. 따라서 4500이 보인다는 것은 결정의 증거이지 가정용 공유기의 증거가 아닙니다.

모든 경계에서 두 흐름을 확인하세요

클라이언트 네트워크, 중간 방화벽, 그리고 서버라는 세 경계를 살펴보세요. 각 지점에는 배포가 문서화한 흐름이 필요하며, 다른 사례에 관한 글의 흐름이 아닙니다.

sudo swanctl --list-sas
sudo tcpdump -ni any 'udp port 500 or udp port 4500'
sudo iptables -S | grep -E '500|4500|esp'
ip xfrm state

방화벽 목록의 ESP 줄은 프로토콜 일치이므로 포트 규칙이 그것을 절대 덮지 못합니다. 클라이언트가 익숙한 번호를 골라 서버에 리스너를 만들 수는 없으므로, 운영자가 사용자 지정 포트를 쓴다면 양쪽 끝에서 문서화된 구성을 따르세요.

협상이 어디서 멈췄는지, 자식 보안 연관이 설치되었는지 기록하세요. 이 짝이 차단된 경로와 인증 또는 정책 오류를 구분합니다. 그다음 도달 가능성은 인증이 아니므로 서버 검증을 켜고 테스트를 반복해 허용된 포트와 신뢰할 수 있는 피어를 구분하세요.