iPhone IKEv2에서 RouterOS로: 어떤 식별자가 어디로 가는가
iOS의 IKEv2 터널은 네 가지 별개의 주장으로 결정됩니다. 다이얼하는 주소, 기대하는 서버 신원, 주장하는 클라이언트 신원, 그리고 인증서 자료입니다.
MikroTik 게이트웨이에 도달하는 것은 IKEv2 배포의 전송 절반만 해결할 뿐 그 이상은 아닙니다. 그다음 네 가지 별개의 주장이 터널이 형성되는지를 결정합니다. 전화기가 다이얼하는 주소, 기대하는 서버 신원, 자신이 주장하는 신원, 그리고 그 주장을 뒷받침하는 인증서 자료입니다. 이 순서대로 확인하고 게이트웨이가 제시하는 것과 일치하지 않는 첫 항목에서 멈추십시오. 각 항목은 서로 다른 곳에서 편집되므로 잘못된 편집은 보통 고장을 고치기보다 옮깁니다.
| Setting | What it decides | What it has to agree with |
|---|---|---|
| Remote address | where IKE packets are sent | a reachable name or address for the gateway |
| Remote Identifier | which server identity is expected | the gateway certificate name and the peer identity RouterOS presents |
| Local Identifier | who the phone claims to be | the client certificate name and the RouterOS identity entry |
| Certificate payload | trust plus proof of key possession | the issuing chain and a usable client private key |
프로필 필드를 교환이 사용하는 순서대로 확인하십시오
원격 주소는 첫 IKE 패킷의 목적지일 뿐 그 이상이 아닙니다. 원격 식별자는 전화기가 게이트웨이가 자신임을 증명하기를 기대하는 대상이며, 경로가 아니라 이름입니다. 둘 다 같은 호스트 이름으로 채우는 것은 게이트웨이 인증서가 그 이름을 담고 있을 때 작동하며, 담고 있지 않을 때는 라우팅 문제처럼 보이는 방식으로 실패합니다. 프로필은 채워 넣을 필드 목록이 아니라 주장의 연속으로 읽으십시오.
로컬 식별자는 전화기 자신의 주장이며, 전화기가 제시하는 클라이언트 인증서에 대해 RouterOS 신원 항목이 받아들이는 이름이어야 합니다. 둘이 일치하지 않으면 게이트웨이는 인증서 자체가 검증된 뒤에 연결을 거부하고, 로그는 이름 지정이 아니라 권한 부여 문제처럼 보입니다.
식별자를 게이트웨이가 제시하는 내용과 대조하십시오
인증서 인증용으로 구성된 RouterOS 피어 항목은 자체 인증서를 제시하며, 달리 구성하지 않았다면 그 신원은 그 인증서에서 나옵니다. 전화기의 원격 식별자가 게이트웨이의 DNS 이름을 지정하면, 게이트웨이 인증서에는 그 이름이 전화기가 받아들일 위치, 보통 주체 대체 이름에 있어야 합니다. 다른 일반 이름으로 발급된 인증서는 키와 체인이 완벽해도 검증되지 않습니다.
관리형 Apple 프로필은 식별자 필드에 더해 평가되는 인증서 이름 제약을 함께 담을 수 있습니다. 설정 화면이 보여 주는 것에서 검증 이름을 추론하지 말고 페이로드를 확인하십시오. 둘은 같은 설정이 아닙니다.
클라이언트 인증서가 신뢰 앵커만이 아니라 키인지 확인하십시오
CA 인증서를 가져오면 전화기는 게이트웨이를 검증할 수단을 얻습니다. 그러나 클라이언트 신원을 얻지는 못하며, 인증서 인증에는 클라이언트 리프 인증서와 그 개인 키를 승인된 등록 경로로 함께 전달해야 합니다. 개인 키 없이 만든 PKCS#12는 깔끔하게 설치되지만 아무것도 인증하지 못하는 프로필을 만듭니다.
클라이언트 리프에는 RouterOS 측이 기대하는 신원도 필요합니다. 즉 주체 또는 주체 대체 이름이 해당 신원 구성과 맞아야 합니다. 하나의 CA에서 클라이언트와 서버 인증서를 발급하면 체인은 편리해지지만 두 리프가 서로 바꿔 쓸 수 있게 되지는 않습니다.
RouterOS 정책이 그 이름을 받아들이는지 확인하십시오
게이트웨이에서 피어 항목은 교환 모드와 인증 방법을 정하고, 신원 항목은 받아들인 원격 신원을 인증서와 그 뒤의 정책에 묶습니다. RouterOS v7에서는 이 짝이 IPsec 피어 및 신원 항목으로 표현되며, 예를 들어 auth-method=digital-signature이 있는 IKEv2 피어입니다. 이전 버전을 위해 쓰인 안내서가 아니라 설치된 릴리스의 실제 메뉴 내용을 확인하십시오.
여기서 불일치를 고치는 비용이 가장 적습니다. 게이트웨이는 받은 신원과 원했던 신원을 모두 알려 줄 수 있기 때문입니다. 오류를 잠재우려고 받아들이는 신원을 넓히면 배포를 의미 있게 만든 결속이 사라집니다.
무엇이든 편집하기 전에 어느 단계가 실패했는지 확인하십시오
양쪽 끝에서 시도를 읽고 제안을 바꾸기 전에 분류하십시오. 제안 불일치, 서명 키 누락, 신뢰할 수 없는 발급자, 잘못된 피어 식별자, 거부된 클라이언트 권한 부여는 모두 전화기 쪽에서 죽은 터널처럼 보이며 각각 담당이 다릅니다. 다섯 설정을 한꺼번에 바꾸면 결과에서 아무것도 배우지 못한다는 것이 보장됩니다.
제시된 신원, 기대한 신원, 인증서 발급자와 일련번호, 관련 정책 이름을 기록하고 개인 키와 프로필 비밀은 그 기록 밖에 두십시오. 인증이 성공하면 개인 서비스와 그 응답을 시험하십시오. IKE 교환이 끝난 뒤에도 주소 할당, 셀렉터, DNS, 접근 정책은 여전히 작동해야 하기 때문입니다.