VPN과 터널링 (3) - 현대 VPN 기술 - soo:bak

작성일 : 2026년 01월 20일

왜 새로운 VPN 프로토콜이 등장했는가

Part 2에서 IPsec의 구조를 살펴보았습니다.

IPsec은 강력한 보안을 제공하지만, 실무에서 여러 어려움이 있습니다.

IPsec이 가진 실질적인 문제점:

설정 복잡성: Phase 1/Phase 2, 다양한 모드, 수많은 암호 알고리즘 조합 등 설정해야 할 항목이 너무 많음
방화벽 통과 어려움: ESP(프로토콜 50), UDP 500/4500 등 일반적이지 않은 포트와 프로토콜 사용
모바일 환경의 한계: 사용자 IP 주소가 변경되면 SA 재협상이 필요하여 연결이 끊김
코드베이스 비대: 커널에 수십만 줄의 코드가 필요하여 버그와 보안 취약점 발생 가능성 증가

이러한 문제들을 해결하기 위해 더 단순하고 사용하기 쉬운 VPN 프로토콜들이 등장하게 되었습니다.

SSL/TLS VPN

SSL/TLS VPN은 웹 통신에 널리 사용되는 TLS 프로토콜을 VPN 터널에 적용한 방식입니다.

IPsec의 한계

IPsec은 네트워크 계층(L3)에서 동작하기 때문에 다음과 같은 제약이 있습니다.

커널 수준에서 동작하므로 관리자 권한이 필요
운영체제별로 별도의 커널 모듈이나 드라이버 설치 필요
ESP, UDP 500/4500 등 특수한 포트와 프로토콜을 사용하여 기업 방화벽에서 차단되는 경우가 많음

TLS VPN의 장점

반면 TLS는 애플리케이션 계층에서 동작하므로 이러한 제약을 우회할 수 있습니다.

HTTPS와 동일한 포트(443)를 사용하여 일반 웹 트래픽처럼 보임
대부분의 방화벽이 443 포트를 허용하므로 차단될 가능성이 낮음
웹 브라우저만으로도 VPN 접속이 가능한 구현 존재 (웹 기반 VPN)

TLS VPN 구조:
┌─────────────────────────────────────────────────────────────┐
│                    TLS (암호화)                             │
├─────────────────────────────────────────────────────────────┤
│                    TCP (포트 443)                           │
├─────────────────────────────────────────────────────────────┤
│                       IP                                    │
└─────────────────────────────────────────────────────────────┘

OpenVPN

OpenVPN은 2001년에 James Yonan이 시작한 오픈소스 VPN 프로젝트입니다.

TLS/SSL 기반의 VPN 중에서 가장 오래되고 널리 사용되는 솔루션입니다.

OpenVPN의 구조

┌─────────────────────────────────────────────────────────────┐
│                    OpenVPN 데이터                           │
├─────────────────────────────────────────────────────────────┤
│          TLS (제어 채널) / 자체 암호화 (데이터 채널)         │
├─────────────────────────────────────────────────────────────┤
│                TCP 또는 UDP (기본: UDP 1194)                │
├─────────────────────────────────────────────────────────────┤
│                          IP                                 │
└─────────────────────────────────────────────────────────────┘

OpenVPN은 두 가지 채널을 분리하여 운영합니다.

제어 채널: TLS로 보호되며, 인증과 키 교환을 담당
데이터 채널: 제어 채널에서 협상된 키로 암호화하여 실제 VPN 트래픽을 전송

OpenVPN의 특징

장점:

오픈소스로 무료 사용 가능하며 소스 코드 감사 가능
Windows, macOS, Linux, iOS, Android 등 다양한 플랫폼 지원
전송 프로토콜로 TCP 또는 UDP 선택 가능
포트 443을 사용하면 일반 HTTPS 트래픽처럼 보여 방화벽 우회가 쉬움
X.509 인증서, 사용자명/비밀번호, 2단계 인증 등 다양한 인증 방식 지원

단점:

커널이 아닌 사용자 공간(user space)에서 동작하여 컨텍스트 스위칭으로 인한 성능 오버헤드 발생
설정 파일의 옵션이 방대하여 초보자에게 진입 장벽이 있음
TCP 모드 사용 시 TCP-over-TCP 문제 발생

TCP-over-TCP 문제

OpenVPN을 TCP 모드로 사용하면 TCP가 이중으로 적용됩니다.

애플리케이션 TCP → OpenVPN 터널 → TCP (전송)

