이 글에서는 Site to Site VPN의 원리를 이해하고 AWS Site to Site VPN 실습과정을 다룹니다. IPsec 프로토콜의 동작 방식, IKE 협상 과정, NAT-T의 필요성, 그리고 VGW/TGW를 활용한 이중화 아키텍처를 설명합니다.
요약
Site to Site VPN은 "가상 사설 네트워크"라는 이름과 달리, 실제로는 인터넷을 통한 Public 통신입니다. 데이터가 암호화되어 있을 뿐, Private 전용선 통신이 아닙니다. 따라서 법적으로 Public 통신이 금지된 환경에서는 Site to Site VPN을 사용할 수 없으며, 이 경우 전용회선 기반 VPN을 검토해야 합니다.
Site to Site VPN이란?
Site to Site VPN은 두 가지 단어를 합친 용어입니다. Site to Site + VPN
- Site
site는 네트워크 영역을 의미합니다.
- Site to Site
site to site는 두개 이상의 네트워크 영역을 연결하는 의미입니다.
- VPN
VPN은 Virtual Private Network의 약어로 가상 사설 네트워크를 의미합니다. 이는 '가상'과 '사설 네트워크'를 결합한 개념입니다. 물리적으로 분리된 네트워크 간에 암호화된 터널을 생성하여 마치 같은 사설 네트워크처럼 안전하게 통신할 수 있게 합니다.
VPN은 공중망 VPN(Internet-based VPN)과 전용회선 기반 VPN(Leased Line-based VPN)으로 나뉩니다. 공중망 VPN은 인터넷망을 통해 암호화된 터널을 생성하고, 전용회선 기반 VPN은 통신사의 전용 네트워크(MPLS 등)를 임대하여 구성합니다. 일반적으로 VPN이라고 하면 공중망 VPN을 의미합니다.
- Site to Site VPN
Site-to-Site VPN은 물리적으로 떨어진 두 개 이상의 네트워크 영역을 공중망 VPN 기술을 통해 연결하는 것을 의미합니다. 네트워크 간 통신 데이터는 암호화됩니다. 또한 아무런 네트워크와 연결하면 안되므로 인증을 수행합니다.

VPN 터널이란?
Site to Site VPN 통신 구간은 public 통신이지만, 데이터가 암호화되어 있어 제3자가 데이터를 해석할 수 없습니다. 이 현상을 마치 터널이 있다고 표현하며 이 터널을 VPN 터널이라고 부릅니다.

VPN의 원리
Site to Site VPN은 IPsec 프로토콜을 사용하여 인증과 데이터 암호화/복호화를 수행합니다. 그래서 VPN 터널을 IPSEC 터널이라고도 부릅니다. 결국 Site to Site VPN의 원리를 이해하는 것은 IPsec 프로토콜을 이해하는 것과 같습니다.

IPSEC이란?
IPsec(Internet Protocol Security)은 IP 계층에서 패킷을 보호하는 프로토콜입니다. 데이터를 암호화하는 것뿐만 아니라, IP 패킷의 출발지/목적지 정보까지 인증하고 무결성을 검증해서 중간에 누군가 패킷을 위변조하거나 재전송 공격을 시도하는 것을 막아줍니다.
IPsec은 전송 모드와 터널 모드로 나뉩니다. 전송 모드는 원본 IP 헤더는 그대로 두고 데이터 부분만 보호하는 방식이고, 터널 모드는 원본 IP 패킷 전체를 새로운 IP 헤더로 감싸서 내부 네트워크 주소까지 숨기는 방식입니다.
또한, IPsec은 여러 프로토콜과 함께 동작합니다. 대표적인 프로토콜로는 IKE, AH, ESP가 있습니다.
- IKE(Internet Key Exchange)는 두 VPN 장비가 서로 신원을 확인하고 암호화에 사용할 키를 안전하게 교환하는 프로토콜입니다.
- AH(Authentication Header)는 데이터 암호화 없이 무결성만 검사합니다.
- ESP(Encapsulating Security Payload)는 실제 데이터를 암호화하고 무결성까지 검증합니다. 데이터를 암호화기 때문에 AH보다 많이 사용합니다.
IPSEC은 모드와 프로토콜의 조합에 따라 보호하는 데이터 범위가 달라집니다.
전송모드 + ESP프로토콜은 데이터만 보호합니다.

