FortiGate Azure 재키: peer SA 제안이 로컬 정책과 일치하지 않음

터널이 올라오고 트래픽이 흘렀으며, 나중에 로그에 peer SA proposal not match local policy라고 나옵니다. 대부분은 이 줄을 두 구성이 한 번도 일치한 적 없다는 증거로 읽습니다. 보통은 더 좁은 의미입니다. 첫 CHILD SA에서는 일치했고 첫 갱신에서 일치가 끝났습니다. 첫 연결은 이후 연결이 수행하는 교환을 한 번도 필요로 하지 않았기 때문입니다. 이 차이가 어디를 볼지 결정합니다.

첫 CHILD SA는 상속하고, 이후는 협상한다

IKEv2에서 초기 CHILD SA는 IKE_AUTH 중에 생성되고 그 키는 IKE SA의 키 자료에서 파생됩니다. 그 시점에는 별도의 Diffie-Hellman 교환이 없으므로 한쪽 peer가 받아들일 수 없는 PFS 그룹은 아직 시험되지 않습니다. 터널이 건강해 보이는 이유는 나중에 실패할 요구 사항이 한 번도 시험되지 않았기 때문입니다.

CHILD_SA 재키는 다른 메시지 순서입니다. PFS가 구성되면 peer는 새 키 교환을 수행하고 양쪽이 받아들이는 그룹과 새 연결을 위한 ESP 제안에 합의해야 합니다. 불일치가 드러나는 순간이 바로 그때이며, 오류가 경로가 아니라 제안을 지목하는 이유이기도 합니다.

따라서 “어제는 작동했다”는 제안에 대해 아무것도 알려 주지 않습니다. 초기 교환이 성공했다는 것, 이미 알고 있던 사실을 알려 줄 뿐입니다.

실패한 교환을 읽으세요. 첫 ping이 아니라

무엇이든 바꾸기 전에 양쪽 끝에서 성공한 IKE 인증, 초기 CHILD SA, 실패한 교체를 수집하세요. 그다음 작업을 정확히 부르세요. IKE SA 재키, IKE 재인증, CHILD SA 재키는 서로 다른 세 가지 사건이며, 일상 대화의 “2단계”는 이 모두를 아우릅니다.

아래 필드는 터널 전반이 아니라 실패한 연결에 대해 비교하세요.

FortiGate에서 해당 터널의 2단계 제안, PFS 설정, 허용된 DH 그룹을 엽니다. 이전에 맺어진 연결에서 추론하지 말고 로드된 값을 읽으세요. GUI 페이지 스크린숏은 실행 중인 구성보다 약한 증거입니다. 업그레이드 후 둘이 어긋날 수 있기 때문입니다. 변경한 섹션을 내보내고 티켓과 함께 보관하세요.

Azure의 기본 정책도 정책이다

연결에 사용자 지정 정책이 붙어 있지 않다고 해서 Azure가 아무 정책도 적용하지 않는 것은 아닙니다. 연결은 게이트웨이의 기본 제안 세트로 되돌아가며, 그것은 FortiGate가 제공하는 것보다 넓거나 좁을 수 있습니다. 두 세트가 IKE에서는 겹치지만 PFS를 쓰는 ESP에서는 겹치지 않는다면, 정확히 이 실패 패턴을 얻습니다.

이 읽기 전용 보기는 비밀을 노출하지 않고 실제로 붙은 정책을 보여 줍니다:

Get-AzVirtualNetworkGatewayConnection -Name 'Branch' -ResourceGroupName 'NetworkRG' |
Select-Object Name, ConnectionStatus, IpsecPolicies

실제 리소스 이름을 사용하세요. 명시적 정책이 필요하면 연결 리소스에 설정합니다. 게이트웨이 전체 스위치가 아니며 같은 게이트웨이의 다른 터널에 조용히 적용되지도 않습니다.

포털에서 해당 연결의 Configuration 페이지가 사용자 지정 IPsec/IKE 정책이 들어가는 곳입니다. Microsoft의 사용자 지정 정책 가이드에는 지원되는 매개 변수와 SKU 요구 사항이 나열되어 있습니다. Azure는 연결마다 하나의 완전한 조합을 받아들이므로 IKE 필드와 IPsec 필드를 함께 지정합니다. 하나씩이 아닙니다.

PFS는 요구 사항이지 뒤집는 스위치가 아니다

보안 기준선이 PFS를 요구한다면 해결책은 양쪽에서 두 peer가 받아들이는 그룹을 일치하는 정책으로 표현하는 것입니다. 오류를 없애려고 PFS를 끄면 유지하려던 보안 속성이 바뀌고, 보통 나중에 다른 불일치로 다시 나타납니다.

Azure 특유의 함정 하나: ESP에 GCM을 선택하면 암호화와 무결성 선택이 같은 GCM 알고리즘과 같은 키 길이를 지정해야 합니다. GCM 암호를 별도 무결성 알고리즘과 섞으면 서비스가 거부하는 조합이 되고, 정책을 주의 깊게 읽기 전까지는 peer 간 불일치처럼 보입니다.

양쪽 끝이 지원하고 요구 사항이 허용하는 가장 강한 조합을 선택한 뒤 변경 기록에 적으세요. 다음 사람은 그 기록과 비교합니다. 작동하던 터널의 기억과 비교하지 않습니다. 정책 이름만이 아니라 PFS 그룹과 ESP 제안도 적으세요. 나중에 누군가 감사가 실패한 이유나 재키가 느린 이유를 물으면 그 한 줄이 두 질문에 답합니다.

실패한 교환을 확인하세요

정책 편집이 고치려는 터널을 끊을 수 있으므로 변경은 복구 경로와 함께 계획하세요. 트래픽이 돌아오면 CHILD_SA 갱신을 기다리거나 촉발하고, 새 연결이 의도한 PFS 그룹으로 수립되었는지 확인하세요. 그다음 애플리케이션 트래픽이 그 위로 계속 흐르는지 확인하세요.

두 가지 잘못된 단서를 짚어 둘 만합니다. SA 수명은 로컬 사양이므로 값이 다른 것이 정상이며, 바꾸면 문제가 나타나는 시점만 옮겨집니다. DPD는 peer가 살아 있는지 감지합니다. 시간 제한을 늘려도 ESP나 PFS 선택이 정렬되지는 않습니다.

변경 후 협상된 결과와 다음 사건을 기록하세요. 이제 연결이 IKE 인증이 끝나기 전에 실패한다면, 방금 편집한 IKE 설정을 보고 있는 것이지 원래의 CHILD 갱신 실패가 아닙니다.