IPSec Site-to-Site VPN & Dead Peer Detection(DPD) 심층 분석 (Deep Dive)

 

들어가면서...

AWS의 Site-to-Site VPN은 고객의 IDC 인프라 환경과 AWS 클라우드 환경 간의 네트워크 통신을 위한 저렴하고 안전한 수단입니다.

이러한 이유로 많은 고객들이 Site-to-Site VPN을 사용하고 있지만, 이에 비례하여 간헐적인 통신 끊김이나 터널 교체와 같은 이슈도 많이 발생하고 있습니다. 따라서 이번 시간에는 이러한 기술적 요소를 제대로 이해하는 시간을 가져보고자 합니다.

 

VPN (Virtual Private Network)은 인터넷을 통해 안전한 통신 채널을 구축하여 개인 또는 조직의 네트워크를 확장하여 원격지에 있는 사용자나 지점이 본사나 데이터 센터의 내부 네트워크에 접속할 수 있도록 합니다. 이를 통해 VPN은 기밀성, 무결성, 인증이라는 3가지 특성을 가지고 있습니다. 

IPSec (Internet Protocol Security)은 L3 네트워크 계층에서 데이터의 기밀성, 무결성, 인증을 제공하는 보안 프로토콜의 모음으로 1990년대 Internet Engineering Task Force가 개발하여, 현재 VPN 구현하는데 널리 사용됩니다. 

 

IPSec 프로토콜 구성요소 

IPsec은 하나의 프로토콜이 아니라 프로토콜 모음입니다. IPsec 제품군을 구성하는 프로토콜은 다음과 같습니다. 

• 인증 헤더 (AH, Authentication Header)
• 캡슐화 보안 페이로드 (ESP, Encapsulating Security Payload)
• 보안 연관 (SA, Security Association) 

인증 헤더 (AH, Authentication Header)

AH는 데이터 패킷의 무결성과 출처 인증을 제공합니다. AH는 IP 패킷의 헤더와 페이로드 모두를 인증하지만, 암호화는 제공하지 않습니다. 따라서 AH는 데이터의 기밀성을 보호하지 않습니다. 

 

AH의 주요 기능:

• 무결성 보장: 해시 함수를 사용하여 데이터가 전송 중에 변조되지 않았음을 확인합니다.
• 출처 인증: 데이터가 신뢰할 수 있는 송신자로부터 왔음을 확인합니다.
• 재생 공격 방지: 순서 번호를 사용하여 이전에 전송된 패킷의 재전송을 감지하고 차단합니다.

캡슐화 보안 페이로드 (ESP, Encapsulating Security Payload)

ESP는 전송 모드가 사용되지 않는 한 각 패킷에 대한 IP 헤더 및 페이로드를 암호화하며, 전송 모드에서는 페이로드만 암호화됩니다.ESP는 각 데이터 패킷에 자체 헤더와 트레일러를 추가합니다.

 

ESP의 주요 기능:

• 암호화: 대칭 키 암호화를 사용하여 데이터의 기밀성을 보호합니다.
• 무결성 및 인증: HMAC(Hash-based Message Authentication Code)를 사용하여 데이터의 무결성과 출처를 확인합니다.
• 재생 공격 방지: AH와 마찬가지로 순서 번호를 사용하여 재생 공격을 방지합니다.

IPsec 프로토콜에서는 패킷에 여러 헤더와 트레일러가 추가되며, 모두 몇 바이트를 차지합니다. IPsec을 사용하는 네트워크의 경우 MSS 및 MTU를 적절하게 조정해야 하며, 그렇지 않으면 패킷이 단편화되고 이로 인한 재전송 작업이 수행될 수 있습니다. 

 

각 모드에 따른 패킷 크기는 다음 그림과 같습니다. 

보안 연관 (SA, Security Association) 

IPSec 통신에서 사용하는 보안 속성의 집합입니다. SA는 통신하는 두 엔티티 간에 공유되며, 다음과 같은 정보를 포함합니다: 

 

• 보안 매개변수 인덱스(SPI): SA를 고유하게 식별하는 값
  • IP 트래픽을 터널링하기 위해 IPsec을 사용하는 동안 헤더에 추가되는 식별 태그
• 암호화 알고리즘 및 키: 데이터 암호화에 사용되는 알고리즘과 키 정보.
• 인증 알고리즘 및 키: 데이터 인증에 사용되는 알고리즘과 키 정보.
• 수명(Lifetime): SA의 유효 기간.
• 프로토콜(AH 또는 ESP): 사용되는 IPSec 프로토콜.

