Day 3 - Site-to-Site VPN과 Client VPN: IPsec 터널의 모든 것

인터넷 위에 암호화 터널을 올리는 VPN은 1990년대 후반부터 기업 네트워킹의 핵심이었다. AWS가 2011년 Site-to-Site VPN을 출시했을 때 많은 기업은 이미 IPsec 기반 VPN에 익숙했다. 그러나 AWS의 VPN은 단순한 IP 터널 그 이상이다. TGW와 결합한 ECMP로 대역폭을 선형으로 확장하고, Global Accelerator와 연동해 전 세계 어디서든 낮은 지연을 보장하며, BGP로 온프레미스 라우팅 변경을 자동으로 반영한다. 오늘은 Site-to-Site VPN의 내부 동작 원리부터 ECMP를 활용한 대역폭 확장, Accelerated VPN, Client VPN의 인증 흐름까지 SAP-C02 수준의 깊이로 다룬다.

IPsec의 구조: VPN의 기반 기술

AWS Site-to-Site VPN은 IPsec(IP Security) 프로토콜을 기반으로 한다. IPsec은 RFC 4301이 정의하는 L3 보안 프로토콜 스위트로, 두 가지 핵심 구성 요소가 있다.

AH(Authentication Header, RFC 4302): 패킷의 무결성과 인증을 보장하지만 암호화는 하지 않는다. 패킷 내용이 변조되지 않았음을 보장하지만 내용은 평문이다.

ESP(Encapsulating Security Payload, RFC 4303): 패킷을 암호화하고 무결성을 보장한다. AWS VPN은 ESP를 사용한다.

IPsec은 두 가지 모드로 동작한다. Transport Mode는 원본 IP 헤더를 유지하고 페이로드만 암호화한다. Tunnel Mode는 원본 IP 패킷 전체를 암호화하고 새로운 IP 헤더로 캡슐화한다. AWS Site-to-Site VPN은 항상 Tunnel Mode를 사용한다.

IPsec에서 보안 연결을 수립하는 프로토콜이 IKE(Internet Key Exchange)다. IKEv1(RFC 2409)은 두 단계(Phase 1: 보안 채널 수립, Phase 2: IPsec SA 협상)로 구성되고, IKEv2(RFC 7296)는 이를 단순화하고 NAT Traversal, 재인증, MOBIKE 같은 기능을 추가했다. AWS VPN은 IKEv1과 IKEv2를 모두 지원하지만, IKEv2를 권장한다. IKEv2는 핸드쉐이크 메시지 수가 적어 터널 수립이 빠르고, Dead Peer Detection(DPD)이 기본 내장되어 있어 장애 감지가 신뢰성 있다.

AWS Site-to-Site VPN 아키텍처

AWS Site-to-Site VPN은 Customer Gateway(CGW, 온프레미스 라우터)와 AWS VPN 엔드포인트 사이에 항상 2개의 IPsec 터널을 자동으로 생성한다. 두 터널은 서로 다른 AZ에 있는 AWS VPN 엔드포인트와 연결되어 AWS 측의 단일 AZ 장애를 방어한다.

[온프레미스 CGW]
       │
       ├── IPsec Tunnel 1 (IKEv2) ──── AWS VPN Endpoint 1 (AZ-a) ──┐
       │   (169.254.10.0/30 링크 넷)                                 │
       │                                                             ├── VGW 또는 TGW
       └── IPsec Tunnel 2 (IKEv2) ──── AWS VPN Endpoint 2 (AZ-b) ──┘
           (169.254.11.0/30 링크 넷)

각 터널: 최대 1.25Gbps 처리량

두 터널은 동시에 활성 상태로 유지될 수 있다. BGP를 사용하면 두 터널에서 동일한 경로를 광고하고 트래픽을 나눌 수 있다(Active-Active). Static Route를 사용하면 AWS가 한 터널을 기본으로 선택하고 다른 터널은 백업으로 둔다(Active-Passive).