TCP가 두 번 적용됨

이 구조에서 네트워크 품질이 나빠지면 심각한 성능 저하가 발생합니다.

패킷 손실 시 내부 TCP와 외부 TCP가 모두 재전송을 시도
양쪽 TCP의 혼잡 제어가 서로 간섭하여 지연이 급격히 증가

따라서 네트워크 상태가 양호한 환경에서는 UDP 모드 사용을 권장합니다.

WireGuard

WireGuard는 보안 연구자 Jason Donenfeld가 설계한 현대적 VPN 프로토콜로, 2020년 Linux 커널 5.6에 정식 포함되었습니다.

설계 철학: 단순함

WireGuard의 핵심 설계 철학은 극단적인 단순함입니다.

코드 크기를 비교하면 그 차이가 명확합니다.

OpenVPN: 약 100,000줄
IPsec (strongSwan): 약 400,000줄
WireGuard: 약 4,000줄

코드가 적다는 것은 단순히 개발이 쉽다는 의미가 아닙니다.

잠재적인 버그 수가 적음
보안 감사(audit)가 실질적으로 가능한 규모
공격자가 노릴 수 있는 공격 표면(attack surface)이 작음

Noise Protocol Framework

WireGuard는 키 교환과 암호화를 위해 Noise Protocol Framework를 채택했습니다.

기존의 TLS나 IKE는 다양한 버전, 모드, 암호 알고리즘 협상으로 인해 복잡성이 높고 구현 오류가 발생하기 쉬웠습니다.

Noise는 이러한 문제를 근본적으로 다른 방식으로 해결합니다.

고정된 암호 조합: 알고리즘을 협상하지 않고 미리 정해진 조합만 사용
단순한 핸드셰이크: 최소한의 메시지 교환으로 연결 설정
형식적 검증 가능: 수학적으로 프로토콜의 보안 속성을 증명 가능

WireGuard가 사용하는 암호 알고리즘 조합은 다음과 같습니다.

Curve25519: 타원곡선 Diffie-Hellman 키 교환
ChaCha20: 고속 스트림 암호로 데이터 암호화
Poly1305: 메시지 인증 코드(MAC) 생성
BLAKE2s: 빠른 암호학적 해시 함수

WireGuard에는 “Cipher agility(암호 유연성)”가 없습니다.

사용자가 약한 알고리즘을 선택할 수 없으므로 설정 실수로 인한 보안 약화가 원천적으로 차단됩니다.

알고리즘에 취약점이 발견되면 프로토콜 버전 자체를 업그레이드하는 방식으로 대응합니다.

WireGuard 핸드셰이크

WireGuard의 핸드셰이크는 극도로 단순합니다.

Initiator                              Responder
    │                                      │
    │ ─── Handshake Initiation ─────────► │
    │     (임시 공개키, 타임스탬프)         │
    │                                      │
    │ ◄─── Handshake Response ──────────  │
    │     (임시 공개키, MAC)               │
    │                                      │
    │         [1-RTT로 완료]               │
    │                                      │
    │ ◄────── 데이터 전송 ──────────►     │
    │                                      │

단 1번의 왕복(1-RTT)만으로 암호화된 연결이 설정됩니다.

IKEv2가 2-RTT, TLS 1.2가 2-RTT인 것과 비교하면 연결 지연이 절반으로 줄어듭니다.

Cryptokey Routing

Cryptokey Routing은 WireGuard만의 독특한 개념으로, 공개키와 허용 IP 주소를 직접 연결합니다.

WireGuard에서 각 피어는 다음 두 가지 정보를 가집니다.

피어의 공개키
해당 피어가 사용할 수 있는 IP 주소 목록 (AllowedIPs)

[Peer]
PublicKey = xTIBA5rboUvnH4htodjb60Y7YAf21J7YQMlYhM2IPVY=
AllowedIPs = 10.200.200.2/32, 192.168.0.0/24

위 설정은 두 가지 동작을 정의합니다.

인바운드: 이 피어에서 오는 패킷은 출발지가 10.200.200.2 또는 192.168.0.0/24 대역인 경우만 허용
아웃바운드: 목적지가 해당 IP 범위인 패킷은 이 피어로 전송

이 구조에서 공개키가 곧 피어의 신원(identity)이 됩니다.

별도의 사용자 인증 없이 공개키 자체가 인증 수단으로 작동하며, IP 주소와 암호학적 신원이 직접 연결됩니다.

WireGuard의 특징