SA의 특징:

• 단방향성: SA는 단방향으로 설정됩니다. 따라서 양방향 통신을 위해서는 두 개의 SA(송신용, 수신용)가 필요합니다.
• 프로토콜별 생성: AH와 ESP 각각에 대해 별도의 SA가 생성됩니다.

대표적으로 사용되는 SA 프로토콜은 IKE (Internet Key Exchange, IKE, IKEv1 및 IKEv2)이 있습니다. 

 

IPSec의 동작 모드

IPSec은 두 가지 모드로 작동합니다.

 

터널 모드 (Tunnel Mode)

터널 모드에서는 원본 IP 패킷 전체를 암호화하고, 새로운 IP 헤더를 추가하여 전송합니다. 이 모드는 게이트웨이 간의 통신에서 주로 사용되며, Site-to-Site VPN에서 일반적으로 활용됩니다.

• 동작 방식:
  • 원본 IP 패킷을 완전히 캡슐화하여 암호화합니다.
  • 새롭게 추가된 IP 헤더는 IPSec 엔드포인트(예: VPN 게이트웨이)의 IP 주소를 포함합니다.
• 장점:
  • 내부 네트워크 구조를 외부에 노출하지 않습니다.
  • NAT(Network Address Translation) 환경에서 유용합니다.
    • NAT 장치는 IP 헤더를 변경하므로, IPsec 터널 모드에서 원본 IP 헤더가 암호화되어 있으면 NAT 처리가 어렵습니다.
    • 따라서 불리하다고 말하는게 정확하지만, NAT-Traversal(NAT-T)을 사용하여 IPsec 패킷을 UDP로 캡슐화하여 NAT 장치를 통과할 수 있게 합니다.

전송 모드 (Transport Mode)

전송 모드에서는 IP 패킷의 페이로드(전송 계층의 데이터)를 암호화하고, 원본 IP 헤더는 그대로 유지됩니다. 이 모드는 호스트 간의 종단 간 통신에서 주로 사용됩니다.

• 동작 방식:
  • IP 헤더를 제외한 나머지 부분을 암호화합니다.
  • 원본 IP 헤더를 그대로 사용하므로, 경로 제어 정보가 유지됩니다.
• 장점:
  • 오버헤드가 적습니다.
  • 호스트 간의 직접 통신에 적합합니다.

만약 전송 모드에서 원본 IP 헤더를 숨기고 싶다면, GRE(Generic Routing Encapsulation)와 같은 별도의 터널링 프로토콜을 사용하여 IP 헤더를 캡슐화할 수 있습니다.

 

 

따라서 비유하자면 다음과 같이 정리할 수 있습니다. 

 

• 터널 모드: 비밀 소포를 이중 포장하여 외부에서는 내용물과 실제 발신자, 수신자를 알 수 없게 하는 것.
• 전송 모드: 비밀 메시지를 일반 봉투에 넣어 보내어, 내용물은 보호되지만 발신자와 수신자는 누구나 알 수 있는 것.

 

IPSec 통신 과정

IPSec 통신과정을 도식화 하여 표현하면 다음과 같이 나타낼 수 있습니다. 

 

 

IPSec은 데이터 전송 전에 통신 상대방과 보안 매개변수를 교환하고, 암호화 키를 안전하게 교환해야 합니다. 이를 위해 IKE(Internet Key Exchange) 프로토콜을 사용합니다.

 

IKE는 두 단계로 구성됩니다:

• IKE Phase 1: 두 엔티티 간에 안전한 통신 채널(ISAKMP SA)을 설정합니다.
  • 여기에는 메인 모드, 공격적 모드 2가지로 분류됩니다. 
  • 메인 모드는 Site-to-Site VPN 통신에 사용되며, 두 사이트 모두 고정 IP를 사용합니다. 
  • 공격적 모드는 원격 사용자가 동적 IP 주소를 갖는 원격 액세스 VPN 통신에 주로 사용됩니다.
• IKE Phase 2: 데이터 전송에 사용할 IPSec SA를 협상하고 설정합니다.

IKE Phase 1

목적: 안전한 IKE SA(ISAKMP SA)를 수립하여 Phase 2의 협상을 보호합니다.

모드:

