Windows와 FortiGate의 IKEv2: 사람들이 합쳐 버리는 세 가지 설정
IKE 키 교환, CHILD SA 보호, 피어 인증은 서로 다른 세 개의 행입니다. 두 대화 상자에서 그룹 번호가 같다고 해서 그것들이 합쳐지는 것은 아닙니다.
Windows 클라이언트와 FortiGate 게이트웨이 사이의 IKEv2 합의는 계속 실패하며, 맞지 않는 번호를 찾을수록 번호 목록은 더 길어집니다. 목록이 다루기 쉬워지는 것은 독립적으로 실패하는 세 개의 행, 즉 IKE를 보호하는 키 교환, CHILD SA에 적용되는 보호, 그리고 어느 쪽이 누구인지 증명하는 인증으로 나눌 때뿐입니다. 그룹 번호는 그중 두 행에 나타나며 서로 다른 의미를 가집니다.
독립적으로 실패하는 세 개의 행
첫 번째 행은 IKE 내부의 키 교환으로, 협상을 보호하는 키를 생성합니다. 두 번째는 CHILD SA에 대한 제안으로, 터널이 운반하는 트래픽을 보호합니다. 세 번째는 인증으로, 각 측이 무엇을 제시하고 상대가 그것을 어떻게 검증하는지 결정합니다.
실패는 서로 다른 지점에서 발생합니다. 교환 실패는 터널이 존재하기 전에 협상을 멈춥니다. CHILD SA 실패는 인증이 성공한 뒤에 발생하며, 때로는 키 갱신 시에만 나타납니다. 인증 실패는 첫 번째 오류만 읽으면 로그에서 교환 실패처럼 보일 수 있습니다.
행을 나누는 것은 회계가 아닙니다. 어떤 설정을 바꿀 가치가 있는지가 달라지고, 이 분야 전체에서 가장 비싼 행동, 즉 제안 불일치를 고치기 위해 정상 작동하는 인증서를 다시 생성하는 일을 막습니다. 한 행의 변경이 나머지 두 행의 변경을 강요해서는 안 됩니다. 그 독립성이 바로 이들을 따로 쓰는 이유 전체입니다.
Windows의 두 필드가 제어하는 것
Windows는 두 필드를 분리합니다: DHGroup는 IKE 교환 자체를 구성하고, PfsGroup는 터널 내부 트래픽을 보호하는 IPsec 정책을 구성합니다. 두 필드는 서로 다른 단계에 속합니다. Windows의 IKE 필드를 FortiGate의 2단계 값과 비교하는 것은 잘못된 짝을 시험하는 일이며, 번호가 일치하더라도 기반 교환은 여전히 실패합니다.
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSA두 번째와 세 번째 명령은 실제로 존재하는 보안 연결을 보고하며, 이것이 클라이언트가 줄 수 있는 답에 가장 가까운 것입니다. 기본 모드 연결은 있는데 빠른 모드 연결이 없다면 CHILD SA 문제이며, 인증서 문제가 아니라 2단계 불일치의 징후입니다.
한 번의 시도에서 무엇이 제안되고 무엇이 선택되었는지 기록하십시오. 수용 가능한 제안을 포함한 제안 목록과 게이트웨이 정책에 맞지 않는 선택된 제안은 구성 불일치이며, 상호 운용성의 수수께끼가 아닙니다.
| Agreement row | Where it is configured in Windows | What it does not decide |
|---|---|---|
| IKE key exchange | DHGroup on the VPN connection IPsec settings | The protection used for tunneled traffic |
| CHILD SA protection | PfsGroup in the same policy object | Which certificate the peer presents |
| Peer authentication | Machine or user certificate, or a supported EAP method | Any group number used for key exchange |
| Certificate validation | Trusted CA store on the validating side | The private key of the certificate being presented |
타원 곡선 그룹은 서명 키를 선택하지 않습니다
이 분야에서 가장 끈질긴 잘못된 추론은 타원 곡선 DH 그룹을 선택하려면 타원 곡선 인증서가 필요하다는 것입니다. DH 그룹은 키 교환 재료를 제공하고, 서명 알고리즘은 인증 프레임워크가 협상하며, IKEv2에서 이 둘은 별개의 결정입니다.
RFC 7427이 존재하는 이유는 바로 그러한 결정들이 이전에 얽혀 있었기 때문이며, 서명 알고리즘을 키 교환과 독립적으로 광고하고 선택하는 방법을 정의합니다. 게이트웨이는 곡선 그룹과 서명 방식의 선택을 동시에 지원할 수 있습니다.
따라서 그룹 변경 후 협상이 실패하면 인증서의 키 유형을 보기 전에 인증 방법을 보십시오. 인증서 교체는 느리고 위험한 작업이며 거의 답이 되지 않고, 그것을 먼저 하면 어떤 변경이 실제로 도움이 되었는지 알 능력을 파괴합니다. 인증서 저장소를 건드리기 전에 인증 행을 읽으십시오.
둘을 합의서의 별도 행에 두면 그 실수는 더 이상 유혹적이지 않습니다. 한 행은 그룹을 나열하고, 다른 행은 서명 방식과 신원을 나열하며, 어느 것도 다른 것에 대한 증거가 아닙니다.
각 개인 키를 실제 소유자와 함께 두십시오
자신의 인증서를 제시하는 게이트웨이에는 그에 맞는 개인 키가 필요합니다. 체인을 검증하는 피어에는 CA 인증서가 필요하고, CA의 서명 키는 특별히 필요하지 않습니다. 이 세 가지 요소를 혼동하는 것이 사람들이 인증서를 다른 범주에 나타나게 하려고 VPN 장치에 CA 개인 키를 가져오는 이유입니다.
FortiOS에서는 역할이 구분됩니다: 키가 있는 로컬 인증서, 피어를 식별하는 데 쓰는 원격 인증서, 그리고 그 CA가 서명한 인증서에 대한 신뢰를 세우는 원격 CA 항목입니다. 개인 키가 없는 원격 CA 항목은 불완전한 것이 아니며, 그 목적에는 올바릅니다.
가져온 CA 서명 키는 그 장치를 읽을 수 있는 모든 사람의 권한을 넓힙니다. 또한 검증에는 공개 인증서와 신뢰 결정이 필요하고 새 인증서를 발급할 능력은 필요 없으므로, 일반적인 피어 검증도 해결하지 못합니다.
CA 서명 키는 발급자의 자체 프로세스 옆에 두고 어떤 장치가 어떤 키를 보유하는지 기록하십시오. 감사에서 누가 누구를 사칭할 수 있었는지 물을 때 소유자 목록의 짧은 표가 알고리즘의 긴 표보다 가치 있습니다. 재고용임을 아는 키를 가져오는 사람은 없습니다. 사고 후가 아니라 사고 전에 재고를 작성하십시오.