태그: VPN

중국의 만리방화벽(Great Filrewall)과 VPN 서비스 차단 우회

최근 들어 중국의 인터넷 검열이 강화되고 있는 추세이다. 철저한 필터링 능력으로 유명한 만리방화벽(Great Firewall)이 이 역할을 수행한다.
만리방화벽은 중국 정부의 전면적인 인터넷 검열 시스템인 황금 방패 프로젝트(Golden Shield Project)의 일환으로, DPI 및 휴리스틱 분석을 통해 중국 정부에서 접속을 막은 사이트와 정보를 실시간으로 검열한다.

VPN은 이러한 만리방화벽을 우회하기 위한 수단으로 많이 사용되었는데, VPN에 대한 검열은 예전부터 계속되어 왔으나, 특히 2017년 9월부로 강화된 검열이 적용되고 있는 듯 하다. 기존에는 차단되지 않았던 중소규모 사업자들의 서비스도 차단되었으니 말이다.

 

VPN 연결을 테스트하면서 발견한 만리방화벽의 특징은 다음과 같다.

1. 시그니쳐 기반으로 차단을 수행한다
2. 연결을 차단하기 위하여 TCP RST를 전송, 세션을 끊어버린다
3. 일반적인 TLS 연결은 차단되지 않는다

 

나는 이 중에서 특히 1번에 주목하였는데, 이것은 만리방화벽의 한계를 드러내는 것이기 때문이다.
아무리 중국 정부가 많은 자원을 투입하여 패킷을 분석한다 한들, 대상이 인터넷 백본인 이상 검열 장비는 필연적으로 전체 패킷을 들여다볼 수 없다. 그러니 시그니쳐 분석을 통한 패턴 매칭으로 타겟 세션을 걸러내는 것이다.

다시 말해, VPN이 차단된 경우라도 사업자를 변경하거나, VPN 서버의 설정을 변경하는 등의 방법으로 시그니쳐를 뒤틀어놓으면 VPN 차단을 우회할 수 있다. 그리고 시그니쳐를 저장하고 매칭하는 시스템의 자원에도 한계가 있는 이상, 시그니쳐 데이터는 일정 기간동안 보존되어 사용되다가 만료될 것임을 쉽게 추론할 수 있다.

 

하지만 이러한 방법을 통한 우회는 결국 하나의 방편에 불과하다. VPN의 사용량이 많다면 시그니쳐는 빠르게 수집, 업데이트 될 것이고, 그 때마다 시그니쳐를 흔들어놓을 수준의 변경을 가하는 것은 쉽지 않은 일이기 때문이다.
그래서 근본적인 해결법으로 제시되는 것이 VPN 트래픽을 TLS로 캡슐화하는 것이다.

널리 알려진 바와 같이, 일단 TLS 세션이 성립되고 나면 회선을 감시하는 제 3자가 TLS 세션의 내용을 들여다보는 것은 MITM 공격을 수행하지 않는 이상 불가능하다. 그렇기 때문에 HTTPS를 이용하여 Warning.or.kr을 회피하는 것이 가능하고.
하지만 OpenVPN의 기본적인 암호화 프로토콜도 TLS이다. 그리고 중국 정부는 OpenVPN의 트래픽을 탐지, 차단하는 것에 성공하였다.

이것이 가능했던 이유는 OpenVPN의 TLS 세션 형성을 위한 핸드쉐이크가 시그니쳐로서 탐지되었기 때문이다. 이것을 특정함으로써 일반적인 TLS 트래픽과 OpenVPN 트래픽을(비록 내용은 모를지라도) 구분하는 것이 가능하다.
그렇다면 우리는 어떻게 이것을 우회할 수 있을까?
아주 단순한 결론이다. TLS 핸드쉐이크를 탐지한다면, ‘일반적인’ TLS로 한번 더 캡슐화해주면 될 뿐인 것이다.

 

이것을 위해 필요한 것이 stunnel이라는 프로그램이 되겠다. stunnel은 여기에서 다운로드 할 수 있으며, 임의의 서버-클라이언트 간 TLS 터널링을 제공한다.

 

stunnel을 서버/클라이언트에 인스톨하고, OpenVPN을 stunnel 터널을 통해 연결하면, 만리방화벽을 우회한 접속이 가능하다.
혹여나 중국에서 VPN 접속이 안 되어서 골머리를 앓고 있는 분이 계시다면, 한번 사용해 보기를 권한다.

Network Study – 6주차 : VPN(Virtual Private Network) 프로토콜

