IPsec 연결에 대한 모범 사례

IPsec 연결을 설정할 때 가장 흔한 문제 중 하나는 IPsec 설정의 잘못된 구성입니다． IPsec 터널을 구성할 때의 핵심 요소는 양 연결 피어의 설정이 100% 일치하도록 하는 것입니다． 설정이 연결 양쪽에서 일치하지 않으면 연결 및 라우팅 문제가 발생할 수 있습니다． 일부 경우에는 터널이 연결될 수 있지만 라우팅이 제대로 구성되지 않으면 터널을 통해 트래픽을 보낼 수 없습니다．

따라서 먼저 엣지 장치(라우터, 방화벽, VM 등)의 IPsec 설정을 확인한 후 Cato IPsec 연결 설정을 구성할 것을 강력히 권장합니다． 그런 다음 동일한 설정을 사용하여 IPsec 사이트를 구성하십시오．

가장 흔한 설정 실수 중 하나는 호환되지 않는 Diffie-Helman (DH) 그룹을 사용하는 것입니다． DH 그룹은 연결 피어 간 인증 및 초기화 메시지에 사용되는 키의 강도 수준을 결정합니다． DH 그룹이 양쪽에서 맞지 않으면 터널 연결에 실패합니다． 따라서 IPsec 연결 양쪽과 일치하는 DH 그룹을 선택해야 합니다． Cato 관리 애플리케이션에서 엣지 장치 구성에 맞추어 DH 그룹 매개변수를 구성하세요．

또 다른 중요한 권장 사항은 키 갱신을 위해 완벽한 전진 비밀성(PFS)을 사용하는 구성에 대한 것입니다． DH 그룹 매개변수가 없음으로 설정된 경우, PFS가 비활성화됩니다． 따라서 PFS를 활성화하는 경우 인증 메시지 매개변수 섹션에서 DH 그룹이 구성되어 있는지 확인하십시오．

다음 스크린샷은 인증 메시지 매개변수와 DH 그룹 옵션의 예시를 보여줍니다：

가능하다면 약한 암호화 설정을 피하고 더 높은 DH 그룹을 사용하여 더 높은 수준의 보안을 제공할 것을 권장합니다．

Cato 관리 애플리케이션에서 사이트를 구성할 때 인증 메시지 매개변수에 IKEv2에 대해 DH 그룹이 구성되지 않은 경우, 자식 보안 연관(SA)에 대한 초기 메시지 매개변수에 DH 그룹이 여전히 표시될 수 있습니다． 이는 첫 번째 자식 SA가 항상 초기 IKE_AUTH 교환에서 생성되며 IKE SA와 동일한 키 자료를 사용하기 때문입니다. IKE SA는 초기 메시지 매개변수 섹션에 구성된 DH 그룹을 사용합니다. IKE_AUTH에는 DH 그룹 교환이 없습니다.

인증 메시지 매개변수 섹션에서 DH 그룹이 구성된 경우 CREATE_CHILD_SA 교환 중에만 사용되어 추가 자식 SA를 생성하거나 기존 SA를 다시 키로 지정합니다．

주의해야 할 점은 Cato 관리 애플리케이션과 IKEv2 피어에 구성된 DH 그룹이 일치하지 않는 것입니다． 이 경우 터널은 처음에는 IKE_AUTH 교환 후에 시작되지만 CREATE_CHILD_SA 교환을 사용하여 다시 키를 설정할 수 없습니다． 터널이 다시 활성화되기 전에 IKE_SA_INIT 및 IKE_AUTH 교환이 수행되면 잠시 중단이 있을 수 있습니다．

두 연결 피어 모두 동일한 암호화 알고리즘을 사용하는 것이 매우 중요합니다． 때때로 사용자들은 하나의 알고리즘을 선택하는 대신 엣지 장치에서 여러 암호화 알고리즘을 활성화합니다． 너무 많은 알고리즘을 활성화하면 장치가 연결을 설정하는 데 더 많은 시간이 걸립니다． 따라서 터널의 양쪽에서 사용하는 알고리즘만 활성화하는 것이 좋습니다． 적은 것이 더 좋습니다．

대역폭이 100Mbps를 초과하는 IPsec 사이트의 경우 AES 128 GCM-16 또는 AES 256 GCM-16 알고리즘만 사용하세요． AES CBC 알고리즘은 대역폭이 100Mbps 미만인 사이트에서만 사용됩니다．

