이 문서는 VPN 을 설계 · 구축 · 운영할 때 자주 등장하는 핵심 개념을 실무 관점에서 정리한 것이다. 목표는 OpenVPN, WireGuard, IPsec/strongSwan 같은 서로 다른 VPN 기술을 비교하거나 설계할 때 공통 언어를 제공하는 것이다. 요약과 구현체 목록은 VPN 에, 제품별 비교는 오픈소스 VPN 비교 에 있다.
VPN 은 공용 네트워크 위에 논리적으로 신뢰 가능한 터널을 형성해, 원격 클라이언트 또는 원격 사이트가 내부 자원에 안전하게 접근하도록 만든다. 핵심은 기밀성, 무결성, 상호 인증, 라우팅 제어 다.
개별 사용자 단말이 외부 네트워크에서 사내 네트워크로 접속하는 모델이다. 재택근무, 출장, 모바일 원격접속에 적합하다. OpenVPN 과 WireGuard 모두 이 모델을 지원한다[1].
두 개 이상의 네트워크를 게이트웨이 간 터널로 연결하는 모델이다. 지사 간 연동, 데이터센터 간 연결에 적합하다.
PKI 는 인증서 기반 신뢰 체계다. CA 가 서버 인증서와 클라이언트 인증서를 발급하고, 장비는 이를 검증해 상대 신원을 확인한다. OPNsense 는 GUI 에서 CA, 서버 인증서, 클라이언트 인증서, CSR, CRL 을 관리할 수 있다[2]. 직접 만드는 절차는 CA 인증서 생성 에 있다.
OpenVPN 에서는 이 구조가 중요하다. WireGuard 는 인증서 대신 공개키 · 개인키 쌍을 쓴다.
인증서 분실 · 퇴사 · 키 유출 상황에서 즉시 차단하는 수단이다[2:1].
RSA 는 공개키 암호 알고리즘으로, 전통적으로 인증서 기반 시스템에서 널리 쓴다. 현대 VPN 에서는 주로 인증서 · 서명 맥락에서 보게 된다.
Diffie-Hellman 은 안전하지 않은 네트워크 위에서 공유 비밀을 합의하기 위한 핵심 개념이다. ECDHE 는 타원곡선 기반의 ephemeral DH 로, Perfect Forward Secrecy(PFS) 를 제공하는 데 중요하다.
WireGuard 는 ECDH 에 Curve25519 를 쓴다. 공식 문서는 Curve25519, ChaCha20, Poly1305, BLAKE2s, HKDF 를 핵심 primitive 로 명시한다[3].
ChaCha20 은 대칭 암호화, Poly1305 는 인증 태그를 제공하며, 둘을 조합한 AEAD 는 기밀성과 무결성을 동시에 보장한다. WireGuard 는 이 조합을 핵심 암호 스택으로 쓴다[3:1].
AEAD(Authenticated Encryption with Associated Data) 는 암호화와 인증을 함께 처리하는 방식이다. 현대 VPN 설계의 기본 속성이다.
WireGuard 는 키 유도에 HKDF, 해싱에 BLAKE2s 를 쓴다. 단순성과 안전성, 성능 균형을 위한 설계다[3:2].
PFS 는 장기 키가 나중에 노출되더라도 과거 세션 키가 보호되는 성질이다. WireGuard 는 재키잉과 Noise 기반 핸드셰이크를 통해 이 목표를 추구하고, TLS 기반 VPN 도 ECDHE 같은 방식으로 유사한 목표를 달성한다[3:3].
OpenVPN 은 TLS 기반으로 동작한다. 따라서 인증서, CA, 서버 · 클라이언트 인증, TLS 보호, 추가적인 tls-crypt 혹은 정적 키 기반 방어가 보안 강화 포인트가 된다. OpenVPN hardening 문서는 제어 채널 보호, UDP 사용, 권한 최소화, chroot, 루트 CA 키 오프라인 보관 등을 강조한다[4].
WireGuard 의 AllowedIPs 는 단순 ACL 이 아니라 사실상 라우팅 + 허용 범위 개념을 함께 가진다. 잘못 설계하면 특정 트래픽이 터널로 가지 않거나, 의도치 않은 경로로 빠질 수 있다. Road Warrior 에서 내부망 접근을 목표로 할 때는 클라이언트 쪽 AllowedIPs 에 내부 서브넷이 반드시 포함되어야 한다[5].
내부 대역 접근만 필요하면 split tunnel 이 일반적으로 더 적합하다.
OpenVPN 은 UDP 기반 구성이 보통 더 유리하며, hardening 문서도 TCP 보다 UDP 를 권한다[4:1].
WireGuard 는 평소 조용하게 동작하며, NAT 뒤 peer 가 장시간 대기 후에도 수신 가능해야 하면 PersistentKeepalive 가 필요할 수 있다. 공식 Quick Start 는 일반적으로 25초가 널리 동작하는 값이라고 설명한다. 필요 없으면 켜지 않는 것이 원칙이다[5:1].
VPN 은 캡슐화로 인해 실제 전송 가능한 MTU 가 줄어든다. MTU · MSS 를 맞추지 않으면 핑은 되지만 대용량 TCP 세션이 끊기거나 특정 서비스만 실패하는 현상이 발생할 수 있다. OPNsense WireGuard 문서도 normalization rule 과 MTU 조정을 언급한다[1:1].
VPN 이 연결되었다는 것은 핸드셰이크 성공일 뿐, 내부망 접근 성공과 동일하지 않다. 실제 성공에는 다음 네 가지가 모두 필요하다.
WireGuard 와 OpenVPN 모두 이 원칙은 동일하다.
OPNsense 에서 OpenVPN assigned interface 를 사용할 경우, 생성된 규칙에 reply-to 가 붙으면서 Road Warrior 클라이언트 응답 경로가 깨질 수 있다. 공식 문서는 자동 생성 게이트웨이 비활성화, 규칙별 Disable Reply-To, 또는 전역 reply-to 비활성화(멀티 WAN 주의)를 대안으로 제시한다[6].
OPNsense — OpenVPN Road Warrior · WireGuard Road Warrior. 2026-09-20 확인. https://docs.opnsense.org/manual/how-tos/sslvpn_instance_roadwarrior.html · https://docs.opnsense.org/manual/how-tos/wireguard-client.html ↩︎ ↩︎
OPNsense — Certificates. 2026-09-20 확인. https://docs.opnsense.org/manual/certificates.html ↩︎ ↩︎
WireGuard Protocol & Cryptography. 2026-09-20 확인. https://www.wireguard.com/protocol/ · 논문 https://www.wireguard.com/papers/wireguard.pdf ↩︎ ↩︎ ↩︎ ↩︎
OpenVPN — Hardening OpenVPN Security. 2026-09-20 확인. https://openvpn.net/community-docs/hardening-openvpn-security.html ↩︎ ↩︎
WireGuard Quick Start. 2026-09-20 확인. https://www.wireguard.com/quickstart/ ↩︎ ↩︎
OPNsense — OpenVPN troubleshooting. 2026-09-20 확인. https://docs.opnsense.org/troubleshooting/openvpn.html ↩︎