iPhone VPN의 Remote ID: 이 필드가 실제로 뜻하는 것
Remote ID는 서버가 iPhone에 증명해야 하는 신원이고, Local ID는 클라이언트가 주장하는 신원입니다. 어느 문자열이 어느 필드에 들어가는지 정리합니다.
설정에서 IKEv2 구성을 추가하고 있는데, 두 필드가 아무도 주지 않은 텍스트를 요구합니다. Remote ID와 Local ID입니다. 둘 다 사용자 이름이 아니고, 둘 다 Server 필드의 두 번째 사본도 아닙니다. Remote ID는 게이트웨이가 iPhone에 증명해야 하는 신원이고, Local ID는 iPhone이 게이트웨이에 주장하는 신원입니다. 둘 중 하나만 틀려도 서버가 이미 응답한 뒤에 터널이 끊깁니다. 그래서 이 실패는 비밀번호 문제처럼 보이지만 실제로는 그렇지 않습니다.
iOS에서 필드가 어디에 있는지
설정 > 일반 > VPN 및 기기 관리 > VPN을 열고 IKEv2 구성을 추가합니다. 인증 아래에서 사용자 이름이나 인증서를 고르면 그때서야 Remote ID와 Local ID가 자유 입력 상자로 나타납니다. 이들은 식별자이지 주소가 아닙니다. iOS는 이들을 IKE_AUTH 교환에서 나르며, 여기서 IKEv2는 개시자의 신원을 IDi, 응답자의 신원을 IDr이라고 부릅니다.
저장하면 iOS는 구성을 한 줄로 접고 더 이상 값을 보여주지 않습니다. 필드가 비었다고 결론내리기 전에 정보 버튼을 누르거나 프로파일을 다시 여십시오. MDM이 배포한 구성은 이들을 완전히 회색으로 만들 수 있으며, 그러면 누가 문제를 고칠 수 있는지가 달라집니다.
Remote ID는 게이트웨이의 이름
iPhone이 서버가 증명하기를 기대하는 값입니다. 인증서 인증에서는 서버 인증서의 이름과 비교되며, 보통 subject나 subjectAltName 항목입니다. 인증서가 vpn.example.com에 발급되었다면 그 호스트 이름이 Remote ID입니다. 맨 IP 주소로 장비에 접속하더라도 마찬가지입니다.
이 불일치가 전형적인 실패입니다. 패킷은 도착하고 서버도 응답하는데, 인증서의 신원이 프로파일이 요구한 값과 맞지 않아 연결이 무너집니다. Server 필드를 원시 IP로 돌리는 것은 도움이 되지 않으며, 많은 게이트웨이에서 서버는 맞출 수 없는 신원에 대한 응답을 그냥 멈춥니다.
게이트웨이에도 대응하는 설정이 있습니다. strongSwan 서버는 leftid로 자기 신원을 보내고 rightid로 클라이언트 신원을 제한할 수 있습니다. 양쪽이 문자열에 합의하지 못하면 IKE_AUTH는 양방향 모두 실패합니다. 브라우저 주소창에서 URL을 베끼는 대신 인증서가 어느 신원에 발급되었는지 운영자에게 물으십시오.
Apple은 페이로드 키를 RemoteIdentifier와 LocalIdentifier로 IKEv2 설정 참조에 문서화합니다. 둘 다 단순 문자열이므로 대소문자와 끝의 공백이 중요할 수 있습니다.
Local ID는 iPhone이 주장하는 것
사용자 이름 인증에서는 EAP가 이름과 비밀번호를 확인하고, Local ID는 일부 게이트웨이가 추가로 강제하는 별도의 IKE 신원입니다. 게이트웨이는 Local ID가 사용자 이름과 같거나, 이메일 주소이거나, 연결 정책의 항목과 일치하기를 요구할 수 있고, 무시하는 곳도 있습니다. 비워 두는 것이 안전한 것은 운영자가 그렇게 말할 때뿐입니다.
인증서 인증에서는 Local ID가 게이트웨이가 그 클라이언트 인증서에 대해 받아들이는 신원과 맞아야 하며, 흔히 인증서의 공통 이름이나 기기 기록에 매핑된 값입니다. 동료의 프로파일을 복사하면 그 사람의 신원도 복사됩니다. 최선의 경우 게이트웨이가 잘못된 기기를 기록하고, 최악의 경우 기기별 정책이 당신을 거부합니다.
함정은 비어 있음이 신원 없음을 뜻한다고 가정하는 것입니다. 미완성처럼 보인다는 이유로 빈 필드를 이메일 주소로 채우지 마십시오. 의도된 값을 확인하고 주어진 그대로 정확히 입력하십시오.
저장 전 오 분 점검
순서대로 진행하되, 처음 실패하는 단계를 고치십시오.
- 운영자에게서 서버 인증서의 이름, 예상 Local ID, 인증 방식 세 문자열을 받으십시오.
- 인증 방식을 맞추십시오. Remote ID와 Local ID는 사용자 이름과 비밀번호를 대신하지 않으며, 인증서 프로파일은 비밀번호를 받지 않습니다.
- 대소문자를 포함해 값을 정확히 입력하고 끝에 공백을 넣지 마십시오.
- 인증서 검증은 켜 둔 채로 두십시오. 경고를 잠재우려고 무관한 루트 인증서를 설치하면 이름 불일치를 고치는 대신 숨기게 됩니다.
- 캡티브 포털이나 분할 DNS가 신원 문제로 보이지 않도록 사무실 Wi-Fi가 아니라 모바일 데이터로 시험하십시오.
| Field | What belongs there | What a wrong value looks like |
|---|---|---|
| Remote ID | The DNS name in the gateway certificate | Server answers, then the tunnel drops with a certificate or identity error |
| Local ID | The identity the gateway policy expects for you | IKE_AUTH or user authentication fails after the server responds |
| Server | A reachable hostname or IP | Timeout with no identity exchange at all |
표를 위에서부터 읽으십시오. Server 행에서 시간 초과가 나면 신원 필드는 시험된 적이 없으므로 거기서 멈추십시오. 서버가 응답한 뒤에만 나타나는 오류는 거의 항상 Remote ID나 Local ID의 불일치입니다.
잘못된 필드를 가리키는 오류
"User authentication failed" 같은 메시지는 자격 증명이나 EAP에 관한 것이지 Remote ID가 아닙니다. 인증서 경고는 인증서의 이름에 관한 것이며, 바로 그 지점에서 Remote ID와 Server 필드가 만납니다. "The VPN server did not respond"는 보통 UDP 500과 4500이 끝나지 않았거나 NAT 통과가 실패해 신원이 전혀 비교되지 않았다는 뜻입니다.
게이트웨이 쪽에서 신원 실패는 다르게 보이며, IKE_AUTH 중에 피어가 거부되거나, 로그가 클라이언트가 보낸 ID를 지목하며 어떤 연결과도 일치하지 않는다고 말합니다. 그 로그 줄이 논쟁을 끝내는 가장 빠른 방법입니다. 전화기가 보낸 정확한 문자열을 보여주기 때문입니다.
비밀번호를 재설정해도 예상된 서버 신원은 고쳐지지 않고, Remote ID를 바꿔도 잘못된 비밀번호는 고쳐지지 않습니다. 먼저 단계를 분리하고, 그 단계에 속한 필드를 편집하십시오.
프로파일이 관리되는 경우
필드가 회색이면 구성이 MDM에서 온 것이며, 전화기는 고칠 장소가 아닙니다. VPN 페이로드가 식별자를 나르므로 올바른 변경은 관리 서버의 프로파일에 있고, 그다음 기기에 다시 설치해야 합니다.
설정 > 일반 > VPN 및 기기 관리에서 프로파일이 관리되는지, 누가 서명했는지 확인하십시오. 제거할 수 없다면 식별자를 로컬에서 편집할 수 없고, 두 번째 로컬 프로파일을 만들면 충돌하는 구성만 생깁니다.
설정을 닫기 전에 입력한 세 문자열과 그 출처를 적어 두십시오. 다음에 터널이 실패하면 게이트웨이 로그가 받은 ID를 그 메모와 비교하십시오. 다르다면 보고 있는 것은 비밀번호가 아니라 필드입니다.