IKE ID와 엔드포인트 주소: 둘을 혼동하지 마십시오

FQDN ID로 표시된 필드는 공인 주소의 역방향 DNS 이름을 요청하는 것이 아니라 문자열 그대로 읽어야 합니다. strongSwan 파서에서 그것은 정확히 문자열이며, 읽는다고 해서 엔드포인트로 확인되는 일은 없습니다. 이 사실만으로도 피어의 식별자를 고를 때 가장 흔한 혼란이 사라집니다. 아래 점검들은 관련된 세 값이 하나로 뭉치지 않게 합니다.

레이블은 조회가 아닙니다

벤더 화면은 FQDN이나 hostname 같은 단어를 느슨하게 쓰며, 상자에 붙은 레이블은 그 뒤의 인코딩에 대해 아무것도 말하지 않습니다. 필드를 Client FQDN이라고 부르는 장비도 FQDN, 이메일 형태의 문자열, 또는 맨 주소를 보낼 수 있습니다. 텍스트와 형식을 두 개의 별도 결정으로 다루고 둘 다 기록하십시오.

문자열로서의 ID에는 DNS가 필요하지 않습니다. 상대편이 확인하는 주장일 뿐, 네트워크가 풀어야 할 이름이 아닙니다.

세 값은 따로 적습니다

하나의 설정 화면 뒤에는 세 가지 역할이 있고, 그것을 합치는 것이 값비싼 실수입니다. 하나는 패킷이 어디로 갈지 결정하는 엔드포인트 주소입니다. 다른 하나는 이 피어가 제시하는 로컬 ID이고, 세 번째는 인증하기 전에 원격에서 기대하는 ID입니다. 변경 티켓에 세 줄로 적으면 충분하며, 그보다 적으면 관계가 아니라 VPN을 설명하게 됩니다.

예시 ID는 배포의 일부로 선택하고 승인해야 합니다. 그것들은 인증이 검증하는 주장이며 어떤 피어든 신뢰할 수 있게 만드는 자격 증명이 아니므로, 그럴듯해 보이는 문자열은 아무것도 승인하지 않습니다.

형식은 값의 일부입니다

strongSwan ID 참조 는 FQDN, 이메일 형태 값, IP 주소 및 기타 인코딩을 구분하므로 인코딩은 문자만큼 중요합니다. 두 장비가 같은 텍스트를 서로 다른 형식으로 받아들이고도 서로를 거부할 수 있습니다. 형식 없이 값을 기록한 메모는 절반의 설정입니다.

장비가 실제로 어떤 형식을 보내는지 벤더에 물어보고, 화면 레이블이 아니라 디코드 결과로 확인하십시오. 추측한 형식은 다음 변경을 기다리는 불일치입니다.

각 측이 상대를 만족해야 합니다

각 측의 로컬 ID는 상대 측의 인증 정책을 통과해야 합니다. 두 장비의 모든 ID 칸에 같은 문자열을 붙여 넣는 것과는 다르며, 그 지름길은 아무도 디버그할 수 없는 설정을 만듭니다.

인증서 인증은 인증서의 ID와 신뢰 조건이 입력한 IKE ID 옆에 나란히 놓이므로 자체 요구 사항을 더합니다. IKE ID 일치만으로는 인증서 피어를 승인하지 않습니다.

DNS가 중요한 곳과 버전이 강제하는 것

검색에 쓰는 게이트웨이 hostname에는 실제로 동작하는 DNS가 필요하며, 그 요구 사항은 입력한 ID의 역방향 조회가 아니라 엔드포인트를 찾는 일에 속합니다. 검색 실패와 ID 불일치는 클라이언트 로그에서 비슷하게 읽히고 고치는 위치도 다르므로 티켓에서 둘을 분리하십시오.

형식을 강제하는 구문을 복사하기 전에 실제로 실행하는 제품과 버전의 파서를 읽으십시오. 오래된 strongSwan 릴리스는 다르게 동작했고 다른 벤더는 자체 제약을 더하는데, 두 끝을 비교할 때는 기대 ID, 제시된 ID, 형식, 인증 오류 네 가지를 함께 붙드십시오. 그 묶음이 불일치를 의견이 아니라 증거로 바꿉니다.