장점:

커널 공간에서 직접 동작하여 매우 빠른 처리 성능
설정 파일이 수십 줄 수준으로 단순하여 오류 가능성 낮음
1-RTT 핸드셰이크로 빠른 연결 설정
피어의 IP 주소가 변경되어도 자동으로 재연결 (모바일 로밍에 적합)
현대적이고 검증된 암호 알고리즘만 사용

단점:

2020년 Linux 커널 포함으로 상대적으로 역사가 짧음
암호 알고리즘을 선택할 수 없어 특수한 규제 환경에서 제약이 될 수 있음
UDP만 지원하여 UDP를 차단하는 방화벽 환경에서 사용 불가
DHCP처럼 동적으로 IP를 할당하는 기능이 내장되어 있지 않아 별도 도구 필요

프로토콜 비교

지금까지 살펴본 세 가지 VPN 프로토콜의 특성을 비교하면 다음과 같습니다.

┌────────────────┬──────────────┬──────────────┬──────────────┐
│     항목       │    IPsec     │   OpenVPN    │  WireGuard   │
├────────────────┼──────────────┼──────────────┼──────────────┤
│ 계층           │     L3       │    L4/L7     │      L3      │
├────────────────┼──────────────┼──────────────┼──────────────┤
│ 암호화         │   다양함     │   TLS 기반   │   고정 조합   │
├────────────────┼──────────────┼──────────────┼──────────────┤
│ 전송 프로토콜  │ ESP/UDP/TCP  │  TCP/UDP     │   UDP만      │
├────────────────┼──────────────┼──────────────┼──────────────┤
│ 코드 복잡성    │    매우 높음  │     높음     │    낮음      │
├────────────────┼──────────────┼──────────────┼──────────────┤
│ 성능           │     높음     │    중간      │    매우 높음  │
├────────────────┼──────────────┼──────────────┼──────────────┤
│ 방화벽 우회    │    어려움    │    쉬움      │    중간      │
├────────────────┼──────────────┼──────────────┼──────────────┤
│ 모바일 로밍    │ 제한적(MOBIKE)│   제한적     │    우수      │
├────────────────┼──────────────┼──────────────┼──────────────┤
│ 표준화         │    IETF      │   사실상     │   Linux 커널  │
└────────────────┴──────────────┴──────────────┴──────────────┘

사용 사례별 선택

각 프로토콜이 적합한 상황을 정리하면 다음과 같습니다.

기업 Site-to-Site VPN:

IPsec이 적합. IETF 표준이며 시스코, 주니퍼 등 모든 장비 벤더가 지원하여 이기종 환경에서도 호환

개인 또는 소규모 VPN:

WireGuard가 적합. 설정이 단순하고 성능이 뛰어나며 유지보수 부담이 적음

방화벽 우회가 중요한 환경:

OpenVPN (TCP 모드, 포트 443)이 적합. 일반 HTTPS 트래픽과 구분이 어려워 차단을 피할 수 있음

모바일 환경:

WireGuard가 적합. IP 주소가 변경되어도 자동으로 재연결되어 Wi-Fi와 셀룰러 간 전환이 매끄러움

Split Tunneling

Split Tunneling은 모든 트래픽을 VPN으로 보내지 않고, 목적지에 따라 일부만 VPN을 통과시키는 기법입니다.

Full Tunnel

Full Tunnel 모드에서는 사용자의 모든 인터넷 트래픽이 VPN을 통과합니다.

사용자 ──► VPN ──► 인터넷
          (모든 트래픽)

장점:

모든 트래픽이 암호화되어 보안 수준 극대화
라우팅 정책이 단순하여 관리가 쉬움

단점:

모든 트래픽이 VPN 서버를 경유하므로 서버 부하 증가
지리적으로 먼 VPN 서버를 경유하면 지연 증가
사용자가 가까운 CDN을 활용하지 못해 대역폭 낭비

Split Tunnel

Split Tunnel 모드에서는 사내 리소스로 향하는 트래픽만 VPN을 통과하고, 일반 인터넷 트래픽은 직접 연결합니다.

사용자 ──► VPN ──► 회사 내부 (10.0.0.0/8)
      │
      └──────────► 인터넷 (직접)

장점:

VPN 서버 대역폭을 효율적으로 사용
일반 웹 서핑, 스트리밍 등의 지연이 낮음
VPN 서버 부하 감소로 비용 절감

단점:

