재택 근무자가 VPN에 접속했지만 내부 서비스 일부만 접근됩니다. 예전처럼 "VPN 접속 = 내부망 전체 허용"으로 생각하면 라우팅과 접근 정책을 잘못 판단하게 됩니다.
VPN과 제로 트러스트는 신뢰의 범위를 다르게 잡습니다. 접속 성공과 권한 허용을 분리해서 봐야 합니다.
VPN과 제로 트러스트 보안 아키텍처
재택근무가 확산되면서 "회사 내부 시스템에 어디서든 안전하게 접속"하는 것은 인프라 엔지니어의 핵심 과제가 되었습니다. 과거에는 "내부 네트워크 = 안전"이라는 경계 기반 보안 모델을 사용했지만, 이제는 그 가정 자체를 버린 제로 트러스트 아키텍처가 표준이 되고 있습니다. 이 챕터에서는 VPN의 기술적 원리부터 현대적인 Zero Trust 개념까지 함께 학습합니다.
VPN 기술 원리
- 1IPsec(L3)과 SSL/TLS VPN(L4~L7)의 동작 원리 및 차이점 비교
- 2Zero Trust 아키텍처 핵심 원칙 — Never Trust, Always Verify
- 3NAC(Network Access Control)를 통한 디바이스 접속 검증 흐름
- 4.ovpn 파일로 OpenVPN 클라이언트 접속 및 트러블슈팅
- 5WireGuard 클라이언트 설정 — 차세대 VPN 연결 방법
- 6Cloudflare Zero Trust, Teleport 등 현업 ZTNA 도구 이해
sudo apt-get install openvpnsudo apt install wireguardsudo apt-get install netcat-openbsdIPsec vs SSL VPN — 두 가지 VPN 기술의 차이
재택근무 중 팀원이 회사 내부 API 서버에 접근해야 합니다. 포트를 외부에 열어두기엔 보안이 걱정되고, VPN을 도입하자니 IPsec과 SSL VPN 중 무엇을 선택해야 할지 모르겠습니다. 각 방식이 어떻게 동작하고 어떤 상황에 적합한지 알아야 인프라 설계에서 올바른 선택을 할 수 있습니다.
VPN의 기본 원리
VPN(Virtual Private Network)은 공용 인터넷 위에 암호화된 터널을 만들어 마치 전용 회선처럼 사용하는 기술입니다. 카페 Wi-Fi에서 회사 DB에 접속한다고 생각해보세요 — 패킷이 평문으로 전송되면 네트워크 위의 누구나 내용을 볼 수 있습니다. VPN은 이 구간을 암호화해서 공용 인터넷을 통과하면서도 내부망에 직접 연결된 것처럼 동작하게 합니다.
원격 사용자 (집) 회사 내부망
│ │
│ [암호화된 VPN 터널] │
│◀══════════════════════════════════▶│
│ 일반 인터넷 패킷처럼 보이지만 │
│ 내용은 암호화됨 │
│ │
내부 서버에 직접 연결된 것처럼 동작!
IPsec VPN
IPsec(Internet Protocol Security)은 **L3(네트워크 계층)**에서 동작하며, IP 패킷 자체를 암호화합니다.
IPsec 동작 모드:
├── Transport 모드: 페이로드만 암호화 (호스트-to-호스트)
└── Tunnel 모드: 전체 IP 패킷을 새 IP 헤더로 캡슐화 (네트워크-to-네트워크)
IPsec 프로토콜:
├── AH (Authentication Header): 무결성 인증만
└── ESP (Encapsulating Security Payload): 암호화 + 인증
키 교환: IKE (Internet Key Exchange) - UDP 500번 포트
IPsec의 특성을 한눈에 정리하면 언제 선택해야 하는지 판단 기준이 명확해집니다.
| 항목 | 내용 |
|---|---|
| 동작 계층 | L3 (네트워크) |
| 클라이언트 | OS 내장 (Windows/macOS/Linux) |
| 방화벽 통과 | 어려움 (UDP 500, ESP 프로토콜 필요) |
| 성능 | 높음 (커널 수준 처리) |
| 주요 사용처 | 사이트 간 VPN, 기업 원격 접속 |
SSL/TLS VPN (OpenVPN)
SSL VPN은 **TLS(전송 계층 보안)**를 사용하여 암호화 터널을 구성합니다. OpenVPN은 가장 널리 사용되는 오픈소스 SSL VPN입니다.
OpenVPN 터널 구조:
┌────────────────────────────────┐
│ 원본 패킷 (내부 트래픽) │
├────────────────────────────────┤
│ OpenVPN 헤더 │
├────────────────────────────────┤
│ TLS 암호화 페이로드 │
├────────────────────────────────┤
│ UDP/TCP 헤더 (1194 기본 포트) │
├────────────────────────────────┤
│ 외부 IP 헤더 │
└────────────────────────────────┘
SSL VPN 특징:
| 항목 | 내용 |
|---|---|
| 동작 계층 | L4~L7 (TLS 사용) |
| 클라이언트 | 별도 소프트웨어 설치 |
| 방화벽 통과 | 쉬움 (TCP 443 사용 가능) |
| 인증 방식 | 인증서, 사용자명/비밀번호, MFA |
| 주요 사용처 | 원격 접속 VPN |
IPsec vs SSL VPN 비교
┌────────────────┬──────────────┬──────────────┐
│ 항목 │ IPsec │ SSL VPN │
├────────────────┼──────────────┼──────────────┤
│ 표준 │ IETF RFC │ OpenVPN 등 │
│ 계층 │ L3 │ L4~L7 │
│ 클라이언트 │ OS 내장 │ 별도 앱 필요 │
│ NAT 통과 │ NAT-T 필요 │ 쉬움 │
│ 방화벽 통과 │ 어려움 │ 쉬움 │
│ 성능 │ 높음 │ 보통 │
└────────────────┴──────────────┴──────────────┘
Zero Trust 아키텍처 — 경계 기반 보안의 한계와 극복
VPN으로 내부망에 접속한 직원 계정이 탈취되었습니다. 공격자는 내부망에 진입한 순간 모든 서버에 자유롭게 접근할 수 있었습니다. 내부는 믿는다는 "경계 기반 보안"의 전제가 무너진 것입니다. Zero Trust는 이 전제를 버리고 내부에서도 매번 인증/인가를 요구하는 방식으로, 클라우드 환경에서 점점 표준이 되어가고 있습니다.
전통적인 경계 기반 보안의 한계
전통 모델 ("성벽" 패러다임):
┌─────────────────────────────────────────┐
│ 내부 네트워크 │
│ ← 여기는 신뢰! 뭐든 OK │
│ │
│ 서버 A ─── 서버 B ─── DB │
│ (내부라서 암호화/인증 없음) │
└──────────────────┬──────────────────────┘
│ 방화벽 (성벽)
인터넷 (불신 구역)
문제점:
- 한 번 내부 진입에 성공하면 자유롭게 이동 가능 (Lateral Movement)
- 내부자 위협에 취약 (직원, 계약업체)
- 클라우드/SaaS 환경에서 "내부"의 경계가 모호
Zero Trust 핵심 원칙
"Never Trust, Always Verify" — 절대 신뢰하지 않고, 항상 검증
Zero Trust 모델:
┌─────────────────────────────────────────────┐
│ 모든 접속 요청 → 정책 엔진 → 허용/거부 │
│ │
│ 검증 항목: │
│ ✓ 사용자 신원 (MFA 인증) │
│ ✓ 디바이스 상태 (보안 패치, 백신) │
│ ✓ 접속 위치 (지리적 이상 탐지) │
│ ✓ 요청 행위 (정상 패턴인지) │
│ ✓ 최소 권한 (필요한 리소스만) │
└─────────────────────────────────────────────┘
Zero Trust의 5가지 원칙
- 최소 권한 원칙: 필요한 최소한의 접근 권한만 부여
- 마이크로 세그멘테이션: 내부 네트워크도 세밀하게 분리
- 다중 인증(MFA): 비밀번호 + 추가 인증 수단 필수
- 지속적 검증: 세션 중에도 지속적으로 신뢰 검증
- 암호화: 내부 트래픽도 암호화 (TLS)
NAC (Network Access Control)
NAC는 Zero Trust의 구현 요소 중 하나로, 네트워크에 접속하려는 디바이스를 검증합니다.
NAC 동작 흐름:
디바이스 접속 시도
│
▼
NAC 에이전트가 디바이스 상태 검사
├── OS 최신 패치 여부
├── 백신 소프트웨어 설치 및 업데이트
├── 디스크 암호화 활성화 여부
└── 회사 인증서 설치 여부
│
▼
정책 서버에서 결정
├── 합격: 정상 네트워크 접속 허용
├── 불합격: 격리 네트워크로 이동 (치료 전용)
└── 미인증 디바이스: 게스트 네트워크만 허용
실습 — VPN 클라이언트 연결
회사나 팀에서 .ovpn 파일을 받아 VPN에 접속하는 방법을 실습합니다. 백엔드 개발자가 재택근무나 신규 입사 시 가장 먼저 하게 되는 작업입니다.
# 실습 디렉토리 준비
mkdir -p /tmp/networking/part5/exam_26 && cd /tmp/networking/part5/exam_26
# 팀장에게 받은 client.ovpn 파일로 VPN 접속
sudo openvpn --config client.ovpn
# 접속 성공 시 출력 (마지막 줄)
# Initialization Sequence Completed
# VPN 인터페이스 확인 — tun0에 IP가 할당되어야 함
ip addr show tun0
# 3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP>
# inet 10.8.0.6/24 brd 10.8.0.255 scope global tun0
# 내부망 서버 접속 테스트
ping 10.0.0.10
curl -s http://10.0.0.20:8080/health
# 라우팅 테이블 확인 — VPN 서브넷이 tun0을 통해야 함
ip route show | grep tun0
# 10.0.0.0/16 via 10.8.0.1 dev tun0
# 10.8.0.0/24 dev tun0
- 핵심 출력—명령 결과에서 성공/실패를 가르는 값을 먼저 확인합니다
- 대상 식별—IP, 포트, 인터페이스, 프로세스명처럼 다음 조치를 결정하는 필드를 봅니다
- 다음 분기—결과가 기대와 다르면 어느 계층을 이어서 점검할지 정합니다
접속 전 포트 연결 확인 (안 될 때 먼저 체크):
# VPN 서버 UDP 1194 포트가 뚫려 있는지 테스트
nc -u -z -w 5 -v vpn.company.com 1194
# Connection to vpn.company.com 1194 port [udp/*] succeeded!
# 위 메시지가 안 나오면 → 현재 네트워크가 UDP 1194를 차단 중
# 차단된 경우: TCP 443 폴백 가능한지 확인
nc -z -w 5 -v vpn.company.com 443
WireGuard는 OpenVPN보다 훨씬 간단한 설정으로 고성능 VPN을 제공합니다. 요즘 팀 VPN으로 WireGuard를 쓰는 회사가 빠르게 늘고 있습니다.
팀에서 WireGuard 설정 파일(.conf)을 받아 연결하는 방법:
# 받은 wg0.conf 파일을 시스템에 배치
sudo cp ~/Downloads/wg0.conf /etc/wireguard/wg0.conf
sudo chmod 600 /etc/wireguard/wg0.conf
# wg0.conf 내용 예시 (인프라팀이 만들어 준 파일)
cat /etc/wireguard/wg0.conf
# [Interface]
# Address = 10.9.0.5/24 ← 나한테 할당된 VPN IP
# PrivateKey = <내 개인키>
# DNS = 10.9.0.1
#
# [Peer]
# PublicKey = <서버 공개키>
# Endpoint = vpn.company.com:51820
# AllowedIPs = 10.0.0.0/8 ← 이 대역은 VPN 터널로 보냄
# VPN 연결 시작
sudo wg-quick up wg0
# 연결 상태 확인
sudo wg show
# interface: wg0
# public key: ...
# listening port: 12345
# peer: ...
# endpoint: vpn.company.com:51820
# latest handshake: 5 seconds ago
# transfer: 1.23 KiB received, 2.34 KiB sent
# 내부망 접속 테스트
ping 10.0.0.10
ssh admin@10.0.0.20
# VPN 연결 해제
sudo wg-quick down wg0
키 생성 (인프라팀에서 서버 설정 시 사용 — 참고):
# 클라이언트 키 페어 생성
wg genkey | tee privatekey | wg pubkey > publickey
cat privatekey # 이 키는 절대 공유하지 않음
cat publickey # 이 키를 서버 관리자에게 전달
트러블슈팅
증상
VPN에 연결은 되었고 tun0 인터페이스도 생겼는데, 회사 내부 서버에 ping이 가지 않습니다.
# VPN 연결 성공
ip addr show tun0
# inet 10.8.0.6/24 ... ← VPN IP 할당 확인
# 내부 서버 ping 실패
ping 10.0.0.10
# Request timeout for icmp_seq 0
# 라우팅 테이블 확인
ip route show
# 10.0.0.0/16 via 10.8.0.1 dev tun0 ← 라우트는 있음
# 10.8.0.0/24 dev tun0 ← VPN 서브넷
# 192.168.1.0/24 dev eth0 ← 로컬 WiFi
진단 — 서브넷 충돌 확인
# 로컬 네트워크 확인
ip route show | grep eth0
# 192.168.1.0/24 dev eth0
# VPN 서버의 내부망 서브넷 확인 (서버 설정에서)
# push "route 10.0.0.0 255.255.0.0" ← 10.0.0.0/16
# 충돌 확인: 로컬이 192.168.1.x이고 내부망이 10.0.0.x이면 괜찮음
# 문제 발생 예시:
# 로컬 WiFi: 192.168.1.0/24
# VPN 내부망: 192.168.1.0/24 ← 동일! 충돌!
해결 방법
서브넷 충돌이 원인인 경우:
이 명령은 서버의 라우팅 또는 인터페이스 설정을 바꿔 원격 접속이 끊길 수 있습니다. 콘솔 접근과 현재 라우팅 백업을 확보한 뒤 실행하세요.
# 서버 설정 변경: 덜 일반적인 서브넷 사용
# /etc/openvpn/server/server.conf 에서:
# server 10.8.0.0 255.255.255.0 → 기존
# push "route 192.168.100.0 255.255.255.0" → 충돌하지 않는 내부망
# 클라이언트에서 수동 라우팅 추가
sudo ip route add 10.0.0.0/16 via 10.8.0.1 dev tun0
VPN 라우팅이 적용 안 되는 경우:
# VPN 서버 로그 확인
sudo tail -f /var/log/openvpn/openvpn.log
# push route가 실제로 전달되는지 확인
# 클라이언트에서 openvpn 실행 시 verbose 3으로 설정하고 로그 확인:
# PUSH: Received control message: 'PUSH_REPLY,...,route 10.0.0.0 255.255.0.0,...'
# 클라이언트 설정에 pull 지시어 있는지 확인
grep pull client1.ovpn
# client 지시어가 있으면 pull이 포함됨
증상
팀장에게 받은 .ovpn 파일로 OpenVPN을 실행했는데 연결이 안 됩니다. GUI 클라이언트(Tunnelblick, OpenVPN Connect)에서는 그냥 "연결 실패"로만 보이고, 터미널에서 실행하면 아래 로그가 출력됩니다.
2024-03-15 10:23:41 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2024-03-15 10:23:41 TLS Error: TLS handshake failed
2024-03-15 10:23:41 SIGUSR1[soft,tls-error] received, process restarting
ping은 되는데 VPN만 안 됩니다.
ping vpn.company.com
# PING vpn.company.com: 56 data bytes
# 64 bytes from 203.0.113.50: icmp_seq=0 ttl=55 time=12.3 ms
원인 진단 — 방화벽이 UDP 1194를 막는 경우
TLS key negotiation 타임아웃은 대부분 VPN 서버 포트까지 패킷이 도달하지 못하는 경우입니다. ICMP(ping)는 통과하지만 OpenVPN이 쓰는 UDP 1194 포트가 방화벽에서 차단되는 상황이 가장 흔합니다.
# OpenVPN 기본 포트(UDP 1194) 연결 테스트
nc -u -z -v vpn.company.com 1194 -w 5
# nc: connect to vpn.company.com port 1194 (udp) failed: Connection refused
# 또는 아무 응답 없이 5초 후 종료 → 방화벽이 DROP하는 것
# 이 경우 TCP 443 폴백이 가능한지 확인
# .ovpn 파일에 이런 설정이 있는지 확인
grep "proto\|port" client.ovpn
# proto udp ← UDP 사용 중
# port 1194
해결 방법
방법 1: 사무실/카페 WiFi에서 UDP가 차단되는 경우 — TCP 443으로 전환
회사 서버 측에 TCP 443 모드가 활성화되어 있다면, 팀장에게 TCP 버전 .ovpn 파일을 요청합니다. 또는 직접 수정:
# client.ovpn 에서
# proto udp → proto tcp
# port 1194 → port 443
TCP 443은 HTTPS 포트라 대부분의 네트워크에서 차단되지 않습니다.
방법 2: .ovpn 파일에 인증 파일이 빠진 경우
받은 .ovpn 파일이 인증서/키를 파일 경로로 참조하는 형태라면, 해당 파일들이 같은 디렉토리에 있어야 합니다.
# .ovpn 파일 내용 확인
grep -E "^ca |^cert |^key |^tls-auth " client.ovpn
# ca ca.crt ← ca.crt 파일이 같은 폴더에 있어야 함
# cert client1.crt
# key client1.key
# tls-auth ta.key 1
# 파일 존재 여부 확인
ls -la ca.crt client1.crt client1.key ta.key
# ls: cannot access 'ca.crt': No such file or directory ← 이게 문제!
해결: 팀장에게 인증서 파일 전체 묶음(zip)을 다시 받거나, .ovpn 파일이 인라인 방식으로 패키징된 버전을 요청합니다.
방법 3: 방화벽 로그로 정확한 차단 원인 파악
# Linux 클라이언트라면 openvpn --verb 6 으로 상세 로그
sudo openvpn --config client.ovpn --verb 6 2>&1 | head -50
# 로그에서 "Attempting to establish TCP connection with" 또는
# "write UDP: Network is unreachable" 등으로 정확한 원인 파악
왜 이런 일이 생기나
팀 입장에서는 VPN이 잘 되고 있어서 방심하기 쉽습니다. 신규 입사자가 집/카페에서 처음 접속 시도할 때야 환경 문제가 드러납니다. 회사 네트워크 내부에서는 UDP 1194가 직접 통하지만, 일반 인터넷에서는 ISP나 카페 공유기가 막는 경우가 많습니다.
실무 맥락
VPN과 Zero Trust의 공존
전통적인 VPN과 Zero Trust는 완전히 다른 것이 아닙니다. 많은 기업에서 VPN을 Zero Trust 방식으로 운영합니다.
기업 원격 접근 성숙도 단계:
1단계: VPN만 사용 (전통적)
외부 → VPN → 내부망 전체 접근 가능
2단계: VPN + MFA
외부 → VPN + OTP인증 → 내부망 접근
3단계: Zero Trust VPN (ZTNA)
외부 → 신원확인 + 디바이스검증 → 특정 앱만 접근
4단계: SASE (Secure Access Service Edge)
모든 트래픽 → 클라우드 보안 엣지 → 최소권한 접근
현업에서 자주 쓰는 Zero Trust 도구
오픈소스:
- Teleport: 서버, DB, 쿠버네티스 접근 Zero Trust 플랫폼
- Authentik: SSO + MFA 오픈소스
- WireGuard: 차세대 고성능 VPN (OpenVPN 대체)
상용 서비스:
- Cloudflare Zero Trust (구 Access + Gateway)
- Zscaler Private Access (ZPA)
- Palo Alto Prisma Access
WireGuard — 현대적 VPN 대안
OpenVPN의 복잡성을 줄인 간단하고 빠른 차세대 VPN입니다.
이 명령은 방화벽 정책을 변경해 현재 접속 중인 세션이나 운영 트래픽에 즉시 영향을 줄 수 있습니다. 적용 전 허용 대상 IP·포트와 롤백 명령을 확인하세요.
# WireGuard 설치 (Ubuntu)
sudo apt install wireguard
# 키 페어 생성
wg genkey | tee privatekey | wg pubkey > publickey
# 서버 설정 (/etc/wireguard/wg0.conf)
cat > /etc/wireguard/wg0.conf << 'EOF'
[Interface]
Address = 10.9.0.1/24
PrivateKey = <서버_개인키>
ListenPort = 51820
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
[Peer]
PublicKey = <클라이언트_공개키>
AllowedIPs = 10.9.0.2/32
EOF
# 서비스 시작
sudo systemctl enable --now wg-quick@wg0
보안 감사 관점 체크리스트
VPN/Zero Trust 감사 항목:
□ 모든 VPN 접속에 MFA 적용 여부
□ 인증서 유효 기간 및 갱신 관리
□ 불필요한 VPN 계정 비활성화 (퇴사자 등)
□ VPN 접속 로그 90일 이상 보관
□ 취약 암호화 알고리즘 (DES, 3DES) 사용 여부
□ Split Tunneling 정책 (기업 트래픽만 VPN)
□ Zero Trust 정책 정기 검토 (분기별)
정리
VPN 기술 비교
├── IPsec: L3, OS 내장, 성능 우수, 방화벽 통과 어려움
└── SSL VPN (OpenVPN): L4~L7, 앱 필요, 방화벽 통과 쉬움
Zero Trust 핵심 원칙
├── Never Trust, Always Verify
├── 최소 권한 원칙
├── 마이크로 세그멘테이션
├── 지속적 검증
└── 내부 트래픽도 암호화
OpenVPN 구축 요소
├── easy-rsa: PKI 인증서 관리 (CA, 서버, 클라이언트)
├── server.conf: 서버 설정 (서브넷, 라우트, 암호화)
├── .ovpn: 클라이언트 통합 설정 파일
└── ip_forward + iptables: 포워딩 및 NAT
주요 트러블슈팅
├── 서브넷 충돌 → 내부망/클라이언트/VPN 서브넷 모두 다르게 설정
└── 인증서 만료 → 만료 전 갱신 자동화 및 모니터링
다음 챕터에서는 폐쇄망 환경에서 Squid Proxy를 사용하여 외부 인터넷에 간접 접근하는 방법을 배웁니다.