Client VPN으로 프라이빗 리소스 접근하기

AWS Client VPN을 활용하여 프라이빗 서브넷의 RDS, EC2 등 내부 리소스에 안전하게 접근하는 방법을 단계별로 알아봅니다. 인증서 생성부터 실제 연결까지 실무에서 바로 적용할 수 있는 완벽 가이드입니다.

---

목차

1. VPN의_필요성과_동작_원리
2. 인증서_기반_VPN_vs_사용자_인증_VPN
3. 인증서와_키_생성하기
4. Client_VPN_엔드포인트_생성
5. VPN_클라이언트_설정_및_연결
6. VPN으로_프라이빗_RDS_접속_테스트

---

1. VPN의 필요성과 동작 원리

김개발 씨는 오늘 새로운 프로젝트에 투입되었습니다. 선배가 건네준 RDS 접속 정보를 보고 MySQL Workbench로 연결을 시도했지만, 연결이 되지 않습니다.

"이상하다, 분명 주소가 맞는데..." 선배 박시니어 씨가 웃으며 말합니다. "그 RDS는 프라이빗 서브넷에 있어서 VPN 없이는 접근이 안 돼요."

**VPN(Virtual Private Network)**은 한마디로 인터넷을 통해 마치 같은 사설 네트워크에 있는 것처럼 연결해주는 기술입니다. 마치 본사와 지사 사이에 전용 터널을 뚫어놓은 것과 같습니다.

AWS Client VPN을 사용하면 여러분의 노트북에서 AWS 프라이빗 서브넷에 있는 리소스에 안전하게 접근할 수 있습니다.

다음 코드를 살펴봅시다.

# VPN이 없을 때 - 프라이빗 RDS 접근 불가
mysql -h private-rds.abcd1234.ap-northeast-2.rds.amazonaws.com -u admin -p
# 결과: ERROR 2003 (HY000): Can't connect to MySQL server

# VPN 연결 후 - 동일한 명령어로 접근 가능
# VPN이 터널을 생성하여 프라이빗 네트워크로 트래픽 전달
mysql -h private-rds.abcd1234.ap-northeast-2.rds.amazonaws.com -u admin -p
# 결과: Welcome to the MySQL monitor.

# VPN 연결 상태 확인
ip route | grep tun
# 10.0.0.0/16 dev tun0 (VPC CIDR로 가는 트래픽이 터널로 라우팅)

김개발 씨는 입사 첫 주에 당황스러운 경험을 했습니다. 분명히 선배가 알려준 데이터베이스 주소로 접속을 시도했는데, 연결이 되지 않는 것입니다.

방화벽 문제인가 싶어 보안 그룹도 확인해봤지만, 문제가 없어 보였습니다. 박시니어 씨가 다가와 상황을 파악하더니 고개를 끄덕였습니다.

"아, VPN 설정을 안 해줬네요. 그 RDS는 프라이빗 서브넷에 있어서 외부에서 직접 접근이 안 됩니다." 그렇다면 프라이빗 서브넷은 왜 존재하는 걸까요?

쉽게 비유하자면, 회사 건물을 생각해보세요. 1층 로비는 누구나 들어올 수 있는 퍼블릭 공간입니다.

하지만 서버실이나 금고는 프라이빗 공간으로, 인가된 사람만 출입할 수 있습니다. AWS에서도 마찬가지입니다.

웹 서버처럼 외부에 공개해야 하는 리소스는 퍼블릭 서브넷에, 데이터베이스처럼 보호해야 하는 리소스는 프라이빗 서브넷에 배치합니다. 문제는 개발자도 이 프라이빗 리소스에 접근해야 한다는 점입니다.

예전에는 **Bastion Host(배스천 호스트)**라는 중간 서버를 두고, SSH 터널링으로 접근하는 방식을 많이 사용했습니다. 하지만 이 방식은 배스천 서버를 별도로 관리해야 하고, 접속 과정도 번거로웠습니다.

바로 이런 불편함을 해결하기 위해 AWS Client VPN이 등장했습니다. Client VPN의 동작 원리는 생각보다 단순합니다.