VPN(Virtual Private Network, 가상 사설망)은 본래 전용 회선(Leased-Line)을 사용하던 기업체들이 인터넷의 확산과 더불어 비용 절감을 꾀하기 위해 만들어낸 기술이다.
전용 회선을 임대하거나, 속도가 보장된 가상 회선을 임대하는 경우(MPLS)와 달리 VPN은 인터넷 망을 그대로 이용한다는 차이점이 있다. 이를 통해서 일반적인 인터넷 회선 사용료를 지불하는 것으로 본-지사간의 네트워크를 구성할 수 있었으나, 전용 회선 혹은 MPLS에서 보장하던 QoS등의 서비스를 제공받을 수 없게 되었다.

또한, 물리적 혹은 논리적으로 하나의 회선을 독점하였던 기존의 서비스와는 달리 인터넷 망을 사용하기에 외부로부터의 접근에 취약해진다는 문제가 있었다. 이를 해결하기 위해 모든 VPN 프로토콜들은 사용자를 인증하고 전송하는 모든 패킷을 암호화한다.
물론 사용하는 암호화 알고리즘과, VPN 터널 생성 방법은 프로토콜마다 다르다.

그리고 개발 목적이 본-지사간의 네트워크를 연결하는 것이었기에, 물리적으로 연결되어 직접 있지 않은 네트워크와 직접 통신할 수 있다는 특징을 가진다.

 

1. VPN 프로토콜의 종류

흔히 사용되는 VPN 프로토콜들은 다음과 같다.

– Internet Protocol Security(IPSec)
– Transport Layer Security(SSL/TLS)
– Datagram Transport Layer Security(DTLS)
– Point to Point Tunneling Protocol(PPTP)
– Secure Socket Tunneling Protocol(SSTP)
– Secure Socket Shell VPN(SSH-VPN)

이제 각 프로토콜의 알고리즘을 살펴 보자.

1-1. IPSec

IPSec은 AH(Authentication Header), ESP(Encapsulating Security Payload), IKE(Internet Key Exchange)로 구성되어 있다. AH는 인증 과정을, ESP는 페이로드의 암호화와 흐름 제어를 제공한다. 그리고 IKE는 키 매니지먼트를 제공한다.
IPSec은 고품질의 통합된 암호화 기반의 보안을 IPv4와 v6에 제공하기 위해 디자인되었고, 접근 제어, 비연결형 무결성(Connectionless Integrity), 데이터 출처 인증(Data Origin Authentication)과 재전송 공격의 차단, 암호화에 의한 기밀성, 제한적인 흐름 제어 무결성(Limited Flow Control Integrity)를 제공한다. 이러한 서비스들은 IP레이어에서 제공되며, IP 자신을 포함한 상위 프로토콜들에게 보호를 제공한다.

IPSec은 또한 최소한의 방화벽 기능을 포함한다. 이것은 IP 레이어에서의 접근 제어 측면에서 필수불가결한데, 만약 좀 더 정교한 방화벽 메커니즘을 제공할 수 있다면 그것을 사용하면 될 것이다(다만, IPSec 구현체에 의해 방화벽의 흐름 제어 기능이 강제되고, 트래픽 선택자(Traffic Selector)기능이 IKEv2에 의해 협상되지 않는다면 상호 운용성 측면에서 문제가 생길 것이다.)
IPSec 방화벽 기능은 강제 암호화된 인증과 무결성을 모든 IPSec 트래픽에게 제공할 수 있으며, 이것은 방화벽에 암호화에 의한 보호를 더하는 것 보다 나을 것이다.

IPSec이 성공적으로 적용되고 배포된 뒤, IPSec의 보호를 적용받지 않는 유저와 호스트, 그리고 다른 네트워크 구성요소들에게 영향을 미쳐서는 안 된다. AH와 ESP, 그리고 필요하다면 IKE는 독립적인 암호화 알고리즘으로 개발되었으며, 이것은 다른 구현 부분에 영향을 미치지 않고 적절한 암호화 알고리즘을 선택할 수 있도록 한다. 광역 인터넷에서의 상호 운용성을 만족하기 위하여, AH와 ESP에 쓰이는 기본 암호화 알고리즘이 RFC 4305에 정의되었다. 그리고 IKEv2를 위해 반드시 구현되어야 하는 암호화 알고리즘이 RFC 4307에 정의되었다. 이 알고리즘들은 암호화 기술의 발전에 따라 주기적으로 업데이트 될 수 있으며, 이러한 표준 암호화 알고리즘들을 분리함으로써 각 프로토콜들은 서로에게 영향을 미치지 않고 알고리즘을 갱신할 수 있다.

 