VPN을 우회하는 트래픽은 암호화되지 않아 공용 Wi-Fi 등에서 위험
어떤 트래픽을 VPN으로 보낼지 정책 설계가 복잡

역 Split Tunnel

일반적인 Split Tunnel과 반대로, 특정 트래픽만 VPN을 우회하도록 설정합니다.

예: 화상 회의(Zoom, Teams) 트래픽은 VPN 우회
    지연에 민감한 실시간 트래픽의 품질 확보

대부분의 트래픽은 VPN으로 보호하면서, 지연에 민감하거나 대역폭이 큰 특정 서비스만 예외 처리하는 방식입니다.

VPN과 Zero Trust

전통적 경계 보안

전통적인 VPN은 “경계 보안(Perimeter Security)” 모델에 기반합니다.

┌──────────────────────────────────────┐
│           신뢰된 내부 네트워크        │
│                                      │
│     서버      데이터베이스    사용자  │
│                                      │
└───────────────────┬──────────────────┘
                    │ 방화벽/VPN
                    │
        ────────────┴────────────────
               신뢰되지 않은 외부

이 모델의 핵심 가정은 내부 네트워크는 신뢰하고, 외부는 신뢰하지 않는다는 것입니다.

VPN으로 연결에 성공하면 사용자는 내부 네트워크의 일원으로 간주됩니다.

경계 보안의 한계

그러나 이 모델에는 현대 환경에서 심각한 문제점이 있습니다.

내부 위협: 악의적인 내부자나 악성코드에 감염된 장치가 이미 내부에 있으면 방어할 수 없음
과도한 접근 권한: VPN 연결만 성공하면 필요 이상의 리소스에 접근 가능
경계의 모호화: 클라우드 서비스 확산과 재택근무 증가로 “내부”와 “외부”의 구분이 무의미해짐

Zero Trust 모델

이러한 한계를 극복하기 위해 등장한 것이 Zero Trust 모델입니다.

핵심 원칙은 “절대 신뢰하지 말고, 항상 검증하라(Never Trust, Always Verify)”입니다.

┌─────────────────────────────────────────────────────────────┐
│                    Zero Trust 환경                          │
│                                                             │
│  사용자 ──[검증]──► 정책엔진 ──[검증]──► 리소스            │
│                        │                                    │
│              신원, 장치, 컨텍스트 확인                      │
│              최소 권한 부여                                 │
│              지속적 검증                                    │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Zero Trust의 핵심 원칙:

항상 검증: 네트워크 위치와 관계없이 모든 접근 요청을 검증
최소 권한: 작업 수행에 필요한 최소한의 권한만 부여
마이크로 세분화: 네트워크를 작은 단위로 분리하여 측면 이동(lateral movement) 차단
침해 가정: 이미 침해되었다고 가정하고 피해 최소화를 위한 설계

VPN의 역할 변화

Zero Trust 환경에서 VPN의 역할은 크게 변화하고 있습니다.

전체 네트워크가 아닌 특정 애플리케이션만 접근 허용
SDP(Software Defined Perimeter)와 결합하여 보이지 않는 인프라 구현
ZTNA(Zero Trust Network Access) 솔루션으로 진화

예를 들어, Zero Trust 환경에서는 VPN 연결 후에도 다음과 같은 제어가 적용됩니다.

사용자 역할에 따라 특정 서버와 애플리케이션에만 접근 가능
접속 시간대, 장치 보안 상태, 지리적 위치에 따른 동적 접근 제어
모든 접근 시도의 상세한 로깅 및 실시간 모니터링

정리: 단순함이 보안이다

VPN 기술은 다음과 같이 발전해 왔습니다.

IPsec: 강력한 보안을 제공하지만 복잡한 설정과 관리 부담
SSL/TLS VPN: 방화벽 친화적이고 사용이 편리하지만 성능 오버헤드 존재
WireGuard: 극단적인 단순함으로 보안성과 성능을 동시에 달성

WireGuard가 보여준 교훈은 VPN 설계를 넘어 보안 소프트웨어 전반에 적용됩니다.

코드가 적을수록 잠재적인 버그와 취약점도 적다
협상 가능한 옵션이 많을수록 공격자가 노릴 수 있는 약점도 많아진다
현대 암호화 알고리즘은 충분히 빠르므로 성능을 이유로 보안을 타협할 필요가 없다

한편 Zero Trust 환경에서 VPN은 더 이상 유일한 보안 수단이 아니라, 여러 보안 레이어 중 하나로 자리매김하고 있습니다.

관련 글