AWS VPN의 터널 내부 IP(Inside CIDR)는 169.254.0.0/16 범위에서 할당된다. 이는 링크-로컬 주소(RFC 3927)로 인터넷 라우팅이 불가능하다. BGP 세션은 이 링크-로컬 주소 사이에서 맺어진다. AWS VPN에서 사용 가능한 Inside CIDR은 169.254.0.0/30 ~ 169.254.255.252/30 범위에서 AWS가 예약한 일부 서브넷을 제외한 범위다. 기업이 여러 VPN 연결을 관리할 때 Inside CIDR 충돌이 발생하지 않도록 체계적으로 할당해야 한다.

Static vs BGP: 시험이 원하는 답

AWS Site-to-Site VPN은 정적 라우팅과 BGP 동적 라우팅을 모두 지원한다.

정적 라우팅: 온프레미스 CIDR을 AWS 콘솔에 수동으로 입력하고, 온프레미스 라우터에도 VPC CIDR로 향하는 정적 라우트를 수동으로 설정한다. 온프레미스 네트워크가 변경되면 양쪽 모두 수동으로 업데이트해야 한다. 터널 장애 시 자동 페일오버가 없다.

BGP 동적 라우팅: 온프레미스 라우터와 AWS VPN 엔드포인트 사이에 eBGP 세션을 수립한다. 온프레미스가 자신의 CIDR을 BGP로 광고하고, AWS는 VPC CIDR을 광고한다. 온프레미스 네트워크 변경이 자동으로 반영된다. 터널 장애 시 BGP가 대안 경로를 자동으로 선택한다.

⚠️ 함정: BGP를 사용해도 두 터널이 자동으로 Active-Active ECMP가 되는 것은 아니다. VGW에 연결된 VPN은 두 터널 중 하나만 활성(Active-Passive)으로 동작한다. TGW에 연결하고 ECMP를 명시적으로 활성화해야 두 터널이 동시에 활성으로 트래픽을 분담한다. SAP-C02에서 "대역폭을 늘려야 한다"는 시나리오에서 VGW를 TGW로 교체하는 것이 정답인 경우가 있다.

SAP-C02에서 BGP가 정답 쪽이다. "페일오버 자동화", "라우트 변경 자동 반영", "동적 라우팅" 키워드가 있으면 BGP다.

TGW + ECMP: VPN 대역폭의 선형 확장

단일 VPN 연결의 최대 대역폭은 2개 터널 × 1.25Gbps = 2.5Gbps다. 이것으로도 부족하다면 TGW의 ECMP 기능을 활용한다.

ECMP(Equal-Cost Multi-Path)는 동일한 목적지로 향하는 여러 경로가 있을 때 트래픽을 분산하는 기법이다. TGW에서 ECMP를 활성화하고 같은 BGP ASN을 사용하는 여러 VPN 연결을 추가하면, 각 VPN 연결의 터널들이 ECMP 그룹에 포함되어 트래픽이 분산된다.

온프레미스 Router-A ─── VPN Connection 1 (Tunnel 1, Tunnel 2) ──┐
온프레미스 Router-B ─── VPN Connection 2 (Tunnel 1, Tunnel 2) ──┤
온프레미스 Router-C ─── VPN Connection 3 (Tunnel 1, Tunnel 2) ──┼── TGW (ECMP)
온프레미스 Router-D ─── VPN Connection 4 (Tunnel 1, Tunnel 2) ──┘

이론적 최대: 4 연결 × 2 터널 × 1.25Gbps = 10Gbps
실제 활용 가능: 약 8~10Gbps (ECMP 해시 불균등 감안)

ECMP의 트래픽 분산은 플로우 해시(Flow Hash) 기반이다. 소스 IP, 목적지 IP, 소스 포트, 목적지 포트, 프로토콜의 조합으로 해시 값을 계산하고, 이 값으로 경로를 선택한다. 동일한 플로우(같은 5-tuple)는 항상 같은 경로를 사용하므로 패킷 순서가 보장된다. 단, 플로우 수가 적은 경우(예: 단일 FTP 전송) ECMP의 효과가 미미하다. 이는 ECMP의 근본적 한계로, RFC 2992가 이를 다룬다.

