OpenVPN 프로토콜

1. 가상 사설망(VPN)과 OpenVPN의 역할

현대 네트워크 환경은 지리적으로 분산된 데이터 센터, 클라우드 인프라, 그리고 원격 근무 인력 간의 끊임없는 데이터 교환을 특징으로 한다. 이러한 복잡하고 개방된 네트워크 구조에서 전송 중인 데이터의 기밀성(Confidentiality), 무결성(Integrity), 그리고 통신 주체에 대한 인증(Authentication)을 보장하는 것은 조직의 핵심 자산을 보호하기 위한 필수 요건이 되었다.1 가상 사설망(VPN)은 공용 네트워크인 인터넷 위에 암호화된 논리적 터널을 생성하여, 마치 사설 네트워크에 직접 연결된 것과 같은 보안 수준을 제공하는 핵심 기술이다.3

수많은 VPN 기술 중에서 OpenVPN은 지난 수십 년간 가장 널리 채택되고 신뢰받는 솔루션 중 하나로 자리매김했다. OpenVPN은 업계 표준 보안 프로토콜인 SSL/TLS를 기반으로 하는 오픈 소스 VPN 프로토콜로, 그 명성은 세 가지 핵심 철학에 기반한다: 개방성(Open-Source), 보안성(Security), 그리고 **유연성(Flexibility)**이다.3

• 개방성: OpenVPN의 소스 코드는 전 세계에 공개되어 있어 누구나 코드를 검토하고 잠재적인 보안 취약점을 발견 및 수정하는 과정에 참여할 수 있다. 이러한 투명성은 특정 기업의 통제하에 있는 독점 기술과 달리, 전 세계 사이버 보안 커뮤니티의 집단적인 감사를 통해 프로토콜의 신뢰성과 견고함을 지속적으로 검증받게 한다.6

• 보안성: OpenVPN은 미국 정부가 1급 비밀 정보를 보호하기 위해 채택한 AES-256과 같은 군사급 암호화 표준을 활용한다. 또한, 강력한 인증서 기반 인증, 완전 순방향 비밀성(PFS) 지원, 그리고 TLS 핸드셰이크 과정을 추가적으로 보호하는 메커니즘을 통해 다계층 보안 아키텍처를 구축한다.6

• 유연성: OpenVPN의 가장 두드러진 특징은 거의 모든 네트워크 환경과 요구사항에 맞춰 세밀하게 조정할 수 있는 탁월한 유연성이다. Windows, macOS, Linux, iOS, Android 등 주요 운영체제를 모두 지원하며 3, 네트워크의 2계층 또는 3계층에서 작동할 수 있고, UDP 또는 TCP 프로토콜을 선택적으로 사용할 수 있어 성능과 호환성 사이의 균형을 사용자가 직접 제어할 수 있다.6

본 안내서는 OpenVPN의 기술적 근간을 심층적으로 분석하는 것을 목표로 한다. 아키텍처의 구성 요소부터 암호학적 보안 메커니즘, 성능 특성, 그리고 실제 활용 시나리오에 이르기까지 OpenVPN의 모든 측면을 체계적으로 해부하여, 네트워크 전문가와 보안 관리자가 이 강력한 도구를 온전히 이해하고 효과적으로 활용할 수 있도록 상세한 분석과 통찰을 제공할 것이다.

2. OpenVPN 아키텍처 심층 분석

OpenVPN의 강력한 유연성과 확장성은 그 독특한 아키텍처 설계에서 비롯된다. 이 장에서는 OpenVPN을 구성하는 핵심 요소인 클라이언트-서버 모델, 네트워킹 계층, 그리고 전송 프로토콜을 분해하여 그 구조적 특징과 작동 원리를 심도 있게 분석한다.

2.1 클라이언트-서버 모델

OpenVPN은 다수의 클라이언트가 단일 서버 프로세스에 연결되는 확장 가능한 클라이언트-서버 모델을 기반으로 작동한다.5 이 모델에서 각 구성 요소는 명확한 역할을 수행한다.

• 서버(Server): VPN 네트워크의 중심점 역할을 한다. 서버는 지정된 포트에서 클라이언트의 연결 요청을 수신 대기하며, 연결 시 클라이언트를 인증하고, 암호화 매개변수를 협상하며, 가상 IP 주소 및 라우팅 정보와 같은 네트워크 구성 옵션을 클라이언트에게 배포(‘push’)한다.3 모든 VPN 트래픽은 서버를 통해 라우팅되거나 중계된다.

• 클라이언트(Client): 원격지 사용자 또는 장치를 나타낸다. 클라이언트는 서버로의 연결을 시작하는 주체이며, 서버로부터 받은 구성 정보를 바탕으로 암호화된 터널을 설정한다. 터널이 생성되면 클라이언트는 이 터널을 통해 서버 측 네트워크의 자원에 접근할 수 있다.3

OpenVPN의 오픈 소스 프로젝트는 이러한 기본적인 클라이언트-서버 데몬을 제공하는 데 중점을 둔다. 반면, OpenVPN Access Server와 같은 상용 솔루션은 이 기본 모델 위에 사용자 관리 데이터베이스, 웹 기반 관리 인터페이스(Admin Web UI), 클라이언트 프로파일 자동 생성 및 배포, 그리고 다중 서버를 묶어 고가용성 및 부하 분산을 구현하는 클러스터링 기능 등을 추가하여 엔터프라이즈 환경에서의 배포와 관리를 대폭 간소화한다.12

2.2 네트워킹 계층: TUN과 TAP의 원리 및 선택 기준

OpenVPN은 운영체제의 Universal TUN/TAP 드라이버를 활용하여 두 가지 근본적으로 다른 유형의 가상 네트워크 인터페이스를 생성할 수 있다. 이 선택은 VPN이 작동하는 OSI 모델의 계층을 결정하며, 이는 전송 가능한 트래픽의 종류와 네트워크 토폴로지에 지대한 영향을 미친다.10

• TUN (Tunnel Interface): 라우팅 모드

• TUN 인터페이스는 OSI 모델의 3계층(네트워크 계층)에서 작동하는 가상 점대점(point-to-point) IP 터널을 생성한다.10 이는 오직 IP 패킷만을 캡슐화하고 터널을 통해 전송함을 의미한다. TUN 모드는 가장 일반적인 VPN 구성 방식으로, 서로 다른 네트워크 대역에 있는 클라이언트와 서버 간에 IP 트래픽을 안전하게 라우팅하는 데 사용된다.14 IP 패킷만 처리하므로 이더넷 헤더와 같은 불필요한 오버헤드가 없어 TAP 모드보다 효율적이다.

• TAP (Network Tap Interface): 브리징 모드

• TAP 인터페이스는 2계층(데이터 링크 계층)에서 작동하며, 가상 이더넷 어댑터처럼 동작한다.10 이는 IP 패킷뿐만 아니라 전체 이더넷 프레임(MAC 주소 포함)을 캡슐화하여 터널링할 수 있음을 의미한다.15 이 모드는 원격 클라이언트를 서버의 로컬 이더넷 세그먼트에 논리적으로 ’연결’하여, 마치 동일한 LAN 스위치에 연결된 것처럼 보이게 만든다. 결과적으로, 원격지와 로컬 네트워크가 단일 브로드캐스트 도메인으로 통합된다.15

• 선택 기준 및 시나리오:

• TUN 모드 사용: 대부분의 VPN 시나리오, 즉 원격 사용자가 회사 내부의 웹 서버, 파일 서버, 데이터베이스 등 특정 IP 기반 서비스에 접근하고자 할 때 TUN 모드가 권장된다. 설정이 간단하고 효율성이 높다.

• TAP 모드 사용: TAP 모드는 다음과 같은 특수한 경우에 필요하다 15:

1. 비-IP 프로토콜 전송: IPX, NetBEUI, AppleTalk와 같이 IP가 아닌 프로토콜을 VPN을 통해 전송해야 할 경우.

2. 브로드캐스트/멀티캐스트 의존 애플리케이션: 네트워크상의 다른 장치를 자동으로 탐색하는 NetBIOS(Windows 파일 공유)나 일부 LAN 게임과 같이 브로드캐스트 또는 멀티캐스트 패킷에 의존하는 애플리케이션을 실행해야 할 경우.

3. 레이어 2 브리징: DHCP 서버가 VPN 클라이언트에게 직접 IP 주소를 할당하게 하는 등, 원격 네트워크를 로컬 네트워크와 완벽하게 통합해야 하는 고급 구성이 필요할 경우.

TAP 모드는 전체 이더넷 프레임을 캡슐화하므로 TUN 모드에 비해 약 14바이트의 추가적인 오버헤드가 발생하며, 브로드캐스트 트래픽으로 인해 네트워크 성능에 영향을 줄 수 있다. 따라서 명확한 2계층 연결성 요구사항이 없는 한, 라우팅 기반의 TUN 모드를 사용하는 것이 표준적인 접근 방식이다.15

2.3 전송 프로토콜: UDP와 TCP의 특성 및 시나리오 분석

OpenVPN의 근본적인 유연성은 아키텍처 설계 단계에서부터 내재된 두 가지 핵심적인 선택지, 즉 네트워크 계층(TUN/TAP)과 전송 프로토콜(UDP/TCP)의 조합에서 비롯된다. OpenVPN 터널 자체는 UDP 또는 TCP 프로토콜 위에서 데이터를 전송할 수 있으며, 이 선택은 성능, 신뢰성, 그리고 네트워크 제약 조건 우회 능력에 직접적인 영향을 미친다.6

• UDP (User Datagram Protocol): 성능 우선