IPSec 보안 서비스는 IP레이어에서 Security Protocol, 암호화 알고리즘과 암호화 키를 선택할 수 있게 한다. IPSec은 (1) 호스트와 호스트 간의 경로를 보호하거나, (2) 보안 게이트웨이 사이의 연결을 보호하거나, (3) 보안 게이트웨이와 호스트 사이의 연결을 보호할 수 있다. 호스트 구현체들은 반드시 (1)(3)을 구현해야 하며, 보안 게이트웨이의 구현체는 3가지의 연결을 모두 구현해야 한다.
앞서 말했듯이 IPSec은 보안 기능을 제공하기 위해 AH, ESP 프로토콜을 사용하는데, 각각의 역할은 다음과 같다.

– AH(Authentication Header) : 무결성과 데이터 출처 인증을 제공한다. 옵션으로 재전송 공격을 차단하는 기능을 제공한다(수신자 단에서 구현한다)
– ESP(Encapsulating Security Payload) : AH의 기능과 더불어 기밀성을 제공한다. 무결성 없이 기밀성을 사용하는 것은 권장되지 않는다. 그리고 ESP의 기밀성이 활성화되면 제한된 트래픽 흐름 기밀성을 제공한다. 예를 들어 패킷 길이를 감추고, 효율적으로 더미 패킷을 생성하고 파기할 수 있다.

AH와 ESP 모두 접근 제어를 제공한다. 이것은 SPD(Security Policy Database)에 서술되어 있는 암호화 키의 분배와 프래픽 흐름 관리에 의해 강제된다.
두 프로토콜들은 모두 개별/통합적으로 제공될 수 있다. 하지만 대부분의 경우 ESP만을 사용하는 것으로 보안 요구사항이 충족될 것이다.
그리고 각 프로토콜들은 Transport Mode와 Tunnel Mode를 지원한다. Transport 모드의 경우 AH와 ESP는 다음 레이어의 프로토콜에 보안성을 제공한다. 그리고 Tunnel 모드에서는 IP 자신도 함께 보호한다.
이 두 모드의 차이점에 대해서는 추후 좀 더 자세히 다루겠다.

IPSec에서 제공하는 대부분의 보안 기능들이 암호화 키를 필요로 하기에, IPSec은 적절한 곳에 적절한 키를 입력해주는 매커니즘을 필요로 한다. IPSec은 수동과 자동 입력을 모두 지원하지만, 그 중 자동화된 공개키 기반의 키 관리 방법이 IKEv2로 정의되었으며, RFC 4306으로 배포되었다. 하지만 다른 자동 키 분배 메커니즘도 사용될 수 있을 것이다.

1-1.1. Security Associations

이 단락에서는 AH와 ESP를 포함한 IPv6, IPv4 구현체가 필요로 하는 IPSec fundamental에 대하여 다룬다. SA를 구성하기 위해 AH와 ESP가 사용되며, IKE의 주된 기능 또한 SA를 형성하고 유지하는 데 이용된다.
모든 AH와 ESP의 구현체는 SA의 개념을 만족해야 한다.
SA는 간단히 말해 보안 기능을 제공하고 트래픽을 옮기는 “연결”을 말한다. 보안 기능은 AH나 ESP를 사용함으로써 SA에 의해 제공되고, AH와 ESP의 보호가 동시에 적용되는 경우, 두 개의 SA가 형성되어 보호를 두 번 적용하는 것으로 동시에 사용된다. 일반적으로, 양방향 통신이 이루어질 때 한 쌍의 SA가 필요하다.

SA가 유니캐스트 트래픽 전달에 사용될 경우 SPI(Security Parameters Index)만으로 SA를 나타내기에 충분하다. 하지만 지역적인 문제로(SPI Collision?) IPSec 구현체들은 SA인증을 위해 SPI와 IPSec 프로토콜을 함께 사용해야 할 것이다. 만약 구현체가 멀티캐스트를 지원한다면, 그것은 멀티캐스트 SA를 지원하기 위해 de-multiplexing 알고리즘을 지원해야 한다.