여러분의 노트북에 VPN 클라이언트를 설치하고, AWS에 생성한 VPN 엔드포인트에 연결합니다. 연결이 성공하면 여러분의 노트북은 마치 AWS VPC 안에 있는 것처럼 동작합니다.

기술적으로 설명하면, VPN 클라이언트는 **가상 네트워크 인터페이스(tun0)**를 생성합니다. 프라이빗 서브넷으로 가는 트래픽은 이 가상 인터페이스를 통해 암호화된 터널로 전송됩니다.

AWS 측에서는 VPN 엔드포인트가 이 트래픽을 받아 VPC 내부로 전달합니다. 위의 코드를 살펴보면, VPN 연결 전에는 프라이빗 RDS에 접근할 수 없습니다.

해당 주소는 인터넷에서 라우팅되지 않는 사설 IP 대역이기 때문입니다. 하지만 VPN 연결 후에는 동일한 명령어로 접근이 가능해집니다.

실제 현업에서는 개발팀 전체가 Client VPN을 통해 스테이징 환경이나 개발 환경의 데이터베이스에 접근합니다. 운영 환경은 더 엄격한 접근 제어를 적용하기도 합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. VPN의 개념을 이해한 김개발 씨는 이제 왜 접속이 안 됐는지 명확히 알게 되었습니다.

"그럼 이제 VPN을 어떻게 설정하면 되나요?" 박시니어 씨가 답합니다. "먼저 인증 방식부터 결정해야 해요."

실전 팁

💡 - Client VPN은 시간당 요금이 부과되므로 사용하지 않을 때는 연결을 해제하세요

• VPN 연결 시 모든 트래픽이 AWS를 경유하면 속도가 느려질 수 있으니 Split Tunnel을 고려하세요

---

2. 인증서 기반 VPN vs 사용자 인증 VPN

박시니어 씨가 화이트보드에 두 가지 선택지를 적었습니다. "VPN 인증 방식은 크게 두 가지가 있어요.

인증서 기반과 사용자 인증 방식이에요. 우리 팀은 어떤 걸 쓸까요?" 김개발 씨는 고민에 빠졌습니다.

두 방식의 차이점이 무엇이고, 어떤 상황에 어떤 것을 선택해야 할까요?

AWS Client VPN은 **상호 인증(Mutual Authentication)**과 사용자 기반 인증 두 가지 방식을 지원합니다. 상호 인증은 클라이언트와 서버가 서로의 인증서를 확인하는 방식이고, 사용자 기반 인증은 Active Directory나 SAML을 통해 개별 사용자를 인증합니다.

소규모 팀에서는 인증서 기반이 간편하고, 대규모 조직에서는 사용자 인증이 관리하기 좋습니다.

다음 코드를 살펴봅시다.

# 인증 방식 비교

# 1. 상호 인증 (Mutual Authentication)
# - 서버 인증서 + 클라이언트 인증서 사용
# - 인증서를 가진 누구나 접속 가능
# - 설정이 간단하고 추가 인프라 불필요
aws ec2 create-client-vpn-endpoint \
  --authentication-options Type=certificate-authentication,\
MutualAuthentication={ClientRootCertificateChainArn=arn:aws:acm:...}

# 2. Active Directory 인증
# - 사용자별 ID/Password로 인증
# - 개별 사용자 추적 및 권한 관리 가능
# - AWS Directory Service 또는 AD Connector 필요
aws ec2 create-client-vpn-endpoint \
  --authentication-options Type=directory-service-authentication,\
ActiveDirectory={DirectoryId=d-1234567890}

# 3. SAML 기반 연동 인증 (SSO)
# - Okta, OneLogin 등 IdP와 연동
# - 기존 SSO 인프라 활용 가능

김개발 씨는 두 가지 인증 방식 앞에서 잠시 생각에 잠겼습니다. 회사에서 어떤 방식을 선택해야 할지 기준이 필요했습니다.

박시니어 씨가 차분히 설명을 시작했습니다. "먼저 상호 인증부터 알아볼게요." 상호 인증은 마치 열쇠와 자물쇠 같은 관계입니다.