터널모드 + ESP프로토콜은 IP헤더와 데이터를 보호합니다.

IKE 협상과정
IKE 프로토콜은 VPN 터널을 맺기 전에 두 VPN 장비가 서로를 인증하고 암호화 방식을 협상하는 역할을 합니다. IKE는 v1와 v2이 있고 v2가 협상과정이 단축되었고 보안이 강화되었습니다. 따라서 IKE v2사용을 권장합니다.
| 구분 | IKEv1 | IKEv2 |
|---|---|---|
| 메시지 교환 횟수 | Phase 1: 6~9회, Phase 2: 3회 | 총 4회 (더 빠름) |
| NAT 통과 | 별도 설정 필요 | 기본 지원 (NAT-T 내장) |
| 연결 복구 | 수동 재협상 필요 | 자동 복구 지원 |
| 보안성 | 일부 취약점 존재 | 보안 강화 |
[IKE v1 프로토콜 협상과정]

[IKE v2 프로토콜 협상 과정]

NAT-T (NAT Traversal)
NAT-T는 NAT 환경에서 IPsec이 정상적으로 동작하도록 지원하는 기술입니다. Site to Site VPN처럼 공중망 VPN을 사용할 때 NAT 환경에서 발생하는 IPsec 호환성 문제를 해결하기 위해 NAT-T가 만들어졌습니다.
IPsec 프로토콜은 패킷의 무결성을 보장하기 위해 IP 헤더를 포함한 데이터의 변조를 탐지합니다. NAT 장비가 IP 주소를 변경하면 IPsec은 이를 비정상적인 변조로 판단하여 패킷을 거부합니다. 그래서 NAT 환경에서 IPsec을 사용하기 위해 VPN 장비가 IPsec 패킷을 UDP로 캡슐화하여 4500/UDP 포트로 전송합니다. 이렇게 하면 NAT 장비는 일반 UDP 트래픽으로 인식하여 포트 기반 주소 변환을 정상적으로 수행할 수 있습니다.

IKE에서 신원확인
VPN은 무단으로 네트워크에 연결되는 것을 방지하기 위해 신원 확인이 필요합니다. 신원 확인 방식은 2가지입니다.
- PSK(Pre-Shared Key): 양측이 미리 약속한 문자열(키)을 공유하고, IKE 협상 과정에서 키가 일치하는지 확인합니다.
- 인증서: Private CA를 사용해 각 사이트에 인증서를 발급합니다. IKE 협상 과정에서 각 사이트는 Private CA의 공개키로 상대방의 인증서를 검증합니다.

방화벽 허용 설정
IPsec VPN을 구축할 때 방화벽에서 다음 포트를 허용해야 합니다.
| 프로토콜 | 포트 | 용도 |
|---|---|---|
| UDP | 500 | IKE 협상 (키 교환) |
| UDP | 4500 | NAT-T (캔슐화된 ESP) |
| IP Protocol | 50 (ESP) | 암호화된 데이터 전송 |
AWS Site to Site VPN
정의
AWS Site to Site VPN은 관리형 Site to Site VPN 서비스입니다. 이를 사용하면 VPC를 다른 네트워크 영역과 연결할 수 있습니다.

성능제한
AWS Site to Site VPN의 대표적인 성능 제한은
- 대역폭 제한(Bandwidth): 각 VPN 터널은 1.25 Gbps과 5 Gbps 대역폭을 선택할 수 있습니다.
- MTU 및 패킷 크기: 점보 프레임(Jumbo Frames)은 지원되지 않습니다. 최대 전송 단위(MTU)는 1446 bytes입니다.
주의사항
AWS Site to Site VPN을 사용한다면, VPN 터널이 주기적으로 끊긴다는 사실을 알아야합니다. AWS는 보안패치 등을 위해 정기으로 유지보수(maintenance)를 합니다. 이 작업이 진행되는 동안 VPN 터널 연결이 끊길 수 있습니다.
서비스 가용성이 중요하다면 반드시 VPN터널을 2개이상 구축해야 합니다. 또한 한쪽 VPN터널이 끊기면 자동으로 다른 터널으로 라우팅되도록 설정해야 합니다.