• UDP는 비연결형 프로토콜로, 데이터 전송 전 핸드셰이크 과정이 없고, 패킷 도착 순서나 전송 성공 여부를 보장하지 않는다. 이러한 특성 덕분에 TCP에 비해 헤더 오버헤드가 적고 지연 시간이 짧아 더 빠른 속도를 제공한다.16

• OpenVPN은 UDP의 비신뢰성을 보완하기 위해 자체적인 신뢰성 및 순서 재정렬 메커니즘을 프로토콜 내에 구현하고 있다.18 따라서 UDP를 사용하더라도 안정적인 터널 통신이 가능하다. 이러한 이유로 OpenVPN은 기본적으로 UDP 사용을 권장하며, 대부분의 상용 VPN 서비스 역시 성능상의 이점 때문에 UDP를 기본값으로 설정한다.19 스트리밍, VoIP, 온라인 게임과 같이 실시간성이 중요한 애플리케이션에 특히 적합하다.17

• TCP (Transmission Control Protocol): 신뢰성 및 호환성 우선

• TCP는 연결형 프로토콜로, 데이터 전송 전에 3-way 핸드셰이크를 통해 연결을 설정하고, 전송된 모든 패킷에 대해 확인 응답(ACK)을 받으며, 패킷이 유실될 경우 재전송을 수행한다. 이는 데이터 전송의 높은 신뢰성을 보장하지만, 이러한 과정들이 추가적인 오버헤드와 지연을 유발하여 UDP보다 속도가 느리다.16

• TCP 사용 시나리오: TCP의 진정한 가치는 매우 제한적인 네트워크 환경을 우회할 때 발휘된다. 일부 기업, 학교, 공공장소의 방화벽은 보안상의 이유로 알려진 소수의 포트와 프로토콜(예: HTTP용 TCP 80, HTTPS용 TCP 443)을 제외한 모든 트래픽을 차단하는 경우가 있다. 이러한 환경에서는 UDP 기반 VPN 연결이 불가능할 수 있다. OpenVPN을 TCP 포트 443에서 실행하도록 구성하면, VPN 트래픽이 암호화된 웹 트래픽(HTTPS)과 동일하게 보이므로 방화벽의 탐지를 우회하여 연결을 성공시킬 가능성이 매우 높아진다.19

• TCP Meltdown 현상:

TCP 기반 OpenVPN 터널을 사용할 때 주의해야 할 심각한 성능 저하 현상으로 ’TCP Meltdown’이 있다.10 이 현상은 프로토콜 계층화(Protocol Layering)로 인해 발생한다. 사용자가 TCP 기반 애플리케이션(예: 웹 브라우징, 파일 전송)을 TCP 기반 OpenVPN 터널 위에서 실행하면, 두 개의 TCP 계층이 중첩된다. 만약 하위 계층(OpenVPN 터널의 TCP)에서 네트워크 혼잡 등으로 인해 패킷 손실이 발생하면, 하위 TCP는 자체적인 재전송 메커니즘을 가동한다. 이로 인한 지연을 감지한 상위 계층(애플리케이션의 TCP) 역시 독립적으로 재전송을 시도한다. 이 두 계층의 재전송 타이머가 서로를 증폭시키면서 불필요한 패킷이 네트워크를 범람시키고, 결국 전체 연결 성능이 급격히 저하되거나 마비되는 현상이 발생한다. 이는 OpenVPN 관리자가 단순히 프로토콜을 선택하는 것을 넘어, 터널링될 트래픽의 특성까지 고려해야 함을 시사한다. 따라서 UDP 연결이 가능한 환경에서는 항상 UDP를 우선적으로 사용해야 한다.

3. 암호학적 토대: SSL/TLS 기반 보안 메커니즘

OpenVPN 보안의 핵심은 수십 년간 인터넷 통신을 보호해 온 검증된 기술인 SSL/TLS(Secure Sockets Layer/Transport Layer Security) 프로토콜 스택에 있다. OpenVPN은 이 강력한 암호화 프레임워크를 활용하여 안전한 통신 채널을 설정하고 유지한다. 이 장에서는 OpenVPN의 보안이 어떻게 ’계층화(Layering)’와 ‘사전 방어(Proactive Defense)’ 철학에 기반하여 구축되는지, 컨트롤 채널과 데이터 채널의 분리, TLS 핸드셰이크 과정, 그리고 키 교환 메커니즘을 통해 상세히 분석한다.

3.1 컨트롤 채널과 데이터 채널

OpenVPN은 효율성과 보안성을 극대화하기 위해 통신을 두 개의 논리적 채널로 명확히 분리하여 운영한다.10

• 컨트롤 채널 (Control Channel): VPN 터널의 ’두뇌’에 해당한다. 이 채널은 SSL/TLS 프로토콜을 사용하여 설정되며, VPN 세션의 생명주기를 관리하는 모든 제어 메시지가 이 채널을 통해 교환된다. 주요 역할은 다음과 같다:

1. 상호 인증: 클라이언트와 서버가 서로의 신원을 확인한다 (주로 X.509 인증서 사용).

2. 암호 매개변수 협상: 데이터 채널에서 사용할 암호화 알고리즘(cipher), 해시 함수 등을 협상한다.

3. 세션 키 교환: 실제 데이터를 암호화하고 복호화하는 데 사용될 대칭 세션 키를 안전하게 생성하고 교환한다.

컨트롤 채널 자체는 TLS 핸드셰이크를 통해 강력하게 암호화되므로, 키 교환 과정이나 제어 명령이 외부에 노출되지 않는다.18

• 데이터 채널 (Data Channel): VPN 터널의 ’고속도로’에 해당한다. 실제 사용자 데이터(IP 패킷, 이더넷 프레임 등)가 이 채널을 통해 전송된다. 데이터 채널의 모든 데이터는 컨트롤 채널에서 안전하게 협상된 대칭 세션 키를 사용하여 암호화된다. 대칭키 암호화는 비대칭키 암호화보다 훨씬 빠르기 때문에, 대용량 데이터 전송에 적합하다. 이 채널의 암호화 및 무결성 검증은 컨트롤 채널과 독립적으로 이루어진다.24

이러한 이중 채널 구조는 OpenVPN 설계의 핵심적인 부분이다. 계산 비용이 많이 드는 비대칭 암호화와 인증 절차는 세션 시작 시 컨트롤 채널에서 한 번만 수행하고, 실제 데이터 전송은 빠르고 효율적인 대칭 암호화를 사용하는 데이터 채널을 통해 이루어지도록 하여 보안성과 성능을 모두 만족시킨다.

3.2 TLS 핸드셰이크 상세 과정

TLS 핸드셰이크는 컨트롤 채널을 통해 클라이언트와 서버가 서로를 인증하고, 안전한 통신에 사용할 공유 비밀(세션 키)을 생성하는 암호학적 협상 과정이다. 이 과정은 다음과 같은 단계로 진행된다.26

1. Client Hello: 클라이언트가 서버에 연결을 시도하며 첫 번째 메시지를 보낸다. 이 메시지에는 다음 정보가 포함된다:

• 클라이언트가 지원하는 가장 높은 TLS 프로토콜 버전 (예: TLS 1.2, 1.3).

• 클라이언트가 생성한 32바이트의 무작위 숫자 (client_random).

• 클라이언트가 지원하는 암호화 스위트(Cipher Suites) 목록. 암호화 스위트는 키 교환 알고리즘, 대칭 암호화 알고리즘, 메시지 인증 코드 알고리즘의 조합이다 (예: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384).

2. Server Hello & Certificate: 서버는 Client Hello 메시지를 받고 응답한다.

• Server Hello: 클라이언트가 제시한 목록 중에서 서버가 지원하는 가장 높은 TLS 버전과 가장 강력한 암호화 스위트를 선택하여 클라이언트에게 알린다. 또한, 서버 자체적으로 생성한 32바이트의 무작위 숫자(server_random)를 포함한다.

• Certificate: 서버는 자신의 신원을 증명하기 위해 X.509 디지털 인증서를 클라이언트에게 보낸다. 이 인증서에는 서버의 도메인 이름, 유효 기간, 그리고 가장 중요한 서버의 **공개 키(Public Key)**가 포함되어 있으며, 신뢰할 수 있는 인증 기관(CA)에 의해 서명되어 있다.26

3. 클라이언트 인증서 검증 및 키 교환:

• 클라이언트는 서버로부터 받은 인증서가 신뢰하는 CA 목록에 있는 CA에 의해 서명되었는지, 유효 기간이 만료되지 않았는지, 그리고 연결하려는 서버의 도메인 이름과 일치하는지 검증한다.

• 검증이 성공하면, 클라이언트는 세션 키 생성의 기반이 될 premaster_secret이라는 또 다른 무작위 값을 생성한다.

• (RSA 키 교환 방식의 경우) 클라이언트는 이 premaster_secret을 서버의 공개 키로 암호화하여 서버에 전송한다. 서버의 공개 키로 암호화되었기 때문에, 해당 공개 키에 대응하는 개인 키를 가진 서버만이 이 메시지를 해독할 수 있다.29

4. 세션 키 생성:

• 서버는 자신의 **개인 키(Private Key)**를 사용하여 클라이언트로부터 받은 암호화된 premaster_secret을 복호화한다.

• 이제 클라이언트와 서버 양쪽 모두 client_random, server_random, premaster_secret이라는 세 가지 동일한 비밀 정보를 공유하게 된다.

• 양측은 이 세 가지 값을 의사 난수 함수(PRF, Pseudo-Random Function)에 입력하여 ’마스터 시크릿(Master Secret)’이라는 48바이트의 핵심 비밀 값을 생성한다.

• 마지막으로, 이 마스터 시크릿으로부터 실제 데이터 암호화에 사용될 대칭 세션 키(예: AES 암호화 키)와 데이터 무결성 검증에 사용될 HMAC 키(예: SHA-256 HMAC 키)를 파생시킨다.26

