IKEv2 NO_PROPOSAL_CHOSEN: 어느 단계에서 스위트가 거부되었나?

로그에서 NO_PROPOSAL_CHOSEN을 보면 사람들은 미리 공유한 키로 몰려가지만, 키를 바꾼 뒤에도 오류는 남습니다. 이것은 결코 자격 증명의 문제가 아니었습니다: 피어는 그 교환을 위해 제안된 모든 제안을 거부했으며, 이는 신원이 아니라 알고리즘에 대한 진술입니다. 첫 번째 유용한 질문은 어떤 알고리즘을 편집할지가 아니라 어떤 교환이 거부되었는지입니다. 무엇이든 비교하기 전에 그 답을 하십시오. 그런 다음 제안된 전체 스위트를 피어가 허용하는 전체 스위트와 비교하십시오.

먼저: 어떤 교환이 거부되었는가

IKEv2는 두 종류의 연관을 협상합니다. IKE SA는 협상 자체를 보호하고, CHILD SA는 트래픽을 보호합니다. 각각 고유한 제안 집합이 있고, 각각 같은 알림으로 실패할 수 있습니다. 초기 IKE 협상 중 거부와 CHILD 협상 중 거부는 서로 다른 수정이 필요하며, 로그는 보통 알림 한두 줄 위에서 교환의 이름을 밝힙니다. 그 두 줄을 함께 읽지 않으면 잘못된 제안 목록을 편집하게 됩니다.

알림만으로는 교환을 식별하지 못합니다. 그 위의 줄이 협상 중인 SA의 이름을 밝히고, 그 이름이 점검해야 할 제안 목록을 가리킵니다.

단일 키워드가 아니라 전체 스위트를 비교하십시오

제안은 조합입니다: 암호화 알고리즘, 무결성 또는 AEAD, 키 교환 그룹, 그리고 임의의 의사 난수 함수입니다. 암호화 이름만 비교하는 것이 흔한 실수인데, 두 피어가 AES-256에 합의하고도 SHA-1과 SHA-256에서는 의견이 다를 수 있기 때문입니다. 실패한 단계에서 제안된 스위트와 허용된 스위트를 나란히 적고, 그다음 빈 교집합을 찾으십시오.

offered:   aes256-sha256-modp2048
permitted: aes256-sha1-modp2048

두 구현 모두 구성한 내용을 지원하는지도 확인하십시오. 다른 플랫폼에서 복사한 이름은 구문상 익숙해 보일 수 있습니다 반면 플러그인이나 구현이 완전히 없습니다.

IKE 스위트와 ESP 스위트는 다른 객체입니다

IKE 제안을 편집해도 거부된 CHILD 제안은 고쳐지지 않으며, 그 반대도 마찬가지입니다. strongSwan에서는 이것이 별도 설정으로, 대략 IKE SA에는 proposals = aes256-sha256-modp2048이고 CHILD SA에는 별도의 ESP 목록입니다. 실패한 교환에 맞는 목록을 바꾸고, 수정이 효과가 있었다고 가정하지 말고 로그를 다시 읽으십시오.

CHILD SA의 경우 관련 설정은 ESP 제안 목록이며 IKE 목록이 아닙니다. 여기에 IKE 줄을 복사하면 구문 분석은 되지만 잘못된 객체를 협상하는 구성이 됩니다.

작동하던 터널이 키 갱신에서 실패하는 경우

터널이 한 시간 동안 작동한 뒤 실패했다면 초기 협상이 문제가 아닙니다. 키 갱신은 다른 조건을 시험할 수 있습니다: 첫 교환 후 다른 키 교환 그룹, 피어 간 수명 불일치, 또는 변경된 응답자 정책입니다. 갱신 타임스탬프와 양쪽의 연관 식별자를 보관하십시오. 그 패턴에는 갱신 시 제안 비교가 필요하며 더 긴 타임아웃이 아닙니다. 타임아웃 변경은 증상을 숨기고 불일치를 그대로 남깁니다.

ipsec statusall 각 연관과 실제로 협상된 알고리즘을 보여 줍니다. 그 출력은 어떤 목록이 사용되었는지 확인하는 가장 빠른 방법이며, 구성 오류와 다시 협상되지 않은 오래된 터널을 구분합니다.

ipsec statusall | grep -E "IKE:|ESP:"

교집합을 고르고, 그다음 두 단계를 확인하십시오

관리자가 두 피어 모두 지원하는 문서화된 현대적 교집합을 고르고 기록하게 하십시오. 모든 레거시 알고리즘을 활성화하거나 신원 검증을 비활성화하여 오류를 해결하지 마십시오, 둘 다 거부에서 나오는 결론이 아니기 때문입니다. 변경 후 새 연결을 설정하고 그다음 키 갱신을 강제하십시오. 첫 연결만으로는 갱신 경로가 작동한다는 것이 증명되지 않습니다.

수용된 조합을 펌웨어 버전과 함께 보관하십시오. 다음 오류가 트래픽 선택자에 관한 것이라면 별도로 다루십시오, 암호화에 대한 합의는 터널이 어떤 서브넷을 보호하는지에 대해 아무것도 말하지 않기 때문입니다. strongSwan의 제안 문서 는 두 목록의 구문을 다룹니다.