프로토콜 비교표
아래 값은 위키백과와 공식 사이트(wireguard.com), RFC 목록에서 확인한 항목만 적었습니다. 속도 수치는 환경에 따라 달라 싣지 않았습니다.
| 프로토콜 | 전송·포트 | 암호·인증 특징 | 표준·출처 | 현황 |
|---|---|---|---|---|
| WireGuard | UDP만 사용 (기본 51820) | Noise 계열 핸드셰이크, Curve25519, ChaCha20-Poly1305, BLAKE2s. 알고리즘을 협상하지 않고 고정 | 제작자 제이슨 도넌펠드, 리눅스 5.6에 포함 | 2019년 INRIA가 기계 검증 증명 발표 |
| OpenVPN | TCP·UDP 모두, IANA 지정 포트 1194 | OpenSSL 기반 TLS로 키 교환 | 제임스 요난, 2001년 5월 첫 공개, GPLv2 | 다양한 플랫폼에서 지원 |
| IPsec/IKEv2 | UDP 500, NAT 환경에서는 UDP 4500 | IKEv2가 키 교환과 연결 관리, IPsec이 암호화 | RFC 7296(2014년 인터넷 표준), 이전 RFC 4306(2005) | MOBIKE(RFC 4555)로 이동성 지원 |
| L2TP/IPsec | L2TP는 UDP 1701, IKE는 UDP 500 | L2TP 자체에는 암호화 없음, IPsec이 보호 | RFC 2661, IPsec 결합은 RFC 3193 | 구형 조합 |
| PPTP | TCP 1723 + GRE(IP 프로토콜 47) | MS-CHAPv2와 RC4 기반 MPPE | RFC 2637(1999년 7월) | 알려진 보안 문제가 많아 폐기 대상 |
왜 WireGuard는 암호를 고르게 하지 않나
오래된 프로토콜은 여러 암호 알고리즘 중 하나를 협상하는 '선택 가능성'을 제공했습니다. WireGuard는 반대로 검증된 조합을 하나로 고정했고, 약점이 발견되면 알고리즘을 바꾸는 대신 프로토콜 새 버전을 내는 방식을 택한다고 위키백과는 설명합니다. 공식 사이트는 '아주 적은 코드로 쉽게 구현되도록 의도되었다'고 소개합니다. 코드가 작을수록 검토할 범위가 줄어든다는 것이 설계 취지이지만, 구체적인 코드 줄 수는 이 글에서 확인하지 못해 적지 않습니다.
실제 사례로 보는 프로토콜의 운명
사례 1. PPTP: 표준이 된 적 없는 프로토콜의 쇠퇴
PPTP는 마이크로소프트, 아센드, 3Com 등 업체 컨소시엄이 만들어 1999년 7월 RFC 2637로 공개되었지만 IETF가 표준으로 채택한 적은 없습니다(위키백과 기준). 인증에 쓰이는 MS-CHAPv2는 사전 공격에 취약하고, 2012년에는 MS-CHAPv2 키를 무차별 대입하는 난이도가 DES 키 하나를 뚫는 수준과 비슷하다는 점이 시연되었습니다. 암호화 계층인 MPPE는 암호문 인증이 없는 RC4 스트림 암호를 써서 비트 뒤집기 공격에 취약합니다. 이런 이유로 PPTP는 오늘날 '쓰지 말아야 할 프로토콜'로 다뤄집니다. 배울 점은 설정이 쉽고 호환성이 넓다는 장점이 있어도 암호 설계가 낡으면 보안은 회복되지 않는다는 것입니다.
사례 2. WireGuard: 커널 합류와 형식 검증
WireGuard 패치는 2019년 12월 9일 리눅스 네트워킹 트리에 받아들여졌고, 2020년 1월 28일 리누스 토르발스가 그 트리를 병합해 2020년 3월 리눅스 5.6에 포함되었습니다(위키백과 기준). 2019년 5월에는 프랑스 INRIA의 논문이 CryptoVerif로 상호 인증, 세션 키 비밀성, 순방향 비밀성 등을 기계로 검증했습니다. 이 증명은 프로토콜의 암호 설계에 대한 것이며, 특정 VPN 서비스의 구현이나 운영까지 보증하는 것은 아닙니다.
사례 3. 가상 예시: 같은 사용자의 환경별 선택
가상 예시입니다. 출장이 잦은 직원이 회사가 지원하는 VPN 앱에서 프로토콜을 고른다고 합시다. 호텔 와이파이에서 UDP가 막혀 연결이 실패한다면 TCP를 지원하는 옵션(예: OpenVPN의 TCP 모드)을 시도하고, 이동 중 와이파이와 모바일 데이터가 자주 바뀐다면 IKEv2의 MOBIKE처럼 주소 변경에 대응하는 옵션이 유리할 수 있습니다. 어디까지나 일반적인 접근이며 실제 결과는 회사 정책과 앱 구현에 달려 있습니다.
점검 체크리스트
- 앱이 PPTP를 기본 또는 선택지로 제공하면 다른 프로토콜을 쓰는 편이 안전합니다.
- 연결이 안 될 때는 UDP와 TCP 중 어느 쪽이 막혔는지 의심합니다.
- 회사 VPN은 서버 정책이 정한 프로토콜만 쓸 수 있으니 IT 담당자의 안내를 따릅니다.
- VPN이 켜져 있어도 로그인한 계정, 쿠키 등으로 서비스는 나를 식별할 수 있습니다.
흔한 오해와 정정
- 오해: 최신 프로토콜이면 무조건 익명이다. 실제: 프로토콜은 터널 암호화의 문제이고, 익명성은 VPN 사업자의 로그 정책과 사용자 행동까지 얽힌 별개 문제입니다.
- 오해: 포트 443을 쓰면 암호화가 더 강해진다. 실제: 포트는 방화벽 통과에 영향을 줄 뿐 암호 강도와는 무관합니다.
- 오해: L2TP만으로 암호화된다. 실제: L2TP는 자체 암호화가 없어 IPsec과 함께 써야 합니다.
- 오해: 코드가 작으면 반드시 안전하다. 실제: 검토하기 쉽다는 장점이지 안전의 보증은 아닙니다.
한계와 더 알아볼 점
프로토콜 비교 글은 구현마다 성능과 보안이 다르다는 점을 먼저 전제해야 합니다. 같은 프로토콜이라도 앱과 서버 설정에 따라 결과가 달라집니다. 또한 이 글은 일반 정보이며 특정 서비스의 신뢰성을 평가하지 않습니다. 구체적 필요가 있다면 각 프로토콜의 RFC와 공식 문서를 확인하세요.
VPN 자체가 처음이라면
VPN이 무엇이고 왜 쓰는지부터 알고 싶다면 VPN 기초 알아보기를 먼저 확인해보세요.
일부 트래픽만 VPN으로 보내고 싶다면
전체 트래픽이 아니라 일부만 선택해 VPN을 거치게 하는 방법이 궁금하다면 VPN 스플릿 터널링(Split Tunneling)이란?도 참고해보세요.
자주 묻는 질문
가장 빠른 VPN 프로토콜은 무엇인가요?
실제 체감 속도는 서버와의 거리, 네트워크 상황, 서비스 구현 방식에 따라 달라지기 때문에 절대적으로 답하기는 어렵습니다. 다만 일반적으로 와이어가드 계열이 가볍고 효율적으로 동작하도록 설계되었다는 평가를 받고 있습니다.
회사에서 정해준 VPN인데 제가 프로토콜을 바꿀 수 있나요?
대부분의 경우 사용자는 VPN 서비스나 앱이 지원하는 프로토콜 중에서 선택할 수 있을 뿐, 프로토콜 자체를 새로 만들거나 서버 쪽 설정 없이 임의로 바꿀 수는 없습니다. 여러 옵션을 지원하는 앱이라면 설정 메뉴에서 다른 프로토콜로 전환해볼 수 있습니다.
WireGuard는 왜 UDP만 쓰나요?
WireGuard는 IP 패킷을 UDP로 감싸 전달하며, 위키백과는 이것이 TCP 위에 TCP를 올리는 터널링의 문제를 피한다고 설명합니다. 대신 UDP가 막힌 네트워크에서는 연결이 어려울 수 있습니다.
L2TP/IPsec은 지금도 쓰나요?
운영체제 기본 기능으로 오래 지원되어 호환 목적으로 남아 있지만, 새로 구축할 때는 다른 방식이 선택되는 추세입니다.
IKEv2와 IPsec은 같은 말인가요?
IKEv2는 IPsec 터널의 키 교환과 연결 관리를 맡는 프로토콜이고, 실제 패킷 암호화는 IPsec(ESP)이 담당합니다. 그래서 흔히 IPsec/IKEv2로 묶어 부릅니다.
VPN을 쓰면 광고 추적이 사라지나요?
IP 주소는 바뀌지만 로그인 정보, 쿠키, 브라우저 특성으로도 식별될 수 있어 추적이 완전히 사라지지는 않습니다.