5. Change Cipher Spec & Finished:

• 양측은 이제부터 협상된 암호화 매개변수와 생성된 세션 키를 사용하여 통신할 것임을 알리는 Change Cipher Spec 메시지를 교환한다.

• 그 직후, 전체 핸드셰이크 과정에서 교환된 모든 메시지의 해시값을 새로 생성된 세션 키로 암호화한 Finished 메시지를 서로에게 보낸다. 상대방이 이 메시지를 성공적으로 복호화하고 내용을 검증할 수 있다면, 이는 양측이 동일한 세션 키를 성공적으로 생성했으며 핸드셰이크 과정이 중간에 변조되지 않았음을 최종적으로 확인하는 것이다. 이 시점부터 컨트롤 채널을 통한 모든 통신은 세션 키로 암호화된다.28

3.3 키 교환 알고리즘: Diffie-Hellman의 원리

TLS 핸드셰이크에서 premaster_secret을 안전하게 공유하는 방법에는 여러 가지가 있지만, OpenVPN은 완전 순방향 비밀성(PFS)을 달성하기 위해 Diffie-Hellman(DH) 또는 그 변형인 Elliptic Curve Diffie-Hellman(ECDH) 키 교환 방식을 강력히 권장한다.3 DH 키 교환은 공개된 채널을 통해 통신하면서도 두 당사자가 동일한 비밀 키를 안전하게 공유할 수 있게 해주는 혁신적인 암호학적 프로토콜이다. 그 원리는 이산 로그 문제(Discrete Logarithm Problem)의 계산적 어려움에 기반한다.31

Diffie-Hellman 키 교환 과정:

1. 공개 매개변수 공유: 두 통신 주체(앨리스와 밥)는 사전에 크고 공개된 소수 p와 생성자(primitive root) g에 동의한다. 이 값들은 외부에 노출되어도 무방하다.

2. 개인 키 생성 및 공개 키 계산/교환:

• 앨리스는 자신만 아는 비밀 정수(개인 키) a를 선택하고, 공개 키 A = g^a \pmod{p}를 계산하여 밥에게 보낸다.

• 밥은 자신만 아는 비밀 정수(개인 키) b를 선택하고, 공개 키 B = g^b \pmod{p}를 계산하여 앨리스에게 보낸다.

3. 공유 비밀 키 계산:

• 앨리스는 밥으로부터 받은 공개 키 B와 자신의 개인 키 a를 사용하여 공유 비밀 키 s = B^a \pmod{p}를 계산한다.

• 밥은 앨리스로부터 받은 공개 키 A와 자신의 개인 키 b를 사용하여 공유 비밀 키 s = A^b \pmod{p}를 계산한다.

수학적으로, 양측이 계산한 공유 비밀 키 s는 동일하다.

s = B^a \pmod{p} = (g^b)^a \pmod{p} = g^{ab} \pmod{p}

s = A^b \pmod{p} = (g^a)^b \pmod{p} = g^{ab} \pmod{p}

중간에서 통신을 도청하는 공격자는 공개된 값인 p, g, A, B를 모두 알 수 있다. 그러나 공유 비밀 키 s를 계산하려면 개인 키인 a 또는 b를 알아내야 한다. A = g^a \pmod{p}라는 관계식에서 A, g, p를 알고 있을 때 a를 찾는 것이 바로 이산 로그 문제이며, p가 충분히 클 경우 계산적으로 거의 불가능하다.31 이 공유 비밀 키 s가 TLS 핸드셰이크의 premaster_secret으로 사용된다.

3.4 완전 순방향 비밀성 (Perfect Forward Secrecy, PFS)

PFS는 통신의 장기적인 보안을 보장하는 매우 중요한 암호학적 속성이다.6 만약 서버의 장기적인 비밀 정보(예: RSA 개인 키)가 미래의 어느 시점에 유출되더라도, 과거에 암호화되어 기록된 통신 내용은 안전하게 유지되어야 한다는 개념이다.2

DH 키 교환은 PFS를 구현하는 핵심적인 수단이다. DH를 사용하면 각 VPN 세션마다 완전히 새롭고 임시적인 키 쌍(a와 b)이 생성되고, 이를 기반으로 고유한 세션 키가 만들어진다. 세션이 종료되면 이 임시 키들은 즉시 파기된다. 서버의 RSA 인증서와 개인 키는 단지 DH 키 교환 과정에서 교환되는 공개 키(A와 B)에 디지털 서명을 하여 통신 상대방을 인증하는 용도로만 사용될 뿐, 세션 키 자체의 암호화에는 관여하지 않는다. 따라서 나중에 서버의 RSA 개인 키가 유출되더라도, 공격자는 과거 세션들의 임시 키를 복원할 수 없으므로 기록된 트래픽을 해독할 수 없다.16

3.5 컨트롤 채널 보안 강화: tls-auth와 tls-crypt

OpenVPN은 표준 TLS 프로토콜 위에 추가적인 보안 계층을 제공하여 방어력을 한층 더 강화한다. 이는 OpenVPN의 ‘사전 방어’ 철학을 명확히 보여주는 기능들이다.

• tls-auth: 이 지시어는 사전에 공유된 정적 키(ta.key)를 사용하여 모든 TLS 컨트롤 채널 패킷에 HMAC(Hash-based Message Authentication Code) 서명을 추가하고 검증하는 기능을 활성화한다.34 OpenVPN 서버는 연결을 시도하는 패킷을 받으면, 가장 먼저 이 HMAC 서명이 올바른지 확인한다. 만약 서명이 없거나 유효하지 않으면, 서버는 더 이상의 복잡하고 자원 소모적인 TLS 처리 과정(예: 인증서 검증, 비대칭 키 복호화)을 수행하지 않고 해당 패킷을 즉시 폐기한다.18 이 기능은 다음과 같은 공격에 대한 효과적인 1차 방어선 역할을 한다 19:

• DoS(Denial-of-Service) 공격: 악의적인 사용자가 대량의 위조된 TLS 핸드셰이크 요청을 보내 서버의 CPU 자원을 고갈시키는 것을 방지한다.

• 포트 스캐닝: OpenVPN 포트가 열려 있는지 확인하려는 스캔 시도를 차단한다.

• OpenSSL 취약점 공격: OpenSSL 라이브러리의 잠재적 버퍼 오버플로우와 같은 취약점을 악용하려는 시도가 실제 TLS 처리 엔진에 도달하기 전에 차단한다.

• tls-crypt: tls-auth의 기능을 포함하면서 한 단계 더 나아간 보안 메커니즘이다.19

tls-auth가 패킷 인증만을 제공하는 반면, tls-crypt는 동일한 사전 공유 키를 사용하여 TLS 컨트롤 채널 패킷 전체를 암호화한다. 이로 인해 TLS 핸드셰이크 과정에서 교환되는 메타데이터(예: 사용된 TLS 버전, 암호화 스위트, 인증서 정보 등)까지 외부 관찰자로부터 숨길 수 있다. 이는 트래픽 분석(Traffic Analysis) 및 VPN 탐지 기술에 대한 저항성을 높여준다.19

• tls-crypt-v2: tls-crypt의 개선된 버전으로, 모든 클라이언트가 동일한 사전 공유 키를 사용하는 대신, 서버가 각 클라이언트를 위해 고유한 암호화 키를 생성하여 사용한다. 이는 만약 한 클라이언트의 키가 유출되더라도 다른 클라이언트의 통신에는 영향을 미치지 않도록 보안 격리 수준을 높여준다.19

이러한 계층적 보안 접근 방식은 OpenVPN이 OpenSSL 라이브러리에서 발견될 수 있는 미래의 제로데이 취약점(과거 Heartbleed 버그 사례와 같이)에 대한 추가적인 완충 장치를 마련하려는 설계 의도를 명확히 보여준다. 즉, 핵심 프로토콜에 문제가 발생하더라도 추가적인 방어선이 공격을 지연시키거나 무력화할 수 있도록 다층 방어 체계를 구축하는 것이다.

4. 데이터 암호화 및 무결성 보장

컨트롤 채널을 통해 안전한 세션 키가 성공적으로 교환되면, 실제 사용자 데이터가 오가는 데이터 채널이 활성화된다. 이 장에서는 데이터 채널에서 사용되는 암호화 사이퍼와 데이터 무결성 보장 메커니즘을 분석하며, OpenVPN의 암호화 전략이 어떻게 ’성능과 보안의 적응적 균형’을 추구하는지 탐구한다.

4.1 데이터 채널 암호화 사이퍼

데이터 채널은 컨트롤 채널에서 협상된 대칭 세션 키를 사용하여 빠르고 효율적으로 데이터를 암호화한다. OpenVPN은 다양한 암호화 알고리즘과 운영 모드를 지원하여, 사용 환경의 보안 요구사항과 하드웨어 성능에 맞춰 최적의 선택을 할 수 있는 유연성을 제공한다.25

• AES (Advanced Encryption Standard):

AES는 현재 전 세계적으로 가장 널리 사용되는 업계 표준 대칭키 암호화 알고리즘이다. OpenVPN은 특히 AES-256 비트 키 길이를 기본으로 사용하며, 이는 현재 알려진 모든 종류의 무차별 대입 공격(Brute-force attack)에 대해 안전한 것으로 간주된다.6 OpenVPN은 AES를 다양한 운영 모드와 함께 사용할 수 있다.

