Android에서 비표준 UDP 포트로 IKEv2가 실패하는 이유

기본 IKEv2 양식은 포트가 아니라 주소를 받습니다. 클라이언트가 이를 지원하는지 확인하고 서버의 두 포트를 모두 설정한 뒤 프레이밍과 로그를 확인하세요.

게이트웨이가 UDP 4443에서 IKEv2에 응답하는 데는 이유가 있고, 프로필에는 Server라는 필드가 있으며, 호스트 이름과 포트를 입력하면 휴대폰은 서버에 도달할 수 없거나 주소를 확인할 수 없다고 보고합니다. 아무것도 차단되고 있지 않습니다. Android의 기본 양식은 호스트를 기대하며 Windows에서도 마찬가지입니다. 사용자 지정 포트는 서버 설정이 되기 전에 클라이언트의 기능이며, 일부 클라이언트만이 이를 표현할 수 있게 합니다. 세 부분을 순서대로 살펴보세요: 클라이언트가 무엇을 말할 수 있는지, 서버가 무엇을 수신하는지, 양쪽 끝이 같은 방식으로 패킷을 프레이밍하는지입니다.

휴대폰이 실제로 보낸 것

이름을 위해 만들어진 필드의 host:port 문자열은 이름으로 확인됩니다. 확인자는 vpn.example.net:4443 에 대해 아무것도 반환하지 않으며, 보이는 오류는 포트의 시간 초과가 아니라 이름 확인 실패 또는 도달 불가입니다. 더 짧은 이름이나 다른 네트워크로 다시 시도해도 양식이 구문 분석할 수 없는 문자열은 결코 고쳐지지 않으므로 이 차이는 중요합니다.

Android의 기본 IKEv2 프로필은 Windows의 내장 VPN 클라이언트와 마찬가지로 표준 IKE 포트에 고정되어 있습니다. 둘 다 포트 필드를 표시하지 않으며 프로필을 편집해도 추가되지 않습니다. 운영자의 수신기가 정말 4443에 있다면 내장 클라이언트는 잘못 구성된 것이 아니라 잘못된 도구입니다.

포트를 노출하는 클라이언트를 사용하세요

strongSwan의 Android 클라이언트는 고급 프로필 설정에서 구성 가능한 서버 포트를 문서화하며, 그래서 이 설계에 대해 작동하는 거의 모든 방법에 등장합니다. 그 지원은 해당 클라이언트의 것이며, 다른 IKEv2 앱이나 같은 앱의 공급업체 포크는 기반 strongSwan 데몬이 지원하더라도 같은 필드를 노출하지 않을 수 있습니다.

운영자에게 전체 세트를 한 번에 요청하세요: 게이트웨이 이름, UDP 포트, 인증 방법, 그리고 클라이언트가 기대해야 하는 서버 ID입니다. 사용자 지정 포트는 인증서 검사를 끄거나 프로토콜을 바꿀 이유가 아닙니다. 설치된 클라이언트가 포트를 기대하는 곳에 입력하고, 그 클라이언트에 그런 필드가 없다면 답은 추측한 우회가 아니라 다른 승인된 클라이언트입니다.

서버에는 두 개의 포트가 있고 둘 다 일치해야 합니다

IKE는 UDP 500에서 시작하고, NAT 통과는 보통 IKE와 캡슐화된 ESP를 UDP 4500으로 옮깁니다. strongSwan에서는 별도의 설정이므로 단일 사용자 지정 포트로 옮긴 서버는 둘 다 같은 값으로 바꿔야 합니다:

plugins {
  socket-default {
    port = 4443
    port_nat_t = 4443
  }
}

하나의 포트가 두 역할을 모두 맡으면 데몬은 같은 소켓에서 IKE와 ESP-in-UDP를 구분해야 하며, IKE 메시지 앞에 오는 네 바이트 비 ESP 마커로 이를 수행합니다. 그래서 클라이언트가 사용자 지정 포트에서 협상한 뒤 조용히 4500으로 계속할 수 없고, “포트만 바꾸면 된다”는 표현이 프레이밍 요구 사항을 숨기는 이유입니다.

전달은 수신기가 아닙니다

4443을 일반 IKE 수신기로 전달하는 것은 거의 성공한 것처럼 보이는 실패 모드입니다. 첫 교환이 도착하고 서버가 응답한 뒤 연결이 멈추거나 키를 아무것도 아닌 상태로 재생성하는데, 이는 응답이 다른 포트에서 나가고 이후 캡슐화된 트래픽이 양쪽 끝이 만든 상태와 결코 일치하지 않기 때문입니다. 수신기를 옮기지 않고 대상 포트를 다시 쓰는 규칙은 정확히 이 반쯤 열린 결과를 만듭니다.

경로는 UDP도 끝에서 끝까지 허용해야 합니다. TCP 443이 호텔이나 통신사 네트워크를 통과한다는 것은 같은 번호라 해도 UDP 포트의 IKEv2에 대해 아무 말도 하지 않습니다. TCP 443만 허용되는 곳에서 사용자 지정 UDP 포트는 IKEv2를 HTTPS로 만들지 않으며, 정답은 또 다른 포트 실험이 아니라 다른 접속 경로일 수 있습니다.

테스트할 때 세 단계를 분리하세요

클라이언트가 한 번 시도하는 동안 서버에서 캡처하세요. 결코 도착하지 않는 요청은 엔드포인트나 방화벽의 문제이고, 응답 없이 도착하는 요청은 수신기나 정책의 문제이며, 응답 뒤에 침묵이 이어지는 것은 프레이밍이나 ID의 문제입니다.

tcpdump -ni eth0 -vv udp port 4443

그다음 클라이언트의 회전 표시가 아니라 메시지를 읽으세요. 제안 오류는 알고리즘이 일치하지 않음을 뜻하고, 인증 실패는 ID나 인증서가 일치하지 않음을 뜻하며, 응답 없는 재전송이 반복되면 그 포트에서 아무것도 응답하지 않는다는 뜻입니다. 한 번에 한 단계씩 테스트하고 시도 사이에 필드 하나만 바꾸며, NAT 통과에 관한 strongSwan 문서가 캡처가 보여 주는 마커와 포트 동작을 설명합니다.

관련 글