OpenVPN Split Tunnel 환경에서 특정 서브넷 라우팅 누락 문제와 EKS 환경 라우팅 고려사항

1. 환경 구성

AWS VPC 서브넷 구조:

• Public A (10.0.1.0/24) : OpenVPN 서버
• Private B (10.0.11.0/24) : EKS 클러스터
• Private C (10.0.21.0/24) : MariaDB 서버

OpenVPN 클라이언트 대역: 10.8.0.0/24

기본 설정:

• 모든 서브넷의 라우트 테이블에 10.8.0.0/24 → OpenVPN EC2 ENI 등록
• SG에서 10.8.0.0/24 → 3306(TCP) 허용
• NACL은 In/Out Any/Any
• OpenVPN EC2: Source/Dest Check 비활성화, ip_forward=1

---

2. 증상

• VPN 클라이언트 → EKS 파드(Ping) : 정상
• VPN 클라이언트 → MariaDB(3306/TCP) : 타임아웃
• EKS 파드 → MariaDB : 정상

---

3. 원인 분석

Windows route print 결과:

 

10.0.11.0    255.255.255.0    10.8.0.1
10.0.12.0    255.255.255.0    10.8.0.1

→ 10.0.21.0/24 (MariaDB 서브넷) 경로 없음 → 패킷이 VPN이 아닌 기본 NIC로 나가 드롭됨.

서버 /etc/openvpn/server.conf에는 21/22 서브넷 푸시 설정이 있었음:

 

push "route 10.0.21.0 255.255.255.0"
push "route 10.0.22.0 255.255.255.0"

 

그러나 클라이언트에 반영되지 않음.

---

4. 추가 원인 — route-nopull 설정

OpenVPN 설치 자동화 스크립트(openvpn-userdata.sh)에서:

 

sed -i '/^<ca>/i route-nopull\nroute 10.0.11.0 255.255.255.0\nroute 10.0.12.0 255.255.255.0' "$CLIENT_OVPN"

즉, 클라이언트 .ovpn에 route-nopull 이 들어가 있고 11/12 서브넷만 수동 라우트로 넣는 구조 → 서버가 푸시한 21/22 라우트는 무시됨.

---

5. 해결 방법

방법 1 — route-nopull 제거 (권장)

1. route-nopull 삽입 라인 제거
2. 서버 push 라우트에 모든 서브넷 포함:

 

 

push "route 10.0.11.0 255.255.255.0"
push "route 10.0.12.0 255.255.255.0"
push "route 10.0.21.0 255.255.255.0"
push "route 10.0.22.0 255.255.255.0"

1. 서버 재시작 후 클라이언트 재연결

방법 2 — route-nopull 유지 시

1. .ovpn에 누락된 서브넷 라우트를 모두 추가:

 

 

route-nopull
route 10.0.11.0 255.255.255.0
route 10.0.12.0 255.255.255.0
route 10.0.21.0 255.255.255.0
route 10.0.22.0 255.255.255.0

---

6. EKS(Container) 환경에서의 라우팅 어려움

EKS 같은 컨테이너 환경에서는 Pod 네트워크와 VPC 네트워크가 분리되어 있어 라우팅이 더 복잡해질 수 있습니다.

특징

• Pod IP 대역(CNI에 따라 예: 192.168.x.x, 172.20.x.x 등)은 VPC 서브넷과 다르며, 직접 접근하려면 해당 CIDR에 대한 라우팅이 필요
• NodePort, ClusterIP, LoadBalancer 타입 서비스에 따라 접근 경로가 달라짐
• IPtables 규칙(kube-proxy)과 CNI(Route Table)가 트래픽을 변환(Masquerade)하기 때문에 VPN에서 직접 Pod로 접근하려면 NAT 규칙을 우회해야 함

예시 문제

• VPN → Pod IP 접근 불가, 대신 Node IP + HostPort 또는 Service를 사용해야 함
• Pod에서 MariaDB 접근 가능하지만 VPN에서는 불가능 → Pod는 VPC 내에서 동작하므로 라우팅이 단순, VPN은 별도의 경로 필요

팁

1. 서비스 엔드포인트 사용: VPN에서 접근 시 가능하면 NodePort나 LoadBalancer를 통한 접근 권장
2. Pod 직접 접근 필요 시: CNI CIDR을 OpenVPN 라우트에 추가하고, EKS 노드에서 iptables FORWARD 규칙 열기
3. Kubernetes 서비스 디스커버리: MariaDB 같은 DB는 K8s Service로 묶어주면 클러스터 내부/외부 접근 경로를 명확히 설계 가능
4. 라우트 및 NAT 일관성 유지: VPN → EKS Pod로 가는 트래픽이 NAT를 거치지 않도록 설계하면 지연과 문제를 줄일 수 있음

---

7. 재발 방지 팁

• Split Tunnel 환경에서 route-nopull은 꼭 필요한 경우 외에는 사용하지 않기
• 서버에서 VPC 전체 CIDR 푸시:

 

push "route 10.0.0.0 255.255.0.0"

 

• 서버 로그 PUSH_REPLY로 푸시 라우트 확인
• 클라이언트 OpenVPN 실행은 관리자 권한으로
• EKS 환경에서 VPN 접속 설계 시 Pod CIDR 라우팅 여부 반드시 점검

---

8. 결론

이번 사례는 클라이언트 설정의 route-nopull 때문에 서버가 푸시한 서브넷 라우트가 누락된 전형적인 경우였습니다.
MariaDB, EKS처럼 서로 다른 네트워크 환경을 혼합 운용할 때는 라우트 경로를 양쪽에서 모두 확인하고, 컨테이너 환경 특성에 맞는 접근 경로 설계를 하는 것이 필수입니다.