• GCM (Galois/Counter Mode): 최신 OpenVPN 버전에서 기본값 및 강력히 권장되는 운영 모드이다.24 GCM은 **AEAD(Authenticated Encryption with Associated Data)**를 지원하는 모드로, 암호화와 메시지 인증(무결성 및 진위성 검증)을 하나의 통합된 과정으로 처리한다. 이는 별도의 HMAC 함수를 사용할 필요가 없애주며, 내부적으로 병렬 처리가 가능하여 최신 CPU의 AES-NI(Advanced Encryption Standard New Instructions)와 같은 하드웨어 가속 기능을 최대한 활용할 수 있다. 그 결과, GCM은 높은 보안 수준을 유지하면서도 매우 뛰어난 성능을 제공한다.16

• CBC (Cipher Block Chaining): 구형 OpenVPN 클라이언트와의 하위 호환성을 위해 지원되는 전통적인 운영 모드이다.24 CBC 모드는 순차적으로 암호화를 수행하므로 GCM만큼 병렬 처리에 유리하지 않아 성능이 상대적으로 낮다. 또한, CBC 모드는 암호화 기능만 제공하므로 데이터 무결성을 보장하기 위해 별도의 HMAC 함수(예: HMAC-SHA256)를 함께 사용해야 한다.25

• ChaCha20-Poly1305:

ChaCha20-Poly1305는 구글이 개발한 최신 스트림 암호 및 메시지 인증 코드의 조합으로, AES-GCM과 마찬가지로 AEAD를 지원한다.24 이 암호화 스위트의 가장 큰 장점은 AES 하드웨어 가속(AES-NI)을 지원하지 않는 저사양 CPU 환경(예: 일부 ARM 기반 모바일 기기, 임베디드 시스템, 구형 데스크톱)에서 소프트웨어만으로도 매우 높은 성능을 발휘한다는 점이다. 따라서 AES-NI가 없는 환경에서는 AES-GCM보다 더 나은 성능을 보일 수 있어, OpenVPN은 이를 강력한 대안으로 지원한다.24

• 사이퍼 협상 (Cipher Negotiation):

OpenVPN의 암호화 전략은 ’성능과 보안의 적응적 균형’을 추구하는 데 있다. 이는 단일 암호화 방식만을 고집하는 대신, 다양한 하드웨어와 클라이언트 환경에서 최적의 성능과 보안을 제공하려는 설계 철학을 반영한다. 이 철학을 구현하는 핵심 메커니즘이 바로 사이퍼 협상이다. 서버 관리자는 data-ciphers (또는 구버전의 cipher) 지시어를 사용하여 지원할 암호화 사이퍼 목록을 우선순위에 따라 지정할 수 있다.24

예를 들어, 서버 설정을 data-ciphers AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305로 구성하면, 클라이언트가 연결을 시도할 때 서버는 다음과 같이 동작한다:

1. 클라이언트가 AES-256-GCM을 지원하는지 확인한다. 지원하면 이 사이퍼를 선택한다.

2. 지원하지 않으면, 다음 우선순위인 AES-128-GCM을 지원하는지 확인한다.

3. 이마저도 지원하지 않으면, ChaCha20-Poly1305를 지원하는지 확인한다.

이러한 협상 메커니즘은 최신 클라이언트는 가장 강력하고 효율적인 암호화를 사용하도록 유도하면서도, 구형 클라이언트는 여전히 호환 가능한 암호화 방식으로 연결할 수 있도록 보장한다.23 이는 보안 수준을 점진적으로 높여가는 ’마이그레이션 경로’를 제공하는 실용적인 접근 방식이다. 예를 들어, 보안에 취약한 것으로 알려진 구형 BF-CBC 사이퍼를 사용하는 레거시 시스템이 존재할 경우, 서버 설정에서 AES-GCM을 최우선으로 두고 BF-CBC를 후순위로 포함시켜, 신규 클라이언트는 강력한 암호화를 사용하게 하고 기존 시스템은 점진적으로 업그레이드할 시간을 확보할 수 있다.25

4.2 데이터 무결성 검증: HMAC

데이터 무결성은 VPN 터널을 통해 전송되는 데이터가 중간에 악의적인 공격자에 의해 변조되지 않았음을 보장하는 필수적인 보안 요소이다.26 OpenVPN은 이를 위해 HMAC(Hash-based Message Authentication Code) 메커니즘을 사용한다.

• HMAC의 작동 원리:

HMAC은 암호학적 해시 함수(예: SHA-256)와 공유 비밀 키(데이터 채널용 HMAC 키)를 결합하여 각 데이터 패킷에 대한 고유한 ‘서명’ 또는 ’태그’를 생성하는 알고리즘이다.10

1. 송신 측: 전송할 원본 데이터 패킷과 HMAC 키를 해시 함수에 입력하여 고정 길이의 HMAC 값을 계산한다. 이 HMAC 값을 원본 데이터 패킷에 첨부하여 함께 전송한다.

2. 수신 측: 패킷을 수신하면, 첨부된 HMAC 값을 분리하고 수신한 데이터 패킷과 자신이 보유한 동일한 HMAC 키를 사용하여 해시 함수로 HMAC 값을 다시 계산한다.

3. 검증: 수신 측에서 새로 계산한 HMAC 값과 송신 측에서 보낸 HMAC 값이 정확히 일치하는지 비교한다. 두 값이 일치하면, 데이터가 전송 중에 변경되지 않았으며(무결성), 올바른 키를 소유한 송신자로부터 온 것임(진위성)을 확신할 수 있다. 만약 단 1비트라도 데이터가 변경되었다면, 해시 함수의 눈사태 효과(avalanche effect)로 인해 완전히 다른 HMAC 값이 계산되므로 변조 사실을 즉시 탐지할 수 있다.

• AEAD와의 관계:

앞서 언급했듯이, AES-GCM이나 ChaCha20-Poly1305와 같은 AEAD(Authenticated Encryption with Associated Data) 사이퍼를 사용하는 경우, 암호화 과정 자체에 데이터 인증 기능이 내장되어 있다. 이 경우 생성되는 인증 태그(Authentication Tag)가 HMAC과 동일한 역할을 수행하므로, 별도의 HMAC 계층이 필요 없다. 이는 연산 과정을 단순화하고 성능을 향상시키는 데 기여한다.16 반면, AES-CBC와 같은 비-AEAD 사이퍼를 사용할 경우에는 반드시 auth 지시어를 통해 HMAC 알고리즘(예: auth SHA256)을 명시적으로 지정하여 데이터 무결성을 보장해야 한다.

5. OpenVPN 배포 및 구성

OpenVPN의 강력한 기능과 유연성은 텍스트 기반의 구성 파일과 공개 키 기반 구조(PKI)를 통해 제어된다. 이 장에서는 OpenVPN을 실제 환경에 배포하고 운영하는 데 필요한 핵심적인 두 가지 요소, 즉 Easy-RSA를 이용한 인증서 관리와 서버 및 클라이언트 구성 파일의 주요 지시어에 대해 상세히 설명한다. OpenVPN의 설정 복잡성은 단점이 아니라, 그 핵심 가치인 유연성을 구현하는 방식에서 비롯된 필연적인 특성이다.

5.1 공개 키 기반 구조(PKI) 구축: Easy-RSA 활용

OpenVPN의 가장 안전한 인증 방식은 인증서 기반 인증이며, 이를 위해서는 신뢰할 수 있는 공개 키 기반 구조(PKI)를 구축해야 한다. Easy-RSA는 OpenVPN을 위한 인증 기관(CA), 서버 및 클라이언트 인증서, 그리고 키를 생성하고 관리하는 과정을 단순화해주는 명령줄 유틸리티 스크립트 모음이다.37

Easy-RSA를 이용한 PKI 구축 단계:

1. Easy-RSA 설치 및 초기화:

• 먼저, OpenVPN 서버 또는 별도의 안전한 시스템에 Easy-RSA를 설치한다.37

• 작업 디렉토리로 이동하여 다음 명령으로 PKI 환경을 초기화한다. 이 명령은 필요한 디렉토리 구조와 기본 설정 파일을 생성한다.

./easyrsa init-pki

38

2. 인증 기관(CA) 생성:

• CA는 PKI의 신뢰의 근간(root of trust)이다. CA의 개인 키는 모든 인증서를 서명하는 데 사용되므로 매우 안전하게 보관해야 한다. 다음 명령으로 CA 개인 키(ca.key)와 자체 서명된 CA 인증서(ca.crt)를 생성한다.

./easyrsa build-ca

38

• 이 과정에서 CA 키를 보호하기 위한 암호를 설정하라는 메시지가 표시된다.

3. 서버 인증서 및 개인 키 생성:

• OpenVPN 서버를 위한 고유한 개인 키와 인증서 서명 요청(CSR)을 생성한다.

./easyrsa gen-req server nopass

38

• server는 생성될 파일의 기본 이름(Common Name)이다. nopass 옵션은 서버가 재시작될 때마다 암호를 입력할 필요가 없도록 개인 키를 암호화하지 않는다. 서버 키 파일의 접근 권한을 엄격하게 관리해야 한다.

4. 서버 인증서 서명:

• 생성된 CSR을 CA를 사용하여 서명함으로써 공식적인 서버 인증서를 발급받는다.

./easyrsa sign-req server server

38

• 이 명령을 실행하면 CA 키의 암호를 입력해야 한다. 성공적으로 완료되면 issued/server.crt 파일이 생성된다.

5. 클라이언트 인증서 및 개인 키 생성:

• VPN에 연결할 각 클라이언트에 대해 고유한 인증서와 키 쌍을 생성해야 한다.

./easyrsa gen-req client1

38

• client1은 클라이언트의 고유한 이름이다. 클라이언트 키는 일반적으로 암호로 보호하는 것이 안전하다.

6. 클라이언트 인증서 서명:

• 서버와 마찬가지로 클라이언트의 CSR을 CA로 서명한다.

./easyrsa sign-req client client1

38

