FortiGate 이중 터널 IPsec VPN SD-WAN 페일오버 스위치 LED 평면 배치
글 요약
FortiGate IPsec VPN 이중화는 단일 터널의 단절 리스크를 없애기 위한 필수 설계입니다. Dual Tunnel 구조와 SD-WAN Health Check를 결합하면 한 회선이 끊겨도 자동 Failover로 업무 공백을 최소화할 수 있거든요. 이 글에서는 구성 절차뿐 아니라 실무에서 자주 겪는 시행착오와 다른 솔루션과의 차이점까지 한 번에 정리했습니다.
“VPN 터널 하나만 두고 운영하다가 본사 연결이 끊겨서凌晨에 출근했던 적 있지 않으세요?”
단일 IPsec 터널은 구조적 취약점을 안고 있거든요. 본문에서는 Dual Tunnel과 SD-WAN Health Check를 엮어 자동 Failover가 동작하는 VPN 이중화 설계 전 과정을 다룹니다. 회선 품질 기준, 라우팅 우선순위, 흔한 실패 사례와 노하우까지 한 자리에서 확인하실 수 있습니다.
많은 분들이 IPsec VPN을 단순히 “암호화된 터널”이라고만 이해하시더라고요. 실제로는 양 끝단 장비의 라우팅, DPD, PFS 같은 세부가 한 줄이라도 어긋나면 터널이 up 상태처럼 보여도 트래픽이 흐르지 않는 경우가 허다합니다. 한 회선에 터널을 올린 구성이라면 ISP 장애나 BGP 경로 문제 시 본사 업무가 사실상 마비되거든요. 이 때문에 Dual Tunnel + SD-WAN 조합이 사실상 표준으로 자리 잡았습니다.
📑 목차
본문은 네트워크 엔지니어가 실제 구성 시 참고할 수 있도록 CLI/GUI 핵심 명령과 설정값 기준을 함께 담았습니다. 단순 개념 정리가 아니라, “왜 이렇게 설정해야 하는가”에 대한 판단 근거까지 드리는 데 초점을 맞췄습니다.
� 이 글의 핵심 정리
- 단일 IPsec 터널은 ISP 단일 장애점에 노출되므로 Dual Tunnel 구조가 사실상 필수입니다.
- SD-WAN Health Check의 서버 선정 기준과 패킷 손실 임계값이 Failover 품질을 좌우합니다.
- 라우팅 우선순위(Distance/Preference)는 Active-Passive를 결정짓는 가장 중요한 값입니다.
- 터널이 up으로 보여도 트래픽이 흐르지 않는 블랙홀 구간을 진단하는 절차가 필요합니다.
- Cisco DMVPN, AWS VPN 등 대안과 비교해 FortiGate SD-WAN의 차별점은 정책 기반 라우팅 통합입니다.
- 정기적인 Failover Drill을 통해 실제로 전환이 되는지 검증해야 설계가 의미를 갖습니다.
IPsec VPN 이중화가 필요한 이유
단일 터널의 구조적 한계
본사-지사 구간에 IPsec VPN을 하나만 구성하면 물리 회선 1회선 + 터널 1개라는 이중 단일 장애점이 생깁니다. 실제로 저는 지사에서 쓰던 광케이블이 단선된 적이 있는데, 당시 VPN은 up 상태로 표시되더라고요. 원인은 CPE 장비에서 ISP 측 인터페이스만 죽고 IPsec SA 자체는 만료 전까지 남아 있었기 때문입니다. 이처럼 단순히 터널 상태만 보는 모니터링은 위험합니다.
이중화로 얻는 세 가지 가치
첫째, 가용성입니다. 한 회선이 끊겨도 다른 회선으로 즉시 우회되므로 업무 공백이 줄어듭니다. 둘째, 성능 분산입니다. 평상시에는 양쪽 터널에 트래픽을 분산시켜 대역폭을 효율적으로 쓸 수 있습니다. 셋째, 유지보수 편의성입니다. 한쪽 회선을 점검하더라도 반대쪽으로 운영이 이어지거든요. 이 세 가치를 동시에 확보하는 것이 Dual Tunnel + SD-WAN 설계의 핵심 목적입니다.
⚠️ IPsec VPN 설계 주의
- 두 회선은 반드시 다른 ISP를 사용해야 합니다. 동일 ISP 백본 장애 시 이중화 의미가 사라집니다.
- 각 터널은 서로 다른 Phase1/Phase2 Proposal을 가져도 되지만, PFS/DPD 설정값은 일관되게 맞추는 게 운영상 안전합니다.
Dual Tunnel 기본 구성과 동작 원리
FortiGate 방화벽 이중 IPsec VPN 터널 LED와 SD-WAN 페일오버 표시등이 빛나는 측면 클로즈업
두 개의 Phase1 인터페이스 구성
FortiGate에서 Dual Tunnel은 phase1-interface를 두 개 만들고 각각 wan1, wan2에 바인딩하는 방식으로 시작합니다. CLI 기준 핵심 흐름은 ike-vpn 터널을 두 개 만든 뒤, phase2 selector로 내부 서브넷을 각각 지정해주는 것이거든요. GUI에서도 VPN → IPsec Tunnels 메뉴에서 동일한 작업을 수행할 수 있습니다.
CLI 핵심 구성 예시
- config vpn ipsec phase1-interface / edit “TO-HQ-PRI” / set interface “wan1” / set remote-gw <HQ IP>
- edit “TO-HQ-SEC” / set interface “wan2” / set remote-gw <HQ IP2> / next / end
- config vpn ipsec phase2-interface에서 각 터널에 대응하는 source/dst subnet 지정
라우팅 테이블에서의 우선순위
두 개의 phase1이 만들어지면 FortiGate는 자동으로 정적 라우팅 두 개를 생성합니다. 여기서 핵심은 distance 값입니다. 보통 Primary 터널은 10, Secondary 터널은 20으로 지정하여 평상시에 Primary로만 트래픽이 흐르게 만듭니다. Secondary는 Primary 경로가 사라질 때만 활성화되는 형태거든요. Active-Active로 운영하려면 별도로 ECMP 설정을 추가해야 합니다.
💡 Dual Tunnel 구성 꿀팁
- Primary/Sec 터널에 동일한 Phase2 selector를 두면 라우팅 우선순위만으로 Failover가 깔끔하게 동작합니다.
- DPD는 on-demand로 두는 것보다 on-detection으로 설정해야 회선 장애를 더 빠르게 감지합니다.
SD-WAN 연동으로 자동 Failover 구현
SD-WAN Zones와 Members 정의
FortiGate SD-WAN은 두 VPN 터널을 SD-WAN Member로 등록하고, 동일한 virtual-wan-link Zone에 묶어 관리합니다. 이렇게 하면 트래픽 흐름은 SD-WAN 규칙이 결정하거든요. System → SD-WAN → Zones에서 “virtual-wan-link”를 선택하고 Members 탭에서 두 VPN 인터페이스를 추가해주시면 됩니다.
Health Check로 회선 품질 측정
자동 Failover의 핵심은 Health Check입니다. 단순히 터널 up/down만 보는 게 아니라, 실제 ping/HTTP probe로 품질을 측정합니다. 서버는 본사 측 내부 IP 또는 VPN 터널 너머의 안정적인 호스트를 지정해야 합니다. 외부 DNS(예: 8.8.8.8)는 ISP DNS 영향까지 섞여 측정값이 흔들리거든요.
Health Check 권장 기준
- Probe: Ping 또는 HTTP (HTTP는 응답 코드까지 검증 가능)
- Interval: 500ms~1000ms (민감하게 잡되 시스템 부하 고려)
- Failover threshold: 3회 연속 실패 시 회선 down으로 판정
- Restore threshold: 5회 연속 성공 시 복구
Performance SLA와 우선순위 규칙
SD-WAN Rules에서 Performance SLA를 매핑하면, 패킷 손실·지연·지터 기준으로 우선순위를 매길 수 있습니다. 본사 업무망(예: ERP, 사내 메신저) 트래픽은 Primary 우선, 일반 인터넷 트래픽은 부하 분산처럼 정책을 분리하시는 게 일반적이더라고요. 이 구분이 있어야 Failover 시에도 업무 영향도가 최소화됩니다.
실무에서 겪는 실패 사례와 해결 노하우
대표적인 시행착오: 터널은 살아있는데 트래픽이 흐르지 않는 경우
실제로 제가 겪었던 사례입니다. 지사 FortiGate에서 get vpn ipsec tunnel summary를 보면 양쪽 터널 모두 “up”으로 표시되어 있었어요. 그런데 본사 ERP 서버에 ping이 안 가더라고요. 원인은 SD-WAN Health Check의 probe target이 본사 VPN 터널 너머가 아닌 외부 DNS였고, ISP DNS 응답이 일시적으로 느려지면서 Primary 회선이 down으로 잘못 판정되었습니다. 동시에 Secondary 회선은 정상인데 라우팅 distance 차이로 인해 Secondary 쪽 ping이 막혀 있는 상황이었습니다.
해결 노하우: 진단 4단계
- 1단계 — diagnose vpn ike gateway list로 phase1 SA 상태를 확인합니다. SA가 비정상 만료 상태라면 재협상 트리거 필요.
- 2단계 — get router info routing-table all에서 두 VPN 라우트가 모두 존재하고 distance가 의도대로인지 점검합니다.
- 3단계 — SD-WAN 상태는 diagnose sys sdwan member로 확인하고, Health Check의 최근 latency/jitter/packetloss 로그를 봅니다.
- 4단계 — diagnose sniffer packet any ‘host [본사 IP]’ 4로 실제 패킷이 어느 인터페이스로 나가는지 추적합니다.
💡 Failover 설계 꿀팁
- Health Check probe target은 반드시 VPN 터널 내부 IP로 잡아야 회선 품질을 정확히 측정할 수 있습니다.
- Primary 회선 장애 시 이중 검사가 되도록 두 가지 SLA(Ping + HTTP)를 동시에 두는 것이 안전합니다.
다른 솔루션과의 비교 분석
주요 대안과의 차이점
FortiGate의 IPsec 이중화는 몇 가지 대안과 비교할 때 뚜렷한 특징이 있습니다. 가장 흔히 비교되는 Cisco DMVPN, AWS VPN, 그리고 전통적인 VRRP 기반 이중화 구성을 표로 정리했습니다.
솔루션 비교표
| 구분 | FortiGate Dual Tunnel + SD-WAN | Cisco DMVPN | AWS Site-to-Site VPN |
|---|---|---|---|
| Failover 속도 | 1~3초 (Health Check 기반) | 5~10초 (IP SLA/Tunnel protection) | 수 초~수십 초 (BGP convergence) |
| 정책 통합 | 방화벽 정책과 통합 | 라우터 단독, FW는 별도 | Transit Gateway 정책 연계 |
| 설정 난이도 | 중간 (GUI 친화적) | 중상 (mGRE/NHRP 이해 필요) | 낮음 (마법사 기반) |
| 성능 기반 라우팅 | 손실·지연·지터 SLA | IP SLA probe | ECMP + BGP MED |
| 추가 비용 | FortiGate 라이선스만으로 가능 | 라우터 라이선스 | AWS 데이터 송신 과금 |
FortiGate만의 차별화된 통찰
가장 큰 차별점은 방화벽 정책과 SD-WAN 정책이 한 화면에서 통합된다는 점입니다. Cisco DMVPN은 라우터에서 터널을 만들고, 별도 ASA/FTD에서 정책을 처리해야 하거든요. AWS VPN은 클라우드 종속적이라 온프레미스-온프레미스 시나리오에 그대로 적용하기 어렵습니다. FortiGate는 하나의 박스에서 터널, 정책, Health Check, 로그 분석까지 끝낼 수 있어 운영 부담이 가장 적다고 판단됩니다.
운영 중 모니터링과 장애 대응 절차
정기 점검 체크리스트
- SA 재협상 주기 — 24시간 단위로 재협상이 일어나는지 확인 (재협상 누락 시 터널 정체 가능)
- Health Check latency — 평균 50ms 이하인지, 일별 추이가 어떤지 모니터링
- 패킷 손실률 — 1% 이상 지속되면 회선 품질 저하로 판단하여 사전 점검
- Failover Drill — 분기 1회 Primary 회선을 강제로 끊어 Secondary 전환 시간 측정
장애 대응 플레이북
장애가 감지되면 우선 SD-WAN Health Check 로그로 어느 회선이 down 판정됐는지 확인합니다. 양쪽 모두 down이라면 본사 측 장비 문제 가능성이 높거든요. 한쪽만 down이라면 ISP 측 회선 점검을 먼저 요청합니다. Failover 후에도 트래픽이 복구되지 않으면, diagnose vpn ike log-filter로 협상 로그를 다시 보고 Phase1/2 mismatch 여부를 확인합니다. 이 절차는 표준화해두면凌晨 장애 대응 시간이 크게 줄어듭니다.
�️ 운영 시 주의
- FortiOS 버전이 다르면 IKE Fragmentation 등 SD-WAN 옵션 동작이 미세하게 다를 수 있어, 양 끝 장비를 동일한 메이저 버전으로 맞추는 것이 안전합니다.
- SD-WAN 규칙을 너무 많이 만들면 정책 매칭 비용이 늘어나므로, 업무 트래픽 단위로 묶어 10개 이내로 관리하시는 게 좋습니다.
자주 묻는 질문
Q. Dual Tunnel만으로도 Failover가 가능한데, 굳이 SD-WAN이 필요한가요?
A. distance 기반 라우팅만으로도 전환은 됩니다. 다만 성능 기반 전환(지연·손실 감지)이 어렵고, 정책과 라우팅을 분리해서 관리해야 하므로 운영 부담이 큽니다. SD-WAN을 쓰면 한 화면에서 정책과 품질을 동시에 제어할 수 있거든요.
Q. Primary와 Secondary 회선의 대역폭을 비대칭으로 잡아도 되나요?
A. 가능합니다. 다만 SD-WAN Rules에서 가중치(weight)를 차등 적용해 트래픽 분배 비율을 조정해야 비대칭 환경을 안정적으로 운영할 수 있습니다.
Q. Health Check 서버는 외부 public IP를 써도 되나요?
A. 가능은 하지만 권장하지 않습니다. VPN 터널 내부의 안정적인 사설 IP를 쓰면 회선 품질을 더 정확히 측정할 수 있거든요. 외부 서버를 쓰면 ISP DNS나 글로벌 경로 문제까지 섞여 측정값이 흔들립니다.
Q. Failover가 자주 발생하는데 임계값을 어떻게 조정해야 하나요?
A. Failover threshold를 3회에서 5회로 늘리고, 동시에 latency 기준을 100ms 이상으로 완화하면 flapping이 줄어듭니다. 단, 전환 감도가 떨어지므로 업무 영향도를 함께 고려하셔야 합니다.
Q. Active-Active로 양쪽 터널에 동시에 트래픽을 분산할 수 있나요?
A. 가능합니다. SD-WAN Rules의 load-balance-mode를 source-ip 또는 session 기반으로 설정하면 양쪽 터널에 세션이 분산됩니다. 다만 일부 애플리케이션은 단일 세션의 latency 차이에 민감하므로 사전 검증이 필요합니다.
FortiGate IPsec VPN 이중화는 단순히 터널 두 개를 만드는 것에서 끝나지 않습니다. SD-WAN Health Check가 회선 품질을 측정하고, 라우팅 우선순위와 정책이 자동 Failover를 뒷받침해야 비로소 견고한 설계가 완성되거든요. 본문의 비교표와 실패 사례를 참고해, 본사-지사 환경에 맞는 구체적인 임계값과 정책을 설정하시길 권해드립니다. 작은 Drill이라도 직접 돌려보시면 설계의 빈틈을 바로 발견하실 수 있을 거예요.
면책조항
본 글의 구성 예시와 명령어는 일반적인 운영 가이드이며, 실제 환경 적용 전에는 반드시 Fortinet 공식 매뉴얼과 라이선스 약관을 확인하시길 권장합니다. 네트워크 환경에 따라 권장값과 절차가 달라질 수 있으며, 본 콘텐츠를 활용해 발생하는 직접·간접적 손해에 대해 작성자는 책임을 지지 않습니다. 제품 세부 사양은 FortiOS 버전에 따라 변경될 수 있으므로 최신 릴리즈 노트를 반드시 검토하시기 바랍니다.
