Private DX + Private VPN으로 금융기관 전용선 연결하기
인터넷을 거치지 않고, Direct Connect 전용선 위에 암호화 VPN을 얹어 은행 펌뱅킹 시스템과 고객사 서비스를 안전하게 연결한 경험을 정리했습니다.
1. 들어가며
신규 펌뱅킹 연계를 앞두고 은행 측에서 이런 요구가 왔습니다.
“금융망 연계는 인터넷 기반 VPN으로는 불가합니다. 전용선 위에서 암호화된 통신이어야 하고, VPN 종단(endpoint)도 인터넷에 노출되면 안 됩니다.”
연결은 운영(PRD)과 스테이징(STG) 두 환경 모두 필요했고, 전용선은 회선 장애에 대비해 이중화해야 했습니다.
| 구간 | 회선/역할 |
| 은행(청라) | KT 회선 -> KINX -> DX1 (Active) |
| 은행(분당) | SKB 회선 -> KINX -> DX2 (Standby) |
| 대상 환경 | prod-pg-tgw, staging-pg-tgw |
처음 떠오른 방법은 Public DX + Public VPN이었습니다. 구성이 단순하지만, VPN 종단이 AWS Public IP라 인터넷에 노출됩니다. 은행 보안 정책상 수용 불가였습니다.
그래서 전용선 자체를 Private 경로로 만들고, 그 위에 Private IP VPN을 얹어 end-to-end로 인터넷 노출이 없는 구조로 구성하게 되었습니다.
2. 왜 Private DX + Private VPN인가
판단 기준은 세 가지였습니다.
- VPN 종단이 인터넷에 노출되면 안 되는가? -> 그렇다
- 은행 VPN 장비에 Private IP(RFC 1918)가 있는가? -> 있다 (10.194.43.x)
- Private IP VPN은 TGW에만 연결되는가? -> 그렇다 (VGW 불가, TGW 필수)
세 조건이 모두 충족되므로 Transit VIF + Direct Connect Gateway(DXGW) + Transit Gateway(TGW) 위에 Private IP VPN을 구성했습니다. Public VIF는 AWS Public 서비스 접근용이라 이 구조에 맞지 않고, Private IP VPN은 CGW IP가 RFC 1918이어야 하며 반드시 TGW에 연결해야 합니다(VGW 불가). 즉 TGW는 선택이 아니라 Private IP VPN 구성의 전제 조건입니다.
3. 전체 구성
전체 요청 흐름은 아래와 같습니다.
은행_청라(FortiGate) – KT회선 – KINX – DX1(KT VIF) -+
+- DXGW – TGW(prod/staging) – VPC
은행_분당(FortiGate) – SKB회선 – KINX – DX2(SKB VIF) -+
각 구성 요소의 역할은 다음과 같습니다.
| 구성 요소 | 역할 |
| Transit VIF | DX Location에서 DXGW까지 BGP 연결 (169.254.x.x 피어링) |
| DXGW | VIF와 TGW를 연결하는 글로벌 라우팅 브릿지 |
| TGW | VPN Attachment와 VPC Attachment를 묶는 라우팅 허브 |
| Private IP VPN | IPSec 암호화 터널 (Outside IP를 TGW CIDR에서 할당) |
| CGW | 은행 VPN 장비의 Private IP 등록 (RFC 1918 필수) |
| VPC | 고객사 서비스 서버가 위치한 네트워크 |
추가로 VPN 종단이 TGW CIDR(Private 대역)에서 할당되므로, 전 구간이 인터넷에 노출되지 않습니다. 금융기관 보안 요구사항을 그대로 충족합니다.
4. 핵심 설정값 살펴보기
4.1 ASN 설계
여기서 실수하기 쉬운 게 ASN 중복입니다. 동일 DXGW에 여러 TGW를 연결하려면 각 TGW의 ASN이 서로 달라야 합니다. 처음에 PRD/STG TGW가 둘 다 64512라서 연결이 거부됐고, STG를 64514로 변경해 해소했습니다.
| 구간 | ASN |
| DXGW (Wesang_Hana_DXGW) | 64515 |
| prod-pg-tgw | 64512 |
| staging-pg-tgw | 64514 (중복 해소 후) |
| KINX (KT VIF) | 64521 |
| KINX (SKB VIF) | 64522 |
| 은행 CGW | 64011 |
4.2 TGW Private CIDR
TGW CIDR은 VPN 터널의 Outside IP가 할당되는 대역입니다. 최소 /24이며, 169.254.0.0/16을 제외한 범위에서 상대방과 겹치지 않게 지정해야 합니다. 은행이 10.0.0.0/8을 전부 쓰고 있어, 초기 VPC 10.170.x.x 대역이 충돌했고 추가 CIDR 192.168.112/113으로 변경해 해결했습니다.
| 환경 | CIDR |
| prod-pg-tgw | 192.168.112.0/24 |
| staging-pg-tgw | 192.168.113.0/24 |
4.3 VPN 터널 / MTU 설정
VPN 환경에서 EC2 기본 MTU(9001)를 그대로 두면, 큰 MSS가 광고되어 VPN 터널(MTU 1427)을 초과하는 패킷이 잘릴 수 있습니다. EC2 MTU를 1500으로 낮추었습니다.
FortiGate 설정:
set mtu-override enable
set mtu 1427
set tcp-mss 1379
5. 겪은 이슈와 해결
| 이슈 | 현상 / 해결 |
| TGW ASN 중복 | 동일 DXGW에 같은 ASN(64512) TGW 2개 연결 불가 -> STG를 64514로 변경 |
| TGW CIDR 충돌 | 초기 CIDR이 은행 10.0.0.0/8과 충돌 -> 192.168.112/113으로 변경 |
| 서버 대역 겹침 | 고객사 서버 대역과 은행 대역 충돌 -> 추가 CIDR로 pg서버 마이그레이션 |
| 방화벽 신청 | /24 대역 오픈 불가, IP 단위 필요 -> ASG 분리 후 고정 IP 확보 |
| 터널 옵션 불일치 | 담당자 변경으로 옵션 불일치 -> 유선 sync 후 재구성 (DH그룹 조정 등) |
| BGP 라우팅 불완전 | 1개 대역만 광고됨 -> 은행 장비 설정 수정, 양방향 광고 확인 |
| 한글 깨짐 (패킷 잘림) | EC2 MTU 9001로 인한 MSS 과대 -> EC2 MTU 1500 조정으로 해결 (송/수신 측의 어플리케이션 이슈일 수도 있습니다. AWS VPN은 MTU 1500) |
6. 주의할 점
ASN은 사전에 계획하시는게 좋습니다. DXGW에 연결할 TGW가 여러 개면 각각 고유 ASN을 미리 배정해야 합니다. 구축 중간에 바꾸려면 VPN을 삭제해야 해서 번거롭습니다.
IP 대역은 상대방 전체를 확인하는게 좋습니다. 금융기관이 10.0.0.0/8처럼 넓은 대역을 쓰는 경우가 많습니다. TGW CIDR과 VPC CIDR 모두 겹치지 않게 사전 조율이 필요합니다.
VPN 환경에서는 EC2 MTU를 1500으로, 기본값 9001은 터널 통과 시 패킷 잘림을 유발할 수도 있습니다. VPN 장비의 MSS Clamping(tcp-mss 1379)도 함께 확인하세요.
담당자 변경에 대비하세요. 금융기관은 담당자 변경 시 커뮤니케이션 미스로 터널 옵션이 어긋나기 쉽습니다. 변경 즉시 sync하고 이력을 문서화해야 합니다.
DX, VPN Connection 모니터링을 걸어두면 좋습니다. CloudWatch에서 VPN TunnelState와 DX ConnectionState 알람을 설정해 장애를 즉시 감지합니다.
7. 마치며
결과적으로 PRD/STG 양쪽 모두 인터넷 노출 없는 전용선 암호화 통신을 구축했고, KT/SKB 이중화로 단일 회선 장애에도 자동 Failover가 가능해졌습니다.
(실제로 2026.09.23 DX회선 하나가 유지보수로인해 끊기는 시간대가 예정 되어있었지만, 잠깐의 순단 후 다른 DX회선으로 통신이 이어졌습니다)
돌아보면 핵심은 Direct Connect라는 서비스보다 “VPN 종단을 인터넷에 노출하지 않는다”는 원칙이었습니다. 금융망 연계처럼 보안 요구가 엄격한 작업이라면, Public DX보다 Transit VIF 기반 Private IP VPN을 먼저 고려해도 좋을 것 같습니다.