이 두 프로토콜을 비교하는 일은 실제로 운영할 것을 비교할 때만 유용하다. WireGuard는 피어를 공개 키로 식별하고 자체 프로토콜을 UDP 위로 운반하는 반면, OpenVPN 은 더 넓은 인증 방식을 제공하며 서버가 둘 다 제공하면 UDP나 TCP 위에서 동작할 수 있다. 이런 차이는 처리량을 만들기 훨씬 전에 구축 방식과 대체 경로를 만든다. 아래 네 가지 점검을 순서대로 하면, 처음 두 가지가 보통 선택을 결정하고 마지막 두 가지는 그 결정이 옳았는지 알려 준다.

암호 목록이 아니라 신원에서 시작하라

WireGuard 피어는 개인 키 하나를 보관하고 도달할 수 있는 공개 키를 나열한다. 제공자는 그 둘레에 계정 포털을 씌울 수 있지만 프로토콜 자체에는 사용자 이름과 비밀번호 교환이 없으므로 계정 수명 주기는 키를 배포하는 무엇인가 안에 산다. OpenVPN은 인증서, 기존 디렉터리에 대한 플러그인, 검증 스크립트를 쓸 수 있어서 신원 체계를 가진 조직이 자주 선호한다. 어느 설계도 분실한 기기를 어떻게 제거하는가라는 물음을 없애지 않는다.

DecisionOpenVPNWireGuard
IdentityCertificates, plugins or scripts against an existing directoryOne private key per peer, public keys listed for the peers it may reach
TransportUDP or TCP profiles when the server offers bothUDP only in the native protocol
Routing and DNSServer pushes routes and DNS optionsAllowedIPs maps ranges to peers, and tooling installs the routes
Where it usually breaksProfile mismatch, expired certificate, failing pluginBlocked UDP, wrong AllowedIPs, key not installed

짧은 구성이 단순한 구축과 같지는 않다. 개인 키 하나를 여러 사람에게 넘기면, 키를 폐기할 때 모두가 한꺼번에 빠지므로 나중의 제거가 모호해진다. 고르기 전에 사람과 키 또는 인증서의 대응을 적어 두면 프로토콜 결정이 훨씬 쉬워진다.

다음으로 전송이 무엇을 허용하는지 보라

WireGuard의 프로토콜은 UDP를 쓴다. OpenVPN 서비스는 UDP와 TCP 프로필을 모두 제공할 수 있고, UDP를 막거나 떨어뜨리는 망에서는 그 두 번째 선택이 이론이 아니라 실용적인 대체 경로다. 서버가 고른 프로필을 지원해야 하며, 포트 번호를 바꾼다고 터널이 HTTPS가 되거나 방화벽이 통과시켜 주지는 않는다.

TCP 안에 TCP를 실으면 손실 시의 동작도 달라진다. 두 계층이 각자 재전송하고 순서를 바꾸기 때문이며, 제약이 심한 망에서 동작하는 TCP 프로필도 손실이 있는 망에서는 여전히 성능이 나쁠 수 있어, 한쪽을 우월하다고 선언하는 대신 두 프로필을 모두 준비해 두는 이유가 된다.

다음으로 경로와 이름 해석을 점검하라

WireGuard의 AllowedIPs는 주소 범위를 피어에 대응시키고 프로토콜 내부의 경로 결정으로 작동하며, 주변 도구는 경로를 설치할 때 그 범위를 쓴다. OpenVPN은 서버에서 경로와 DNS 옵션을 밀어 넣는다. 두 경우 모두 의도한 정책이 절반만 적용된 채 클라이언트가 올라올 수 있다.

ip route show
ip -6 route show
resolvectl status
wg show

연결됨 표시를 믿기 전에 출력을 읽어라. ip route show는 클라이언트가 IPv4를 위해 무엇을 설치했는지 나열하고, IPv6 판은 한쪽 체계만 나르는 터널을 잡아낸다. resolvectl status는 클라이언트가 실제로 어느 해석기에 물을지 보여 주고, wg show는 WireGuard가 자기 것이라고 여기는 AllowedIPs를 찍는다. 경로가 전체를 덮는다고 주장하는데 해석기가 여전히 로컬 망을 가리키면 DNS는 터널 밖으로 나간다.

다음으로 신경 쓰는 작업을 측정하라

기기와 망과 목적지를 고정하고, 사용한 클라이언트와 종단점을 기록하라. 두 서비스가 다른 도시에서 나가거나 다른 하드웨어에서 돌아간다면, 결과는 프로토콜이 아니라 그 서비스를 설명하므로 그렇게 적어라.

iperf3 -c 203.0.113.20 -t 30
mtr -rwzbc 50 203.0.113.20

두 명령을 프로필 쌍마다 한 번씩, 같은 망과 같은 기기에서 두 번씩 실행하라. iperf3는 처리량 수치를 주고, mtr는 경로와 손실이 어디에 나타나는지를 주며, 이는 다운로드 수치 하나로는 보여 줄 수 없다. 다운로드 수치는 통화가 알아차리는 것, 곧 늘어난 지연과 흔들림, 재연결에 걸리는 시간도 놓친다. 이것들은 처리량에서 이기는 프로토콜이 실제로 돌리는 작업에서는 질 수 있으므로 따로 기록하라.

관리형 연결에서는 호환성과 지원과 갱신 수고가 작은 벤치마크 차이보다 무거울 수 있다. 개인용 출구에서는 운영자의 기록과 관할이 프로토콜 이름표보다 중요하다. 두 프로토콜 모두 좋은 연결을 실을 수 있지만, 무엇을 얻는지는 서비스와 그 구성이 결정한다.

시험하기 전에 프로필 쌍을 적어 두라

측정하기 전에 프로토콜마다 프로필 하나를 고르고 각각이 무엇을 해야 하는지 — 사설 서브넷만인지, 아니면 특정 출구를 지나는 모든 트래픽인지 — 적어라. 분할 터널 프로필과 전체 터널 프로필을 비교하는 시험은 프로토콜이 아니라 프로필을 측정한다. 클라이언트 이름과 클라이언트 판과 출구 위치를 같은 메모에 넣어라.

다음으로 같은 작업을 둘 모두에서, 같은 망에서, 같은 세션에서 실행하라. 하나가 아예 연결되지 않는다면 그 실패가 결과이며 이유와 함께 기록에 들어간다. 기록을 서비스 문서와 함께 두어 다음 사람이 처음부터 다시 시작하는 대신 같은 쌍을 비교하게 하라.

관련 글