서버는 자신의 인증서로 "나는 진짜 AWS VPN 서버야"라고 증명하고, 클라이언트도 자신의 인증서로 "나는 허가된 사용자야"라고 증명합니다. 양쪽 모두 서로를 확인하기 때문에 상호(Mutual) 인증이라고 부릅니다.

이 방식의 장점은 설정이 간단하다는 것입니다. 인증서만 생성하고 배포하면 됩니다.

별도의 Active Directory나 SSO 인프라가 필요 없습니다. 5명 이하의 소규모 팀이라면 이 방식으로 충분합니다.

하지만 단점도 있습니다. 인증서를 가진 사람은 누구나 접속할 수 있기 때문에, 누가 언제 접속했는지 개별적으로 추적하기 어렵습니다.

또한 팀원이 퇴사하면 인증서를 폐기하고 모든 팀원에게 새 인증서를 배포해야 합니다. "그럼 사용자 기반 인증은 어떤가요?" 김개발 씨가 물었습니다.

사용자 기반 인증은 이름 그대로 개별 사용자를 인증합니다. Active Directory와 연동하면 회사 계정으로 VPN에 로그인할 수 있습니다.

SAML을 사용하면 Okta, Google Workspace 같은 기존 SSO 시스템과 연동할 수 있습니다. 이 방식의 가장 큰 장점은 감사(Audit) 기능입니다.

누가 언제 접속했는지, 어떤 리소스에 접근했는지 개별 사용자 단위로 추적할 수 있습니다. 팀원이 퇴사하면 해당 계정만 비활성화하면 됩니다.

하지만 초기 설정이 복잡합니다. Active Directory를 사용하려면 AWS Directory Service를 구성해야 하고, SAML 연동은 IdP 설정이 필요합니다.

추가 비용도 발생합니다. "우리 팀은 어떤 걸 선택하면 좋을까요?" 김개발 씨가 다시 물었습니다.

박시니어 씨가 정리해주었습니다. "지금 우리 팀은 4명이고, 보안 감사 요구사항도 없어요.

인증서 기반으로 시작하고, 팀이 커지면 사용자 인증으로 전환하면 됩니다." 실제로 많은 스타트업이 이런 방식을 택합니다. 처음에는 간단한 인증서 기반으로 시작하고, 조직이 성장하면서 보안 요구사항이 높아지면 사용자 기반 인증으로 마이그레이션합니다.

두 가지 방식을 함께 사용할 수도 있습니다. 인증서로 1차 인증을 하고, 추가로 사용자 인증을 요구하는 이중 인증 구성도 가능합니다.

보안이 중요한 환경에서는 이런 방식을 권장합니다. 김개발 씨는 고개를 끄덕였습니다.

"그럼 일단 인증서 기반으로 진행해볼게요. 인증서는 어떻게 만드나요?"

실전 팁

💡 - 소규모 팀(5명 이하)은 인증서 기반으로 시작하세요

• 보안 감사가 필요하거나 팀이 크다면 처음부터 사용자 인증을 고려하세요
• 두 방식을 조합한 이중 인증도 가능합니다

---

3. 인증서와 키 생성하기

"자, 이제 인증서를 만들어볼까요?" 박시니어 씨가 터미널을 열었습니다. 김개발 씨는 인증서라는 단어에 살짝 긴장했습니다.

SSL, TLS, CA, 공개키, 개인키... 어렵게 느껴지는 용어들이 머릿속에 맴돌았습니다.

하지만 박시니어 씨는 미소를 지었습니다. "걱정 마세요.

AWS에서 제공하는 easy-rsa를 사용하면 생각보다 간단해요."

VPN 인증서 생성에는 easy-rsa라는 도구를 사용합니다. 먼저 **CA(Certificate Authority)**를 만들고, 이 CA로 서버 인증서와 클라이언트 인증서에 서명합니다.

마치 정부가 여권을 발급해주는 것처럼, CA가 인증서의 진위를 보증해주는 역할을 합니다.

다음 코드를 살펴봅시다.

# easy-rsa 설치 및 초기화
git clone https://github.com/OpenVPN/easy-rsa.git
cd easy-rsa/easyrsa3

# PKI(Public Key Infrastructure) 초기화
./easyrsa init-pki

