암전된 데스크 위 라우터에서 뻗어 나온 동심원 케이블 터널
글 요약
AWS Site-to-Site VPN 장애 분석의 핵심인 Phase 1, Phase 2, BGP, Tunnel 상태 진단법을 한 번에 정리합니다. 콘솔 로그 해석부터 실제 장애 사례 해결까지, 실무자가 바로 써먹을 수 있는 트러블슈팅 노하우를 담았습니다.
“VPN 터널은 분명 UP인데 사내망에서 AWS 자원에 접속이 안 됩니다.”
AWS Site-to-Site VPN 장애는 단순히 Tunnel 상태만 봐서는 원인을 알 수 없는 경우가 대부분이더라고요. Phase 1, Phase 2, BGP 세션, 라우팅 전파까지 4계층으로 나눠 진단해야 정확한 근본 원인이 보입니다. 이 글에서는 로그 해석법, 상태별 체크리스트, 실제 장애 해결 노하우까지 한 번에 정리합니다.
VPN 콘솔에서 Tunnel State가 UP으로 표시되는데도 내부 서버 통신이 끊기는 현상, 정말 답답하시죠? 많은 분이 “터널이 살아있는데 왜 안 되지?”라고 먼저 의아해하시더라고요. 실제로는 BGP 세션이 Established 상태가 아니거나, Phase 2 SA가 주기적으로 재협상되며 패킷이 드롭되는 등 복합 원인이 얽혀 있는 경우가 많습니다. 오늘은 4계층 진단 체계로 깔끔하게 정리해 드릴게요.
목차
AWS Site-to-Site VPN은 내부적으로 IPsec 프로토콜 스택(IKEv1/IKEv2, ESP/AH), BGP 라우팅 프로토콜, 그리고 AWS 측 Virtual Private Gateway(VGW) 또는 Transit Gateway(TGW)까지 연결되는 다중 계층 구조로 되어 있거든요. 어느 한 계층이라도 문제가 생기면 전체 통신이 영향을 받기 때문에, 어느 곳에서 끊겼는지 정확히 짚어내는 것이 사고 대응의 첫 번째 관문입니다.
📌 이 글의 핵심 정리
- VPN 장애는 4계층(Physical → Phase1 → Phase2 → BGP)으로 나눠야 근본 원인이 보입니다. 콘솔의 Tunnel State 한 줄만으로는 절반만 진단한 셈이에요.
- Phase 1 실패의 90%는 Pre-Shared Key, IKE 버전, Proposal 미스매치에서 발생합니다. 양쪽 디바이스의 ISAKMP 설정을 1:1로 대조해야 합니다.
- Phase 2가 UP인데도 트래픽이 흐르지 않으면 MTU, PFS, Selector(Proxy ID) 불일치를 의심해야 합니다.
- BGP가 Active 상태에 머물러 있다면 ASN, MD5, source-address, TTL 보안 설정을 순서대로 점검합니다.
- CloudWatch 메트릭(TunnelState, TunnelDataIn/Out)과 VPG 로그를 동시에 보는 것이 빠른 진단의 지름길이에요.
- 주기적인 DOWN은 DPD, DPD timeout, Keepalive 주기 불일치에서 비롯되는 경우가 많습니다.
- Direct Connect, Transit Gateway, SD-WAN과의 명확한 차이를 이해해야 적합한 백업/구성 전략이 세워집니다.
1. AWS Site-to-Site VPN 장애, 왜 4계층 진단이 필요한가
현장에서는 VPN이 “안 된다”는 한마디로 모든 장애를 뭉뚱그려 부르는 경우가 많습니다. 하지만 실제 트러블슈팅을 시작하면 ① 물리/인터넷 회선 ② IKE(Phase 1) SA ③ IPsec(Phase 2) SA ④ BGP 피어링이라는 4계층 어디서 끊겼느냐에 따라 접근법이 완전히 달라지거든요. 이 4계층을 모르면 콘솔 로그만 30분 동안 들여다봐도 답이 안 나옵니다.
VPN 4계층 구조 한눈에 보기
각 계층이 살아야 다음 계층이 의미를 가집니다.
| 계층 | 프로토콜 | 확인 명령/위치 | 주요 실패 원인 |
|---|---|---|---|
| L1 인터넷 회선 | UDP 500/4500, ESP 50 | ping, traceroute, NAT/방화벽 | 방화벽 차단, PAT 미설정 |
| L2 Phase 1 (IKE) | ISAKMP/IKEv1·v2 | show crypto isakmp sa | PSK, Proposal 불일치 |
| L3 Phase 2 (IPsec) | ESP/AH, SA SPI | show crypto ipsec sa | Proxy ID, PFS 불일치 |
| L4 BGP 피어링 | BGPv4, MD5 | show ip bgp summary | ASN mismatch, MD5 mismatch |
⚠️ VPN 장애 진단 시 흔한 실수
- 콘솔에서 Tunnel State만 보고 “VPN은 정상”이라고 단정하는 경우. BGP가 Established가 아니면 라우팅이 안 잡혀 트래픽이 흐르지 않습니다.
- AWS 측 VGW만 재부팅하고 CPE(Customer Premises Equipment)는 그대로 두는 경우. 양쪽 모두 동기화해야 합니다.
2. Phase 1 (IKE) 장애 분석과 로그 해석법
AWS Site-to-Site VPN 트러블슈팅용 네트워크 라우터 측면
Phase 1은 양단 디바이스가 서로를 인증하고 ISAKMP/IKE SA를 맺는 첫 단계입니다. 이 단계가 실패하면 그 이후 모든 계층이 의미가 없어요. 콘솔에서 Tunnel State가 DOWN이라면 90%는 Phase 1에서 막혔다고 보시면 됩니다.
Phase 1 실패의 대표 로그 패턴
로그를 읽을 때는 “어디서, 어떤 이유로 끊겼는지” 키워드를 찾는 게 핵심이에요.
- “No proposal chosen” : IKE Proposal(암호화, 해시, DH-group, lifetime)이 양쪽 디바이스 간에 겹치는 게 없을 때 발생합니다.
- “Invalid ID information” : Local/Remote ID(IP 또는 FQDN)가 미스매치된 상태입니다.
- “Authentication failed” : Pre-Shared Key가 한 글자라도 다르면 이 로그가 뜹니다.
- “IKE phase-1 SA lifetime expired” : Lifetime은 정상 만료된 경우로, 재협상 실패가 아니면 단순 만료일 수 있습니다.
AWS 측 권장 IKE Proposal 조합
AWS가 공식 지원하는 알고리즘만 사용해야 호환성이 보장됩니다.
| 항목 | 권장 값 | 비고 |
|---|---|---|
| 암호화 | AES-256-GCM | AES-128도 가능 |
| 해시 | SHA-256 | MD5는 보안상 비권장 |
| DH Group | 14 (2048-bit) | 2(1024)는 legacy |
| Lifetime | 28800초(8h) | 양측 일치 권장 |
3. Phase 2 (IPsec) 장애, 재협상 루프 잡기
Phase 1이 MM_ACTIVE 상태로 살아 있는데도 Tunnel State가 UP으로 표시되지 않거나, 간헐적으로 DOWN을 반복한다면 Phase 2 단계에서 문제가 발생하고 있을 가능성이 높습니다. Phase 2에서는 실제 데이터 트래픽이 암호화될 SA(Security Association)를 협상하기 때문이에요.
Proxy ID(Selector) 미스매치 — 가장 빈번한 원인
AWS의 VGW/TGW는 기본적으로 Proxy ID를 0.0.0.0/0 ↔ 0.0.0.0/0으로 사용하지만, 일부 CPE 장비(특히 Cisco ASA, Fortigate 등)는 별도의 ACL 기반 Proxy ID를 요구합니다. 양쪽의 Proxy ID가 다르면 “received unexpected ID” 로그가 뜨면서 SA가 맺히지 않아요.
💡 Phase 2 재협상 루프 노하우
- SA Lifetime을 양쪽 디바이스에서 동일하게(예: 3600초) 맞추고, Phase 1 만료 시점보다 짧게 두면 자연스러운 재협상이 가능합니다.
- PFS(Perfect Forward Secrecy) Group을 양측 모두 활성화하되 동일 그룹 번호로 설정해야 재협상 실패를 막을 수 있습니다.
MTU와 MSS 문제로 인한 Phase 2 의심 사례
IPsec 터널은 캡슐화 오버헤드 때문에 일반 LAN보다 MTU가 작아져야 합니다. AWS Site-to-Site VPN은 일반적으로 MTU 1436을 권장하고, TCP MSS는 1387로 설정하는 것이 안정적이에요. 이 부분이 누락되면 큰 패킷만 drop되어 “가끔 안 된다”는 미묘한 장애로 나타납니다.
4. BGP 세션 장애, Established가 안 잡힐 때
Phase 1, Phase 2 모두 UP인데도 라우팅이 전파되지 않는다면 BGP 세션이 Established 상태가 아닌 경우입니다. 콘솔에서 “BGP Status”를 확인했을 때 Active, Connect, Idle 중 하나에 멈춰 있다면 다음 순서대로 점검해 주세요.
BGP 상태 코드별 의미와 조치
| 상태 | 의미 | 즉시 조치 |
|---|---|---|
| Idle | 연결 시도 자체가 안 됨 | Peer IP, source-interface 점검 |
| Connect | TCP 179 핸드셰이크 시도 중 | ACL, routing 확인 |
| Active | 상대 응답을 못 받음 | ASN, MD5, peer IP 재확인 |
| Established | 정상 | 라우트 학습 상태 확인 |
AWS VGW BGP 옵션 핵심 3가지
- ASN : 기본 64512이며, 필요 시 변경 가능하지만 CPE의 BGP 설정과 일치해야 합니다.
- IP 주소 : VGW 측 터널 IP와 CPE 측 터널 IP가 정확히 매핑되어야 합니다.
- Hold time / Keepalive : 기본 30초/10초이며, 양측이 다르면 hold-time 협상 규약에 따라 더 작은 값으로 통일됩니다.
5. Tunnel 상태별 진단표와 메트릭 읽기
AWS 콘솔이 보여주는 Tunnel State 값은 표면적인 정보일 뿐, 실제 통신 가능 여부는 BGP와 라우팅 테이블을 함께 봐야 판단됩니다. 그래서 CloudWatch 메트릭과 VPC Flow Logs를 함께 활용하는 것이 핵심이에요.
Tunnel State × BGP Status 조합별 진단
| Tunnel State | BGP Status | 실제 통신 | 원인 추정 |
|---|---|---|---|
| UP | Up | 가능 | 정상 운영 |
| UP | Down | 불가 | BGP 설정 오류 |
| Down | Down | 불가 | Phase 1 또는 회선 장애 |
| Up(간� DOWN) | Up(간헐 Down) | 불안정 | DPD, MTU, 장비 부하 |
CloudWatch 핵심 메트릭 5종
- TunnelState : 0(Down) / 1(Up) 값을 주기적으로 기록합니다.
- TunnelDataIn / TunnelDataOut : 바이트 단위 트래픽 추이, 갑자기 0이 되면 장애 신호예요.
- TunnelPacketLossRate : 손실률이 1% 이상이면 회선 또는 Phase 2 이상을 의심합니다.
- TunnelDataIn/DroppedPackets : 폐기 패킷 카운터로 DPD 실패 패턴 분석에 유용합니다.
⚠️ DPD(Dead Peer Detection) 설정 주의
- AWS는 DPD를 기본 활성화하지만, timeout이 너무 짧게 설정되면 정상 트래픽도 DOWN으로 잘못 감지될 수 있습니다. 10~30초 범위에서 양측을 맞춰 주세요.
6. 실제 장애 사례와 해결 노하우
실무에서 자주 마주치는 대표 실패 사례 하나를 들어볼게요. 어느 금융사의 케이스인데, 평일 낮 시간대만 5분씩 VPN이 DOWN됐다 다시 살아나는 현상이 반복되더라고요.
실패 사례 — BGP Hold Timer 미스매치로 인한 활성 회선 DOWN
원인 분석 과정
처음에는 회선 품질 문제라고 판단해 ISP를 점검했지만 이상이 없었어요. 콘솔 로그를 더 깊이 들여다보니 “BGP neighbor 169.254.x.x (ASxxxxx) Down — BGP Notification sent” 메시지가 주기적으로 떴습니다. CPE 라우터의 BGP Hold Timer가 90초, AWS VGW는 기본 30초였어요. 그런데 문제는 다른 쪽에서 발생했어요. CPE가 트래픽 burst 상황에서 Hold Timer 3배(270초) 동안 keepalive를 못 보내면 AWS 측에서 세션을 끊는데, 그 직후 VGW는 빠르게 재협상하는 반면 CPE는 Down 회선을 Active로 인식한 채 최대 4~5분간 대기가 발생하는 게 원인이었어요. 결국 BFD(Bidirectional Forwarding Detection)를 활성화하고 Hold Timer를 양측 30초로 통일한 뒤 장애가 완전히 사라졌습니다.
� 이런 노하우를 기억하세요
- 장애가 특정 시간대나 트래픽 패턴과 연관되어 있다면 Hold Timer, DPD, 장비 부하를 1순위로 의심합니다.
- BFD 활성화는 sub-second 단위로 회선 장애를 감지할 수 있어 금융·제조처럼 다운타임에 민감한 환경에 매우 효과적이에요.
- 두 개의 터널을 active-active로 운영할 때는 ECMP가 정상 작동하는지, AWS 측에서 ASN을 동일하게 설정했는지 반드시 재확인합니다.
다른 대안들과의 구체적 비교 — VPN vs Direct Connect vs Transit Gateway
| 항목 | Site-to-Site VPN | Direct Connect | SD-WAN / 3rd-party VPN |
|---|---|---|---|
| 구축 속도 | 수 분 | 수 주~수개월 | 수 시간 |
| 대역폭 | 터널당 ~1.25Gbps | 1~100Gbps | 제조사별 상이 |
| 지연/지터 | 다소 높음(인터넷 의존) | 매우 낮음(전용선) | 중간 |
| 비용 구조 | 시간당 과금(저렴) | 포트+전송비(고정) | 라이선스+구독 |
| 가용성 | 인터넷 회선 품질 의존 | 99.9% SLA | 다중 경로 가능 |
이 글만의 차별화된 통찰은, AWS Site-to-Site VPN의 진짜 가치는 단독 사용이 아니라 Direct Connect 백업 회선 또는 SD-WAN의 secondary 터널로 활용될 때 극대화된다는 점이에요. 또한 Transit Gateway와 함께 쓰면数十 개의 VPC를 hub-spoke로 묶어 단일 VPN 엔드포인트로 관리할 수 있어 운영 부담이 크게 줄어듭니다.
자주 묻는 질문
Q. Phase 1이 UP인데 Phase 2가 DOWN으로 표시되는 이유는 무엇인가요?
A. IKE SA는 정상적으로 협상되었지만 IPsec SA 협상 단계에서 실패한 상태입니다. Proxy ID(Selector) 미스매치, PFS 그룹 불일치, Phase 2 lifetime 차이 등이 주요 원인이므로 CPE의 IPsec transform-set과 AWS 측 설정을 1:1로 대조해 보세요.
Q. BGP 세션이 Established 상태가 되기까지 가장 빠르게 확인하는 순서는?
A. ① Peer IP 정확성 → ② ASN 일치 여부 → ③ MD5 비밀번호(설정한 경우) → ④ source-interface에서 BGP advertise IP 노출 여부 → ⑤ inbound/outbound ACL 179 포트 허용 여부를 순서대로 확인하면 대부분 5분 안에 원인을 찾을 수 있습니다.
Q. VPN Tunnel이 하루에 여러 번 주기적으로 DOWN됐다 살아납니다. 어디부터 봐야 할까요?
A. 주기성이 있다면 DPD timeout 또는 Keepalive 간격 미스매치를 가장 먼저 의심해 주세요. 또한 CloudWatch의 TunnelDataIn/DroppedPackets 메트릭이 시점과 일치하는지 확인하면 회선 품질 문제와 설정 문제를 구분할 수 있어요.
Q. VPN 연결을 Transit Gateway로 묶으면 어떤 이점이 있나요?
A.数十 개의 VPC를 단일 VPN 엔드포인트(TGW attachment)로 연결할 수 있어 라우팅과 방화벽 정책을 중앙 집중 관리할 수 있습니다. 또한 Direct Connect, 다른 VPC, 다른 VPN을 같은 TGW에 attach해 hub-and-spoke 토폴로지를 손쉽게 구성할 수 있어요.
Q. Site-to-Site VPN 비용을 절감하려면 어떻게 해야 하나요?
A. VPN 자체는 시간당 과금이지만 데이터 전송 비용이 발생합니다. 동일 리전 내에서는 VPC peering으로 묶고, 리전 간 통신만 VPN으로 라우팅하면 전송 비용을 크게 줄일 수 있어요. 또한 사용하지 않는 시간에는 터널을 삭제해 두는 것도 한 가지 방법입니다.
VPN 장애는 겉으로 보기엔 단순해 보여도 4계층 어디에서 끊겼느냐에 따라 해결법이 완전히 달라집니다. 오늘 정리한 단계별 진단 흐름을 익혀두시면, 새벽 긴급 호출이 와도 침착하게 원인을 좁혀 나갈 수 있을 거예요. 그리고 무엇보다 평상시 Hold Timer, BFD, DPD 값을 문서화해 두는 습관이 장애 대응 시간을 80% 이상 줄여 줍니다.
VPN은 클라우드와 온프레미스를 잇는 가장 보편적인 다리입니다. 그 다리가 무너졌을 때 빠르게 복구할 수 있는 능력, 그것이 곧 클라우드 운영의 실력이라 할 수 있거든요. 오늘의 진단 체크리스트를 북마크해 두고, 실제 장애 상황에서 바로 활용해 보세요.
본 글이 포함하는 모든 설정 가이드와 비교표는 일반적인 운영 경험을 바탕으로 작성된 참고용 정보이며, AWS의 공식 SLA 및 기술 지원은 별도 AWS Support 플랜을 통해 받으실 수 있습니다. 실제 환경에 적용하기 전에는 반드시 테스트 환경에서 충분한 검증을 거치시기 바랍니다. 본 글에 기재된 명령어, 알고리즘 권장값 등은 AWS의 업데이트에 따라 변경될 수 있습니다.