많은 안전한 멀티캐스트 알고리즘들이 있지만, 그 중에서 RFC 3740에서 정의된 중앙 그룹 컨트롤러/일방적으로 할당된 GSA의 SPI를 가지는 키 서버 모델은 키 매니지먼트 서브시스템에 의해 협상될 수 없고, 그렇기에 GSA와 유니캐스트 SA가 동시에 같은 SPI를 사용할 수 있다. 멀티캐스트 지원 IPSec 구현체는 반드시 de-multiplex 인바운드 트래픽을 SPI 충돌이 발생하는 상황에서도 올바르게 전달하여야 한다.

 

여기서 IPSec에서 사용하는 데이터베이스의 개념을 짚고 가자.
IPSec은 크게 두 종류의 데이터베이스를 사용하는데, 하나는 SAD(Security Association Database), 다른 하나는 SPD(Security Policy Database)이다.

SAD는 SA의 집합체인데, IPSec이 적용되는 특정 Connection에 대하여 SA가 정의되고, 그것의 집합이 SAD가 된다. Incoming, Outgoing 트래픽에 따라 각각 정의된다.
SAD에는 다음과 같은 내용이 포함된다.

– AH Parameter : AH 사용시 이와 관련된 인증 알고리즘 및 관련 Key
– ESP Parameter : ESP 사용시 이와 관련된 인증 알고리즘 및 관련 Key
– Mode : Transport Mode / Tunnel Mode
– Destination IP Addr, IPSec Protocol (AH or ESP), SPI : SPI는 하나의 목적지에 대해 다수의 SA가 정의되어 있을 경우 사용하는 식별자(Index)이다.
– Lifetime : SA의 생존시간

SPD는 System Manager에 의해 정의되며, 어떠한 트래픽에 IPSec 서비스가 적용될지 정의한다. 참고로 IPSec의 동작에는 Discard, Protection, Passthrough가 있음을 미리 밝혀 둔다.
이러한 Policy의 적용은 다음과 같은 항목에 의하여 결정된다.

– Source / Destination Address
– Name : DNS 사용자 식별자 / FQDN
– Transport Layer Protocol : TCP or UDP
– Source / Destination Port

SPD는 조건에 맞는 SAD의 SA들을 지정하고, 트래픽이 IPSec 레이어를 통과할 때 정책을 적용한다.

다시 원점으로 돌아가, SAD의 각 엔트리는 반드시 Source/Destination IP Address를 표시해야 한다. 이것은 멀티캐스트의 경우 SPI가 중복될 수 있기 때문에, SPI가 중복될 경우 Destination IP Address로 목적지를 결정하기 위함이다.
이렇게 SA와 Source-Destination Address를 매칭하는 것은 들어오는 IPSec 트래픽과 SA를 매핑해야 한다는 것을 의미한다.

그리고 제한적인 QoS의 경우, DSCP(Differentiated Service Code Point) 비트가 같은 SA로 전송되고, 수신자가 재전송 방지 기능을 AH와 ESP에서 활성화해 놓았다면 그 결과 더 낮은 우선순위의 패킷이 Windowing 메커니즘에 의해 파기되게 된다.
그렇기 때문에 송신자는 반드시 트래픽을 다른 클래스로 보내고, 같은 셀렉터 값을 지정한 뒤 다른 SA를 할당해야 한다. 이 기능을 지원하기 위해 IPSec 구현체는 송신자와 수신자 사이에 다수의 SA를 만들고 유지할 수 있어야 한다.
이러한 병렬 SA를 통한 트래픽 분산은 송신자에 의해 지엽적으로 결정되며, IKE에 의한 교섭을 거치지 않는다. 수신자는 다른 SA들로 들어오는 트래픽을 편견 없이 처리해야 한다.

앞서 서술했듯이, Transport Mode와 Tunnel Mode. 두 종류의 SA가 정의된다. IKE가 한 쌍의 SA를 만들고, 처리의 단순화를 위해 한 쌍의 SA는 반드시 같은 모드여야만 한다.
Transport Mode SA는 주로 한 쌍의 호스트가 종단간 보안을 제공해야 할 경우 사용된다. Transport Mode가 Security Gateway간, Host-Security Gate간에서 사용될 경우 Transport Mode는 in-IP Tunneling이나 GRE(Generic Routing Encapsulation)을 사용할 것이다. 상황을 명확하게 하기 위해, Intermediate System에 의한 Transport Mode 사용은 인바운드의 Destination Address 아웃바운드의 Source Address가 Intermediate System에 속해있는 경우로 한한다. 그리고 Transport Mode의 경우 종단간 패킷 헤더에는 적용되지 않는다. 그러므로 이 모드의 IPSec은 신중히 적용되어야 할 것이다.