# CA(Certificate Authority) 생성
# Common Name은 그냥 Enter로 기본값 사용
./easyrsa build-ca nopass

# 서버 인증서 생성 (AWS VPN 엔드포인트용)
./easyrsa build-server-full server nopass

# 클라이언트 인증서 생성 (개발자 PC용)
./easyrsa build-client-full client1.domain.tld nopass

# 생성된 인증서 확인
ls pki/issued/      # server.crt, client1.domain.tld.crt
ls pki/private/     # server.key, client1.domain.tld.key
ls pki/ca.crt       # CA 인증서

김개발 씨는 인증서에 대해 막연한 두려움이 있었습니다. 보안 관련 용어들은 왠지 어렵게 느껴졌기 때문입니다.

박시니어 씨가 쉬운 비유로 설명을 시작했습니다. "인증서 시스템을 여권에 비유해볼게요." **CA(Certificate Authority)**는 정부와 같습니다.

정부가 국민의 신원을 확인하고 여권을 발급해주듯이, CA는 서버와 클라이언트의 신원을 확인하고 인증서를 발급합니다. 우리가 만들 CA는 우리 조직만의 작은 정부라고 생각하면 됩니다.

서버 인증서는 VPN 서버의 여권입니다. 클라이언트가 VPN에 연결할 때 "당신이 진짜 우리 회사 VPN 서버가 맞나요?"라고 확인할 수 있게 해줍니다.

클라이언트 인증서는 개발자 각자의 여권입니다. VPN 서버가 "당신이 우리 회사에서 허가한 사용자가 맞나요?"라고 확인할 수 있게 해줍니다.

이제 실제로 인증서를 만들어봅시다. 먼저 easy-rsa를 설치합니다.

이 도구는 OpenVPN 프로젝트에서 제공하는 인증서 관리 스크립트입니다. 복잡한 OpenSSL 명령어를 쉽게 사용할 수 있도록 감싸놓은 것입니다.

init-pki 명령은 **PKI(Public Key Infrastructure)**를 초기화합니다. 쉽게 말해 인증서를 저장할 폴더 구조를 만드는 것입니다.

build-ca 명령으로 CA를 생성합니다. nopass 옵션은 비밀번호 없이 생성한다는 의미입니다.

프로덕션 환경에서는 비밀번호를 설정하는 것이 좋지만, 테스트 환경에서는 편의상 생략하기도 합니다. build-server-full 명령으로 서버 인증서를 생성합니다.

이 인증서는 AWS ACM(Certificate Manager)에 업로드하여 VPN 엔드포인트가 사용합니다. build-client-full 명령으로 클라이언트 인증서를 생성합니다.

팀원마다 별도의 클라이언트 인증서를 발급할 수도 있고, 팀 전체가 하나의 인증서를 공유할 수도 있습니다. 생성된 파일들을 살펴보면, pki/issued/ 폴더에는 인증서(.crt) 파일이, pki/private/ 폴더에는 개인키(.key) 파일이 저장됩니다.

pki/ca.crt는 CA 인증서입니다. 주의할 점이 있습니다.

개인키 파일은 절대로 외부에 노출되면 안 됩니다. 개인키가 유출되면 해당 인증서를 폐기하고 새로 발급해야 합니다. 특히 Git 저장소에 실수로 커밋하지 않도록 주의하세요.

김개발 씨가 명령어를 따라 실행하면서 물었습니다. "이렇게 만든 인증서를 AWS에 어떻게 등록하나요?" 박시니어 씨가 답했습니다.

"다음 단계로 ACM에 업로드하고, VPN 엔드포인트를 생성할 거예요."

실전 팁

💡 - 개인키(.key) 파일은 절대 Git에 커밋하지 마세요

• 프로덕션 환경에서는 CA 생성 시 비밀번호를 설정하세요
• 팀원별로 별도 클라이언트 인증서를 발급하면 개별 폐기가 가능합니다

---

4. Client VPN 엔드포인트 생성

인증서 준비가 끝났습니다. 이제 AWS 콘솔에서 실제 VPN 엔드포인트를 생성할 차례입니다.