🎯 시나리오: 미디어 스트리밍 회사가 온프레미스 렌더링 팜에서 AWS의 S3로 매일 밤 100GB의 렌더링 결과물을 전송한다. 현재 1개 VPN 연결로 최대 2.5Gbps를 사용하지만 전송 시간이 너무 길다. DX는 프로비저닝에 몇 달이 걸린다. 즉시 해결책은 TGW로 마이그레이션하고 VPN 연결 4개를 ECMP로 구성해 이론상 10Gbps까지 확장하는 것이다. 비용은 VPN 연결 4개 시간당 요금이 추가되지만 DX 구축 기간보다 훨씬 빠르다.

Accelerated Site-to-Site VPN: 글로벌 백본 활용

일반 Site-to-Site VPN은 온프레미스 라우터에서 인터넷을 통해 AWS VPN 엔드포인트까지 공개 인터넷 경로를 이용한다. 한국에서 us-east-1의 VPN 엔드포인트까지 수많은 ISP 홉을 거치면 지연 시간이 불안정해진다.

Accelerated Site-to-Site VPN은 AWS Global Accelerator의 Anycast IP를 VPN 터널의 AWS 측 엔드포인트로 사용한다. 온프레미스에서 인터넷으로 나가는 트래픽이 가장 가까운 AWS 에지 로케이션에 도달하는 순간 AWS 글로벌 백본으로 진입한다. 이후 AWS 백본을 통해 목적지 리전의 TGW로 전달된다.

[한국 온프레미스] ──인터넷~~ [서울 AWS 엣지] ──AWS 백본── [us-east-1 TGW]
                  (홉 적음)  (바로 백본 진입)  (안정적 저지연)

일반 VPN:
[한국 온프레미스] ~~인터넷~~ 수많은 ISP 홉 ~~ [us-east-1 VPN 엔드포인트]
                  (홉 많고 지연 변동 큼)

Global Accelerator는 BGP Anycast를 사용한다. AWS는 전 세계 여러 에지 로케이션에서 동일한 두 개의 정적 IPv4 주소를 광고한다. 인터넷 라우터는 BGP의 최단 경로 알고리즘으로 가장 가까운 에지 로케이션을 선택한다. 이는 DNS 기반 라우팅(Route 53)과 달리 TTL 캐시가 없어 즉각적인 경로 변경이 가능하다. Accelerated VPN은 이 메커니즘을 IPsec 터널 엔드포인트에 적용한 것이다.

Accelerated VPN의 제약: TGW에 연결된 VPN만 지원한다. VGW에 연결된 VPN에는 사용할 수 없다. 추가 비용(Global Accelerator 시간당 요금 + 데이터 처리 요금)이 발생한다.

DPD(Dead Peer Detection): 터널 생존 감지

IKEv2에 내장된 DPD(RFC 3706)는 VPN 피어의 생존 여부를 주기적으로 확인한다. AWS VPN의 기본 DPD 타임아웃은 30초다. DPD 패킷에 응답이 없으면 IKE 세션을 종료하고 터널을 재수립하거나 대안 터널로 전환한다.

DPD는 "On-Demand" 모드와 "Periodic" 모드로 동작한다. On-Demand는 트래픽이 없는 상태에서 일정 시간 후에만 DPD 패킷을 보내는 방식이다. Periodic은 항상 주기적으로 보낸다. AWS VPN은 On-Demand DPD를 사용한다. 이 때문에 트래픽이 전혀 없는 터널에서 피어 장애 감지가 느려질 수 있다. 항상 트래픽을 유지하거나 Periodic DPD를 지원하는 온프레미스 라우터 설정이 권장된다.

VPN 이중화 패턴: 무엇이 어디를 방어하는가

2개 CGW + 4터널 구성이 권장되는 이유는 온프레미스 CGW(라우터) 자체의 장애를 방어하기 때문이다. 단일 CGW 구성에서 CGW 라우터가 다운되면 AWS의 2개 터널이 모두 끊어진다.

[온프레미스 Router-A] ── Tunnel 1 ──┐
                    └── Tunnel 2 ──┤
                                   ├── TGW (BGP ECMP)