7. Diffie-Hellman(DH) 파라미터 생성:

• 완전 순방향 비밀성(PFS)을 제공하는 DH 키 교환을 위해 DH 파라미터를 생성해야 한다. 이 과정은 상당한 시간이 소요될 수 있다.

./easyrsa gen-dh

39

• 생성된 dh.pem 파일은 서버 구성 파일에서 사용된다.

5.2 서버 및 클라이언트 구성 파일 해부

OpenVPN의 모든 동작은 선언적(declarative) 방식의 텍스트 기반 구성 파일에 의해 정의된다. 사용자는 원하는 최종 상태(예: 프로토콜, 포트, 암호화 방식, 라우팅 규칙)를 파일에 명시하면, OpenVPN 데몬이 이를 해석하여 실행한다. 이 모델은 엄청난 유연성을 제공하지만, 각 지시어의 의미와 상호작용을 정확히 이해해야 하는 복잡성을 수반한다.2

아래 표는 OpenVPN 서버(server.conf)와 클라이언트(client.ovpn) 구성 파일에서 사용되는 주요 지시어들을 정리한 것이다.

이러한 지시어들의 조합을 통해 관리자는 특정 네트워크 환경과 보안 정책에 맞는 매우 정교하고 맞춤화된 VPN 솔루션을 구축할 수 있다. 예를 들어, server 지시어로 라우팅 VPN을 구성하고, server-bridge로 브리징 VPN을 구성하며, push 지시어로 클라이언트의 라우팅 테이블을 동적으로 제어하는 등 무한에 가까운 시나리오 구현이 가능하다.14 하지만 이러한 유연성은 서버와 클라이언트 간의 dev, proto, comp-lzo 등의 설정이 일치하지 않을 경우 연결 실패로 이어질 수 있는 등, 구성의 정확성에 대한 높은 이해를 요구하는 양면성을 지닌다.14

6. 성능 특성 및 최적화

OpenVPN은 강력한 보안과 유연성을 제공하지만, 그 성능은 다양한 요소에 의해 결정된다. 이 장에서는 OpenVPN의 성능에 영향을 미치는 핵심 변수들을 분석하고, 전통적인 구현의 병목 현상과 이를 극복하기 위한 최신 기술인 데이터 채널 오프로드(DCO)의 원리를 탐구한다. OpenVPN의 성능 진화 과정은 ’사용자 공간의 보안성’과 ‘커널 공간의 효율성’ 사이의 기술적 균형점을 찾아가는 여정을 보여준다.

6.1 OpenVPN 성능에 영향을 미치는 핵심 변수

OpenVPN의 처리량(Throughput)과 지연 시간(Latency)은 단일 요인이 아닌, 여러 변수들의 복합적인 상호작용에 의해 결정된다.41

• CPU 성능: 암호화 및 복호화 연산은 매우 CPU 집약적인 작업이다. 따라서 CPU의 클럭 속도와 아키텍처는 OpenVPN 성능에 가장 직접적인 영향을 미친다. 특히, 전통적인 OpenVPN 2.x 버전의 코어 프로세스는 단일 스레드로 작동하기 때문에, 다중 코어 CPU의 모든 코어를 활용하지 못하고 단일 코어의 성능에 크게 의존하는 경향이 있다.42

• 암호화 알고리즘: 선택된 암호화 사이퍼와 키 길이는 성능에 지대한 영향을 미친다. 예를 들어, AES-GCM과 같이 최신 CPU의 하드웨어 가속(AES-NI)을 활용할 수 있는 사이퍼는 순수 소프트웨어로만 처리되는 CBC 모드나 구형 사이퍼에 비해 월등히 높은 성능을 보인다.16 키 길이가 길어질수록(예: AES-128 vs AES-256) 보안성은 높아지지만 암호화 오버헤드도 소폭 증가한다.41

• 전송 프로토콜 (UDP vs. TCP): 앞서 논의된 바와 같이, UDP는 연결 설정 및 오류 확인 오버헤드가 없어 TCP보다 일반적으로 더 높은 처리량과 낮은 지연 시간을 제공한다.16

• 패킷 크기 (MTU): VPN 터널은 원본 IP 패킷에 추가적인 헤더(IP 헤더, UDP/TCP 헤더, OpenVPN 헤더 등)를 덧붙여 캡슐화한다. 이로 인해 전체 패킷 크기가 물리적 네트워크의 최대 전송 단위(MTU, 보통 1500 바이트)를 초과할 수 있다. 이 경우 패킷 단편화(fragmentation)가 발생하여 성능이 저하된다. 따라서 tun-mtu와 같은 옵션을 사용하여 터널의 MTU를 적절히 조정하는 것이 중요하다.19

• 네트워크 환경: 물리적 네트워크의 품질, 즉 대역폭, 지연 시간, 패킷 손실률 등은 VPN 성능의 상한선을 결정한다. 특히 패킷 손실률이 높은 네트워크에서는 TCP 기반 OpenVPN의 성능이 급격히 저하될 수 있다.41

6.2 성능 병목 현상 및 벤치마크 해석

• 단일 스레드 한계와 다중 데몬 아키텍처:

OpenVPN의 전통적인 아키텍처는 단일 프로세스가 단일 CPU 코어에서 실행되는 단일 스레드 모델에 기반한다.42 이는 다중 코어 CPU가 보편화된 현대 서버 환경에서 심각한 성능 병목의 원인이 된다. 즉, 서버에 16개의 CPU 코어가 있더라도 단일 OpenVPN 프로세스는 그중 하나만 사용하게 되어 서버의 전체 처리 능력을 낭비하게 된다.

OpenVPN Access Server와 같은 솔루션은 이 한계를 극복하기 위해 다중 데몬(Multi-daemon) 아키텍처를 도입했다. 이 방식은 서버의 가용한 CPU 코어 수에 맞춰 여러 개의 독립적인 OpenVPN 데몬 프로세스를 동시에 실행시킨다. 그리고 들어오는 클라이언트 연결 요청을 이 데몬들에게 지능적으로 분산(load balancing)하여 여러 CPU 코어가 동시에 VPN 트래픽을 처리하도록 한다. 예를 들어, 4코어 CPU 시스템에서는 TCP와 UDP 프로토콜을 각각 지원하기 위해 코어당 2개씩, 총 8개의 데몬을 실행하여 자원 활용률을 극대화할 수 있다.42 이는 기존 아키텍처를 근본적으로 바꾸지 않으면서도 수평적 확장을 통해 성능을 향상시키는 실용적인 해결책이다.

• 벤치마크 해석:

다양한 성능 벤치마크 결과는 OpenVPN의 성능이 하드웨어 사양과 구성에 따라 크게 달라짐을 보여준다.41 예를 들어, 저사양 임베디드 시스템에서는 수십 Mbps의 처리량을 보일 수 있지만, 고사양 Xeon CPU를 탑재한 서버에서는 수백 Mbps에서 기가비트급에 가까운 처리량을 달성할 수도 있다. 그러나 일반적으로 IPsec과 비교했을 때, 전통적인 OpenVPN의 성능은 다소 낮게 측정되는 경향이 있다. 이는 OpenVPN이 운영체제의 커널이 아닌 사용자 공간(userspace)에서 작동하는 구조적 특성에서 기인하는 근본적인 차이 때문이다.43

6.3 고성능 구현: 데이터 채널 오프로드(DCO)

OpenVPN의 성능 진화 과정에서 가장 혁신적인 변화는 데이터 채널 오프로드(DCO) 기술의 도입이다. 이는 OpenVPN의 성능을 저해하는 근본적인 원인을 해결하여, WireGuard와 같은 최신 커널 기반 VPN 프로토콜과 대등한 수준의 성능을 제공하기 위한 전략적 발전이다.

• 사용자 공간(Userspace) vs. 커널 공간(Kernelspace):

OpenVPN의 초기 설계는 보안을 위해 의도적으로 모든 프로세스를 운영체제의 사용자 공간에서 실행하도록 했다. 이는 만약 OpenVPN 데몬이 공격자에 의해 침해되더라도, 프로세스 권한을 낮추거나(user/group 지시어) chroot jail과 같은 기술을 통해 시스템 전체에 미치는 피해를 최소화하려는 보안 우선 철학의 결과물이다.10

하지만 이 설계는 성능 면에서 필연적인 대가를 치른다. 네트워크를 통해 들어온 데이터 패킷은 먼저 커널 공간(네트워크 드라이버)에서 수신된다. 사용자 공간에서 실행되는 OpenVPN 프로세스가 이 패킷을 암호화하거나 복호화하려면, 커널 공간에서 사용자 공간으로 데이터를 복사하는 과정이 필요하다. 처리가 끝난 패킷은 다시 사용자 공간에서 커널 공간으로 복사되어 네트워크를 통해 전송된다. 이처럼 커널과 사용자 공간을 오가는 데이터 복사 과정과 문맥 교환(Context-switching)은 상당한 CPU 오버헤드를 유발하며, 이는 고속 네트워크 환경에서 성능 병목의 주된 원인이 된다.44

• DCO의 작동 원리:

OpenVPN DCO는 이 문제를 해결하기 위해, 성능에 가장 큰 영향을 미치는 데이터 채널의 암호화 및 복호화 작업을 커널 모듈 형태로 구현하여 커널 공간으로 ’오프로드(offload)’하는 기술이다.44

• DCO 미적용 시: [네트워크] -> [커널] --(복사)--> [사용자 공간: OpenVPN] --(복사)--> [커널] -> [애플리케이션]

• DCO 적용 시: [네트워크] -> -> [애플리케이션]