박시니어 씨가 AWS 콘솔을 열며 말했습니다. "VPN 엔드포인트는 클라이언트들이 접속할 문이에요.

이 문을 통해 VPC 내부로 들어갈 수 있죠." 김개발 씨는 화면을 주시하며 한 단계씩 따라갔습니다.

Client VPN 엔드포인트는 VPN 접속의 진입점입니다. 생성 시 클라이언트 CIDR(VPN 클라이언트에게 할당할 IP 대역), 인증 방식, 연결할 VPC를 지정합니다.

엔드포인트 생성 후에는 서브넷 연결과 인증 규칙을 추가로 설정해야 실제로 사용할 수 있습니다.

다음 코드를 살펴봅시다.

# 1. ACM에 인증서 업로드
aws acm import-certificate \
  --certificate fileb://pki/issued/server.crt \
  --private-key fileb://pki/private/server.key \
  --certificate-chain fileb://pki/ca.crt \
  --region ap-northeast-2

# 클라이언트 CA 인증서도 업로드 (클라이언트 인증용)
aws acm import-certificate \
  --certificate fileb://pki/ca.crt \
  --private-key fileb://pki/private/ca.key \
  --region ap-northeast-2

# 2. Client VPN 엔드포인트 생성
aws ec2 create-client-vpn-endpoint \
  --client-cidr-block "10.100.0.0/16" \
  --server-certificate-arn "arn:aws:acm:ap-northeast-2:123456789:certificate/xxx" \
  --authentication-options Type=certificate-authentication,MutualAuthentication={ClientRootCertificateChainArn=arn:aws:acm:...} \
  --connection-log-options Enabled=false \
  --vpc-id vpc-0abcd1234 \
  --split-tunnel

# 3. 서브넷 연결 (프라이빗 서브넷)
aws ec2 associate-client-vpn-target-network \
  --client-vpn-endpoint-id cvpn-endpoint-xxx \
  --subnet-id subnet-private-xxx

# 4. 인증 규칙 추가 (VPC CIDR 접근 허용)
aws ec2 authorize-client-vpn-ingress \
  --client-vpn-endpoint-id cvpn-endpoint-xxx \
  --target-network-cidr "10.0.0.0/16" \
  --authorize-all-groups

김개발 씨는 AWS 콘솔의 VPC 서비스로 이동했습니다. 왼쪽 메뉴에서 Client VPN Endpoints를 찾을 수 있었습니다.

박시니어 씨가 첫 번째 단계를 안내했습니다. "먼저 아까 만든 인증서를 **ACM(AWS Certificate Manager)**에 업로드해야 해요." ACM은 AWS에서 인증서를 관리하는 서비스입니다.

VPN 엔드포인트가 인증서를 사용하려면 ACM에 등록되어 있어야 합니다. 서버 인증서와 CA 인증서, 두 개를 각각 업로드합니다.

업로드가 완료되면 VPN 엔드포인트 생성 화면으로 이동합니다. 여기서 몇 가지 중요한 설정을 해야 합니다.

Client IPv4 CIDR은 VPN에 접속한 클라이언트들에게 할당할 IP 대역입니다. 이 대역은 VPC의 CIDR과 겹치지 않아야 합니다.

예를 들어 VPC가 10.0.0.0/16을 사용한다면, 클라이언트 CIDR은 10.100.0.0/16처럼 다른 대역을 지정합니다. Server certificate ARN에는 앞서 ACM에 업로드한 서버 인증서를 선택합니다.

Authentication Options에서는 상호 인증을 선택하고, 클라이언트 CA 인증서의 ARN을 지정합니다. Split Tunnel 옵션은 중요한 선택입니다.

이 옵션을 활성화하면 VPC로 가는 트래픽만 VPN을 통해 전송되고, 나머지 인터넷 트래픽은 일반 경로로 전송됩니다. 비활성화하면 모든 트래픽이 VPN을 경유하므로 속도가 느려질 수 있습니다.

엔드포인트 생성 후에도 할 일이 남아 있습니다. **서브넷 연결(Associate Target Network)**을 해야 합니다.

