IPsec VPN 터널 Phase1 Phase2 DPD 장애 분석을 돋보기와 자물쇠로 표현한 이미지
글 요약
IPsec VPN 터널 장애 분석은 Phase 1 협상, Phase 2 협상, DPD 상태, Rekey 흐름을 순차적으로 점검해야 근본 원인이 보입니다. 이 글에서는 실무에서 자주 겪는 실패 사례와 비교 분석, 그리고 단계별 대응 절차를 정리합니다.
“VPN 터널이 자꾸 끊어지는데 로그만 봐서는 뭐가 문제인지 모르겠어요.”
IPsec VPN 장애의 90%는 Phase 1, Phase 2, DPD, Rekey 네 가지 키워드로 환원됩니다. 로그를 어디서부터 봐야 하고, 어떤 카운터 값이 끊겼을 때 무엇을 의심해야 하는지, 한 번에 정리해 드립니다.
현업에서 VPN 터널 장애를 맡아 본 엔지니어라면 한 번쯤은 “ping은 되는데 내부 망이 안 잡힌다”거나 “새벽에만 자꾸 끊긴다”는 모순적인 증상을 마주친 적이 있을 거예요. 단순히 라우팅이나 방화벽만 의심하다 보면 시간을 꽤 쓰게 되더라고요. IPsec은 협상 단계가 여러 개라서, 어느 단계에서 실패했는지를 먼저 가려내야 정확한 원인에 도달할 수 있습니다.
그렇다고 모든 로그를 처음부터 끝까지 읽을 필요는 없어요. 핵심은 Phase 1의 IKE SA가 살아 있는지, Phase 2의 Child SA가 정상 협상됐는지, DPD로 상대_peer가 살아 있는지, Rekey가 주기적으로 정상 갱신되는지 네 가지를 분리해서 보는 습관을 들이는 겁니다. 이 글에서는 그 네 가지 관점에서 장애를 읽는 방법과, 흔히 빠지기 쉬한 실수 사례, 그리고 다른 VPN 솔루션과의 비교까지 한 번에 다루어 볼게요.
목차
📌 이 글의 핵심 정리
- IPsec 터널 장애는 네 가지 협상 단계(Phase 1, Phase 2, DPD, Rekey)로 분류해서 접근하면 로그가 한결 읽기 쉬워집니다.
- Phase 1은 IKE SA 협상 단계이며, 사전키(PSK) 불일치, ISAKMP 정책 mismatch, 인증서 만료가 주요 원인이에요.
- Phase 2는 암호화 트래픽을 위한 Child SA 단계로, Proxy-ID(흥미 트래픽) 불일치와 PFS 그룹 mismatch가 가장 흔합니다.
- DPD 실패는 단절 후 복구 지연으로 나타나며, 대부분 keepalive 주기 불일치와 NAT 환경에서 발생합니다.
- Rekey 실패는 Lifetime 도달 시 새 SA 협상 실패를 의미하며, crypto map과 tunnel interface 환경에서 다르게 동작합니다.
- SSL VPN, WireGuard 등 대안과 비교했을 때 IPsec은 L3 정책 기반 제어가 강점이지만 운영 복잡도가 더 높습니다.
IPsec VPN 터널의 기본 구조와 협상 단계
IPsec VPN은 단순히 한 번 연결되고 끝나는 프로토콜이 아니에요. 두 단계의 협상(Phase 1, Phase 2)과 연결 유지(DPD), 그리고 주기적 갱신(Rekey)이 한 묶음으로 돌아가는 구조입니다. 이걸 모르고 로그를 보면, 같은 줄이 반복되는 것 같아서 어디가 핵심인지 놓치기 쉬워요.
협상 단계별 역할 정리
Phase 1(ISAKMP/IKE SA)은 관리 채널을 안전하게 만드는 단계예요. 여기가 성립해야 다음 단계로 갈 수 있거든요. 보통 IKEv1은 Main Mode 6패킷, Aggressive Mode 3패킷으로 나뉘고, IKEv2는 4패킷으로 단순화돼 있습니다.
Phase 2(IPsec SA/Child SA)
Phase 2는 실제 데이터를 암호화할 SA를 만드는 단계예요. ESP 터널/트랜스포트 모드, 암호 알고리즘, 인증 알고리즘, PFS(Perfect Forward Secrecy) 사용 여부 등을 여기서 협상합니다. Proxy-ID(또는 Traffic Selector)로 보호할 대역을 명시하기 때문에, 양쪽 대역 정의가 다르면 여기서 무조건 협상이 깨져요.
DPD와 Rekey
DPD는 상대 peer가 살아 있는지 주기적으로 확인하는 메커니즘이고, Rekey는 SA가 만료되기 전에 새 SA로 미리 교체하는 절차입니다. 이 두 개가 정상 동작해야 한 번 잡힌 터널이 오랫동안 유지돼요.
Phase 1(IKE) 단계 장애 분석
Phase 1이 실패하면 로그에는 보통 “ISAKMP SA not found”, “no proposal chosen”, “pre-shared key mismatch” 같은 메시지가 남습니다. 이 단계에서 망설이면 시간을 많이 쓰게 되는데, 사실 체크포인트는 다섯 가지로 압축돼요.
Phase 1 체크포인트 5가지
- Phase 1 정책 일치: encryption(AES-256 등), hash(SHA-256 등), DH group(14/19/20), authentication method(PSK/cert) 일치 여부
- 사전 공유 키(PSK) 정확성: 공백, 특수문자, 페어링 순서(좌→우 vs 우→좌)까지 확인
- ISAKMP 피어 IP 도달성: UDP 500 / 4500(NAT-T) 패킷이 양방향으로 통과하는지
- 인증서 유효성: 인증서 방식일 경우 CA 체인, 만료일, CRL/OCSP 상태
- Aggressive Mode의 ID 노출: PSK + Aggressive Mode는 ID 평문 노출로 보안상 권장되지 않음
⚠️ Phase 1 장애 주의
- PSK 오타는 대소문자/공백 단 하나 차이로도 협상 실패로 이어지므로, 양쪽 장비에서 키를 동일하게 export/import 하는 절차를 표준화하세요.
- 중개 방화벽이 UDP 500/4500을 막고 있는 경우가 생각보다 많습니다. 협상 자체가 시작조차 안 되는 경우엔 가장 먼저 확인해 보세요.
실무에서 자주 보는 실패 사례
한 지사에서 본사 VPN 장비와 연결이 자꾸 안 됐던 적이 있었어요. 양쪽 설정을 줄 단위로 비교했는데, DH group만 14와 2로 어긋나 있어서 협상이 안 잡히는 상황이더라고요. 로그에는 “no proposal chosen”이라고만 찍혀 있어서, 암호화나 해시 알고리즘을 의심하고 시간 보내다가 결국 DH group 매트릭스 표를 만들어서 발견한 케이스였습니다.
실패 사례의 본질
이처럼 설정은 “맞다”고 믿지만 협상이 안 된다면, 가장 먼저 의심해야 할 것은 정책 그룹 매트릭스입니다. Phase 1은 양쪽 장비가 같은 “조합”을 가지고 있어야만 성립하기 때문에, 한쪽이라도 다른 값을 갖고 있으면 즉시 fail로 처리돼요.
Phase 2(IPsec SA) 단계 장애 분석
Phase 1은 멀쩡한데 Phase 2가 자꾸 안 잡히는 경우가 있어요. ping은 되는데 특정 대역만 안 통한다거나, IKE SA는 있는데 Child SA가 안 보인다는 증상이면 거의 Phase 2 문제입니다.
Phase 2 핵심 변수
Proxy-ID / Traffic Selector
Cisco는 crypto ACL, Juniper는 proxy-id, paloalto/fortigate는 local/remote network로 불려요. 양쪽에서 보호할 대역이 정확히 일치하거나, wildcard로 호환되는 형태여야 합니다. 10.1.0.0/16과 10.1.1.0/24는 다르다는 점이 핵심이에요.
PFS(Perfect Forward Secrecy) 그룹
PFS가 활성화돼 있으면 Phase 2마다 DH 교환을 다시 합니다. 한쪽만 켜져 있으면 협상 불일치로 fail로 떨어져요.
ESP 알고리즘 / AH 사용 여부
ESP와 AH는 따로 놀아요. 한쪽이 AH, 한쪽이 ESP만 허용하면 협상 자체가 성립하지 않습니다.
💡 Phase 2 분석 꿀팁
- show crypto ipsec sa 또는 equivalent 명령으로 encrypt/decrypt 카운터가 동시에 증가하는지 확인하면, SA가 실제로 트래픽을 처리 중인지 즉시 알 수 있어요.
- transform-set 조합 표를 미리 만들어 두면 장애 발생 시 양쪽을 빠르게 비교할 수 있습니다. Excel 한 장이면 충분합니다.
DPD 장애와 Peer 연결성 문제
DPD는 한 번 잡힌 터널이 상대방이 살아 있는지 확인하는 헬스체크예요. NAT 환경이나 어중간한 인터넷 회선에서 특히 문제가 많이 발생합니다. 증상은 “5분마다 자꾸 끊긴다”, “트래픽이 잠시 멈췄다 다시 살아난다” 같은 형태로 나타나죠.
DPD 파라미터 핵심
- DPD interval: DPD 패킷을 보내는 주기(보통 10초)
- DPD timeout / retry: 응답이 없을 때 재시도 횟수와 간격
- DPD on-demand vs periodic: 트래픽이 있을 때만 검사할지, 주기적으로 검사할지
- 한 쪽만 DPD가 활성화되어 있으면, 상대는 자기가 끊긴 줄 모르고 계속 패킷을 던지는 현상이 생겨요.
NAT 환경에서의 특수성
NAT-Traversal(NAT-T)이 활성화돼야 UDP 4500으로 캡슐화돼요. NAT 매핑이 만료되면 keepalive로 빠르게 rebind 해줘야 하는데, 이게 비활성화돼 있으면 DPD가 자꾸 fail로 떨어져서 터널이 자주 끊깁니다.
Rekey, Lifetime, 그리고 다른 VPN 솔루션과의 비교
Rekey는 SA Lifetime이 만료되기 전에 새 SA로 미리 교체하는 절차예요. 보통 lifetime의 75~90% 시점에 자동 협상이 시작돼요. 만약 Rekey가 실패하면 어떻게 될까요? 기존 SA가 만료된 시점에 트래픽이 한 번 끊기고, 새 SA 협상부터 다시 시작됩니다. 그래서 “정시마다 끊김” 같은 증상이 나타나죠.
Rekey 관련 체크포인트
- Phase 1 lifetime: 보통 86400초(24시간)
- Phase 2 lifetime: 3600초(1시간) ~ 28800초(8시간) 사이에서 운영
- 시스템 클럭 차이: 양쪽 장비 시간 차이가 크면 Rekey 타이밍이 어긋날 수 있음
- Crypto map vs Tunnel interface: Cisco ASA와 IOS, 그리고 vEdge 등 구현체마다 Rekey 동작 특성이 다름
IPsec VPN vs 다른 VPN 솔루션 비교
IPsec이 만능은 아니에요. 최근엔 WireGuard, SSL VPN, MPLS 등으로 갈아타는 조직이 많습니다. 각 솔루션의 차별점을 정확히 이해해야, 도입이나 마이그레이션 결정도 합리적으로 내릴 수 있어요.
이 표를 보면 IPsec이 가장 강력한 L3 정책 제어와 site-to-site 확장성을 갖지만, 그만큼 운영 복잡도가 높다는 점이 명확해요. 이 글만의 차별화된 통찰은, 복잡한 만큼 트러블슈팅 절차 자체가 표준화돼 있다는 점이죠. Phase 1/2/DPD/Rekey로 분리해서 보는 사고방식 자체가 곧 IPsec 장애 분석의 표준 프레임워크가 됩니다.
실무 장애 대응 절차와 체크리스트
실무에서 IPsec 장애를 받을 때는 순서가 중요해요. 순차적으로 좁혀가는 작업 흐름이 없으면, 끝없이 설정을 들여다보는 함정에 빠질 수 있습니다.
표준 대응 절차 7단계
1단계: 증상 확정
“터널이 아예 안 잡힌다 / 한 번 잡혔는데 끊겼다 / 특정 트래픽만 안 된다” 중 어디에 해당하는지 먼저 확정합니다.
2단계: 물리/네트워크 도달성
ping, traceroute, UDP 500/4500 포트 도달성 확인. 중개 방화벽 ACL 점검.
3단계: Phase 1 로그 분석
IKE SA 상태, 협상 실패 메시지, 정책 그룹 mismatch 확인.
4단계: Phase 2 로그 분석
Proxy-ID 매칭, PFS 활성 여부, transform-set 일치 확인.
5단계: DPD / keepalive 검증
주기적 DPD 카운터, NAT 환경 keepalive 동작 확인.
6단계: Rekey 동작 검증
lifetime 직전 정상 갱신이 일어나는지, 시스템 클럭 차이는 없는지.
7단계: 데이터 트래픽 확인
encrypt/decrypt 카운터 증가, 라우팅/방화벽 정책 정상 동작.
⚠️ 장애 대응 주의
- 한 번에 여러 설정을 동시에 바꾸지 마세요. 어느 변경이 효과를 냈는지 추적이 불가능해집니다.
- 로그 수집은 시간 동기화(NTP) 후 진행해야 DPD, Rekey 같은 시간 기반 이벤트의 상관관계를 잡을 수 있어요.
자주 묻는 질문
Q. IPsec 터널은 정상으로 보이는데 특정 대역만 통신이 안 될 때는 어떻게 하나요?
A. 대부분 Phase 2의 Proxy-ID(흥미 트래픽) 매칭 문제입니다. 양쪽 장비에서 보호할 대역 서브넷과 mask가 정확히 일치하는지 확인해 보세요. 10.1.0.0/16과 10.1.1.0/24처럼 표면상 비슷하지만 실제로는 다른 경우가 많아요.
Q. “no proposal chosen” 메시지가 계속 나오면 원인이 뭔가요?
A. Phase 1의 encryption, hash, DH group, authentication 조합이 양쪽에서 일치하지 않을 때 발생합니다. 정책 그룹을 표로 만들어서 한 줄씩 대조해 보는 게 가장 빠른 방법이에요.
Q. 새벽 특정 시간에만 VPN이 끊기는 현상은 어디를 봐야 하나요?
A. 대부분 Rekey 실패입니다. Phase 2 lifetime에 도달해서 새 SA를 협상하려는데 실패하는 케이스로, 변환 집합(transform-set)과 PFS 설정부터 확인해 보세요.
Q. NAT 환경에서 IPsec 터널이 자주 끊기는 이유는 무엇인가요?
A. NAT-T(UDP 4500 캡슐화) 미활성화나 NAT 매핑 만료 후 keepalive 부재가 원인인 경우가 많습니다. DPD와 NAT keepalive를 둘 다 활성화해 주세요.
Q. IKEv1과 IKEv2 중 어느 쪽을 쓰는 게 좋나요?
A. 가능하다면 IKEv2를 권장합니다. 협상 패킷이 절반으로 줄고, NAT-T, MOBIKE, EAP 지원 등 보안과 유연성 모두에서 advantage가 있어요.
Q. SA 카운터(encrypt/decrypt)가 한쪽만 증가하는 건 정상인가요?
A. 정상입니다. inbound는 decrypt, outbound는 encrypt 카운터가 증가합니다. 양쪽이 동시에 증가하지 않으면 비대칭 트래픽이거나 SA가 한쪽만 살아 있는 상태일 수 있어요.
IPsec VPN 터널 장애는 결국 네 가지 키워드(Phase 1, Phase 2, DPD, Rekey)로 환원됩니다. 이 프레임워크를 머릿속에 두고 로그를 읽으면, 어디서 협상이 무너졌는지 한눈에 들어와요. 처음엔 어렵게 느껴지더라도, 사례를 몇 개 직접 추적해 본 뒤엔 “아, 이건 Phase 1 문제네”라는 감각이 자연스럽게 생기더라고요. 오늘 정리한 체크리스트를 출력해서 책상에 붙여 두고, 장애가 발생할 때마다 한 단계씩 좁혀가며 활용해 보세요.
이 글이 실무에서 VPN 터널 장애를 분석할 때 조금이나마 도움이 되었으면 합니다. 네트워크 엔지니어링은 결국 “순서대로 보는 힘”이 가장 큰 무기인데, IPsec은 그 순서를 가장 명확하게 정의해 둔 프로토콜이기 때문에 오히려 공부할 가치가 큽니다.
본 글의 내용은 일반적인 IPsec VPN 트러블슈팅 경험을 바탕으로 정리된 정보이며, 특정 벤더 환경이나 제품 버전에 따라 세부 동작이 달라질 수 있습니다. 실제 장애 대응 시에는 반드시 해당 장비의 공식 매뉴얼과 벤더 지원 문서를 함께 확인하시기 바랍니다. 본 내용으로 인해 발생하는 직접·간접적 손해에 대해 책임지지 않습니다.