DCO를 사용하면 데이터 패킷이 더 이상 사용자 공간으로 복사될 필요 없이 커널 내에서 직접 처리된다. 이로써 문맥 교환과 데이터 복사 오버헤드가 원천적으로 제거된다. 또한, 커널 모듈은 운영체제의 멀티스레딩 및 네트워킹 스택과 직접적으로 통합되어 다중 CPU 코어를 훨씬 효율적으로 활용할 수 있다.19

• DCO의 효과:

DCO를 적용함으로써 OpenVPN은 처리량을 수배에서 수십 배까지 향상시켜 와이어스피드(wire-speed)에 근접하는 성능을 달성할 수 있다. 이는 OpenVPN이 전통적인 아키텍처의 성능 한계를 극복하고, WireGuard와 같은 최신 커널 네이티브 VPN 프로토콜과 성능 면에서 직접적으로 경쟁할 수 있게 되었음을 의미한다. DCO는 단순한 성능 개선 기능을 넘어, OpenVPN 아키텍처의 근본적인 약점을 해결하고 미래에도 경쟁력을 유지하기 위한 중요한 전략적 진화이다. 최적의 성능을 위해서는 서버와 클라이언트 양쪽 모두 DCO를 지원하고 활성화해야 한다.44

7. 주요 프로토콜 비교 분석: OpenVPN, IPsec, WireGuard

VPN 프로토콜을 선택하는 것은 조직의 보안 정책, 성능 요구사항, 운영 환경 등 다양한 요소를 고려해야 하는 중요한 결정이다. 이 장에서는 OpenVPN을 업계의 다른 주요 프로토콜인 IPsec 및 WireGuard와 다각적으로 비교 분석하여 각 기술의 상대적 강점과 약점, 그리고 기술적 지향점을 명확히 한다. VPN 프로토콜의 발전사는 ’유연성’에서 ’단순성’으로, ’사용자 공간’에서 ’커널 공간’으로 이동하는 거대한 기술적 흐름을 반영한다.

7.1 OpenVPN vs. IPsec

IPsec(Internet Protocol Security)은 인터넷의 표준 보안 프로토콜 스위트로, 오랜 기간 기업 환경에서 VPN의 표준으로 사용되어 왔다.

• 보안 모델 및 작동 계층: OpenVPN은 SSL/TLS를 기반으로 하는 애플리케이션 계층(OSI 7계층)의 프로토콜로, 사용자 공간에서 실행된다.46 반면, IPsec은 네트워크 계층(OSI 3계층)에서 작동하며 운영체제의 커널에 깊숙이 통합되어 있는 프로토콜 스위트이다.20 이 근본적인 차이는 설정, 호환성, 성능 등 모든 면에서 두 프로토콜의 특성을 결정짓는다.

• 설정 복잡성 및 호환성: OpenVPN은 단일 UDP 또는 TCP 포트(주로 1194 또는 443)를 사용하므로 구성이 비교적 간단하고, NAT(Network Address Translation) 환경을 쉽게 통과할 수 있어 방화벽 친화적이다.10 반면, IPsec은 인증 헤더(AH), 캡슐화 보안 페이로드(ESP), 인터넷 키 교환(IKE) 등 여러 프로토콜과 고정된 포트(UDP 500, 4500)를 복합적으로 사용한다. 이로 인해 설정이 매우 복잡하며, 엄격한 방화벽이나 NAT 환경에서는 연결 설정에 어려움을 겪는 경우가 많다.20

• 성능: 일반적으로 운영체제 커널에서 직접 IP 패킷을 처리하는 IPsec이 사용자 공간에서 작동하는 전통적인 OpenVPN(DCO 미적용 시)보다 더 낮은 CPU 사용률과 높은 처리량을 보인다.43

7.2 OpenVPN vs. WireGuard

WireGuard는 ’단순성’과 ’최고의 성능’을 목표로 설계된 최신 VPN 프로토콜로, 등장과 함께 VPN 시장의 판도를 바꾸고 있다.

• 설계 철학: OpenVPN의 핵심 철학이 ’유연성’과 ’선택’이라면, WireGuard의 철학은 ’단순성’과 ’의견(opinionated)’이다. OpenVPN은 수많은 암호화 알고리즘, 프로토콜, 설정을 제공하여 사용자가 모든 것을 제어할 수 있는 ’스위스 군용 칼’과 같다.36 반면, WireGuard는 보안 전문가들이 현재 가장 안전하고 효율적이라고 판단한 단 하나의 최신 암호화 스위트(ChaCha20-Poly1305, Curve25519, BLAKE2s 등)만을 고정적으로 사용한다.36 이는 복잡한 설정으로 인해 발생할 수 있는 사용자의 실수를 원천적으로 차단하고, ‘기본적으로 안전한(Secure by Default)’ 상태를 보장하려는 설계 의도를 반영한다.

• 코드베이스 및 감사 용이성: OpenVPN은 수십 년간 기능이 추가되면서 수십만 라인에 달하는 방대한 코드베이스를 가지게 되었다. 이는 전체 코드를 감사하여 보안 취약점을 찾는 것을 매우 어렵게 만든다. 반면, WireGuard는 약 4,000 라인에 불과한 매우 작고 간결한 코드베이스를 가지고 있다. 이는 단 한 명의 보안 전문가도 전체 코드를 쉽게 감사할 수 있게 하며, 잠재적인 공격 표면(attack surface)이 현저히 적다는 것을 의미한다.36

• 성능: WireGuard는 리눅스 커널 내에서 직접 실행되도록 설계되었고, 최신 고속 암호화 기술을 사용하므로 전통적인 OpenVPN보다 훨씬 빠르고 효율적이다. 벤치마크 결과, 처리량은 더 높고 지연 시간과 데이터 오버헤드는 더 낮아, 특히 배터리와 데이터 사용량에 민감한 모바일 환경에서 압도적인 장점을 보인다.17 OpenVPN DCO 기술은 이러한 성능 격차를 줄이기 위한 OpenVPN 진영의 응답이다.

• 호환성: 이 분야에서는 OpenVPN이 명백한 우위를 점한다. 수십 년의 역사를 통해 OpenVPN은 거의 모든 운영체제, 임베디드 장치, 상용 라우터에서 폭넓게 지원된다.6 WireGuard는 비교적 최신 기술이므로 주요 운영체제에는 통합되었지만, 레거시 시스템이나 다양한 하드웨어 장치에서의 지원은 아직 확대되고 있는 단계이다.

7.3 기타 프로토콜 (PPTP, L2TP, SSTP)

• PPTP (Point-to-Point Tunneling Protocol): 설정이 매우 간단하고 빠르지만, 수많은 심각한 보안 결함이 발견되어 현재는 절대 사용해서는 안 되는 구식 프로토콜로 간주된다.20

• L2TP/IPsec (Layer 2 Tunneling Protocol over IPsec): L2TP는 터널링을, IPsec은 암호화를 담당하는 조합이다. PPTP보다는 안전하지만, OpenVPN보다 느리고 일부 방화벽에서 차단되기 쉽다. 또한 미국 국가안보국(NSA)에 의해 손상되었을 수 있다는 의혹이 제기된 바 있다.16

• SSTP (Secure Socket Tunneling Protocol): Microsoft가 개발한 프로토콜로, SSL/TLS를 기반으로 하므로 TCP 포트 443을 사용하여 방화벽을 잘 우회한다. Windows 운영체제와 매우 잘 통합되어 있지만, 소스 코드가 공개되지 않은 독점 기술이라는 점과 Microsoft에 대한 의존성 때문에 널리 사용되지는 않는다.16

7.4 종합 비교

아래 표는 OpenVPN, IPsec, WireGuard 세 가지 주요 프로토콜의 핵심적인 차이점을 요약한 것이다.

결론적으로, OpenVPN은 여전히 최고의 호환성과 유연성이 필요한 환경에서 강력한 선택지로 남아있다. 반면, WireGuard는 성능과 단순성을 최우선으로 하는 현대적인 환경에서 미래의 표준으로 빠르게 자리 잡고 있다. IPsec은 복잡성에도 불구하고 기존 엔터프라이즈 네트워크와의 통합 및 표준 준수가 중요한 경우에 여전히 유효한 옵션이다.

8. 활용 시나리오 및 고급 구성

OpenVPN의 이론적 기반과 기술적 특성을 이해했다면, 이제 실제 환경에서 어떻게 활용되는지 구체적인 시나리오를 통해 살펴볼 차례이다. OpenVPN은 그 유연성 덕분에 단순한 개인용 프라이버시 도구를 넘어, 복잡한 기업 네트워크 요구사항을 해결하는 다목적 솔루션으로 기능한다.

8.1 원격 근무 (Remote Access VPN)

이는 OpenVPN의 가장 일반적이고 기본적인 활용 사례로, 외부의 개별 사용자가 인터넷을 통해 안전하게 회사 내부 네트워크에 접속할 수 있도록 지원한다.9

• 개념: 재택근무자, 외근 중인 직원, 출장 중인 임원 등이 자신의 노트북이나 모바일 기기를 사용하여 공용 인터넷을 통해 회사 내부의 파일 서버, 데이터베이스, 인트라넷 웹사이트 등 비공개 자원에 안전하게 접근하는 것을 목표로 한다.4

• 아키텍처 및 구성:

1. 서버 배치: OpenVPN 서버(예: OpenVPN Access Server)는 일반적으로 회사 네트워크의 경계, 즉 DMZ(Demilitarized Zone) 또는 방화벽 바로 뒤의 내부망에 배치된다.49

2. 방화벽 설정: 외부 인터넷에서 OpenVPN 서버로의 연결을 허용하도록 회사 방화벽에서 특정 포트(예: UDP 1194 또는 방화벽 우회를 위한 TCP 443)에 대한 인바운드 규칙을 설정한다.49