VPN 엔드포인트를 어떤 서브넷과 연결할지 지정하는 것입니다. 프라이빗 서브넷을 선택하면 VPN 클라이언트가 해당 서브넷의 리소스에 접근할 수 있습니다.

고가용성을 위해 여러 가용 영역의 서브넷을 연결할 수도 있습니다. **인증 규칙(Authorization Rules)**도 추가해야 합니다.

기본적으로는 아무 것도 접근할 수 없습니다. VPC CIDR(예: 10.0.0.0/16)에 대한 접근을 허용하는 규칙을 추가해야 프라이빗 리소스에 접근할 수 있습니다.

김개발 씨가 궁금한 점을 물었습니다. "서브넷 연결에 비용이 발생하나요?" 박시니어 씨가 고개를 끄덕였습니다.

"네, 서브넷 연결당 시간당 요금이 부과돼요. 그래서 테스트할 때는 하나의 서브넷만 연결하고, 프로덕션에서는 고가용성을 위해 여러 개를 연결하는 경우가 많아요." 모든 설정이 완료되면 엔드포인트 상태가 Available로 바뀝니다.

이제 클라이언트 설정 파일을 다운로드받을 준비가 되었습니다.

실전 팁

💡 - 클라이언트 CIDR은 VPC CIDR과 겹치지 않게 설정하세요

• Split Tunnel을 활성화하면 일반 인터넷 속도에 영향을 주지 않습니다
• 서브넷 연결당 비용이 발생하므로 필요한 만큼만 연결하세요

---

5. VPN 클라이언트 설정 및 연결

AWS 콘솔에서 모든 설정이 끝났습니다. 이제 개발자 PC에서 VPN에 접속할 차례입니다.

박시니어 씨가 "클라이언트 설정 파일 다운로드" 버튼을 클릭했습니다. "이 파일을 받아서 약간 수정하고, VPN 클라이언트로 열면 끝이에요." 김개발 씨의 눈이 반짝였습니다.

드디어 연결할 수 있는 것입니다.

AWS 콘솔에서 다운로드한 .ovpn 설정 파일에 클라이언트 인증서와 개인키를 추가해야 합니다. 수정된 파일을 OpenVPN 또는 AWS VPN Client로 열어 연결합니다.

macOS, Windows, Linux 모두 지원되며, AWS 공식 클라이언트를 사용하면 가장 간편합니다.

다음 코드를 살펴봅시다.

# 1. AWS 콘솔에서 클라이언트 설정 파일 다운로드
# VPC > Client VPN Endpoints > 엔드포인트 선택 > Download Client Configuration

# 2. 다운로드받은 .ovpn 파일 끝에 클라이언트 인증서와 키 추가
cat >> downloaded-config.ovpn << 'EOF'

<cert>
-----BEGIN CERTIFICATE-----
(pki/issued/client1.domain.tld.crt 내용 붙여넣기)
-----END CERTIFICATE-----
</cert>

<key>
-----BEGIN PRIVATE KEY-----
(pki/private/client1.domain.tld.key 내용 붙여넣기)
-----END PRIVATE KEY-----
</key>
EOF

# 3. OpenVPN으로 연결 (Linux/macOS 터미널)
sudo openvpn --config downloaded-config.ovpn

# 연결 성공 시 출력 예시
# Initialization Sequence Completed

# 4. 연결 확인
ip addr show tun0    # 가상 네트워크 인터페이스 확인
ping 10.0.1.100      # 프라이빗 서브넷 리소스 테스트

김개발 씨는 AWS 콘솔에서 Download Client Configuration 버튼을 클릭했습니다. downloaded-client-config.ovpn이라는 파일이 다운로드되었습니다.

박시니어 씨가 파일을 열어 보여주었습니다. "이 파일에는 VPN 서버 주소, 포트, 프로토콜 같은 기본 설정이 들어 있어요.

하지만 클라이언트 인증서는 없어요. 우리가 직접 추가해야 합니다." 파일의 마지막 부분을 보면 아무 것도 없습니다.

여기에 두 가지를 추가해야 합니다. 첫 번째는 클라이언트 인증서입니다.