Tunnel Mode SA의 경우,  SA는 IP tunnel을 적용받는다. 접근 제어가 헤더와 트래픽에 모두 적용되며, 두 호스트는 반드시 서로에게 Tunnel SA를 만들어야 한다. 아래의 두 예외를 제외하고, Tunnel SA의 종단은 Security Gateway가 된다. 그러므로 두 Security Gateway 사이의 연결은 보통 Tunnel Mode SA이며, 그렇지 않은 두 종류의 예외는 다음과 같다.

–  트래픽이 Security Gateway를 지나갈 때 : 예를 들어 SNMP 프로토콜의 경우 Security Gateway가 호스트처럼 동작하고, Transport Mode가 허용된다. 이 경우 SA는 Security Gateway내의 호스트(매니지먼트) 기능에서 종단된다.
– 앞서 말했듯이 Security Gateway들은 경로 상의 IP 트래픽에게 보안을 제공하기 위하여 Transport Mode를 지원할 수 있다.

이러한 보안 서비스의 집합들은 SA 모드와 프로토콜의 선택에 달렸다.
예를 들어, AH와 ESP 둘 다 무결성과 인증 기능을 제공하지만, 적용 범위는 각각의 프로토콜마다 다르며, Transport/Tunnel 모드에 따라서도 다르다. 만약 IPv4옵션과 IPv6 확장 헤더의 무결성이 보장되어야 한다면, 옵션이 예키치 못하게 수정될 수 있는 AH 대신 ESP를 사용해야 할 것이다.
접근 제어를 쪼개보면, 가장 먼저 어떠한 셀렉터를 고르느냐에 따라 결정된다. 예를 들어, IKE와 Child에 따라서 다른 접근 제어 방법을 가진다.

일단 암호화에 사용되는 프로토콜이 결정되면, ESP SA는 양쪽 끝단에서 부분적인 트래픽 흐름 기밀성을 제공할 수 있다. 터널 모드를 사용하는 것은 내부 IP 헤더를 암호화하고, 트래픽의 발신지와 수신지를 감춘다. 거기에 ESP 페이로드의 패딩은 패킷 사이즈를 감추어 트래픽의 특정을 어렵게 만들 수도 있다.
IPSec 구현체들은 반드시 ESP SA가 암호화와 무결성 알고리즘을 사용하지 않고는 설정될 수 없도록 만들어야 한다.

 

1-1.2. AH(Authentication Header)

AH는 IP Extension Header로서, IP Packet에 대한 인증을 제공한다. 암호화를 수행하지 않기에 데이터그램의 기밀성은 보장하지 않으며, 앞서 말했듯이 IP 패킷 인증, 무결성 검증, 출발지 기반 인증과 재전송 공격의 방어를 제공할 수 있다.

IPSec Transport Mode와 Tunnel Mode에서의 패킷 구조를 나타낸 것이다. Transport Mode를 사용할 경우 IPv4 헤더의 뒤에 AH가 오고, Tunnel Mode를 사용할 경우 IPv4 헤더의 앞에 위치하여 IPv4 데이터그램을 캡슐화한다.

AH의 상세 구조를 나타낸 것이다. Payload Length는 IPv4 페이로드의 길이를, SPI는 앞서 설명한 SA 식별자를, Sequence Number는 AH Processing을 수행할 때마다 1씩 증가하며, 재전송 공격의 방어에 사용된다.
마지막으로 Authentication Data는 패킷 데이터 전체에 대한 해쉬 값으로, 변하기 쉬운(Mutable) 값들은 0으로 세팅하여 계산한다.

1-1.3. ESP(Encapsulating Security Payload)

ESP는 AH의 기능에 덧붙여 암호화를 제공한다. 때문에 대부분의 IPSec 연결들은 ESP를 사용하며, VPN에서 사용되는 것도 ESP이다.

ESP 또한 Transport Mode와 Tunnel Mode를 지원한다. AH와는 달리 ESP 헤더가 오고, ESP Auth Data가 마지막에 위치하는 것을 알 수 있다. 이는 ESP 헤더 ~ ESP Auth Data 사이의 페이로드만이 암호화 되기 때문이다.

ESP 패킷의 상세 구조이다. 페이로드 뒤에 패딩이 오고, 패딩을 포함하여 암호화를 하는 것에 주목하자. 패딩이 적용될 경우 원본 데이터그램의 길이를 유추하는 것이 불가능하기에 패킷 분석에 어려움을 더한다.
따라서 공격자로부터 더 안전한 프로토콜이 되겠다.