3. 클라이언트 설정: 원격 근무자는 자신의 기기에 OpenVPN 클라이언트 소프트웨어(예: OpenVPN Connect)를 설치하고, 관리자로부터 전달받은 구성 프로파일(.ovpn 파일)을 가져온다. 이 프로파일에는 서버 주소, 인증서, 암호화 설정 등 모든 연결 정보가 포함되어 있다.12

4. 연결 및 접근: 클라이언트가 VPN 연결을 시작하면, TLS 핸드셰이크를 통해 인증이 이루어지고 암호화된 터널이 생성된다. 성공적으로 연결되면, 클라이언트는 회사 내부 네트워크의 IP 주소 대역에서 가상 IP 주소를 할당받는다. 이 순간부터 원격 근무자의 기기는 논리적으로 회사 LAN의 일부가 되며, 허가된 내부 자원에 마치 사무실에 직접 연결된 것처럼 접근할 수 있다.48

구성도 (논리적 흐름):

[원격 클라이언트] <–> [인터넷] <–> [회사 방화벽] <–> [OpenVPN 서버] <–> [사내 네트워크 자원]

8.2 사이트 간 연결 (Site-to-Site VPN)

지리적으로 분산된 여러 사무실을 가진 기업을 위한 솔루션으로, 각 사무실의 로컬 네트워크(LAN) 전체를 암호화된 터널로 안전하게 연결한다.9

• 개념: 서울 본사와 부산 지사의 네트워크를 OpenVPN 터널로 연결하여, 양쪽 사무실의 직원들이 별도의 VPN 클라이언트 소프트웨어 없이도 서로의 파일 서버, 프린터, 내부 시스템에 직접 접근할 수 있도록, 마치 하나의 거대한 통합 네트워크처럼 만드는 것을 목표로 한다.20

• 아키텍처 및 구성:

1. 게이트웨이 설정: 각 사이트(본사, 지사)의 네트워크 게이트웨이(방화벽 또는 전용 라우터)에 OpenVPN 인스턴스를 설치하고 구성한다. 일반적으로 한쪽(예: 본사)은 서버 모드로, 다른 쪽(예: 지사)은 클라이언트 모드로 작동하도록 설정한다.52

2. 라우팅 구성: 이것이 Site-to-Site VPN의 핵심이다.

• 서버 측: server.conf 파일에 route 지시어를 사용하여 클라이언트 측(지사)의 LAN 대역을 명시한다. 그리고 push "route <본사_LAN_대역>" 지시어를 통해, 클라이언트(지사 게이트웨이)가 연결될 때 본사 LAN으로 가는 트래픽을 VPN 터널로 보내도록 라우팅 규칙을 자동으로 설정해준다. 또한, client-config-dir과 iroute 지시어를 사용하여 특정 클라이언트(지사)가 책임지는 네트워크 대역을 서버에 알려준다.

• 클라이언트 측: client.ovpn 파일에 remote 지시어로 서버(본사 게이트웨이)의 공인 IP 주소를 지정한다. 터널이 연결되면 서버로부터 push된 라우팅 규칙을 자동으로 적용받게 된다.53

3. 투명한 연결: 구성이 완료되고 터널이 활성화되면, 부산 지사의 직원이 서울 본사의 파일 서버 IP 주소(예: 192.168.1.100)로 접근을 시도하면, 지사 게이트웨이는 이 트래픽을 자동으로 OpenVPN 터널을 통해 암호화하여 본사로 전송한다. 본사 게이트웨이는 이 트래픽을 복호화하여 내부 파일 서버로 전달한다. 이 모든 과정은 최종 사용자에게는 완전히 투명하게 이루어진다.9

구성도 (논리적 흐름):

[사이트 A LAN] <–> [게이트웨이 (OpenVPN 서버)] <== (인터넷을 통한 암호화 터널) ==> [게이트웨이 (OpenVPN 클라이언트)] <–>

8.3 제로 트러스트 네트워크 접근 (ZTNA)

ZTNA는 “절대 신뢰하지 말고, 항상 검증하라(Never Trust, Always Verify)“는 원칙에 기반한 현대적인 보안 패러다임이다. 기존의 경계 기반 보안 모델(내부 네트워크는 안전하고 외부 네트워크는 위험하다는 가정)을 폐기하고, 모든 접근 요청을 신뢰할 수 없는 것으로 간주하여 엄격하게 인증하고 권한을 부여한다.9

• OpenVPN의 역할: OpenVPN, 특히 OpenVPN Access Server와 같은 솔루션은 ZTNA 아키텍처에서 보안 접속 게이트웨이(Secure Access Gateway) 또는 **정책 실행 지점(Policy Enforcement Point)**의 핵심적인 역할을 수행할 수 있다.54

• 활용 방식:

1. 강력한 신원 인증: OpenVPN 서버를 SAML, LDAP, RADIUS 프로토콜을 통해 Okta, Azure AD, Google Workspace와 같은 외부 신원 공급자(IdP)와 연동한다. 이를 통해 사용자는 익숙한 기업 계정과 다단계 인증(MFA)을 사용하여 VPN에 로그인하게 된다.48

2. 세분화된 접근 제어: 인증된 사용자를 역할이나 부서에 따라 그룹으로 나누고, 각 그룹에 대해 접근 가능한 애플리케이션이나 네트워크 대역을 최소한으로 제한하는 접근 제어 목록(ACL)을 적용한다. 예를 들어, 영업팀 그룹은 CRM 서버에만 접근할 수 있고, 개발팀 그룹은 개발 서버와 코드 저장소에만 접근할 수 있도록 설정한다.1

3. 공격 표면 감소: 이 방식을 통해 사용자는 자신의 역할에 필요한 최소한의 자원에만 접근 권한을 갖게 된다(최소 권한 원칙). 만약 한 사용자의 계정이 탈취되더라도, 공격자는 해당 사용자가 접근할 수 있었던 제한된 영역 내에서만 활동할 수 있으며, 네트워크 전체로 확산되는 측면 이동(Lateral Movement) 공격을 효과적으로 방지할 수 있다.54

8.4 개인 정보 보호 및 검열 우회

기업 환경뿐만 아니라 개인 사용자에게도 OpenVPN은 중요한 도구이다.

• 공용 Wi-Fi 보안: 카페, 공항 등 보안이 취약한 공용 Wi-Fi 네트워크에 연결할 때, OpenVPN 터널을 통해 모든 인터넷 트래픽을 암호화함으로써 동일 네트워크상의 다른 사용자가 데이터를 가로채는 것을 방지한다 (중간자 공격 방어).6

• 프라이버시 보호: 사용자의 실제 IP 주소를 VPN 서버의 IP 주소로 마스킹하여, 웹사이트나 온라인 서비스가 사용자의 위치를 추적하거나 활동을 프로파일링하는 것을 어렵게 만든다.3

• 검열 우회: 일부 국가에서 시행하는 인터넷 검열이나 지역 제한(Geo-blocking) 콘텐츠에 접근하기 위해 OpenVPN이 널리 사용된다. 특히 OpenVPN을 TCP 포트 443에서 실행하면, VPN 트래픽을 일반적인 HTTPS 트래픽처럼 위장하여 심층 패킷 검사(DPI) 기반의 차단 시스템을 우회할 가능성을 높일 수 있다.3

9. 결론: OpenVPN의 현재와 미래

OpenVPN은 지난 20여 년간 가상 사설망 기술의 발전을 이끌어온 핵심적인 프로토콜로서, 그 기술적 깊이와 실용적 가치는 여전히 유효하다. 본 안내서에서 심층적으로 분석한 바와 같이, OpenVPN의 아키텍처, 암호학적 기반, 그리고 다양한 활용 사례는 이 기술이 왜 오늘날까지도 네트워크 보안의 표준으로 인정받는지를 명확히 보여준다.

핵심 강점과 약점 요약:

• 강점:

• 검증된 보안성과 안정성: SSL/TLS라는 업계 표준 위에 구축되고, 수십 년간 전 세계 커뮤니티의 검증을 거치면서 축적된 안정성은 OpenVPN의 가장 큰 자산이다.

• 압도적인 호환성과 유연성: 거의 모든 운영체제와 네트워크 장비를 지원하며, TUN/TAP, UDP/TCP, 다양한 암호화 알고리즘을 조합하여 거의 모든 네트워크 시나리오에 맞춤형으로 적용할 수 있는 극강의 유연성을 제공한다.

• 투명한 오픈 소스 모델: 소스 코드의 완전한 공개는 기술적 신뢰를 담보하며, 백도어나 숨겨진 취약점에 대한 우려를 불식시킨다.

• 약점:

• 상대적으로 낮은 기본 성능: 사용자 공간에서 작동하는 전통적인 아키텍처는 커널 기반의 최신 프로토콜에 비해 성능 오버헤드가 존재한다.

• 설정의 복잡성: 높은 유연성은 필연적으로 다양한 구성 옵션을 수반하며, 이는 초심자에게 복잡하고 어렵게 느껴질 수 있다. 잘못된 구성은 보안 취약점으로 이어질 수 있다.

• 방대한 코드베이스: 오랜 기간 발전해 온 만큼 코드베이스가 비대해져 전체적인 보안 감사에 많은 노력이 요구된다.

보안 환경 변화와 OpenVPN의 발전 방향:

클라우드 컴퓨팅의 보편화와 하이브리드 근무 형태의 확산은 안전한 원격 접속 기술의 중요성을 그 어느 때보다도 높이고 있다. 이러한 변화 속에서 OpenVPN은 다음과 같은 방향으로 진화하며 그 역할을 계속해 나갈 것으로 전망된다.