우리는 기본 및 보조 IPsec 연결을 모두 구성하여 중복성을 확보하는 것을 권장합니다． 또한, 연결을 위해 서로 다른 소스 IP 주소와 서로 다른 목적지 PoP를 사용해야 합니다． 하나의 소스나 목적지가 연결되지 않고 터널이 다운되면 두 번째 터널이 트래픽을 다른 PoP로 전달합니다． 기본 및 보조 연결 모두에서 동일한 소스 IP 주소를 구성하고 이 소스 IP에 문제가 생기면 트래픽을 전달할 다른 연결이 없습니다．

Cato는 두 연결 피어 간의 협상을 위해 IKEv1과 IKEv2를 모두 지원합니다． Cato 관리 애플리케이션에서 IPsec 사이트를 생성할 때 엣지 장치와 일치하는 지원되는 인터넷 키 교환 버전을 선택하세요 (IKEv1 또는 IKEv2)． IKEv2가 지원된다면 일반적으로 사용을 권장합니다． 그러나 일부 장치는 Cato 관리 애플리케이션에서 제공하는 IKEv2 매개변수를 지원하지 않습니다． 그런 경우에는 IKEv1을 대신 사용하세요． 예를 들어, 방화벽이 AES CBC 256 암호화를 지원하지 않는 경우 IPsec 구성에서 사용하지 마십시오． IKEv1 및 IKEv2에 대한 자세한 내용은 Cato IPsec Guide: IKEv1 vs IKEv2를 참조하세요

IKEv2 사이트가 활성화되어 있는 경우 Cato가 연결을 초기화하는 옵션을 선택하는 것을 강력히 권장합니다． 대부분의 경우 엣지 장치는 재연결 시도 사이에 긴 지연이 설정되어 있습니다． 이 장치들이 연결을 초기화할 때 VPN 협상 프로세스는 오래 걸립니다． 반대로 Cato가 연결을 초기화하면 협상 속도가 훨씬 빠릅니다．

다음 스크린샷은 IKEv2 초기화자 옵션을 보여줍니다：

다른 클라우드 벤더 VPN의 IPsec 구성은 서로 호환되지 않을 수 있습니다. 각 클라우드 벤더(예: Amazon AWS, Microsoft Azure 또는 GCP)는 IPsec 터널에 대해 서로 다른 기본 구성 설정을 사용합니다. 클라우드 벤더의 IPsec 구성을 확인하고 Cato IPsec 사이트와 일치하는 구성을 사용하십시오.

참고: 기본 클라우드 IPsec 설정을 변경하는 경우, Cato 관리 애플리케이션의 IPsec 사이트 설정에서 동일한 설정을 사용해야 합니다．

예를 들어, Azure는 PFS 처리를 초기화자 또는 응답자( ESP SA)로서의 역할에 따라 다르게 처리합니다． 초기화자인 경우, Azure는 기본적으로 DH 그룹을 전송하지 않습니다． 응답자인 경우, Azure는 피어로부터 DH 그룹을 수락합니다． 이는 Cato 관리 애플리케이션의 인증 메시지 매개변수 섹션에서 DH 그룹이 구성되어 있고, Azure가 CREATE_CHILD_SA 교환을 사용하여 ESP SA를 생성하려고 시도하면 Cato는 "제안 없음"으로 응답하고 SA 설정이 실패한다는 것을 의미합니다． 그러나 Cato가 CREATE_CHILD_SA 교환을 시작하면, 구성된 DH 그룹이 Azure가 응답자로서 수락하는 그룹일 경우 ESP SA가 설정됩니다． 따라서 Azure와 최대 호환성을 보장하려면 IKEv2 사이트 설정의 인증 메시지 매개변수 섹션에서 DH 그룹을 없음으로 설정하거나 Azure에서 Cato 관리 애플리케이션에 구성된 DH 그룹과 동일한 PFS 그룹을 지정하는 사용자 정의 정책을 구성합니다．

다음 스크린샷은 Azure 사용자 정의 구성의 예시를 보여줍니다：

Azure VPN 매개변수에 대한 자세한 내용은 VPN 장치 및 IPsec 매개변수 정보를 참조하십시오．

Cato Networks는 IKEv2 초기화 및 인증 메시지 매개변수에 대해 암호화, RPF 및 무결성 알고리즘과 같은 자동 매개변수를 선택할 수 있도록 합니다． 자동 구성을 사용할 때 연결성 또는 라우팅 문제를 겪는 경우, 에지 장치 설정과 일치하는 정확한 구성을 선택하고 자동을 사용하지 않는 것이 좋습니다．

그러나 암호화 알고리즘(AES GCM 128 또는 AES GCM 256)에 대해 GCM으로 구성된 사이트의 경우, GCM이 무결성을 제공하므로 무결성 알고리즘은 관련이 없습니다． AES GCM 암호화 알고리즘을 선택하면 무결성 알고리즘은 자동으로 설정됩니다．