[온프레미스 Router-B] ── Tunnel 3 ──┤
                    └── Tunnel 4 ──┘

Router-A 장애 → Tunnel 1, 2 중단 → BGP가 Tunnel 3, 4로 자동 전환

2021년 한 글로벌 제조업체가 온프레미스 → AWS VPN 연결 중 온프레미스 BGP 라우터가 소프트웨어 버그로 재시작됐다. 단일 CGW 구성이었기 때문에 VPN이 완전히 단절됐고, 재수립까지 약 4분이 걸렸다. 이 4분 동안 생산 라인 제어 시스템과 AWS의 통신이 끊어져 알람이 발생했다. 이후 회사는 2개 CGW 구성으로 변경하고 BGP ECMP로 운영해 단일 라우터 재시작 시 트래픽이 다른 CGW로 즉시 전환되도록 했다.

Client VPN: 원격 직원의 VPC 접근

Site-to-Site VPN이 데이터센터 대 AWS를 연결하는 사이트 VPN이라면, AWS Client VPN은 개별 직원 노트북이나 모바일 기기에서 VPC에 접근하는 솔루션이다.

Client VPN은 OpenVPN 프로토콜 기반이다. 클라이언트는 AWS가 제공하는 OpenVPN 클라이언트 또는 호환 클라이언트를 설치하고, 구성 파일을 다운로드해 VPN 서버(Client VPN Endpoint)에 연결한다.

인증 방식 3가지

1. Active Directory 인증: AWS Directory Service 또는 온프레미스 AD와 연동. 사용자가 도메인 자격증명으로 로그인한다.

2. SAML 2.0 연합 (IAM Identity Center): SAML 2.0을 지원하는 IdP(Okta, Azure AD, 등)와 연동. SSO로 VPN 인증이 가능하다. SAP-C02에서 "운영 부담 최소화 + SSO + Client VPN"이면 이 조합이 정답이다.

3. 상호 인증서 인증 (Mutual TLS): 서버 인증서와 클라이언트 인증서 모두 검증. 사용자 ID/PW 없이 인증서만으로 인증한다. 가장 강력한 인증이지만 인증서 관리 부담이 있다.

mTLS(Mutual TLS, RFC 8446)는 TLS 핸드쉐이크에서 서버가 클라이언트에게도 인증서를 요청하는 방식이다. 일반 TLS는 서버만 인증서를 제시하고 클라이언트는 ID/PW로 인증한다. mTLS는 클라이언트 인증서가 탈취되지 않은 장치에서만 연결이 가능하므로, BYOD 환경에서 미승인 기기의 접근을 차단하는 효과가 있다. X.509 인증서(RFC 5280)를 PKI(Public Key Infrastructure)로 관리한다.

Client VPN 비용 구조

Client VPN 비용은 두 가지 요소로 구성된다. Endpoint 시간당 요금: Client VPN Endpoint가 존재하는 시간만큼 AZ당 과금. 연결 시간당 요금: 활성 클라이언트 연결 수 × 연결 시간. 이 구조 때문에 사용자가 없어도 Endpoint를 삭제하지 않으면 비용이 발생한다.

⚠️ 함정: Client VPN Endpoint는 특정 서브넷에 Association하여 AZ에 배치한다. 각 AZ의 가용성을 위해 여러 AZ에 서브넷을 Association해야 한다. 단일 AZ 서브넷만 Association하면 해당 AZ 장애 시 Client VPN도 사용 불가능해진다. 시험에서 "고가용성 Client VPN" 시나리오면 멀티 AZ Association이 정답 구성 요소다.

VGW vs TGW: VPN 연결의 허브 선택

SAP-C02에서 VPN 문제의 전형적인 정답 흐름: "단일 VPC, 대역폭 무관 → VGW", "다중 VPC 또는 ECMP 또는 Accelerated → TGW".

IPsec vs SSL VPN: Client VPN의 프로토콜 선택

AWS Client VPN은 OpenVPN(SSL/TLS 기반)을 사용한다. AWS Site-to-Site VPN은 IPsec을 사용한다.