앞서 생성한 pki/issued/client1.domain.tld.crt 파일의 내용을 <cert> 태그 사이에 붙여넣습니다. 두 번째는 클라이언트 개인키입니다.

pki/private/client1.domain.tld.key 파일의 내용을 <key> 태그 사이에 붙여넣습니다. 수정이 완료되면 이제 VPN 클라이언트로 연결할 수 있습니다.

OpenVPN을 사용하는 경우, 터미널에서 sudo openvpn --config 명령으로 바로 연결할 수 있습니다. 연결이 성공하면 Initialization Sequence Completed라는 메시지가 출력됩니다.

AWS VPN Client를 사용하면 GUI로 더 편리하게 연결할 수 있습니다. AWS 공식 홈페이지에서 macOS, Windows용 클라이언트를 다운로드할 수 있습니다.

프로파일 추가 메뉴에서 .ovpn 파일을 선택하면 됩니다. 연결 후 ip addr show tun0 명령을 실행하면 가상 네트워크 인터페이스가 생성된 것을 확인할 수 있습니다.

클라이언트 CIDR 범위의 IP가 할당되어 있을 것입니다. ip route 명령을 실행하면 VPC CIDR로 가는 트래픽이 tun0 인터페이스로 라우팅되는 것을 볼 수 있습니다.

이제 프라이빗 서브넷의 리소스에 접근할 준비가 완료되었습니다. 김개발 씨가 연결에 성공하자 환하게 웃었습니다.

"와, 진짜 연결됐어요!" 하지만 박시니어 씨가 한 가지 주의사항을 덧붙였습니다. "연결이 끊어지면 .ovpn 파일에 개인키가 그대로 남아 있으니까 조심해야 해요.

파일 권한을 600으로 설정하고, 다른 사람과 공유하면 안 돼요." 연결 문제가 발생한다면 몇 가지를 확인해보세요. 첫째, 보안 그룹에서 UDP 443 또는 1194 포트가 열려 있는지 확인합니다.

둘째, 라우팅 테이블이 올바르게 설정되어 있는지 확인합니다. 셋째, CloudWatch Logs에서 연결 로그를 활성화하면 자세한 오류 원인을 파악할 수 있습니다.

실전 팁

💡 - .ovpn 파일에는 개인키가 포함되어 있으므로 파일 권한을 600으로 설정하세요

• AWS VPN Client는 GUI로 편리하게 연결할 수 있어 초보자에게 추천합니다
• 연결 문제 시 CloudWatch Logs로 디버깅하세요

---

6. VPN으로 프라이빗 RDS 접속 테스트

드디어 마지막 단계입니다. VPN에 연결된 상태에서 프라이빗 RDS에 접속해봅시다.

김개발 씨는 처음 입사했을 때 실패했던 그 명령어를 다시 입력했습니다. 이번에는 달랐습니다.

터미널에 "Welcome to the MySQL monitor"라는 메시지가 나타났습니다. 박시니어 씨가 어깨를 두드리며 말했습니다.

"축하해요. 이제 프라이빗 리소스에 마음껏 접근할 수 있어요."

VPN 연결 상태에서는 프라이빗 서브넷의 RDS, ElastiCache, EC2 등에 직접 접근할 수 있습니다. 로컬의 데이터베이스 클라이언트(MySQL Workbench, DBeaver, psql 등)로 프라이빗 RDS 엔드포인트에 연결하면 됩니다.

마치 AWS VPC 안에 있는 EC2에서 접속하는 것과 동일한 경험을 제공합니다.

다음 코드를 살펴봅시다.

# VPN 연결 상태 확인
ip route | grep tun
# 10.0.0.0/16 dev tun0 proto static scope link

# 프라이빗 RDS 연결 테스트 (MySQL)
mysql -h private-rds.cluster-abcd1234.ap-northeast-2.rds.amazonaws.com \
  -u admin -p -P 3306
# Enter password: ****
# Welcome to the MySQL monitor. Commands end with ; or \g.

# 프라이빗 RDS 연결 테스트 (PostgreSQL)
psql -h private-postgres.abcd1234.ap-northeast-2.rds.amazonaws.com \
  -U postgres -d mydb