• 메인 모드(Main Mode): 6개의 메시지를 교환하여 SA를 설정합니다.
  
  • 메시지 1-2: 제안된 보안 정책을 교환합니다(암호화, 해싱 알고리즘 등).
  • 메시지 3-4: Diffie-Hellman 공개 키 교환을 통해 공유 비밀 키를 생성합니다.
  • 메시지 5-6: 상대방을 인증합니다(사전 공유 키 또는 인증서 사용).

 

 

 

• 공격적 모드(Aggressive Mode): 3개의 메시지로 빠르게 SA를 설정하지만, 보안성이 약간 낮습니다.
  • 메시지 1: Initiator가 보안 정책 제안, Diffie-Hellman 공개 키, 식별 정보를 전송합니다.
  • 메시지 2: Responder가 선택된 보안 정책, Diffie-Hellman 공개 키, 식별 정보를 전송합니다.
  • 메시지 3: 인증 데이터를 교환하여 상호 인증을 완료합니다.

 

과정:

1. 협상: 암호화 알고리즘, 해싱 알고리즘, 인증 방법, Diffie-Hellman 그룹 등을 협상합니다.
2. 키 교환: Diffie-Hellman 알고리즘을 사용하여 공유 비밀 키를 생성합니다.
3. 인증: 사전 공유 키(Pre-Shared Key)나 디지털 인증서(Certificate)를 사용하여 상대방을 인증합니다.

IKE Phase 2

목적: 실제 데이터 전송에 사용할 IPSec SA를 생성합니다.

모드:

• 퀵 모드(Quick Mode): 3개의 메시지를 교환하여 IPSec SA를 설정합니다.
  • 메시지 1: Initiator가 제안된 IPSec SA 파라미터(프로토콜, 암호화/인증 알고리즘 등)를 전송하고, 새로운 세션 키 생성을 위한 난수 값을 보냅니다.
  • 메시지 2: Responder가 선택된 IPSec SA 파라미터를 확인하고, 자신의 난수 값을 보냅니다.
  • 메시지 3: IPSec SA 설정 완료를 확인하고, 선택적으로 SA 수명을 조정합니다.

과정:

1. 협상: 사용할 IPSec 프로토콜(AH 또는 ESP), 암호화 및 인증 알고리즘 등을 협상합니다.
2. 키 생성: Phase 1에서 수립된 IKE SA를 기반으로 세션 키를 생성합니다.
3. IPSec SA 수립: 데이터 전송에 사용할 SA를 생성하고, 암호화 및 인증에 필요한 정보를 교환합니다.

 

IPSec SA가 수립되면, 송신 측에서 패킷이 IPSec 정책과 일치하면 IPSec 프로세스로 전달되어 패킷은 설정된 SA에 따라 암호화되고 인증됩니다. 이후 각 모드에 맞춰서 패킷이 캡슐화되고, 이를 네트워크를 통해 수신 측으로 전달하게 됩니다. 

수신 측에서 패킷을 수신하면, SPI(Security Parameter Index)와 목적지 IP 주소를 사용하여 해당 SA를 식별하여 패킷을 복호화하고, 무결성과 인증을 확인한 다음에 검증에 성공하면 패킷을 상위 계층으로 전달합니다. 

 

 

Site-to-Site VPN

Site-to-Site VPN은 두 개 이상의 분리된 네트워크(예: 기업의 본사와 지사)를 인터넷과 같은 공용 네트워크를 통해 안전하게 연결하는 VPN(Virtual Private Network) 유형입니다. 이를 통해 지리적으로 떨어져 있는 네트워크들이 마치 하나의 통합된 네트워크처럼 동작할 수 있습니다.

 

각 네트워크의 경계에 위치한 장치(예: 라우터, 방화벽)가 VPN 게이트웨이 역할을 수행하여 이 게이트웨이들 간에 IPSec 터널이 설정되어, 내부 네트워크의 트래픽을 암호화하여 전송합니다. 

 

AWS에서 제공하는 Site-to-Site VPN 역시 CGW (Customer Gateway)와 VGW (Virtual Private Gateway) 간의 IPSec 통신이라고 이해하면 됩니다. 

 

Dead Peer Detection (DPD)

지금까지 IPSec에 대한 부분과 SIte-to-Site VPN에 대해서 살펴보았습니다. 이번 글의 핵심인 DPD에 대해 알아보도록 하겠습니다. 

실무에서 Site-to-Site VPN의 간헐적인 끊김 현상이 발생할 경우 가장 먼저 확인하는 것이 DPD 설정을 가장 먼저 확인라하고 조언하기도 하는데 과연 DPD는 무엇일까요? 

 