OpenVPN은 UDP 1194 또는 TCP 443으로 동작한다. 기업 방화벽이 UDP를 차단해도 TCP 443은 HTTPS와 동일한 포트라 거의 모든 네트워크에서 허용된다. AWS Client VPN은 TCP 443을 기본으로 사용한다. 반면 IPsec은 IKE에 UDP 500, NAT 환경에서 UDP 4500(NAT-T)을 사용한다. 엄격한 방화벽 환경에서는 OpenVPN이 더 통과하기 쉽다.

다른 클라우드 VPN과의 비교

(가상 사례) 한 SaaS 기업이 AWS와 GCP를 동시에 사용하는 멀티클라우드 환경을 구축했다. AWS의 Site-to-Site VPN과 GCP Cloud VPN 사이에 IPsec 터널을 연결했다. 두 클라우드 모두 IKEv2와 BGP를 지원하므로 상호 연동이 가능했다. 단, GCP의 HA VPN은 터널당 3Gbps를 지원해 AWS의 1.25Gbps보다 높아 AWS 측 ECMP 구성이 필요했다.

실전 CLI: VPN 완전 구성

# Customer Gateway 생성 (온프레미스 라우터 IP와 ASN)
aws ec2 create-customer-gateway \
  --type ipsec.1 \
  --bgp-asn 65000 \
  --public-ip 203.0.113.1 \
  --device-name "OnPrem-Router-A"
 
# TGW에 연결된 VPN (ECMP를 위해 TGW 사용)
aws ec2 create-vpn-connection \
  --type ipsec.1 \
  --customer-gateway-id cgw-aaa \
  --transit-gateway-id tgw-xxx \
  --options '{
    "EnableAcceleration": true,
    "StaticRoutesOnly": false,
    "TunnelOptions": [
      {
        "TunnelInsideCidr": "169.254.10.0/30",
        "PreSharedKey": "MySecretKey1",
        "IKEVersions": [{"Value": "ikev2"}],
        "DPDTimeoutAction": "restart",
        "DPDTimeoutSeconds": 30
      },
      {
        "TunnelInsideCidr": "169.254.11.0/30",
        "PreSharedKey": "MySecretKey2",
        "IKEVersions": [{"Value": "ikev2"}],
        "DPDTimeoutAction": "restart",
        "DPDTimeoutSeconds": 30
      }
    ]
  }'
 
# TGW ECMP 활성화 확인
aws ec2 describe-transit-gateways \
  --transit-gateway-ids tgw-xxx \
  --query 'TransitGateways[].Options.VpnEcmpSupport'
 
# Client VPN Endpoint 생성
aws ec2 create-client-vpn-endpoint \
  --client-cidr-block 10.100.0.0/22 \
  --server-certificate-arn arn:aws:acm:us-east-1:ACCT:certificate/SERVER-CERT \
  --authentication-options '[{
    "Type": "federated-authentication",
    "FederatedAuthentication": {
      "SAMLProviderArn": "arn:aws:iam::ACCT:saml-provider/Okta"
    }
  }]' \
  --connection-log-options '{"Enabled": true, "CloudwatchLogGroup": "/client-vpn-logs"}' \
  --dns-servers 10.0.0.2
 
# Client VPN Endpoint를 멀티 AZ 서브넷에 Association
aws ec2 associate-client-vpn-target-network \
  --client-vpn-endpoint-id cvpn-endpoint-xxx \
  --subnet-id subnet-az-a
 
aws ec2 associate-client-vpn-target-network \
  --client-vpn-endpoint-id cvpn-endpoint-xxx \
  --subnet-id subnet-az-b

Site-to-Site VPN은 빠른 구축, VPN 백업, DX 대안으로서의 즉시 대역폭 확장을 위해 AWS에서 가장 자주 사용되는 하이브리드 연결 솔루션이다. SAP-C02에서 핵심은 시나리오의 요구사항(대역폭, 지연, 이중화 수준, 사용자 수)을 파악해 VGW vs TGW, Static vs BGP, 일반 vs Accelerated, Site-to-Site vs Client VPN 중 올바른 조합을 선택하는 것이다.