인증서가 신뢰할 수 있는 CA에 연결되어 있고 날짜도 정상인데, 피어는 식별 정보 오류와 함께 1단계 완료를 계속 거부합니다. 도달 가능성과 유효한 서명은 IKEv2 클라이언트가 확인하는 것의 절반에 불과합니다. 나머지 절반은 기대하는 식별 정보가 인증서의 올바른 필드에 나타나는지 여부이며, 그 기대치는 인증서 파일 이름이 아니라 프로필이 설정합니다.

증상은 항상 같은 모양입니다

연결 프로필이 호스트 이름에서 IP 주소로 바뀌거나, DNS 이름을 담던 인증서에서 주소만 담은 인증서로 갱신되면,터널이 협상을 멈춥니다. 네트워크 경로에서는 아무것도 바뀌지 않았습니다. 클라이언트는 피어에 도달하고 인증서를 받은 뒤, 기대하라고 들은 식별자가 자신이 받아들이는 필드에 표현되지 않았기 때문에 피어 식별 정보를 거부합니다. 교체 인증서가 교체 대상과 다른 템플릿에서 오는 경우가 많아 갱신이 흔한 계기입니다.

그러면 양쪽 모두 쓸모없는 로그를 남기므로, 장애는 보통 인증서 문제로 보고됩니다. 클라이언트 로그에 원하던 식별 정보가 적혀 있을 수 있으며, 그 이름이 바로 원하는 단서이고 만료 날짜가 아닙니다.

식별자 유형을 맞추세요, 값만이 아니라

dNSName SAN과 iPAddress SAN은 일치 규칙이 다른 서로 다른 필드이므로, 203.0.113.10을 DNS 문자열로 담은 인증서는 IP 식별 정보를 기대하는 클라이언트를 만족시키지 못합니다. 최신 검증기는 일반 이름을 대부분 무시하므로 인증서 세부 정보의 친숙한 레이블은 무엇이 일치할지 증명하지 못합니다. 문제 해결 중에 호스트 이름을 주소로 바꿨다면 확인할 때까지 기대하는 식별 정보도 함께 옮겨졌다고 가정하세요. 프로필의 문자열과 SAN의 문자열은 끝의 점이나 불필요한 공백만으로도 어긋나므로 글자 하나씩 비교하세요.

와일드카드는 DNS 전용 편의 기능이며 자체 일치 규칙을 따르므로, IP 기반 프로필이 절대 그것에 의존해서는 안 되는 또 하나의 이유입니다.

각 클라이언트가 기대치를 어디에 저장하는지 찾으세요

strongSwan에서 인증서와 비교되는 값은 피어 ID 설정에서 나옵니다: rightid 기존 구성에서는, 또는 id swanctl의 원격 연결 섹션의 id입니다. Apple IKEv2 상호 운용성에 관한 이 문서는 프로필 기반 클라이언트가 사용하는 식별 정보 관례를 설명하므로 여기서 유용하며, 그 관례는 네트워크상에서 무작위로 보이는 불일치 유형을 설명합니다.

Apple 구성 프로필에는 원격 식별자 필드가 있으며, 클라이언트는 연결 설정의 서버 주소가 아니라 그 값을 확인합니다. Windows와 어플라이언스 클라이언트는 각자 고유한 필드와 기본값을 가지며, 기본값은 흔히 입력한 주소를 따릅니다. 두 필드가 어긋나면 클라이언트가 실제로 읽는 쪽이 이기며, 그것이 편집한 쪽인 경우는 드뭅니다.

프로필이나 인증서를 의도적으로 고치세요

무엇이든 바꾸기 전에 승인된 도구로 피어 인증서를 검사하고 SAN 항목을 유형과 함께 나열하세요. 그 검사에는 개인 키도 업로드도 필요 없으며, 문제를 몇 초 만에 정리합니다. 배포가 하나의 DNS 식별 정보를 의도한다면 인증서는 그것을 dNSName 항목으로 담아야 하고, 배포가 주소를 의도한다면 인증서에는 정확히 그 주소에 대한 iPAddress 항목이 필요합니다.

인증서가 잘못되었으면 운영자에게 구체적인 기대 식별자를 알려 주고 수정된 인증서를 요청하세요. 프로필이 잘못되었으면 프로필을 고치고 인증서는 그대로 두세요. 식별 정보 검증을 끄면 오류는 사라지지만, 터널이 의도한 피어와 통신하고 있다는 검사도 사라집니다.

한 클라이언트가 자동으로 도출하는 값이 다른 클라이언트에서는 명시적으로 필요할 수 있으므로, 클라이언트 플랫폼별로 기대하는 식별 정보를 문서화하세요.

갱신 요청에 네 가지 사실을 담으세요

기대하는 식별자와 그 유형, 현재 인증서가 실제로 가진 SAN 항목, 검사를 수행하는 클라이언트와 버전, 정확한 오류 텍스트를 적으세요. 이 네 줄로 만든 갱신 요청은 똑같이 익숙한 파일 이름의 또 다른 인증서 대신 처음부터 올바른 인증서를 받습니다.

관련 글