DPD는 G. Huang, S. Beaulieu, D. Rochefort가 작성한 RFC 3706 : "A Traffic Based Method of Detecting Dead Internet Key Exchange(IKE) Peers"에 원문 내용을 확인할 수 있습니다. 

 

DPD는 IPsec과 VPN과 같은 다양한 네트워킹 프로토콜에서 중요한 역할을 담당합니다. 특히나 VPN 장비라면 필수적으로 들어가 있는 기능으로, 원격 피어가 응답하지 않거나 장애가 발생했는지 식별하도록 설계되어, 안전하고 신뢰할 수 있는 네트워크 연결을 유지하는 데 중요한 메커니즘입니다. 

 

IPSec 환경에서 DPD가 더 중요한 이유는 IPSec에 SA 과정의 IKE 통신이 UDP로 이루어지기 때문입니다. 일반적으로 IPSec SA는 터널이 구성되고 나면, 만료되기 전까지는 다시 협상을 진행하지 않기 때문에, 원격 피어가 손실되었는지 자동으로 감지하지 못합니다.

이로 인해, 원격 피어가 실패하면 SA가 해제될 때까지 트래픽이 계속 전달되는 블랙홀이 발생할 수 있습니다.

 

DPD 동작 과정

죽은 IKE 피어를 감지하는 이 문제는 생존 여부를 확인하기 위해 주기적인 HELLO/ACK 메시지를 보내는 제안으로 해결되었습니다. 이러한 방식은 단방향(HELLO만) 또는 양방향(HELLO/ACK) 일 수 있습니다. 여기서 단방향 메시지를 "heartbeats"라고 하고, 양방향 메시지를 "keepalives"라고 합니다.

 

먼저 이 2가지의 통신 과정을 살펴보고 어떠한 문제점이 있는지 살펴보도록 하겠습니다. 

 

keepalives를 사용하기 위해서는 두 피어간의 SA 과정(Phase 1 부분에서)에서 추가적인 주기 설정이 필요하며, 신속한 장애 처리를 위해서는 빈번한 간격(약 10초)으로 전송되어야 합니다. 이 시나리오에서는 각 피어가 10초마다 keepalives를 교환하기로 설정되어 있다고 가정하며, 상대측이 HELLO 메시지를 전송하면 수신 측은 이에 대한 ACK를 보내야 합니다. 

 

Peer A 10초 타이머가 먼저 만료되고, B에게 HELLO를 보냅니다. B는 ACK로 응답합니다. 

 

만약 Peer B가 응답하지 않으면, Peer A는 재전송을 시도하고, 일정 횟수의 시도 후에 B가 죽었다고 판단하고 SA를 삭제하거나 장애 조치를 시작할 수 있습니다.

 

heartbeats 방식에서는 각 피어가 주기적으로 자신의 생존 여부를 알리는 메시지를 보냅니다. 피어 A와 B는 서로의 하트비트 메시지를 받아 생존 여부를 확인합니다.

 

 

이 두가지 방식의 문제점은 정기적으로 메시지를 보내야 한다는 것입니다. 구현 시에는 이러한 메시지 간격을 관리하기 위해 타이머를 설정해야 합니다. 또한, 죽은 피어를 신속하게 감지하기 위해서는 메시지를 빈번하게 보내야 하며, 이는 메시지 처리에 상당한 오버헤드를 초래합니다. 많은 수의 IKE 세션을 동시에 관리해야 하는 경우, 이러한 정기적인 heartbeats/keepalives는 실용적이지 않습니다. 

 

DPD는 IKE keepalives 및 heartbeats 방식의 단점을 보완하여 독립적으로 요할 때 활성 상태 증명을 요청할 수 있으며, 이는 정해진 시간의 간격에 구애받지 않습니다. 

이러한 비동기적 특성 덕분에 DPD는 전송되는 메시지 수를 줄일 수 있으며, 이는 DPD가 더 높은 확장성을 달성할 수 있습니다. 

 

다음 그림을 보면서 자세히 살펴보도록 하겠습니다. 

 

두 피어 간에 유효한 IPSec 트래픽이 지속적으로 교환되고 있다면, IPSec 트래픽 자체가 활성 상태 증명의 역할을 하기 때문에 DPD는 터널 상태를 굳이 확인할 필요가 없습니다. 

만약, 일정기간 동안 패킷 교환이 없는 상태에서 Peer A가 IPSec 패킷을 보내야 한다면 Peer B의 상태를 확인하기 위해서 DPD 교환을 시작할 수 있습니다. 

