서론 : Client VPN이란?
Client VPN은 개인 디바이스(노트북, 태블릿, 스마트폰)를 AWS 네트워크에 안전하게 연결하는 서비스다.
재택근무 직원이 회사 서버에 접속하거나, 출장 중인 개발자가 개발 환경에 접근할 때 사용한다.
Site-to-Site VPN과의 핵심 차이는 연결 주체다:
- Site-to-Site VPN: 네트워크 ↔ 네트워크 (예: 본사 전체 ↔ AWS)
- Client VPN: 개인 디바이스 ↔ 네트워크 (예: 내 노트북 ↔ AWS)
물리적 사무실에 출근하지 않아도, 마치 사무실 네트워크에 연결된 것처럼 AWS 리소스에 접근할 수 있다.
보안팀 입장에서는 "누가, 언제, 어디에 접속했는지" 통제하고 감사(audit)할 수 있는 중앙 집중식 접근 관리 도구다.
그렇다면 Client VPN은 어떤 기술을 기반으로 동작하는 걸까.
이를 이해하려면 먼저 OpenVPN 프로토콜과 접근 통제 메커니즘을 알아야 한다.
Part 1: OpenVPN 동작 원리
AWS Client VPN은 OpenVPN이라는 오픈소스 VPN 프로토콜 기반으로 만들어진 서비스다.
앞서 설명한 Site-to-Site VPN은 IPsec이라는 프로토콜을 사용했지만, Client VPN은 OpenVPN + TLS(SSL) 방식을 사용한다.
방식은 다르지만 목적은 같다:
공개된 인터넷 위에서 안전한 통신 통로를 만드는 것이다.
OpenVPN은 어떤 VPN인가
OpenVPN은 "개인 사용자 단말이 VPN 서버에 접속"하는 구조에 최적화된 VPN이다.
웹 브라우저가 HTTPS로 서버에 접속하듯, OpenVPN은 TLS 암호화를 이용해 안전한 터널을 만든다.
이 방식 덕분에 다음과 같은 특징을 가진다.
- SSL/TLS를 활용한 암호화
- TCP 또는 UDP 프로토콜 위에서 동작
- 포트 443 사용 가능 → 방화벽 / 프록시 환경에서도 비교적 정상 연결됨 - 클라이언트-서버 모델 (사용자 디바이스 ↔ VPN 서버)
- 크로스 플랫폼 지원 (Windows, Mac, Linux, iOS, Android)
그리고, Site-to-Site VPN의 IKE Phase 1/2와 유사하게,
OpenVPN도 제어 채널(Control Plane) 수립 → 데이터 채널(Data Plane) 암호화 과정을 거친다.
1단계: 인증 (Authentication)
첫번째 단계는 "이 사용자가 누구인가?"를 확인하는 것이다.
VPN 연결을 시도하는 사용자나 디바이스가 신뢰할 수 있는 주체인지 확인한다.
AWS ClientVPN은 여러 인증 방식을 지원한다.
가장 단순한 방식은 상호 인증서 (Mutual Certificate) 다.
클라이언트와 서버가 서로 인증서를 교환하기 때문에, 구성은 쉽지만 인증서 관리가 번거롭다.
기업 환경에서는 Active Directory (AD) 인증을 많이 사용한다.
기존 사내 계정으로 로그인할 수 있어 관리가 편하다.
더 큰 조직에서는 SAML 기반 SSO를 사용한다.
Okta나 AzureAD 같은 IdP와 연동해 MFA까지 적용할 수 있다.
어떤 방식을 쓰든 핵심은 하나다.
인증에 실패하면 VPN 세션 자체가 수립되지 않는다.
2단계: 접근 인가 (Authorization)
두 번째 단계는 "어디까지 접근해도 되는지"를 결정하는 것이다.
ClientVPN에서는 이를 Authorization Rule로 정의한다.
예를 들어, 개발팀 사용자는 개발 VPC에만 접근할 수 있고, 운영팀 사용자는 운영 VPC에만 접근하도록 설정할 수 있다.
예시 규칙:
1. 목적지: 10.0.0.0/16 (개발 VPC)
허용 대상: "개발팀" AD 그룹
2. 목적지: 10.1.0.0/16 (운영 VPC)
허용 대상: "운영팀" AD 그룹
3. 목적지: 192.168.1.0/24 (민감 데이터베이스)
허용 대상: "DBA" 그룹만
사용자가 어떤 서버로 패킷을 보내면, ClientVPN은 먼저 이 규칙을 확인한다.
여기서 허용되지 않으면 트래픽은 즉시 차단된다.
실무에서 "VPN은 연결되는데, 서버 접속이 안되는" 문제의 원인 대부분은 Authorization Rule이 없거나 잘못된 경우다.
3단계: 라우팅 (Routing)
마지막 단계는 "이 트래픽을 어느 경로로 보낼 것인지" 다.
Client VPN은 이를 Endpoint Route Table로 결정한다.
Route Table에는 "이 목적지 CIDR는 어느 VPC subnet으로 보낼 것인지"가 정의되어 있다.
목적지 타겟 네트워크
10.0.0.0/16 → subnet-abc123 (개발 VPC)
10.1.0.0/16 → subnet-def456 (운영 VPC)
172.16.0.0/12 → subnet-ghi789 (온프렘, TGW 통해)
클라이언트가 특정 IP로 패킷을 보내면, ClientVPN은 이 테이블을 보고 어느 네트워크로 전달할지 결정한다.
따라서, Route Table에 없는 CIDR는 VPN으로 가지 않는다.
그래서 특정 네트워크만 접속이 안될 때는 대부분 Route 누락이 원인이다.
Full-Tunnel vs. Split-Tunnel
ClientVPN 설계 시, 가장 중요한 설계 중 하나가 Full-Tunnel을 사용할지, Split Tunnel을 사용할지다.
Full-Tunnel 방식
Full Tunnel은 말 그대로 모든 트래픽을 VPN으로 전송한다.
사용자 PC
├─ 10.0.0.50 (AWS 서버) → VPN ✓
├─ youtube.com → VPN → AWS → 인터넷 ✓
└─ google.com → VPN → AWS → 인터넷 ✓
업무 트래픽이든, 유튜브든, 검색이든 전부 AWS를 거친다.
이 방식은 보안 통제는 강력하지만, 모든 트래픽이 우회하기 때문에 속도가 느려지고 비용이 크게 증가한다.
Split-Tunnel
Split Tunnel은 업무에 필요한 네트워크만 VPN으로 보내고, 나머지는 기존 인터넷을 그대로 사용한다.
사용자 PC
├─ 10.0.0.50 (AWS 서버) → VPN ✓
├─ youtube.com → 로컬 인터넷 ✓
└─ google.com → 로컬 인터넷 ✓
이 방식은 비용과 사용자 측면에서 훨씬 효율적이다.
그래서 대부분의 기업에서는 Split Tunnel을 기본으로 사용한다.
다만, 보안 요구사항이 매우 높은 환경에서는 Full Tunnel을 선택하기도 한다.
Part 2: AWS Client VPN 구현
AWS Client VPN 구성 요소
AWS Client VPN은 OpenVPN 기반의 VPN에 인증 → 인가 → 라우팅이라는 3단계 접근 통제를 결합한 AWS 관리형 서비스다.
그 구성요소는 다음과 같다.
- Client VPN Endpoint
- OpenVPN 서버 역할을 하는 AWS 관리형 리소스
- 고가용성 자동 제공 (AWS가 내부적으로 이중화)
- 클라이언트 IP 풀(CIDR) 관리
- Target Network Association
- VPN Endpoint를 특정 VPC 서브넷에 연결
- 최소 1개, 권장 2개 이상(Multi-AZ)
- 서브넷의 가용 IP를 사용 (ENI 생성)
- Authorization Rules
- 네트워크별 접근 권한 정의
- AD 그룹, SAML 속성, 또는 "모든 사용자" 기반
- Endpoint Route Table
- 트래픽 라우팅 규칙
- Split-Tunnel 동작 제어
- Client Configuration File (.ovpn)
- 클라이언트에 배포할 설정 파일
- 서버 주소, 인증서, 라우팅 정보 포함
AWS Client VPN 구현 절차
실제 프로젝트에서 Client VPN을 구축할 때는 다음 순서를 따른다.
1단계: 사전 준비
인증 방식에 따라 필요한 것들이 다르다.
상호 인증서 방식을 사용할 경우, 서버 인증서와 클라이언트 인증서를 준비해 AWS Certificate Manager (ACM)에 업로드한다.
Active Directory 방식을 사용할 경우, AWS Directory Service를 구성하거나 On-premise AD와 연동한다.
SAML 방식을 사용할 경우 Okta나 Azure AD 같은 IdP의 메타데이터를 준비하고 IAM SAML Provider를 생성한다.
2단계: Client VPN Endpoint 생성
- 이름: dev-client-vpn
- 클라이언트 IPv4 CIDR: 172.16.0.0/22 (1022개 동시 접속)
- 서버 인증서: ACM 인증서 ARN
- 인증 방식: Active Directory
- VPN 포트: UDP 443 (방화벽 통과 유리)
- Transport Protocol: UDP (성능) 또는 TCP (안정성)
- Split-Tunnel: 활성화
- Connection Logging: CloudWatch Logs 그룹 지정
이 endpoint가 모든 사용자 연결의 진입점이 된다.
3단계: Target Network Association
VPC: vpc-abc123 (개발 VPC)
Subnet 1: subnet-az1 (ap-northeast-2a)
Subnet 2: subnet-az2 (ap-northeast-2c)
실무에서는 서로 다른 AZ의 서브넷 2개 이상을 연결해 고가용성을 확보한다.
이때, 서브넷에 ENI가 생성되므로 IP CIDR 여유 공간을 반드시 확인해야 한다.
4단계: Authorization Rules 생성
규칙 1:
목적지: 10.0.0.0/16 (개발 VPC)
접근 허용: AD 그룹 "Developers"
규칙 2:
목적지: 10.1.0.0/16 (운영 VPC)
접근 허용: AD 그룹 "DevOps"
규칙 3:
목적지: 0.0.0.0/0 (인터넷)
접근 허용: 모든 사용자
(Full-Tunnel 시 필요)
이처럼 네트워크 단위로 접근 권한을 명확히 나눈다.
5단계: Routes 추가
Endpoint Route Table:
목적지 타겟 서브넷 설명
10.0.0.0/16 → subnet-az1 개발 VPC
10.1.0.0/16 → subnet-az2 운영 VPC
172.31.0.0/16 → (TGW 통해) 온프렘 네트워크
Split-Tunnel 환경에서는 여기에 없는 CIDR은 절대 VPN으로 가지 않는다.
6단계: 보안 그룹 및 NACL 확인
VPN 트래픽이 목적지 서브넷에 도착하면 그 다음에는 일반 VPC 트래픽과 동일하게 처리된다.
즉, 서브넷의 NACL과 대상 리소스의 보안 그룹을 모두 통과해야 한다.
Inbound Rule:
Type: All Traffic
Source: 172.16.0.0/22 (Client VPN CIDR)
설명: Client VPN 사용자
보안 그룹은 Client VPN CIDR 대역을 허용하는 것이 일반적이다.
7단계: 클라이언트 설정 파일 다운로드
AWS 콘솔에서 .ovpn 파일을 다운로드해 사용자에게 배포한다.
사용자는 OpenVPN 클라이언트에 이 파일을 import한 뒤 접속한다.
연결이 성공하면 가상 IP를 할당받고, 설정된 Route Table에 따라 트래픽이 흐른다.
AWS ClientVPN 운영 포인트
1. 로그 및 모니터링
Client VPN은 연결 로그와 트래픽 통계를 CloudWatch에 남긴다.
{
"connection-id": "cvpn-connection-xxx",
"client-ip": "172.16.0.45",
"username": "john.doe@company.com",
"connection-established-time": "2026-01-14T10:30:00Z",
"connection-terminated-time": "2026-01-14T15:45:00Z",
"ingress-bytes": 1048576,
"egress-bytes": 5242880
}
이를 통해 다음을 감시할 수 있다.
- ActiveConnectionsCount: 현재 연결 수
- IngressBytes / EgressBytes: 트래픽 사용량
- AuthenticationFailures: 인증 실패 횟수
이 지표에 기반하여 이벤트를 정의할 수 있다.
예를 들어, 동시 접속자 수가 900명을 초과할 경우 CIDR 고갈 경고를, 5분(혹은 단시간) 내에 100회 이상 인증이 실패한다면 무차별 대입 공격을 의심할 수 있다.
2. 인가 규칙 설계 원칙
Authorization Rule은 최소 권한 원칙이 기본이다.
모든 사용자에게 0.0.0.0/0을 허용하는 구성은 보안 사고로 직결된다.
네트워크 중요도에 따라 계층적으로 접근 권한을 나누는 것도 하나의 방법이다.
1. 기본 접근: 모든 직원 → 공유 리소스(파일서버 등)
2. 개발 환경: 개발팀 → 개발 VPC
3. 운영 환경: 운영팀 → 운영 VPC
4. 민감 데이터: 특정 그룹만 → 데이터베이스 서브넷3. Split-Tunnel 최적화
Split-Tunnel은 비용과 사용자 경험을 동시에 개선한다.
업무에 필요한 네트워크만 VPN으로 보내고, 나머지는 로컬 인터넷을 사용하도록 설계한다.
※ 대부분의 기업 환경에서는 Split-Tunnel이 기본 선택이다.
Full-Tunnel:
- 100명 사용자
- 평균 1GB/일/인 인터넷 사용
- AWS 데이터 전송 비용: 100GB × $0.09 = $9/일 = $270/월
Split-Tunnel (업무 트래픽 20%만):
- 20GB × $0.09 = $1.8/일 = $54/월
- 절감: $216/월 (80% 감소)4. 인증 방식별 운영 팁
Active Directory:
- 정기적인 AD 동기화 확인
- 그룹 멤버십 변경 시 즉시 반영됨
- 패스워드 정책(복잡도, 만료) 엄격 설정
SAML:
- IdP 세션 타임아웃과 VPN 세션 타임아웃 조율
- MFA 필수 적용 권장
- IdP 장애 시 대체 인증 수단 준비
상호 인증서:
- 인증서 만료 전 갱신 프로세스 자동화
- 인증서 폐기 목록(CRL) 관리
- 분실/퇴사 시 인증서 즉시 revoke
5. 보안 강화
- 네트워크 분리 : VPN 트래픽을 전용 서브넷으로 분리하고 세션 타임아웃을 설정하면 보안 수준을 한 단계 더 높일 수 있다.
- Client Connect Handler 활용 : 접속 시간, 위치, 디바이스 상태에 따라 동적 접근 통제도 가능하다.
# Lambda로 동적 통제
def lambda_handler(event, context):
user = event['username']
source_ip = event['public-ip']
device_id = event['device-id']
# 특정 국가 IP만 허용
if not is_allowed_country(source_ip):
return {'allow': False}
# 디바이스 보안 상태 확인
if not check_device_compliance(device_id):
return {'allow': False}
# 업무 시간만 접속 허용
if not is_business_hours():
return {'allow': False}
return {'allow': True}마무리
AWS Client VPN은 OpenVPN과 3단계 접근 통제를 결합한 강력한 원격 접속 솔루션이다.
핵심은 단순하다 :
- 인증으로 사용자를 확인하고
- 인가로 접근 범위를 제한하며
- 라우팅으로 트래픽을 통제한다.
이 구조를 이해하면 ClientVPN은 더 이상 복잡한 서비스가 아니다.
참고 출처
- AWS Client VPN 구성하기
- Get started with AWS Client VPN - AWS Client VPN
-
Powered By. Claude
'클라우드 > AWS' 카테고리의 다른 글
| [AWS] AWS VPN : IPsec 프로토콜과 Site-to-Site VPN (1) | 2026.01.13 |
|---|---|
| [AWS] IAM User/Role/Policy & Service Role (0) | 2025.11.11 |
| [AWS] App Runner, ECS/EKS Anywhere (0) | 2025.11.05 |
| [AWS] ECS, ECR, EKS (0) | 2025.11.05 |
| [SAP] Amazon API Gateway - REST API (0) | 2025.09.08 |
