AWS Site-to-Site VPN에서 MODP3072가 들어가는 자리

누군가 IKEv2, ESP, MODP3072라고 적힌 요구 사항을 보냈는데 콘솔에는 그런 이름의 필드가 없습니다. 실수는 그런 필드를 찾아 나서는 것입니다. IKEv2는 협상 버전이고, ESP는 보호된 트래픽을 나르는 프로토콜이며, MODP3072는 키 교환 그룹, 즉 IANA 그룹 15입니다. 이 세 가지 사실은 세 곳에 따로 있고, 그룹은 두 번 나타납니다.

그 문장은 하나의 설정이 아닙니다

무엇이든 건드리기 전에 요구 사항을 옵션 목록으로 바꾸십시오. 아래 표가 전체 대응 관계입니다.

MODP3072는 그룹 15이며, AWS는 현재 Phase 1과 Phase 2의 DH 그룹 목록 모두에서 15를 허용합니다. 두 곳에서 허용하는 것은 두 곳에서 요구하는 것과 같지 않으며, 파트너가 둘 다를 뜻했다는 것도 결코 아닙니다.

Phase 1과 Phase 2는 서로 다른 것을 협상합니다

Phase 1은 두 게이트웨이가 어떻게 인증하고, 키에 합의하며, 자기들의 대화를 보호하는지에 대한 IKE 보안 연결을 만듭니다. Phase 2는 실제 트래픽을 나르는 CHILD SA를 만들며, 그 키 교환은 상속이 아니라 새로울 수 있습니다.

이 분리가 바로 파트너가 완전 순방향 비밀성 이야기를 할 때 중요한 이유입니다. PFS는 Phase 2의 속성이며, Phase 1 목록에 있는 그룹은 그것을 제공하지 않습니다. 각 요구 사항이 어느 교환에 적용되는지, 암호화 모드, 무결성을 AEAD 암호가 제공하는지, 양쪽의 키 갱신 기대치를 함께 물으십시오.

AES라는 단어나 하나의 DH 번호에서 완전한 허용 스위트를 추론하지 마십시오. 두 대화의 반쪽씩을 모아 만든 정책이야말로 터널이 어느 팀도 동의하지 않은 것을 제안하게 되는 경로입니다.

허용 목록은 협상 결과가 아닙니다

옵션 목록은 각 측이 무엇을 받아들일 준비가 되어 있는지 설명합니다. 무엇이 선택되었는지는 알려 주지 않습니다. 새 연결에 실제로 선택된 IKE 및 CHILD-SA 제안을 읽고, 요구 사항이 단지 허용된 것이 아니라 충족되었는지 확인하십시오. 목록에 있는 강력한 옵션은 그것이 사용 가능했다는 것만 증명합니다.

갱신도 지켜보십시오. 첫 IKEv2 CHILD SA와 나중의 PFS를 동반한 CHILD 교환은 두 번째 교환이 PFS 그룹과 함께 새 키 자료를 만들기 때문에 서로 다른 호환성 조건을 드러낼 수 있습니다. 수용 테스트가 터널의 첫 분만 다룬다면, 파트너가 신경 쓰는 부분은 시험하지 않은 것입니다.

AWS 터널 옵션 참조는 Phase 1과 Phase 2를 따로 나열하며, 다음 요구 사항이 오기 전에 익혀 둘 만한 구조입니다.

정말로 의도한 터널을 바꾸십시오

Site-to-Site VPN 연결에는 자체 옵션과 자체 상태를 가진 두 개의 터널이 있습니다. 무엇이든 검토하거나 편집하기 전에 AWS 터널의 외부 주소를 고객 게이트웨이 측 피어와 맞추고, 한 번 저장으로 둘 다 갱신된다고 가정하지 마십시오.

승인된 변경에는 고객 게이트웨이 측이 같은 정책에 대비되어 있어야 하고, 선택한 터널이 겪을 중단을 위한 시간 창이 필요합니다. 변경하는 단계에서 피어가 그룹 15에 대비되어 있지 않다면 터널은 그냥 올라오지 않게 되고, 콘솔은 어느 쪽이 거부했는지 알려 주지 않습니다.

합의된 정책을 단계, 프로토콜 버전, 암호화, 무결성, DH 그룹으로 기록하고, 그것이 보호해야 할 교환에서 확인하십시오. 라우팅, 트래픽 선택자, 애플리케이션 권한은 따로 남지만, 이 대응은 완전한 게이트웨이 구성이 아니며, 다양성을 위해 추가 알고리즘을 켜라는 권고도 아닙니다.