아키텍처
AWS Site to Site VPN을 직접 구축할 때 자주 사용하는 아키텍처는 2가지입니다. 아래 아키텍처는 VPN 터널 2개를 연결합니다.
- VGW를 사용하는 아키텍처(Active-Standby)
VGW(Virtual Private Gateway)를 사용하는 아키텍처는 터널을 Active-Standby로 관리합니다. 즉 실시간으로 사용할 수 있는 VPN터널은 1개뿐입니다. 만약 Active VPN터널이 끊기면 Standby가 Actvie터널이 됩니다.

- TGW를 사용하는 아키텍처
TGW를 사용하는 아키텍처는 VPN터널을 Active-Active로 관리합니다. 무조건 Active-Active가 아니라 TGW와 Site to Site VPN이 연결하는 VPN장비 모두가 ECMP프로토콜을 지원해야 합니다.

ECMP는 VPN 터널 간 트래픽을 균등하게 분산하는 기술입니다.

터널 이중화
AWS Site to Site VPN을 만들면 기본으로 VPN터널 2개를 제공합니다. VPN구축과정에서 2개의 VPN터널을 연결하면 터널 이중화가 됩니다.

장비 이중화
AWS Site to Site VPN이 연결하는 상대방 VPN 장비가 1개라면, VPN 터널을 이중화해도 장비에 장애가 발생하면 VPN 통신이 불가능합니다.
따라서 VPN 터널 이중화 시 장비 이중화도 함께 고려해야 합니다. 장비 이중화를 위해서는 Site to Site VPN을 연결할 VPN 장비가 2개 필요합니다. VPN장비를 2중화하면 VPN터널은 총 4개가 생성됩니다.

Site to Site VPN을 헷갈리면 안되는 점
Site to Site VPN은 공중망 VPN을 사용하기 때문에 인터넷을 통한 public 통신을 의미합니다. private 통신을 의미하는게 아닙니다. VPN을 사용해 연결된 네트워크에 접근할 수 있어 private 통신처럼 보일 수 있지만, 실제로는 public기반 암호화 통신입니다.
따라서 Site to Site VPN을 적용할 때 법적 요건상 public 통신이 허용되는지 반드시 확인해야 합니다. 만약 법적 요건에서 public 통신이 허용되지 않는다면 전용회선 VPN을 사용해야 합니다. AWS에서 전용회선 VPN을 사용하려면 Direct connect와 Site to Site VPN을 같이 사용해야 합니다.

Site to Site VPN을 사용할 때 보안관점에서 주의해야할 것
Site to Site VPN은 서로 다른 네트워크를 연결하므로, VPN 터널이 생성되는 순간 상대방 네트워크의 모든 리소스에 접근할 수 있습니다. 따라서 다른 회사와 Site to Site VPN을 구축할 때는 라우팅을 신경써야합니다. 또는 VPN 전용 네트워크 영역을 별도로 만들고 VPN으로 접근이 필요한 리소스만 선택적으로 라우팅해야 합니다.

실습
실습은 저의 github에 공개되어 있습니다. TGW와 BGP를 사용해서 Active-Active VPN터널을 실습합니다.
참고자료
- https://dev.classmethod.jp/articles/site-to-site-vpn-bgp-logging-vpn-tunnels
- https://docs.aws.amazon.com/vpn/latest/s2svpn/turn-elc-off.html
- https://docs.aws.amazon.com/ko_kr/whitepapers/latest/aws-vpc-connectivity-options/aws-direct-connect-site-to-site-vpn.html
- https://docs.aws.amazon.com/vpn/latest/s2svpn/your-cgw.html
- https://aws.amazon.com/ko/blogs/networking-and-content-delivery/scaling-vpn-throughput-using-aws-transit-gateway/
- https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/aws-transit-gateway-vpn.html
- https://aws.amazon.com/ko/blogs/aws/ec2-vpc-vpn-update-nat-traversal-additional-encryption-options-and-more/
- https://www.sharetechnote.com/html/IP_Network_IPSec_ESP.html
'전공영역 공부 기록' 카테고리의 다른 글
| DB비밀번호 없이 AWS RDS 접속하는 방법 (feat, RDS IAM 인증) (0) | 2026.01.18 |
|---|---|
| OIDC란? GitHub Actions 인증 사례로 알아보기 (0) | 2026.01.04 |
| OAuth프로토콜 (0) | 2026.01.01 |
| EKS ALB controller에서 gateway API 사용하는 방법 (0) | 2025.12.30 |
| Kubernetes Gateway API 간단히 알아보기 (2) | 2025.12.30 |