IPsec 제안에는 무엇이 들어갈까? IKE와 ESP 필드

IKE가 시작되고 양쪽 피어가 AES를 알리는데도 터널은 NO_PROPOSAL_CHOSEN으로 실패합니다. 로그는 제안의 이름을 알려 주지만 일치하지 않은 필드는 알려 주지 않습니다. 제안은 하나의 완전한 오퍼이며, 호환되지 않는 필드 하나가 그 줄만이 아니라 전체 조합을 무효로 만듭니다. 이를 독립적인 알고리즘 선택의 자루로 읽는 것이 불일치가 보이지 않게 남는 흔한 이유입니다.

별도의 제안 목록을 가진 두 협상

IKEv2는 두 개의 보안 연결을 만듭니다. 첫째는 제어 교환 자체를 보호하는 IKE SA이고, 둘째는 ESP를 통해 트래픽을 운반하는 CHILD SA입니다. 각각 고유한 제안 목록이 있으며, 한 피어가 하나를 수락하고 다른 하나를 거부할 수 있습니다.

이 분리는 흔한 혼란을 설명합니다. 동작하는 IKE SA는 제어 채널의 알고리즘이 일치했다는 것만 증명하며, CHILD 제안이 실패하면 첫 단계가 끝나고 로그 상단이 정상으로 보여도 터널은 패킷을 하나도 운반하지 않습니다.

각 목록 안의 순서도 중요합니다. 응답자는 개시자의 정렬된 오퍼에서 고르므로, 폭넓게 호환되는 항목을 좁은 항목보다 위로 옮기면 알고리즘 이름을 하나도 바꾸지 않고도 설치되는 스위트가 달라집니다. 기본값에 의존하지 말고 그 순서를 구성에 고정하십시오. 안정된 순서는 사이트 간 로그 비교도 의미 있게 만듭니다.

어떤 필드가 어떤 제안에 속하는가

필드 집합은 작지만 두 협상에서 동일하지는 않습니다. 한 열에 있는 필드가 다른 열에는 없을 수 있으므로 표를 행 단위로 읽되, 구문은 구현마다 다릅니다. strongSwan의 제안 문서가 하나의 구체적인 참고 자료입니다.

암호화 필드는 암호를, 대부분의 구문에서는 키 길이도 지정합니다. 무결성 필드는 암호문을 인증하는 데 쓰는 해시를 지정하고, PRF는 IKE SA의 키 자료를 도출하는 함수를 지정합니다. DH 그룹은 새로운 공유 비밀 자료를 설정하며, 그래서 양측에 나타나지만 목적은 다릅니다.

확장 시퀀스 번호는 데이터 경로에만 속합니다. 시퀀스 공간을 넓히고 CHILD 제안의 일부로 협상되므로, 그곳의 불일치는 CHILD 오퍼를 거부하면서 IKE SA는 그대로 둡니다.

하나의 완전한 오퍼가 선택되는 방식

각 제안은 집합이며, 응답자는 모든 필수 필드가 허용되는 집합을 찾습니다. 두 목록이 모두 AES와 SHA-256을 포함해도 키 길이, PRF 또는 DH 그룹이 달라 호환되는 항목이 없을 수 있습니다. 비교는 알고리즘이 아니라 제안 단위로 이루어집니다.

아무것도 맞지 않으면 응답자는 실패한 SA 유형과 함께 NO_PROPOSAL_CHOSEN을 보냅니다. 구성을 편집하기 전에 알림이 어느 제안 목록을 가리키는지 읽고, IKE 제안이 거부되었는데 ESP 알고리즘을 바꾸는 것은 디버깅 한 주기를 낭비합니다.

프로파일을 조정할 때 선택 동작을 알아 둘 가치가 있습니다. 일부 구현은 개시자의 순서를 선호하고 다른 구현은 로컬 정책에 따라 다시 정렬하므로, 두 벤더 사이에서 동작하던 스위트가 연결을 시작하는 쪽을 뒤집으면 사라질 수 있습니다.

AEAD는 필드를 추가하는 것이 아니라 제거합니다

AES-GCM과 ChaCha20-Poly1305는 한 번의 연산으로 인증과 암호화를 수행합니다. 둘 중 하나가 ESP용으로 선택되면 AEAD 구성이 이미 그것을 포함하므로 무결성 알고리즘은 별도로 협상되지 않습니다. 따라서 AES-GCM을 SHA-256과 짝지은 제안은 기껏해야 중복이고 최악의 경우 거부됩니다.

PRF는 IKE 측에서 여전히 별개입니다. 페이로드를 보호하는 것이 아니라 제어 채널의 키를 도출하기 때문이며, 그래서 IKE 제안은 AEAD 암호와 PRF, DH 그룹을 정당하게 조합할 수 있지만, 대응하는 ESP 제안은 AEAD 암호와 선택적 PFS 그룹만 나열합니다.

키 길이는 암호화 토큰의 일부이므로 AES-128-GCM과 AES-256-GCM은 서로 다른 오퍼입니다. 256-bit 키를 가정한 가이드에서 복사한 프로파일은 두 줄 모두 AES-GCM이라고 해도 128-bit용으로 구성된 엔드포인트와 일치하지 않습니다. 두 피어는 암호 계열에 합의하고도 하이픈 뒤의 숫자 때문에 서로를 거부할 수 있습니다.

구성이 아니라 설치된 SA를 읽으십시오

구성된 제안 목록은 오퍼이고 설치된 SA는 결과입니다. strongSwan과 Linux 커널에서는 두 보기가 모두 제공됩니다:

sudo swanctl --list-sas
sudo ip xfrm state
sudo ip xfrm policy

swanctl --list-sas SA별로 협상된 알고리즘을 출력하며 CHILD가 AEAD를 쓰는지도 포함합니다. ip xfrm state 커널이 실제로 무엇을 설치했는지 보여 줍니다, 그리고 키 갱신이 문서화한 것과 다른 스위트로 되돌아가지 않았는지 확인할 지점이 바로 여기입니다.

수정 후에는 그 출력을 구성 옆에 저장하십시오. 클라이언트 업데이트가 기본값을 바꾸면 기록된 스위트가 비교 기준선이 되고, 비교는 조사를 처음부터 다시 시작하는 대신 움직인 필드를 가리킵니다.