이러한 특성으로 인해 각 요구사항에 따른 DPD 설정을 다르게 가져갈 수 있습니다. 예를 들어 Peer A는 신속한 장애 조치를 요구할 수 있는 반면, Peer B는 리소스 정리에 대한 요구가 덜 긴급할 수 있습니다. DPD에서는 각 피어가 자체 "걱정 지표(worry metric)"인 간격을 정의할 수 있습니다. 만약에 Peer A는 자신의 DPD 간격을 10초로 정의하였다면, Peer A가 송신 IPSec 트래픽을 보냈지만, 10초 동안 수신 트래픽을 받지 못하면 DPD 교환을 시작할 수 있습니다.

 

DPD 교환은 양방향(HELLO/ACK) 메시지로 구성되어있으며, 교환 방식은 다음과 같습니다. 

    Sender                                      Responder
   --------                                    -----------
HDR*, NOTIFY(R-U-THERE), HASH   ------>
                             <------    HDR*, NOTIFY(R-U-THERE-ACK), HASH

 

R-U-THERE 메시지는 "HELLO"에 해당하며, R-U-THERE-ACK는 "ACK"에 해당합니다. 

 

 

정리하자면...

Dead Peer Detection(DPD)은 이전에 연결된 피어가 더 이상 사용 가능하지 않을 때 이를 감지하는 네트워크 보안 프로토콜입니다. DPD는 네트워크 피어에게 주기적인 메시지를 보내고 응답을 기다립니다. 피어가 메시지에 응답하지 않으면 Dead Peer Detection IPSec 프로토콜은 피어가 더 이상 사용 가능하지 않다고 가정하고 적절한 조치를 취합니다.

또한 DPD가 기존의 keepalives 및 heartbeats 방식보다 제공하는 성능상의 이점은 정기적인 메시지를 보낼 필요가 없다는 점에서 비롯됩니다.

이로 인해 DPD 방식은 피어로부터 마지막으로 받은 트래픽의 타임스탬프를 유지하여 "유휴 기간"의 시작을 추적하면 되므로, DPD R-U-THERE 메시지를 보낸 후, 구현은 재전송을 신호하는 타이머 하나만 유지하면 됩니다. 따라서 활성 타이머 상태를 유지할 필요가 줄어들어 확장성이 향상됩니다. 또한, DPD 교환은 최근에 피어로부터 트래픽을 받지 못한 경우에만 발생하므로, 전송되고 처리되는 IKE 메시지 수도 줄어듭니다. 결과적으로, DPD의 확장성은 keepalives 및 heartbeats보다 훨씬 우수합니다.

 

만약 각 피어 간의 IPSec 연결이 하나라면 기존 IKE 확인 방법을 사용해도 무방하겠지만, 여러 IPSec 연결을 사용하는 구성 환경이라면 DPD 구성을 사용하는 것을 적극적으로 권장하며, 클라우드 환경에서는 DPD 사용이 강제됩니다. 다만 동시에 DPD와 IKE heartbeats/keepalives 방식을 사용하시면 안 됩니다. 

 

만약 터널이 비활성화 되는 부분을 원칙적으로 막고자 한다면 각 벤더사의 네트워크 트래픽 모니터링 기능을 통해 주기적으로 트래픽을 발생시키거나, 간단한 쉘 스크립트를 통해 ICMP 패킷을 발생시키는 것으로 터널 환경을 계속해서 유지시킬 수 있습니다. 

 

Site-to-Site VPN 구성을 통해 각 벤더사의 장비나 클라우드 환경에서의 DPD 구성은 서로 독립적으로 구성될 수 있으나, DPD 간격이 너무 짧으면 네트워크 오버헤드가 증가하고, 너무 길면 피어 상태 감지가 지연될 수 있고, 적절한 재전송 횟수를 설정하여 불필요한 세션 종료를 방지해야 하며, 모든 피어가 DPD를 지원하는지 확인해야 합니다. 

 

벤더마다 다르겠지만 DPD 항목 구성에서 On demand, On Idle, Disable의 의미는 다음과 같습니다. 

• On demand : 아웃바운드 트래픽만 있고, 인바운드 트래픽이 없는 경우 
• On Idle : 터널에서 트래픽이 보이지 않을 경우, 터널수가 많을 경우 사용하지 않는 것을 권장 
• Disable : 상대측의 DPD 요청에 대한 응답만 허용, 벤더에 따라 응답도 허용하지 않는 경우가 있어 터널 fail 감지 불가