# Password for user postgres: ****
# mydb=>

# 프라이빗 EC2 SSH 접속
ssh -i mykey.pem ec2-user@10.0.1.50

# 프라이빗 ElastiCache Redis 연결
redis-cli -h private-redis.abcd12.0001.apn2.cache.amazonaws.com -p 6379
# private-redis.abcd12.0001.apn2.cache.amazonaws.com:6379>

김개발 씨는 입사 첫 날의 기억을 떠올렸습니다. 선배가 알려준 RDS 주소로 접속을 시도했지만, 연결 시간 초과 오류만 반복됐었습니다.

그때는 왜 안 되는지 이유조차 몰랐습니다. 하지만 이제는 다릅니다.

VPN이 어떻게 동작하는지 이해했고, 직접 설정까지 해봤습니다. VPN에 연결된 상태에서 같은 명령어를 입력했습니다.

몇 초 후, 터미널에 익숙한 MySQL 프롬프트가 나타났습니다. Welcome to the MySQL monitor. 드디어 성공입니다.

박시니어 씨가 설명을 덧붙였습니다. "이제 너의 노트북은 VPC 내부에 있는 것처럼 동작해요.

프라이빗 서브넷에 있는 모든 리소스에 접근할 수 있어요." 실제로 테스트해보면, 프라이빗 RDS뿐만 아니라 다양한 리소스에 접근할 수 있습니다. 프라이빗 EC2에 SSH로 직접 접속할 수 있습니다.

더 이상 배스천 호스트를 거칠 필요가 없습니다. ssh -i mykey.pem ec2-user@10.0.1.50처럼 프라이빗 IP로 바로 연결하면 됩니다.

ElastiCache Redis에도 접근할 수 있습니다. ElastiCache는 보안상 VPC 내부에서만 접근할 수 있도록 설계되어 있습니다.

VPN을 통해 redis-cli로 직접 연결하여 캐시 상태를 확인하거나 디버깅할 수 있습니다. **Elasticsearch(OpenSearch)**나 DocumentDB 같은 서비스도 마찬가지입니다.

프라이빗 서브넷에 배포된 모든 AWS 리소스에 로컬 도구로 접근할 수 있습니다. 개발 워크플로우가 크게 개선됩니다.

예전에는 배스천 호스트에 SSH 터널을 설정하고, 로컬 포트 포워딩을 구성하는 복잡한 과정이 필요했습니다. 이제는 VPN에 연결만 하면 끝입니다.

MySQL Workbench나 DBeaver 같은 GUI 도구도 그대로 사용할 수 있습니다. 연결 설정에서 호스트를 프라이빗 RDS 엔드포인트로 지정하기만 하면 됩니다.

로컬에서 개발하는 것처럼 편리하게 작업할 수 있습니다. 김개발 씨가 만족스러운 표정으로 말했습니다.

"이렇게 편한 거였군요. 왜 진작 안 알려주셨어요?" 박시니어 씨가 웃으며 답했습니다.

"네가 직접 삽질해봐야 제대로 기억하거든요. 이제 VPN 설정은 문제없겠지?" 한 가지 주의할 점이 있습니다.

VPN 연결 중에는 보안 그룹도 확인해야 합니다. RDS 보안 그룹에서 VPN 클라이언트 CIDR(예: 10.100.0.0/16)로부터의 접속을 허용해야 합니다.

그렇지 않으면 VPN은 연결되었는데 RDS 접속이 안 되는 상황이 발생할 수 있습니다. 김개발 씨는 오늘 배운 내용을 정리하며 생각했습니다.

VPN은 단순히 연결 도구가 아니라, 안전하게 프라이빗 리소스에 접근하기 위한 필수 인프라라는 것을. 그리고 이제 그 인프라를 직접 구축하고 관리할 수 있게 되었습니다.

실전 팁

💡 - RDS 보안 그룹에서 VPN 클라이언트 CIDR을 허용해야 접속이 가능합니다

• GUI 도구(MySQL Workbench, DBeaver)도 프라이빗 엔드포인트로 직접 연결됩니다
• VPN 사용 후에는 연결을 해제하여 불필요한 비용을 방지하세요

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!