Windows와 strongSwan 암호: 올바른 계층을 맞추십시오

양쪽 모두 AES-128이라고 말하는데 터널은 여전히 구축을 거부합니다. CBC와 GCM은 우연히 같은 키 길이를 공유하는 서로 다른 변환이며, 하나를 제시하는 클라이언트는 다른 하나만 받아들이는 게이트웨이를 만족시키지 못합니다. AES라는 단어는 제품군을 뜻하지 합의를 뜻하지 않습니다.

두 번째 축도 있으며, 혼란스러운 오류를 만들어내는 것은 바로 이 축입니다.

두 계층, 두 개의 독립적인 목록

IKE는 협상 자체를 보호하고, 자식 연결은 실제로 신경 쓰는 트래픽을 보호합니다. Windows는 전자를 암호화 방법과 무결성 방법으로, 후자를 암호 및 인증 변환 상수로 노출합니다. 이 필드들은 서로의 별칭이 아니며, 한쪽에서 유효한 값이 다른 쪽에서는 의미가 없거나 잘못될 수 있습니다. 이 분리를 염두에 두고 프로필을 읽으면 혼란의 대부분이 사라집니다.

실질적인 결과는 완전히 수용 가능한 키 교환 정책과 상대방이 받아들이지 않을 데이터 채널 정책을 동시에 가질 수 있다는 것입니다. 한 목록은 협상하고, 다른 목록은 패킷을 보호합니다. 구성 대화 상자에서 둘이 아무리 비슷해 보여도 첫 번째의 값을 바꾸면 두 번째에는 영향이 없습니다.

게이트웨이와 비교하기 전에 두 목록을 적어 두십시오. 기억에 의존한 비교는 한 필드를 두 번 편집하고 다른 필드는 한 번도 편집하지 않는 방식입니다. 프로필 옆에 게이트웨이 콘솔을 열어 두십시오.

제안 옆에서 오류를 읽으십시오

실패한 단계가 어느 목록을 살펴봐야 하는지 알려줍니다. 초기 키 교환 중 거부는 IKE 제안 문제입니다, 그리고 그것은 어떤 자식 연결도 존재하기 전에 발생합니다. 보호된 트래픽 연결을 협상하는 중의 실패는 ESP 제안 문제이며, 키 교환은 이미 성공했습니다. 클라이언트의 일반적인 정책 일치 메시지는 두 단계 중 어느 것도 지목하지 않으므로 게이트웨이 자체의 관점이 유용합니다.

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 60 --no-pager

수신한 제안, 구성된 제안, 선택된 제안을 비교하십시오 그 한 번의 시도에 대해. 여기서는 세 개의 서로 다른 목록이 중요하며, 실제로 사용된 것을 설명하는 것은 마지막 하나뿐입니다. 요약하지 말고 티켓에 그대로 인용하십시오.

CBC와 GCM을 별도의 대안으로 유지하십시오

어느 제품군이든 받아들이도록 의도적으로 허용된 게이트웨이에는 하나가 아니라 두 개의 제안이 필요합니다. strongSwan에서 쉼표는 대안을 구분하고, 하이픈은 단일 스위트의 구성 요소를 연결합니다. 두 제품군을 하이픈으로 결합하면 두 개의 수용 가능한 제안이 아니라 하나의 불가능한 제안이 만들어집니다.

proposals = aes128gcm16-prfsha256-ecp256, aes128-sha256-ecp256
esp_proposals = aes128gcm16-ecp256

첫 번째 대안은 인증된 암호화를 사용하며 여전히 의사 난수 함수를 지정합니다. 무결성이 암호에서 나오더라도 키 유도에는 하나가 필요하기 때문입니다. 두 번째 대안은 별도의 무결성 알고리즘을 사용하는 고전적 암호화입니다. 둘 다 로드된 암호 구현이 지원하는 것에 따라 달라집니다.

ESP 제안은 이름만 바꾼 IKE 제안이 아닙니다

암호 토큰은 두 목록에서 동일해 보이지만 그 외에는 거의 이어지지 않습니다. ESP 제안에는 키 교환 의사 난수 함수가 없으며, 무결성과 전방 비밀성 요구 사항은 IKE 줄에서 복사되는 대신 반대편의 Windows 정책에 맞서 논증됩니다. 한 목록을 다른 목록으로 기계적으로 번역하면 검증은 통과하지만 결코 협상하지 않는 것이 만들어집니다.

방향을 하나 선택하고 그대로 유지하십시오. 게이트웨이가 GCM 전용 정책을 유지하고 클라이언트가 완전한 호환 정책을 배포하거나, 게이트웨이가 두 제품군을 모두 받아들이고 클라이언트가 기존 스위트를 유지하는 것입니다. 보안 정책이 금지하는 폴백을 활성화하는 것은 오류를 아무리 빨리 없애도 해결책이 아닙니다.

두 스위트를 확인한 다음 키 재생성을 확인하십시오

선택된 키 교환 스위트와 선택된 트래픽 스위트를 별도로 확인하십시오. 서로 다른 목록에서 나오며 독립적으로 성공할 수 있기 때문입니다. 그런 다음 키 재생성이 일어나도록 하고 그것도 확인하십시오. 작동하는 첫 핸드셰이크와 실패하는 키 재생성은 부분적으로만 수용 가능한 제안 집합을 보여줍니다.

그 증거를 변경 사항과 함께 보관하십시오. 반복되는 연결 끊김은 누군가 타이머나 플랫폼 결함을 탓하기 전에 자체적인 실패한 교환 기록이 필요합니다.