1-2. PPTP

PPTP는 인터넷의 초창기에 등장한 암호화 프로토콜로, Microsoft와 Ascend Communications, 3Com에 의하여 개발되었다.
PPTP의 프로토콜 명세는 1999년, RFC 2637로 배포되었으며, Microsoft Windows에 기본적으로 내장되어 있기에 가장 널리 쓰이는 VPN 프로토콜이 되었다.

하지만 RC4 해쉬 알고리즘이 Bias를 가진다는 것이 널리 알려져 있으며, 인증 프로토콜로 사용되었던 MS-CHAPv1이 56-Bit DES 암호화를 사용하기에 현대의 컴퓨팅 기술로는 비밀키를 손쉽게 추론할 수 있게 되어서 더 이상 안전하지 않은 프로토콜로 분류, IPSec, L2TP 등의 더 안전한 프로토콜을 사용할 것을 권고하고 있다.

 

PPTP는 터널 형성을 위해 PPP(Point-to-Point Protocol)과 GRE(Generic Routing Encapsulation)을 사용한다.
PPP가 Data-Link 계층에서 사용하기 위해 개발되었기에, PPP를 캡슐화하기 위해서 GRE가 사용되며, IP 패킷은 PPP로 캡슐화된 뒤 GRE로 다시 캡슐화된다. 따라서 아래와 같은 패킷 구조를 갖는다.

그리고 PPTP는 데이터 전송 채널과 제어 채널이 분리되어 있는데, 제어 채널은 TCP 연결을 사용하고, 캡슐화되지 않는다.

그리고 GRE-PPP만으로는 터널은 구성되지만 페이로드에 대한 암호화가 수행되지 않기에, 따로 MPPE(Microsoft Point-to-Point Encryption)을 이용하여 암호화를 수행한다.
MPPE는 RFC 3078로 출판되었으며, PPP Payload에 대한 암호화를 수행한다.

MPPE는 Keberos나 TLS 등의 방법으로 세션 키를 교환하고, 세션 키를 이용해 RC4 암호화를 수행함으로써 동작한다.

우분투에 OpenVPN 서버 설치하기

 

사용 환경: Ubuntu 14.0.4 LTS, OpenVPN 2.3.2-7

 

OpenVPN 2.3부터 Easy-RSA가 다른 프로젝트로 떨어져 나가면서 OpenVPN을 설치할 때 함께 설치되지 않게 되었다.

때문에, 먼저 apt-get install easy-rsa 로 Easy-RSA를 설치해 준다.

 

Easy-RSA 설치가 끝난 뒤, /usr/share/easy-rsa/ 로 이동하고, vars 파일을 입맛에 맞게 수정해 준다.

그리고 다음과 같은 명령어를 입력한다.

 

 

이제 keys 폴더 안에 다음과 같은 파일들이 생성되었을 것이다.

이 중 ca.crt, <서버 이름>.crt, <서버 이름>.key,dh2048.pem 이 서버에서 사용되는 파일들이다.

cp -r keys /etc/openvpn  을 입력, 키 파일들을 복사한다.

apt-get install openvpn  을 입력하어 OpenVPN을 설치한다.

 

openvpn의 설정 파일 샘플은 /usr/share/doc/openvpn/samples/ 에 있다.

이 폴더에서 gzip -d server.conf.gz 를 입력, 설정 파일의 압축을 푼다.

 

vi server.conf 를 입력, 설정 파일의 값을 적절하게 수정한다. 그리고 수정이 완료된 설정 파일을 /etc/openvpn 으로 복사한다.

 

OpenVPN 서버의 실행은 openvpn <설정 파일 경로> 를 통하여 이루어진다.

OpenVPN 서버를 실행한 뒤, 리눅스 커널에서 IP 포워딩을 활성화하기 위하여 echo 1 > /proc/sys/net/ipv4/ip_forward 를 입력한다.

이 설정을 시스템 재시작 시에도 유지하기 위해 sysctl.conf를 수정한다.

시스템 시작 시 OpenVPN 서비스를 자동으로 실행하기 위해서 rc.local을 수정한다.

이 때 주의할 점은, rc.local에 등록된 스크립트는 root로 실행이 된다는 것이다. 비특권 유저로 실행하고 싶다면 이 포스팅을 참조하길 바란다.

ca.key, <클라이언트 키 이름>.key는 클라이언트의 접속에 필요한 키 파일들이다.