1. 성능 혁신을 통한 경쟁력 유지: 데이터 채널 오프로드(DCO) 기술의 도입은 OpenVPN의 가장 큰 약점이었던 성능 문제를 해결하는 결정적인 전환점이다. DCO의 안정화와 보급이 확대됨에 따라, OpenVPN은 WireGuard와 같은 최신 프로토콜과 성능 면에서 대등하게 경쟁하며 고속 네트워크 환경에서도 여전히 매력적인 선택지로 남을 것이다.

2. 제로 트러스트 아키텍처와의 통합 심화: OpenVPN은 더 이상 단순한 네트워크 터널링 도구가 아니다. SAML, LDAP 등과의 연동을 통해 강력한 신원 기반 인증을 제공하고, 세분화된 접근 제어를 통해 최소 권한 원칙을 구현함으로써 현대적인 제로 트러스트 네트워크 접근(ZTNA) 프레임워크의 핵심 구성 요소로 자리매김하고 있다.1 앞으로 이러한 통합 기능은 더욱 강화될 것이다.

3. 미래 위협에 대한 대비: 양자컴퓨팅의 등장은 현재의 공개키 암호 체계를 무력화할 수 있는 장기적인 위협이다. OpenVPN 커뮤니티는 이러한 미래 위협에 대비하여 양자내성암호(PQC) 알고리즘을 프로토콜에 통합하기 위한 연구를 지속할 것이다.10

결론적으로, OpenVPN은 ’오래되었지만 여전히 강력한 표준’으로서 그 입지를 공고히 하고 있다. WireGuard와 같은 새로운 프로토콜이 성능과 단순성을 무기로 미래의 방향을 제시하고 있지만, OpenVPN이 제공하는 압도적인 호환성, 극한의 유연성, 그리고 수십 년간 쌓아온 신뢰는 특정 요구사항을 가진 환경에서 여전히 대체 불가능한 가치를 지닌다. 따라서 OpenVPN은 사라지는 기술이 아니라, 새로운 기술과 공존하며 끊임없이 진화하는, 네트워크 보안의 살아있는 역사이자 현재 진행형 솔루션으로 남을 것이다.

10. 참고 자료

1. OpenVPN: Business VPN For Secure Networking, https://openvpn.net/
2. OpenVPN - Pros and Cons - Bobcares, https://bobcares.com/blog/openvpn-pros-and-cons/
3. OpenVPN은 무엇이며 어떻게 작동하나요? - Surfshark, https://surfshark.com/ko/blog/what-is-openvpn
4. What Is a VPN? A Complete Guide to Virtual Private Networks, https://www.paloaltonetworks.com/cyberpedia/what-is-a-vpn
5. 2x HOW TO - OpenVPN, https://openvpn.net/community-docs/how-to.html
6. OpenVPN Security: Why It’s the Safest VPN Protocol - IT GOAT, https://www.itgoat.com/blog/openvpn-security-why-its-the-safest-vpn-protocol/
7. OpenVPN Compliance, https://openvpn.net/openvpn-compliance/
8. What Is OpenVPN? How It Works, Features, and Benefits - CometVPN, https://cometvpn.com/blog/what-is-openvpn/
9. OpenVPN이란? 안전한 원격 접속을 위한 VPN 솔루션 - NordVPN, https://nordvpn.com/ko/blog/openvpn-explained/
10. OpenVPN - Wikipedia, https://en.wikipedia.org/wiki/OpenVPN
11. OpenVPN configuration examples - Teltonika Networks Wiki, https://wiki.teltonika-networks.com/view/OpenVPN_configuration_examples
12. Getting Started with Access Server - OpenVPN, https://openvpn.net/as-docs/getting-started.html
13. VPN Cluster Setup — Access Server - OpenVPN, https://openvpn.net/as-docs/cluster-setup.html
14. Creating Configuration Files for Server and Clients - OpenVPN, https://openvpn.net/community-docs/creating-configuration-files-for-server-and-clients.html
15. OpenVPN 브리징 - 부족함을 인정하는 순간 - 티스토리, https://jihwan-study.tistory.com/31
16. VPN Encryption Types | OpenVPN, IKEv2, PPTP, L2TP/IpSec, SSTP - ProPrivacy.com, https://proprivacy.com/vpn/guides/vpn-encryption-the-complete-guide
17. What is OpenVPN, and how does it work? - NordVPN, https://nordvpn.com/blog/what-is-openvpn/
18. OpenVPN Cryptographic Layer, https://openvpn.net/community-docs/openvpn-cryptographic-layer.html
19. Configuration - OpenVPN, https://openvpn.net/as-docs/configuration.html
20. What Is OpenVPN? How It Works & Should You Use It in 2025, https://www.wizcase.com/blog/what-is-openvpn/
21. What are the advantages of using OpenVPN compared to other types of connections such as PPTP and L2TP? - Quora, https://www.quora.com/What-are-the-advantages-of-using-OpenVPN-compared-to-other-types-of-connections-such-as-PPTP-and-L2TP
22. What Is OpenVPN? - Palo Alto Networks, https://www.paloaltonetworks.com/cyberpedia/what-is-openvpn
23. Advanced Security Options - OpenVPN, https://openvpn.net/as-docs/advanced-security.html
24. Tutorial: Change the Data-Channel Encryption Cipher - OpenVPN, https://openvpn.net/as-docs/tutorials/tutorial–change-encryption-cipher.html
25. Data-channel Encryption Cipher Negotiation on Access Server | OpenVPN, https://openvpn.net/as-docs/data-channel-encryption-cipher.html
26. TLS란? | 네트워크 보안 프로토콜 | Cloudflare, https://www.cloudflare.com/ko-kr/learning/ssl/transport-layer-security-tls/
27. SSL/TLS Handshake Process: Step-by-Step Guide - Serverion, https://www.serverion.com/uncategorized/ssl-tls-handshake-process-step-by-step-guide/
28. An overview of the SSL/TLS handshake - IBM, https://www.ibm.com/docs/en/ibm-mq/9.3.x?topic=tls-overview-ssltls-handshake
29. What happens in a TLS handshake? | SSL handshake - Cloudflare, https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/
30. OpenVPN: 보안 및 호환성 이해하기 - Tutkit.com, https://www.tutkit.com/ko/tekseuteu-tyutorieol/10523-openvpn-boan-mich-hohwanseong-ihaehagi
31. Diffie–Hellman key exchange - Wikipedia, https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
32. “Diffie-Hellman Key Exchange” in plain English, https://security.stackexchange.com/questions/45963/diffie-hellman-key-exchange-in-plain-english
33. 2.3 Diffie–Hellman key exchange - Brown Math, https://www.math.brown.edu/~jhs/MathCrypto/SampleSections.pdf
34. Hardening OpenVPN Security, https://openvpn.net/community-docs/hardening-openvpn-security-178571.html
35. Tutorial: Create Connection Profiles - OpenVPN, https://openvpn.net/as-docs/tutorials/tutorial–create-connection-profiles.html
36. OpenVPN vs WireGuard: Top Two VPN Protocols Side By Side, https://www.goodaccess.com/blog/openvpn-vs-wireguard
37. OpenVPN Configuration with Easy-RSA - Nitrokey Documentation, https://docs.nitrokey.com/nitrokeys/features/openpgp-card/openvpn/easyrsa
38. Tutorial: Configure External PKI with Easy-RSA - OpenVPN, https://openvpn.net/as-docs/tutorials/tutorial–epki-with-easy-rsa.html
39. EasyRSA3-OpenVPN-Howto – community wiki, https://community.openvpn.net/Pages/EasyRSA3-OpenVPN-Howto
40. Easy Windows Guide - OpenVPN Community Wiki, https://community.openvpn.net/Pages/Easy%20Windows%20Guide
41. PerformanceTesting - OpenVPN Community Wiki, https://community.openvpn.net/Archived/PerformanceTesting
42. Advanced Options Managed From The Command-Line Interface - OpenVPN, https://openvpn.net/as-docs/advanced-options.html
43. OPNsense OpenVPN performance tests and results - Thomas-Krenn-Wiki-en, https://www.thomas-krenn.com/en/wiki/OPNsense_OpenVPN_performance_tests_and_results
44. OpenVPN Data Channel Offload (DCO), https://openvpn.net/as-docs/openvpn-data-channel-offload.html
45. Access Server - Self-Hosted VPN - OpenVPN, https://openvpn.net/access-server/
46. OpenVPN Compatibility, https://openvpn.net/faq/openvpn-compatibility/
47. IPsec vs. OpenVPN: What Are the Differences? - Palo Alto Networks, https://www.paloaltonetworks.com/cyberpedia/ipsec-vs-openvpn
48. Secure Remote Access VPN for SMBs - OpenVPN, https://openvpn.net/solutions/use-cases/secure-remote-access/
49. Simple Infrastructure - OpenVPN, https://openvpn.net/as-docs/simple-infrastructure.html
50. Set up OpenVPN for Remote Access in a Single Region on Oracle Cloud Infrastructure, https://docs.oracle.com/en/learn/oci-openvpn-part1/index.html
51. Introduction - OpenVPN, https://openvpn.net/as-docs/introduction.html
52. Creating site-to-site tunnels networks with OpenVPN, https://support.edge.arista.com/hc/en-us/articles/202391008-Creating-site-to-site-tunnels-networks-with-OpenVPN
53. OpenVPN Site-to-Site Configuration Example with Shared Key | pfSense Documentation, https://docs.netgate.com/pfsense/en/latest/recipes/openvpn-s2s-psk.html
54. Business VPN - OpenVPN, https://openvpn.net/solutions/use-cases/business-vpn/
55. Authentication - OpenVPN, https://openvpn.net/as-docs/authentication-78640.html
56. Authenticating Users for Access Server | OpenVPN, https://openvpn.net/as-docs/authenticating.html