Ubuntu에서 WireGuard 설정하는 방법

소개

WireGuard는 IPv4와 IPv6 연결을 모두 지원하는 경량 가상 사설망(VPN)입니다. VPN은 신뢰할 수 없는 네트워크를 마치 사설 네트워크인 것처럼 통과할 수 있게 해줍니다. 이를 통해 공용 WiFi를 포함한 신뢰할 수 없는 네트워크에 연결된 경우에도 노트북이나 휴대폰과 같은 장치에서 보다 안전하게 인터넷에 접속할 수 있습니다.

WireGuard의 암호화는 피어들이 서로 암호화된 터널을 설정할 수 있도록 공개 키와 개인 키에 기반합니다. 각 WireGuard 릴리스는 고정된 최신 암호화 방법 세트를 사용하여 프로토콜을 단순하고 예측 가능하게 유지합니다. 이러한 설계는 런타임 협상을 피하고 구성 오류의 위험을 줄입니다.

이에 비해, 다른 VPN 소프트웨어인 OpenVPN과 IPsec은 전송 계층 보안(TLS)과 인증서를 사용하여 인증하고 암호화된 터널을 설정합니다. 이러한 접근 방식은 유연성을 제공하고 다양한 클라이언트를 지원하지만, 구성의 복잡성을 높이고 운영 동작을 이해하기 어렵게 만들기도 합니다.

이 튜토리얼에서는 Ubuntu 서버에 WireGuard를 설정하고, 다른 컴퓨터가 IPv4와 IPv6를 모두 사용하여 피어로 연결하도록 구성하는 방법을 배우게 됩니다. 이를 일반적으로 듀얼 스택 구성이라고 합니다. 또한 게이트웨이 설정에서 피어 트래픽을 WireGuard 서버를 통해 라우팅하는 방법과, 암호화된 피어 투 피어 통신을 위해 VPN을 사용하는 방법도 배우게 됩니다.

핵심 설정 외에도, 이 가이드는 실제 배포에서 중요한 실용적인 주제를 다룹니다. 여기에는 WireGuard의 피어 투 피어 아키텍처 이해, 키 관리 및 교체, IPv6 및 이중 스택 라우팅 올바르게 처리, NAT 뒤에 있는 피어의 신뢰성 향상, 성능 최적화, 그리고 WireGuard가 전송 프로토콜 및 방화벽 동작 측면에서 OpenVPN과 어떻게 비교되는지 이해하는 내용이 포함됩니다.

이 튜토리얼의 목적상, 다른 Ubuntu 시스템이 WireGuard 피어로 사용됩니다. 이 시리즈의 이후 튜토리얼에서는 Windows, macOS, Android 및 iOS에서 WireGuard를 설치하고 사용하는 방법을 다룹니다.

전제 조건

이 튜토리얼을 따라하려면 다음이 필요합니다:

• sudo 권한이 있는 비루트 사용자와 방화벽이 활성화된 하나의 Ubuntu 서버. 이를 설정하려면, 우리 튜토리얼인 'Ubuntu 초기 서버 설정'을 따라 할 수 있습니다. 이 가이드 전체에서 이를 WireGuard 서버라고 부르겠습니다.

• WireGuard 서버에 연결하는 데 사용할 클라이언트 머신이 필요합니다. 이 튜토리얼에서는 이 머신을 WireGuard 피어라고 부르겠습니다. 이 튜토리얼의 목적상, 로컬 머신을 WireGuard 피어로 사용하는 것이 권장되지만, 원하면 원격 서버나 모바일 폰을 클라이언트로 사용할 수도 있습니다. 원격 시스템을 사용하는 경우, 나중에 나오는 선택적 섹션을 모두 따라야 시스템에 접근할 수 없는 상황을 피할 수 있습니다.

• WireGuard를 IPv6와 함께 사용하려면 서버가 해당 유형의 트래픽을 지원하도록 구성되어 있는지 확인해야 합니다. WireGuard에서 IPv6 지원을 활성화하고 Linux-Console.net Droplet을 사용 중이라면, 이 문서 페이지인 'Droplet에서 IPv6 활성화 방법'을 참고하시기 바랍니다. Droplet을 생성할 때 IPv6 지원을 추가하거나, 이후 해당 페이지의 지침을 따라 추가할 수 있습니다.

WireGuard 아키텍처 개요

WireGuard를 구성하기 전에, 시스템, 피어, 네트워크 트래픽이 어떻게 상호작용하는지 이해하는 것이 도움이 됩니다. WireGuard는 제어 평면, 인증서 기관, 구성 매개변수의 런타임 협상을 피하는 의도적으로 단순한 아키텍처를 사용합니다. 모든 암호화, 인증 및 라우팅 동작은 구성 파일을 통해 명시적으로 정의됩니다.

피어 투 피어 설계 및 토폴로지 용어

WireGuard는 근본적으로 피어 투 피어 프로토콜입니다. 모든 참여 시스템에서 동일한 WireGuard 소프트웨어와 커널 모듈이 실행되며, 별도의 서버나 클라이언트 바이너리는 없습니다.

이 튜토리얼에서 WireGuard 서버라는 용어는 허브 앤 스포크(hub-and-spoke) 토폴로지에서 중앙 허브를 의미합니다. 이 시스템은 공개적으로 접근 가능하며 다른 피어들을 조정하는 중심점 역할을 합니다. WireGuard 피어라는 용어는 이 허브에 연결되는 장치를 의미합니다. 이러한 용어들은 이 가이드에서 사용되는 네트워크 토폴로지를 설명하는 것이며, 서로 다른 소프트웨어 역할이나 기능을 의미하지 않습니다.

이 구분을 이해하는 것은 중요합니다. 왜냐하면 WireGuard에는 서버 전용 구성 옵션이 없기 때문입니다. 모든 시스템은 키, 주소 및 라우팅 규칙이 어떻게 정의되느냐에 따라 허브, 스포크, 또는 두 가지 모두로 작동할 수 있습니다.

WireGuard 배포의 핵심 구성 요소

WireGuard 배포는 각각 특정한 책임을 가진 소수의 명확하게 정의된 구성 요소로 이루어져 있습니다.

• 중앙 피어(허브): 중앙 피어는 단일 포트에서 암호화된 UDP 트래픽을 수신할 수 있는 공개 접근 가능한 시스템입니다. 이 시스템은 일반적으로 wg0라고 불리는 가상 터널 인터페이스를 호스팅하며, 통신이 허용된 다른 피어들의 공개 키를 저장합니다. 허브는 피어를 동적으로 탐지하지 않으며, 연결을 암묵적으로 수락하지 않습니다. 트래픽은 공개 키와 허용된 IP 범위가 명시적으로 구성된 피어로부터만 수락됩니다.

• 피어 연결(스포크): 피어를 연결하는 장치는 중앙 피어와 암호화된 터널을 설정하는 장치입니다. 이러한 장치는 노트북, 서버, 가상 머신 또는 모바일 시스템일 수 있습니다. 각 피어는 고유한 암호 키 쌍과 터널 인터페이스에 할당된 하나 이상의 사설 IP 주소를 가지고 있습니다. 피어는 라우팅 규칙이 그렇게 지시할 때만 트래픽을 터널로 전송합니다.

• 터널 인터페이스 (wg0): 터널 인터페이스는 각 참여 시스템에서 생성되는 가상 네트워크 장치입니다. 모든 암호화된 트래픽은 이 인터페이스를 통해 들어오고 나갑니다. 운영 체제 관점에서 wg0는 일반 네트워크 인터페이스처럼 동작하여 일반적인 라우팅 테이블, 방화벽 규칙 및 포워딩 동작이 적용될 수 있습니다.

암호화, 인증, 그리고 핸드셰이크

WireGuard는 공개 키 암호화를 사용하여 피어를 인증하고 트래픽을 암호화합니다. 각 피어는 로컬 시스템에만 남아 있으며 절대 전송되지 않는 장기 비밀 키를 생성합니다. 해당 공개 키는 다른 피어와 공유되며 그들의 구성에 추가됩니다.

통신이 시작되면 WireGuard는 Noise 프로토콜 프레임워크를 기반으로 조용하고 자동적인 암호화 핸드셰이크를 수행합니다. 이 핸드셰이크는 일시적인 세션 키를 설정하고 완전한 전방 비밀성을 제공합니다. 이러한 세션 키는 사용자 개입 없이 주기적으로 교체됩니다.

WireGuard는 암호 모음, 인증 방법 또는 프로토콜 버전을 협상하지 않습니다. 모든 암호학적 원시 요소는 설계상 고정되어 있습니다. 이는 현대적인 보안 보장을 제공하면서도 전체 구성 오류 범위를 제거합니다.

지원되는 트래픽 흐름 패턴

WireGuard는 라우팅과 포워딩 설정 방식에 따라 여러 트래픽 패턴을 지원합니다. 이 튜토리얼은 가장 일반적인 두 가지 사용 사례에 중점을 둡니다.

피어 투 피어 또는 내부 네트워크 액세스

피어 투 피어 또는 내부 액세스 구성에서는 VPN의 일부인 시스템 간에만 트래픽이 암호화됩니다. 중앙 피어는 안전한 엔드포인트 또는 중계 역할을 하지만, 외부 네트워크로 트래픽을 전달하지는 않습니다.

이 구성은 일반적으로 사설 서비스에 접근하거나, 인프라를 관리하거나, 격리된 시스템에 연결하는 데 사용됩니다. 트래픽은 대상 주소가 피어의 구성에 정의된 사설 IP 범위와 일치할 때만 터널로 라우팅됩니다.

VPN 게이트웨이 모드

게이트웨이 모드에서 중앙 피어는 다른 피어들로부터의 트래픽을 공용 인터넷을 포함한 외부 네트워크로 전달합니다. 피어들은 일부 또는 전체 트래픽을 터널로 전송하며, 중앙 피어는 IP 포워딩과 네트워크 주소 변환을 사용하여 그 트래픽을 전달합니다.

이 구성에는 커널 포워딩 및 방화벽 규칙을 포함한 추가 시스템 설정이 필요합니다. 게이트웨이 모드를 활성화하면 피어에서 나가는 트래픽이 중앙 피어의 공인 IP 주소에서 시작된 것으로 나타납니다.

AllowedIPs의 이중 역할

AllowedIPs 지시어는 WireGuard에서 두 가지 구별된 목적을 제공합니다.

먼저, 아웃바운드 라우팅 동작을 정의합니다. 패킷의 목적지 주소가 AllowedIPs의 항목과 일치하면, 해당 패킷은 WireGuard 터널을 통해 라우팅됩니다.

둘째, AllowedIPs는 엄격한 인바운드 접근 제어 목록 역할을 합니다. 피어로부터 패킷을 수신하면 WireGuard는 패킷의 출발지 IP 주소를 확인합니다. 출발지 주소가 해당 피어의 AllowedIPs에 나열되어 있지 않으면 패킷은 즉시 삭제됩니다.

이중 역할은 의도된 것이며 구성 오류가 발생하는 가장 일반적인 원인 중 하나입니다. 올바른 라우팅만으로는 충분하지 않습니다. 피어가 사용할 수 있는 소스 IP 주소도 명시적으로 허용되어야 합니다.

라우팅 자동화 및 도우미 도구

WireGuard 커널 모듈 자체는 시스템 경로나 DNS 설정, 방화벽 규칙을 변경하지 않습니다. 이 모듈은 단지 패킷을 암호화하고 복호화하며 피어와 연결하는 기능만 수행합니다.

라우팅 자동화는 wg-quick과 같은 도우미 도구에 의해 처리됩니다. 이 유틸리티는 WireGuard 구성 파일을 읽고 터널이 올라가거나 내려갈 때 필요한 라우팅 테이블 항목, DNS 설정 및 방화벽 규칙을 적용합니다.

WireGuard가 raw wg 명령어, systemd-networkd 또는 사용자 지정 스크립트와 같은 대체 도구를 사용하여 구성된 경우, 이러한 라우팅 변경 사항은 수동으로 관리해야 합니다.

이 분리는 핵심 프로토콜을 간단하게 유지하면서도 다양한 시스템 네트워킹 스택과 유연하게 통합될 수 있게 합니다.

1단계 — WireGuard 설치 및 키 쌍 생성

이 튜토리얼의 첫 번째 단계는 서버에 WireGuard를 설치하는 것입니다. 시작하려면 WireGuard 서버의 패키지 인덱스를 업데이트하고 다음 명령어를 사용하여 WireGuard를 설치하세요. 이 세션에서 처음으로 sudo를 사용한다면 sudo 사용자 비밀번호를 입력하라는 메시지가 나타날 수 있습니다:

sudo apt update

sudo apt install wireguard

이제 WireGuard를 설치했으므로 다음 단계는 서버용 개인 키와 공개 키 쌍을 생성하는 것입니다. 내장된 wg genkey 및 wg pubkey 명령어를 사용하여 키를 생성한 후, 개인 키를 WireGuard 구성 파일에 추가하면 됩니다.

생성한 키 파일은 기본적으로 서버의 모든 사용자가 읽을 수 있으므로, chmod 명령어를 사용하여 권한을 변경해야 합니다.

아래 명령어를 사용하여 WireGuard용 개인 키를 생성하고 권한을 변경하세요:

wg genkey | sudo tee /etc/wireguard/private.key

sudo chmod go= /etc/wireguard/private.key

sudo chmod go=... 명령어는 루트 사용자 외의 사용자와 그룹에 대한 파일 권한을 제거하여 루트 사용자만 비공개 키에 접근할 수 있도록 합니다.

개인 키인 base64 인코딩 출력이 한 줄로 표시될 것입니다. 출력물의 사본은 명령어의 tee 부분에 의해 나중에 참조할 수 있도록 /etc/wireguard/private.key 파일에도 저장됩니다. 출력된 개인 키를 잘 기록해 두세요. 이후 이 섹션에서 WireGuard 구성 파일에 추가해야 합니다.

다음 단계는 개인 키에서 파생된 해당 공개 키를 생성하는 것입니다. 다음 명령어를 사용하여 공개 키 파일을 생성하세요:

sudo cat /etc/wireguard/private.key | wg pubkey | sudo tee /etc/wireguard/public.key

이 명령어는 | (파이프) 연산자를 사용하여 연결된 세 개의 개별 명령어로 구성됩니다:

• sudo cat /etc/wireguard/private.key: 이 명령어는 개인 키 파일을 읽어 표준 출력 스트림으로 출력합니다.
• wg pubkey: 두 번째 명령어는 첫 번째 명령어의 출력을 표준 입력으로 받아 처리하여 공개 키를 생성합니다.
• sudo tee /etc/wireguard/public.key: 마지막 명령어는 공개 키 생성 명령어의 출력을 받아서 /etc/wireguard/public.key라는 파일로 보내는 역할을 합니다.

명령어를 실행하면 다시 한 줄로 된 base64 인코딩 출력이 표시되며, 이는 WireGuard 서버의 공개 키입니다. 서버에 연결되는 모든 피어에게 공개 키를 배포해야 하므로, 나중에 참고할 수 있도록 어딘가에 복사해 두세요.

2단계 — IPv4 및 IPv6 주소 선택

이전 섹션에서는 WireGuard를 설치하고 서버와 주고받는 트래픽을 암호화하는 데 사용할 키 쌍을 생성했습니다. 이번 섹션에서는 서버용 구성 파일을 만들고, 서버가 재부팅될 때 WireGuard가 자동으로 시작되도록 설정할 것입니다. 또한 WireGuard 서버와 피어에서 사용할 사설 IPv4 및 IPv6 주소도 정의할 것입니다.

IPv4와 IPv6 주소를 모두 사용하려는 경우, 두 섹션 모두를 따르세요. 그렇지 않으면, VPN 네트워크 요구에 맞는 적절한 섹션의 지침을 따르세요.

2단계(a) — IPv4 범위 선택

IPv4 피어와 함께 WireGuard 서버를 사용하고 있는 경우, 서버는 클라이언트와 터널 인터페이스에 사용할 사설 IPv4 주소 범위가 필요합니다. 다음의 예약된 주소 블록 중에서 원하는 IP 주소 범위를 선택할 수 있습니다(이 블록이 어떻게 할당되는지 자세히 알고 싶다면 RFC 1918 명세서를 참조하세요):

• 10.0.0.0 부터 10.255.255.255 까지 (10/8 프리픽스)
• 172.16.0.0부터 172.31.255.255까지 (172.16/12 프리픽스)
• 192.168.0.0에서 192.168.255.255까지 (192.168/16 프리픽스)

이 튜토리얼의 목적을 위해 우리는 예약된 IP의 첫 번째 범위에서 10.8.0.0/24를 IP 주소 블록으로 사용할 것입니다. 이 범위는 최대 255개의 서로 다른 피어 연결을 허용하며, 일반적으로 다른 사설 IP 범위와 겹치거나 충돌하는 주소가 없어야 합니다. 이 예제 범위가 네트워크에 맞지 않는 경우, 네트워크 구성에 맞는 주소 범위를 자유롭게 선택하셔도 됩니다.

WireGuard 서버는 개인 터널 IPv4 주소를 위해 해당 범위에서 단일 IP 주소를 사용합니다. 여기서는 10.8.0.1/24를 사용하지만, 10.8.0.1부터 10.8.0.255 범위 내의 어떤 주소도 사용할 수 있습니다. 10.8.0.1/24와 다른 주소를 사용하는 경우 선택한 IP 주소를 기록해 두십시오. 이 IPv4 주소는 WireGuard 서버 구성 만들기에서 정의한 구성 파일에 추가하게 됩니다.

2단계(b) — IPv6 범위 선택

IPv6과 함께 WireGuard를 사용하고 있다면, RFC 4193의 알고리즘을 기반으로 고유한 로컬 IPv6 단일주소 프리픽스를 생성해야 합니다. WireGuard에서 사용하는 주소는 가상 터널 인터페이스와 연결됩니다. 개인 IPv6 주소의 예약된 fd00::/8 블록 내에서 무작위로 고유한 IPv6 프리픽스를 생성하려면 몇 가지 단계를 완료해야 합니다.

RFC에 따르면, 고유한 IPv6 프리픽스를 얻는 권장 방법은 하루 중 시간을 시스템의 시리얼 번호나 장치 ID와 같은 고유 식별 값과 결합하는 것입니다. 그런 다음 해당 값들을 해싱하고 잘라낸 결과, IP의 예약된 프라이빗 fd00::/8 블록 내에서 고유 주소로 사용할 수 있는 비트 집합이 생성됩니다.

WireGuard 서버용 IPv6 범위를 생성하려면, 다음 명령어를 사용하여 date 유틸리티로 64비트 타임스탬프를 수집하세요:

date +%s%N

다음과 같은 숫자를 받게 되며, 이는 1970-01-01 00:00:00 UTC 이후의 초 수(date 명령어의 %s)와 나노초(%N)가 함께 합쳐진 값입니다:

1628101352127592197

나중에 이 섹션에서 사용할 수 있도록 값을 어딘가에 기록하세요. 다음으로, 서버의 /var/lib/dbus/machine-id 파일에서 machine-id 값을 복사하세요. 이 식별자는 시스템별로 고유하며 서버가 존재하는 동안 변경되지 않아야 합니다.

cat /var/lib/dbus/machine-id

다음과 같은 출력 결과를 받게 됩니다:

/var/lib/dbus/machine-id
20086c25853947c7aeee2ca1ea849d7d

이제 타임스탬프를 machine-id와 결합하고 SHA-1 알고리즘을 사용하여 결과 값을 해시해야 합니다. 명령어는 다음 형식을 사용합니다:

printf <timestamp><machine-id> | sha1sum

타임스탬프와 기기 식별값을 대체하여 명령을 실행하세요:

printf 162810135212759219720086c25853947c7aeee2ca1ea849d7d | sha1sum

다음과 같은 해시 값을 받게 됩니다:

4f267c51857d6dc93a0bca107bca2f0d86fac3bc  -

출력 결과는 sha1sum 명령어가 16진수로 나타내기 때문에, 출력에서 하나의 바이트를 나타내기 위해 두 글자를 사용합니다. 예를 들어, 예제 출력에서 4f와 26은 해시된 데이터의 첫 번째 두 바이트입니다.

RFC의 알고리즘은 해시된 출력의 가장 하위(뒤쪽) 40비트, 즉 5바이트만 필요로 합니다. 해시에서 마지막 5바이트를 16진수로 출력하려면 cut 명령어를 사용하세요:

printf 4f267c51857d6dc93a0bca107bca2f0d86fac3bc | cut -c 31-

-c 인수는 cut 명령어가 지정된 문자 집합만 선택하도록 지시합니다. 31- 인수는 cut가 입력 라인의 31번째 위치부터 끝까지 모든 문자를 출력하도록 지시합니다.

다음과 같은 출력을 받게 될 것입니다:

0d86fac3bc

이 예제 출력에서 바이트 집합은 다음과 같습니다: 0d 86 fa c3 bc.

이제 생성한 5바이트를 fd 접두사와 결합하고, 가독성을 위해 각 2바이트마다 : 콜론으로 구분하여 고유한 IPv6 네트워크 접두사를 구성할 수 있습니다. 고유 접두사의 각 서브넷은 총 18,446,744,073,709,551,616개의 가능한 IPv6 주소를 가질 수 있으므로, 단순화를 위해 서브넷을 표준 크기인 /64로 제한할 수 있습니다.

이전에 /64 서브넷 크기로 생성된 바이트를 사용하면 결과 접두사는 다음과 같습니다:

Unique Local IPv6 Address Prefix
fd0d:86fa:c3bc::/64

이 fd0d:86fa:c3bc::/64 범위는 서버와 피어 간 WireGuard 터널 인터페이스에 개별 IP 주소를 할당하는 데 사용됩니다. 서버에 IP를 할당하려면 마지막 :: 문자 뒤에 1을 추가하세요. 결과적으로 얻어지는 주소는 fd0d:86fa:c3bc::1/64가 됩니다. 피어들은 범위 내의 어떤 IP든 사용할 수 있지만, 보통 피어를 추가할 때마다 값이 1씩 증가합니다. 예를 들어 fd0d:86fa:c3bc::2/64 같은 경우입니다. IP를 메모하고 다음 튜토리얼 섹션에서 WireGuard 서버 설정을 진행하세요.

IPv6 및 듀얼 스택 구성 고려 사항

이 튜토리얼의 기존 단계에서는 IPv6 주소를 생성하고 이를 WireGuard 인터페이스에 할당하는 방법을 설명합니다. 그러나 WireGuard에서의 IPv6 동작은 특히 WireGuard를 VPN 게이트웨이로 사용할 때 IPv4와 여러 중요한 점에서 다릅니다. 이러한 차이를 이해하면 라우팅 실패, 부분 터널링, 일반적인 IPv6 누출을 방지하는 데 도움이 됩니다.

WireGuard에서의 IPv6 지원

WireGuard는 IPv6를 일급 프로토콜로 지원합니다. IPv6 트래픽은 IPv4 트래픽과 동일한 메커니즘을 사용하여 암호화, 인증 및 라우팅됩니다. 별도의 IPv6 모드나 추가 구성 플래그가 필요하지 않습니다. 터널 인터페이스에 IPv6 주소가 할당되고 라우팅 규칙이 허용되면 IPv6 트래픽은 자동으로 터널을 통해 흐릅니다.

IPv4와 달리, IPv6는 전역 라우팅 가능한 주소를 사용하여 NAT를 피하도록 설계되었지만, 실제로 많은 VPN 및 클라우드 환경에서는 운영상의 단순화를 위해 여전히 NAT를 사용합니다. 그러나 이러한 동작은 네트워크 환경에 따라 달라집니다. 클라우드 VPS 인스턴스나 가정용 라우터와 같은 많은 VPN 게이트웨이 설정에서는 서버가 VPN 피어로 라우팅할 수 있는 위임된 IPv6 프리픽스를 받지 못합니다.

이러한 일반적인 시나리오에서 피어들은 일반적으로 고유 로컬 주소(ULA) 범위에서 개인 IPv6 주소가 할당됩니다. 개인 IPv6 주소가 사용되고 서버가 해당 주소에 대한 라우팅 가능한 접두사를 가지고 있지 않은 경우에도 IPv6 마스커레이딩이 필요합니다. 이는 일반적으로 IPv4 마스커레이딩과 유사하게 ip6tables -t nat 규칙으로 구현되어 VPN 피어가 공용 인터넷에 접속할 수 있도록 합니다.

IPv6는 적절한 프리픽스 할당이 가능할 때 NAT를 완전히 피할 수 있습니다. 그러나 대부분의 단순 VPN 게이트웨이 배포는 여전히 라우팅 관리를 위해 IPv6 마스커레이딩에 의존합니다.

듀얼 스택 동작 설명

듀얼 스택 구성은 동일한 WireGuard 인터페이스에서 IPv4와 IPv6를 모두 활성화할 수 있게 합니다. 이 설정에서는 wg0 인터페이스에 하나의 IPv4 주소와 하나의 IPv6 주소가 할당되며, 각 프로토콜은 독립적으로 라우팅됩니다.

운영 체제는 IPv4와 IPv6 경로를 별도로 평가합니다. 피어가 IPv4 트래픽을 터널을 통해 성공적으로 라우팅하는 동안 IPv6 트래픽은 이를 우회할 수 있으며, 그 반대의 경우도 마찬가지입니다. 이러한 동작은 예상되는 것이며 거의 항상 WireGuard 자체의 문제가 아니라 구성 문제를 나타냅니다.

듀얼 스택 라우팅이 올바르게 작동하려면 여러 조건이 충족되어야 합니다. 서버와 피어 모두 WireGuard 인터페이스에 IPv4 및 IPv6 주소가 할당되어 있어야 합니다. AllowedIPs 지시문에는 IPv4 및 IPv6 범위가 모두 포함되어야 합니다. IP 포워딩은 IPv4와 IPv6 각각에 대해 별도로 활성화되어야 합니다. 방화벽 규칙은 두 프로토콜 모두에 대해 포워딩 및 반환 트래픽을 허용해야 합니다.

주소 할당 및 접두사 길이

IPv4의 경우 WireGuard 배포에서는 일반적으로 10.0.0.0/8 또는 192.168.0.0/16과 같은 사설 주소 범위를 사용합니다. 각 피어는 일반적으로 단일 IPv4 주소를 할당받습니다.

IPv6의 경우 VPN 네트워크를 /64 프리픽스로 정의하는 것이 일반적이며, 예를 들어 fd00::/64와 같이 설정합니다. 이더넷 네트워크는 이웃 탐지와 주소 자동 구성에 /64를 필요로 하지만, WireGuard는 3계층 포인트투포인트 인터페이스로 작동하며 이러한 메커니즘을 사용하지 않습니다.

이로 인해 각 피어에 /128 IPv6 주소(예: fd00::2/128)를 할당하는 것이 안전하며 종종 권장됩니다. /128 주소를 사용하면 엄격한 라우팅 동작이 보장되며, 피어가 적절한 라우팅 규칙 없이 서브넷의 다른 주소와 직접 통신하려는 시도를 방지할 수 있습니다.

네트워크를 /64로 정의하고 피어에게 /128 주소를 할당하면 명확성을 제공하고 모호한 라우팅을 피할 수 있습니다.

IPv6로 모든 트래픽 라우팅하기

WireGuard가 VPN 게이트웨이로 구성될 때, IPv6 트래픽도 IPv4 트래픽과 동일한 방식으로 명시적으로 라우팅되어야 합니다.

IPv4의 경우, 모든 트래픽을 라우팅할 때 0.0.0.0/0 접두사를 사용합니다. IPv6의 경우, 이에 해당하는 접두사는 ::/0입니다. 모든 트래픽을 VPN을 통해 라우팅하려면 두 접두사를 모두 포함해야 합니다.

만약 0.0.0.0/0만 구성되어 있다면, IPv4 트래픽은 VPN을 통해 전송되지만 IPv6 트래픽은 계속해서 로컬 네트워크 인터페이스를 사용합니다. 이러한 상황은 IPv6 누수로 알려져 있습니다. 이는 일반적으로 IPv4 트래픽은 보호되지만 DNS 쿼리, 웹 트래픽 또는 애플리케이션 연결이 IPv6를 통해 VPN을 우회하게 되는 결과를 초래합니다.

IPv6 누출은 혼란을 일으키는 흔한 원인이며, 듀얼 스택 네트워킹이 활성화된 경우 항상 테스트해야 합니다.

방화벽, 포워딩, 그리고 ICMPv6

IPv6 포워딩은 IPv4 포워딩과는 별도로 활성화해야 합니다. 하나를 활성화한다고 해서 다른 하나가 자동으로 활성화되지는 않습니다. 인터페이스 간 트래픽을 라우팅할 때 두 설정 모두 필요합니다.

방화벽 규칙은 IPv6에 대해서도 명시적으로 정의해야 합니다. ufw, iptables, nftables와 같은 도구는 IPv4와 IPv6를 별도의 규칙 집합으로 취급합니다. IPv6 규칙이 없으면 IPv4 연결이 정상적으로 작동하는 것처럼 보여도 트래픽이 조용히 차단될 수 있습니다.

ICMPv6 트래픽을 허용하는 것이 특히 중요합니다. IPv4와 달리 IPv6는 경로 MTU 검색(Path MTU Discovery)과 같은 필수 기능을 위해 ICMPv6에 의존합니다. ICMPv6가 차단되면 작은 패킷은 제대로 작동하는 것처럼 보여도, 큰 패킷을 전송할 때 연결이 멈추거나 실패할 수 있습니다.

일반적인 듀얼 스택 문제

듀얼 스택 WireGuard 배포에서는 여러 문제가 흔히 발생합니다. AllowedIPs 지시문에 IPv6 경로가 누락되어 IPv6 트래픽이 터널을 우회할 수 있습니다. 서버에서 IPv6 포워딩이 활성화되지 않아 트래픽이 터널 인터페이스를 벗어나지 못할 수 있습니다. 방화벽 규칙이 IPv4 트래픽은 허용하지만 IPv6 또는 ICMPv6 트래픽을 차단할 수 있습니다. DNS 리졸버가 IPv6 경로가 제대로 구성되지 않았음에도 IPv6 주소를 반환할 수 있습니다.

이러한 문제는 종종 간헐적 실패로 나타나며, 애플리케이션이나 프로토콜 문제로 잘못 진단되는 경우가 많습니다.

IPv4 전용, IPv6 전용, 듀얼 스택 중 선택하기

일부 환경에서는 단일 프로토콜을 사용하는 것이 운영을 간소화합니다.

IPv4 전용 배포는 기존 시스템 및 도구와 통합하기가 더 쉽습니다. IPv6 전용 배포는 IPv4 NAT가 필요 없고 주소 고갈을 피할 수 있지만, 공급자와 클라이언트 네트워크에서 일관된 IPv6 지원이 필요합니다.

듀얼 스택 배포는 가장 큰 유연성을 제공하지만, 가장 철저한 계획, 구성 및 검증도 필요합니다.

3단계 — WireGuard 서버 구성 만들기

WireGuard 서버의 구성을 만들기 전에 다음 정보를 준비해야 합니다:

• WireGuard 설치 및 키 쌍 생성에서 개인 키를 준비했는지 확인하세요.
• IPv4로 WireGuard를 사용하는 경우, IPv4 범위 선택에서 서버에 대해 선택한 IP 주소가 필요합니다. 이 예에서는 10.8.0.1/24입니다.
• 만약 IPv6와 함께 WireGuard를 사용하고 있다면, IPv6 범위 선택에서 생성한 서버의 IP 주소가 필요합니다. 이 예제에서 IP는 fd0d:86fa:c3bc::1/64입니다.

필요한 개인 키와 IP 주소를 확보한 후, 다음 명령어를 실행하여 nano 또는 선호하는 편집기를 사용해 새 구성 파일을 만드세요:

sudo nano /etc/wireguard/wg0.conf

다음 줄을 파일에 추가하고, 강조 표시된 base64_encoded_private_key_goes_here 값 대신 개인 키를 넣고, Address 줄에 IP 주소를 입력하세요. WireGuard를 다른 포트에서 사용하고 싶다면 ListenPort 줄도 변경할 수 있습니다:

/etc/wireguard/wg0.conf
[Interface]
PrivateKey = base64_encoded_private_key_goes_here
Address = 10.8.0.1/24, fd0d:86fa:c3bc::1/64
ListenPort = 51820
SaveConfig = true

SaveConfig 라인은 WireGuard 인터페이스가 종료될 때 모든 변경 사항이 구성 파일에 저장되도록 보장합니다.

/etc/wireguard/wg0.conf 파일을 저장하고 닫습니다. nano를 사용 중이라면 CTRL+X를 누른 후 Y와 ENTER를 눌러 확인할 수 있습니다. 이제 WireGuard VPN 서버를 어떻게 사용하려는지에 따라 확장할 수 있는 초기 서버 구성이 준비되었습니다.

4단계 — WireGuard 서버의 네트워크 구성 조정

만약 WireGuard를 사용하여 피어를 WireGuard 서버에 연결하고 서버에서만 서비스를 이용하려는 경우, 이 섹션을 완료할 필요가 없습니다. 하지만 WireGuard 피어의 인터넷 트래픽을 WireGuard 서버를 통해 라우팅하려는 경우, 이 튜토리얼의 이 섹션을 따라 IP 포워딩을 설정해야 합니다.

포워딩을 설정하려면 nano 또는 원하는 편집기를 사용하여 /etc/sysctl.conf 파일을 열십시오:

sudo nano /etc/sysctl.conf

IPv4를 사용하여 WireGuard를 사용하는 경우, 파일 맨 아래에 다음 줄을 추가하십시오:

net.ipv4.ip_forward=1

WireGuard에서 IPv6를 사용하는 경우, 파일 맨 아래에 이 줄을 추가하세요:

net.ipv6.conf.all.forwarding=1

IPv4와 IPv6를 모두 사용하고 있다면 두 줄 모두 포함되었는지 확인하세요. 완료되면 파일을 저장하고 닫으세요.

파일을 읽고 현재 터미널 세션에 새 값을 불러오려면 다음을 실행하십시오:

sudo sysctl -p

net.ipv6.conf.all.forwarding = 1
net.ipv4.ip_forward = 1

이제 WireGuard 서버는 가상 VPN 이더넷 장치에서 들어오는 트래픽을 서버의 다른 장치로 전달하고, 거기서부터 공용 인터넷으로 전달할 수 있습니다. 이 구성을 사용하면 WireGuard 피어의 모든 웹 트래픽을 서버의 IP 주소를 통해 라우팅할 수 있으며, 클라이언트의 공용 IP 주소는 사실상 숨겨지게 됩니다.

하지만 트래픽이 서버를 통해 올바르게 라우팅되기 전에 몇 가지 방화벽 규칙을 구성해야 합니다. 이러한 규칙은 WireGuard 서버와 피어 간의 트래픽이 제대로 흐르도록 보장합니다.

5단계 — WireGuard 서버 방화벽 구성

이 섹션에서는 WireGuard 서버의 구성을 편집하여 서버와 클라이언트 간의 트래픽이 올바르게 라우팅되도록 방화벽 규칙을 추가합니다. 이전 섹션과 마찬가지로, VPN을 통해 제한된 리소스에 접근하기 위한 기기 간 연결만 사용하는 경우에는 이 단계를 건너뛰어도 됩니다.

서버의 방화벽을 통해 WireGuard VPN 트래픽을 허용하려면, 클라이언트 연결을 올바르게 라우팅하기 위해 즉시 동적 네트워크 주소 변환(NAT)을 제공하는 iptables 개념인 마스커레이딩을 활성화해야 합니다.

먼저 ip route 하위 명령어를 사용하여 WireGuard 서버의 공개 네트워크 인터페이스를 찾으세요:

ip route list default

공용 인터페이스는 이 명령의 출력에서 'dev '라는 단어 다음에 나오는 문자열입니다. 예를 들어, 이 결과는 아래에 강조 표시된 eth0라는 이름의 인터페이스를 보여줍니다:

default via 203.0.113.1 dev eth0 proto static

다음 단계에서 iptables 규칙에 추가할 것이므로 기기의 이름을 기록해 두세요.

WireGuard 서버에 방화벽 규칙을 추가하려면 /etc/wireguard/wg0.conf 파일을 nano 또는 선호하는 편집기로 다시 열면 됩니다.

sudo nano /etc/wireguard/wg0.conf

파일 맨 아래 SaveConfig=true 줄 뒤에 다음 줄을 붙여 넣으십시오:

/etc/wireguard/wg0.conf
. . .
PostUp = ufw route allow in on wg0 out on eth0
PostUp = iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
PostUp = ip6tables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
PreDown = ufw route delete allow in on wg0 out on eth0
PreDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
PreDown = ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

PostUp 라인은 WireGuard 서버가 가상 VPN 터널을 시작할 때 실행됩니다. 여기 예제에서는 세 가지 ufw 및 iptables 규칙을 추가합니다:

• ufw route allow in on wg0 out on eth0: 이 규칙은 wg0 VPN 인터페이스로 들어오는 IPv4 및 IPv6 트래픽이 서버의 eth0 네트워크 인터페이스로 전달되도록 허용합니다. 이는 이전 섹션에서 설정한 net.ipv4.ip_forward 및 net.ipv6.conf.all.forwarding sysctl 값과 함께 작동합니다.
• iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE: 이 규칙은 마스커레이딩을 설정하며, wg0 VPN 인터페이스를 통해 들어오는 IPv4 트래픽을 WireGuard 서버의 공용 IPv4 주소에서 직접 나온 것처럼 보이도록 재작성합니다.
• ip6tables -t nat -I POSTROUTING -o eth0 -j MASQUERADE: 이 규칙은 마스커레이딩을 설정하며, wg0 VPN 인터페이스로 들어오는 IPv6 트래픽을 WireGuard 서버의 공용 IPv6 주소에서 직접 발생한 것처럼 보이도록 다시 작성합니다.

PreDown 규칙은 WireGuard 서버가 가상 VPN 터널을 중지할 때 실행됩니다. 이 규칙은 PostUp 규칙의 반대이며, VPN이 중지될 때 VPN 인터페이스에 대한 포워딩 및 마스커레이딩 규칙을 되돌리는 기능을 합니다.

두 경우 모두 구성에서 VPN에 적합한 IPv4 및 IPv6 규칙을 포함하거나 제외하도록 편집하세요. 예를 들어 IPv4만 사용하는 경우 ip6tables 명령어가 포함된 줄은 제외할 수 있습니다.

반대로, IPv6만 사용 중이라면 구성 파일을 수정하여 ip6tables 명령만 포함하도록 하세요. ufw 줄은 IPv4와 IPv6 네트워크가 혼합된 경우에도 존재해야 합니다. 작업이 끝나면 파일을 저장하고 닫으세요.

WireGuard 서버에서 방화벽을 구성하는 마지막 단계는 WireGuard UDP 포트 자체로의 트래픽을 허용하는 것입니다. 서버의 /etc/wireguard/wg0.conf 파일에서 포트를 변경하지 않았다면 열게 될 포트는 51820입니다. 구성 파일을 편집할 때 다른 포트를 선택했다면, 다음 UFW 명령어에서 해당 포트로 바꿔주어야 합니다.

사전 요구사항 튜토리얼을 따라갈 때 SSH 포트를 열지 않는 것을 잊었다면, 여기에서도 추가하세요:

sudo ufw allow 51820/udp

sudo ufw allow OpenSSH

그 규칙들을 추가한 후, UFW를 비활성화했다가 다시 활성화하여 수정한 모든 파일의 변경 사항을 적용하고 재시작하세요:

sudo ufw disable

sudo ufw enable

규칙이 적용되어 있는지 확인하려면 ufw status 명령어를 실행하면 됩니다. 실행하면 다음과 같은 출력이 나타날 것입니다:

sudo ufw status

Status: active

To                         Action      From
--                         ------      ----
51820/udp                  ALLOW       Anywhere                  
22/tcp                     ALLOW       Anywhere                  
51820/udp (v6)             ALLOW       Anywhere (v6)             
22/tcp (v6)                ALLOW       Anywhere (v6)

이제 WireGuard 서버가 피어 트래픽 전달 및 마스커레이딩을 포함하여 VPN 트래픽을 올바르게 처리하도록 구성되었습니다. 방화벽 규칙이 적용되었으므로, 피어 연결을 수신하기 위해 WireGuard 서비스를 시작할 수 있습니다.

6단계 — WireGuard 서버 시작

WireGuard는 내장된 wg-quick 스크립트를 사용하여 systemd 서비스로 실행되도록 구성할 수 있습니다. VPN을 사용할 때마다 매번 wg 명령을 사용하여 터널을 수동으로 생성할 수도 있지만, 이는 반복적이고 오류가 발생하기 쉬운 수동 과정입니다. 대신, wg-quick 스크립트의 도움을 받아 systemctl을 사용하여 터널을 관리할 수 있습니다.

systemd 서비스를 사용하는 것은 서버가 실행 중인 한 언제든지 VPN에 연결할 수 있도록 WireGuard가 부팅 시 자동으로 시작되도록 설정할 수 있다는 것을 의미합니다. 이를 위해, 정의한 wg0 터널에 대해 wg-quick 서비스를 활성화하여 systemctl에 추가하세요:

sudo systemctl enable wg-quick@wg0.service

이제 서비스를 시작하세요:

sudo systemctl start wg-quick@wg0.service

다음 명령어로 WireGuard 서비스가 활성 상태인지 다시 한 번 확인하세요. 서비스가 활성 상태로 표시되어야 합니다. wg-quick는 인터페이스를 구성한 후 종료되므로 active (exited)가 정상입니다.

sudo systemctl status wg-quick@wg0.service

● wg-quick@wg0.service - WireGuard via wg-quick(8) for wg0
     Loaded: loaded (/lib/systemd/system/wg-quick@.service; enabled; vendor preset: enabled)
     Active: active (exited) since Wed 2021-08-25 15:24:14 UTC; 5s ago
       Docs: man:wg-quick(8)
             man:wg(8)
             https://www.wireguard.com/
             https://www.wireguard.com/quickstart/
             https://git.zx2c4.com/wireguard-tools/about/src/man/wg-quick.8
             https://git.zx2c4.com/wireguard-tools/about/src/man/wg.8
    Process: 3245 ExecStart=/usr/bin/wg-quick up wg0 (code=exited, status=0/SUCCESS)
   Main PID: 3245 (code=exited, status=0/SUCCESS)

Aug 25 15:24:14 wg0 wg-quick[3245]: [#] wg setconf wg0 /dev/fd/63
Aug 25 15:24:14 wg0 wg-quick[3245]: [#] ip -4 address add 10.8.0.1/24 dev wg0
Aug 25 15:24:14 wg0 wg-quick[3245]: [#] ip -6 address add fd0d:86fa:c3bc::1/64 dev wg0
Aug 25 15:24:14 wg0 wg-quick[3245]: [#] ip link set mtu 1420 up dev wg0
Aug 25 15:24:14 wg0 wg-quick[3245]: [#] ufw route allow in on wg0 out on eth0
Aug 25 15:24:14 wg0 wg-quick[3279]: Rule added
Aug 25 15:24:14 wg0 wg-quick[3279]: Rule added (v6)
Aug 25 15:24:14 wg0 wg-quick[3245]: [#] iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
Aug 25 15:24:14 wg0 wg-quick[3245]: [#] ip6tables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
Aug 25 15:24:14 wg0 systemd[1]: Finished WireGuard via wg-quick(8) for wg0.

출력에는 가상 wg0 장치를 생성하고 구성 파일에 추가한 IPv4 및 IPv6 주소를 할당하는 데 사용되는 ip 명령이 표시됩니다. 이러한 규칙을 사용하여 터널을 문제 해결할 수 있으며, VPN 인터페이스를 수동으로 구성해보고 싶다면 wg 명령 자체와 함께 사용할 수도 있습니다.

서버가 설정되고 실행되면, 다음 단계는 클라이언트 머신을 WireGuard 피어로 구성하고 WireGuard 서버에 연결하는 것입니다.

7단계 — WireGuard 피어 구성하기

WireGuard 피어를 구성하는 것은 WireGuard 서버를 설정하는 것과 비슷합니다. 클라이언트 소프트웨어를 설치한 후에는 공개 키와 개인 키 쌍을 생성하고, 피어의 IP 주소를 결정하며, 피어용 구성 파일을 정의한 다음, wg-quick 스크립트를 사용하여 터널을 시작합니다.

다음 단계를 사용하여 키 쌍과 구성을 생성하면 원하는 만큼 VPN에 피어를 추가할 수 있습니다. VPN에 여러 피어를 추가하는 경우 충돌을 방지하기 위해 각 피어의 사설 IP 주소를 꼭 기록해 두세요.

WireGuard 피어를 구성하려면 먼저 다음 apt 명령어를 사용하여 WireGuard 패키지가 설치되어 있는지 확인하세요. WireGuard 피어에서 실행합니다:

sudo apt update

sudo apt install wireguard

WireGuard 피어 키 쌍 생성

다음으로, 서버에서 사용한 것과 동일한 단계로 피어에서 키 쌍을 생성해야 합니다. 피어 역할을 할 로컬 기기나 원격 서버에서 다음 명령어를 사용하여 피어의 개인 키를 생성합니다:

wg genkey | sudo tee /etc/wireguard/private.key

sudo chmod go= /etc/wireguard/private.key

다시 한 번 base64로 인코딩된 한 줄짜리 출력, 즉 개인 키를 받게 됩니다. 출력물의 사본은 또한 /etc/wireguard/private.key에 저장됩니다. 나중에 이 섹션에서 WireGuard의 설정 파일에 추가해야 하므로 출력된 개인 키를 주의 깊게 기록해 두세요.

다음으로, 공개 키 파일을 생성하려면 다음 명령어를 사용하세요:

sudo cat /etc/wireguard/private.key | wg pubkey | sudo tee /etc/wireguard/public.key

다시 한 줄의 base64 인코딩된 출력값을 받게 되며, 이는 WireGuard 피어의 공개 키입니다. 나중에 참조할 수 있도록 어딘가에 복사해 두세요. 암호화된 연결을 설정하려면 공개 키를 WireGuard 서버에 전달해야 하기 때문입니다.

WireGuard 피어 설정 파일 생성

키 쌍이 준비되었으므로, 피어가 WireGuard 서버에 연결을 설정하는 데 필요한 모든 정보를 포함하는 구성 파일을 만들 수 있습니다.

구성 파일을 위해 몇 가지 정보가 필요합니다:

• 피어에서 생성한 base64 인코딩된 개인 키.
• WireGuard 서버에서 정의한 IPv4 및 IPv6 주소 범위입니다.
• WireGuard 서버의 base64로 인코딩된 공개 키.
• WireGuard 서버의 공용 IP 주소와 포트 번호입니다. 일반적으로 이는 IPv4 주소이지만, 서버에 IPv6 주소가 있고 클라이언트 기기가 인터넷에 IPv6로 연결되어 있다면 IPv4 대신 이를 사용할 수 있습니다.

이 모든 정보를 가지고 WireGuard 피어 머신에서 nano 또는 선호하는 편집기를 사용하여 새로운 /etc/wireguard/wg0.conf 파일을 엽니다:

sudo nano /etc/wireguard/wg0.conf

다음 줄을 파일에 추가하고, 필요한 경우 강조된 부분에 다양한 데이터를 대입하세요:

/etc/wireguard/wg0.conf
[Interface]
PrivateKey = base64_encoded_peer_private_key_goes_here
Address = 10.8.0.2/24
Address = fd0d:86fa:c3bc::2/64

[Peer]
PublicKey = U9uE2kb/nrrzsEU58GD3pKFU3TLYDMCbetIsnV8eeFE=
AllowedIPs = 10.8.0.0/24, fd0d:86fa:c3bc::/64
Endpoint = 203.0.113.1:51820

첫 번째 Address 라인이 이전에 선택한 10.8.0.0/24 서브넷의 IPv4 주소를 사용하고 있는 것을 확인하세요. 이 IP 주소는 서버의 IP와 다르기만 하면 서브넷 내의 어떤 주소라도 될 수 있습니다. 피어를 추가할 때마다 주소를 1씩 증가시키는 방식이 일반적으로 IP를 할당하는 가장 쉬운 방법입니다.

마찬가지로, 두 번째 Address 줄이 이전에 생성한 서브넷의 IPv6 주소를 사용하고 서버의 주소를 하나 증가시키는 방식을 주목하세요. 역시, 다른 주소를 사용하기로 결정하면 범위 내의 어떤 IP도 유효합니다.

파일에서 또 다른 주목할 만한 부분은 마지막 AllowedIPs 라인입니다. 이 두 개의 IPv4 및 IPv6 범위는 상대방이 목적지 시스템의 IP 주소가 어느 한 범위에 속할 때에만 VPN을 통해 트래픽을 보내도록 지시합니다. AllowedIPs 지시어를 사용하여 상대방을 VPN 내 다른 상대방과 서비스에만 연결하도록 제한하거나, 모든 트래픽을 VPN을 통해 터널링하고 WireGuard 서버를 게이트웨이로 사용하도록 설정할 수 있습니다.

만약 IPv4만 사용하고 있다면, 끝에 있는 fd0d:86fa:c3bc::/64 범위(및 , 쉼표)를 생략하세요. 반대로 IPv6만 사용하고 있다면 fd0d:86fa:c3bc::/64 접두사만 포함하고 10.8.0.0/24 IPv4 범위는 제외하세요.

두 경우 모두, 모든 피어의 트래픽을 VPN을 통해 보내고 WireGuard 서버를 모든 트래픽의 게이트웨이로 사용하고 싶다면, 전체 IPv4 주소 공간을 나타내는 0.0.0.0/0와 전체 IPv6 주소 공간을 위한 ::/0를 사용할 수 있습니다.

(선택 사항) 피어가 터널을 통해 모든 트래픽을 라우팅하도록 구성하기

만약 0.0.0.0/0 또는 ::/0 경로를 사용하여 피어의 모든 트래픽을 터널을 통해 라우팅하도록 선택했고, 피어가 원격 시스템이라면, 이 섹션의 단계를 완료해야 합니다. 만약 피어가 로컬 시스템이라면, 이 섹션은 건너뛰는 것이 좋습니다.

공용 IP 주소를 사용하여 SSH 또는 기타 프로토콜을 통해 접근하는 원격 피어의 경우, 피어의 wg0.conf 파일에 몇 가지 추가 규칙을 추가해야 합니다. 이러한 규칙은 터널이 연결되어 있을 때도 외부에서 시스템에 연결할 수 있도록 보장합니다. 그렇지 않으면 터널이 설정되면 일반적으로 공용 네트워크 인터페이스에서 처리되는 모든 트래픽이 wg0 터널 인터페이스를 우회하도록 올바르게 라우팅되지 않아 원격 시스템에 접근할 수 없게 됩니다.

먼저, 시스템이 기본 게이트웨이로 사용하는 IP 주소를 확인해야 합니다. 다음 ip route 명령어를 실행하세요:

ip route list table main default

다음과 같은 출력 결과를 받게 됩니다:

default via 203.0.113.1 dev eth0 proto static

나중에 사용할 수 있도록 게이트웨이의 강조된 IP 주소 203.0.113.1와 장치 eth0를 기록해 두세요. 장치 이름이 다를 수 있습니다. 그렇다면 다음 명령어에서 eth0 대신 해당 장치 이름을 사용하세요.

다음으로 ip address show 명령어를 사용하여 장치를 검사하여 시스템의 공인 IP를 찾습니다:

ip -brief address show eth0

다음과 같은 출력 결과를 받게 됩니다:

eth0             UP             203.0.113.5/20 10.20.30.40/16 2604:a880:400:d1::3d3:6001/64 fe80::68d5:beff:feff:974c/64

이 예제 출력에서 강조된 203.0.113.5 IP(뒤의 /20 없이)는 WireGuard 구성에 추가해야 하는 eth0 장치에 할당된 공인 주소입니다.

이제 WireGuard 피어의 /etc/wireguard/wg0.conf 파일을 nano 또는 선호하는 편집기로 열어보세요.

sudo nano /etc/wireguard/wg0.conf

[Peer] 줄 앞에 다음 4줄을 추가하세요:

PostUp = ip rule add table 200 from 203.0.113.5
PostUp = ip route add table 200 default via 203.0.113.1
PreDown = ip rule delete table 200 from 203.0.113.5
PreDown = ip route delete table 200 default via 203.0.113.1

[Peer]
. . .

이 줄들은 사용자 지정 라우팅 규칙을 만들고, 시스템으로 향하는 공용 트래픽이 기본 게이트웨이를 사용하도록 사용자 지정 경로를 추가합니다.

• PostUp=ip rule add table 200 from 203.0.113.5 - 이 명령어는 IP가 시스템의 공인 203.0.113.5 주소와 일치할 때 숫자 200번 테이블의 라우팅 항목을 확인하는 규칙을 생성합니다.
• PostUp=ip route add table 200 default via 203.0.113.1 - 이 명령어는 200 테이블에서 처리되는 모든 트래픽이 WireGuard 인터페이스가 아니라 203.0.113.1 게이트웨이를 통해 라우팅되도록 보장합니다.

PreDown 라인은 터널이 종료될 때 사용자 정의 규칙과 경로를 제거합니다.

모든 피어의 트래픽을 VPN을 통해 라우팅하는 경우, WireGuard 서버의 네트워크 구성 조정과 WireGuard 서버의 방화벽 구성에서 올바른 sysctl 및 iptables 규칙을 WireGuard 서버에 설정했는지 확인하세요.

(선택 사항) WireGuard 피어의 DNS 해상기 구성

모든 피어의 트래픽에 대해 WireGuard 서버를 VPN 게이트웨이로 사용하고 있다면, [Interface] 섹션에 DNS 해석기를 지정하는 줄을 추가해야 합니다. 이 설정을 추가하지 않으면 DNS 요청이 VPN으로 보호되지 않거나 인터넷 서비스 제공업체 또는 다른 제3자에게 노출될 수 있습니다.

WireGuard를 사용하여 VPN 네트워크의 리소스에 접근하거나 피어 투 피어 구성에서만 사용한다면 이 절은 건너뛸 수 있습니다.

피어의 구성에 DNS 해석기를 추가하려면 먼저 WireGuard 서버에서 사용 중인 DNS 서버를 확인해야 합니다. WireGuard 서버에서 다음 명령어를 실행하되, 예제와 다르다면 eth0 대신 자신의 이더넷 장치 이름을 입력하세요:

resolvectl dns eth0

다음과 같은 출력을 받게 될 것입니다:

Link 2 (eth0): 67.207.67.2 67.207.67.3 2001:4860:4860::8844 2001:4860:4860::8888

출력되는 IP 주소는 서버가 사용하는 DNS 해석기입니다. 필요에 따라 모든 주소를 사용하거나, 일부만 사용하거나, IPv4 또는 IPv6만 선택할 수 있습니다. 사용할 해석기를 메모해 두세요.

다음으로 선택한 해상도 서버(resolvers)를 WireGuard Peer의 설정 파일에 추가해야 합니다. WireGuard Peer로 돌아가서 nano 또는 선호하는 편집기를 사용하여 /etc/wireguard/wg0.conf 파일을 엽니다:

sudo nano /etc/wireguard/wg0.conf

[Peer] 라인 전에 다음을 추가하세요:

DNS = 67.207.67.2 2001:4860:4860::8844

[Peer]
. . .

다시 말해, IPv4와 IPv6에 대한 선호도나 요구 사항에 따라 필요에 맞게 목록을 편집할 수 있습니다.

Global: 67.207.67.2 67.207.67.3
. . .

이러한 모든 DNS 해석기 설정이 완료되면 이제 피어의 공개 키를 서버에 추가한 다음 피어에서 WireGuard 터널을 시작할 준비가 된 것입니다.

단계 8 — 동료의 공개 키를 WireGuard 서버에 추가하기

피어를 서버에 연결하기 전에 피어의 공개 키를 WireGuard 서버에 추가하는 것이 중요합니다. 이 단계는 VPN을 통해 연결하고 트래픽을 라우팅할 수 있도록 보장합니다. 이 단계를 완료하지 않으면 WireGuard 서버는 피어가 터널을 통해 트래픽을 송수신하지 못하게 됩니다.

다음을 실행하여 WireGuard 피어의 base64 인코딩된 공개 키 사본이 있는지 확인하세요:

sudo cat /etc/wireguard/public.key

PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg=

이제 WireGuard 서버에 로그인한 다음, 다음 명령어를 실행하세요:

sudo wg set wg0 peer PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg= allowed-ips 10.8.0.2,fd0d:86fa:c3bc::2

명령어의 allowed-ips 부분은 쉼표로 구분된 IPv4 및 IPv6 주소 목록을 받는다는 점에 유의하세요. 피어가 자체적으로 할당할 수 있는 IP 주소를 제한하려면 개별 IP를 지정할 수 있으며, 예제처럼 VPN 범위 내에서 모든 IP 주소를 사용하도록 허용하려면 범위를 지정할 수도 있습니다. 또한 두 피어가 동일한 allowed-ips 설정을 가질 수 없다는 점도 참고하세요.

기존 피어의 allowed-ips를 업데이트하려면 동일한 명령어를 다시 실행하되 IP 주소를 변경하면 됩니다. 여러 IP 주소도 지원됩니다. 예를 들어, 방금 추가한 WireGuard 피어에 기존 10.8.0.2 및 fd0d:86fa:c3bc::2 IP에 10.8.0.100과 같은 IP를 추가하려면 다음과 같이 실행하면 됩니다:

sudo wg set wg0 peer PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg= allowed-ips 10.8.0.2,10.8.0.100,fd0d:86fa:c3bc::2

피어를 추가하는 명령을 실행한 후, 서버에서 wg 명령을 사용하여 터널 상태를 확인하세요:

sudo wg

interface: wg0
 public key: U9uE2kb/nrrzsEU58GD3pKFU3TLYDMCbetIsnV8eeFE=
 private key: (hidden)
 listening port: 51820

peer: PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg=
 allowed ips: 10.8.0.2/32, fd0d:86fa:c3bc::/128

WireGuard Peer의 공개 키와 해당 Peer가 스스로 IP를 할당할 수 있도록 허용된 IP 주소 또는 주소 범위를 peer 라인에서 어떻게 표시하는지 확인하세요.

이제 서버에서 피어의 연결 매개변수를 정의했으므로, 다음 단계는 피어에서 터널을 시작하는 것입니다.

단계 9 — WireGuard 피어를 터널에 연결하기

이제 서버와 피어가 모두 IPv4, IPv6, 패킷 전달 및 DNS 해상을 지원하도록 구성되었으므로, 피어를 VPN 터널에 연결할 시간입니다.

특정 사용 사례에 대해서만 VPN을 켜고 싶을 수 있으므로, wg-quick 명령어를 사용하여 수동으로 연결을 설정하겠습니다. 서버에서 했던 것처럼 터널 시작을 자동화하고 싶다면, wq-quick 명령어를 사용하는 대신 WireGuard 서버 시작 섹션의 단계를 따라주세요.

모든 트래픽을 VPN을 통해 라우팅하고 DNS 포워딩을 설정한 경우, 터널을 시작하기 전에 WireGuard 피어에 resolvconf 유틸리티를 설치해야 합니다. 이를 설정하려면 다음 명령어를 실행하세요:

sudo apt install resolvconf

터널을 시작하려면, WireGuard 피어에서 다음 명령을 실행하세요:

sudo wg-quick up wg0

다음과 같은 출력 결과를 받게 됩니다:

[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.8.0.2/24 dev wg0
[#] ip -6 address add fd0d:86fa:c3bc::2/64 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] resolvconf -a tun.wg0 -m 0 -x

피어에 할당한 강조 표시된 IPv4 및 IPv6 주소를 확인하세요.

만약 상대방(peer)에 AllowedIPs를 0.0.0.0/0 및 ::/0로 설정하거나 VPN에서 선택한 범위 외의 다른 범위를 사용하면, 출력은 다음과 비슷하게 나타납니다:

[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.8.0.2/24 dev wg0
[#] ip -6 address add fd0d:86fa:c3bc::2/64 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] resolvconf -a tun.wg0 -m 0 -x
[#] wg set wg0 fwmark 51820
[#] ip -6 route add ::/0 dev wg0 table 51820
[#] ip -6 rule add not fwmark 51820 table 51820
[#] ip -6 rule add table main suppress_prefixlength 0
[#] ip6tables-restore -n
[#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820
[#] ip -4 rule add not fwmark 51820 table 51820
[#] ip -4 rule add table main suppress_prefixlength 0
[#] sysctl -q net.ipv4.conf.all.src_valid_mark=1
[#] iptables-restore -n

이 예제에서, 명령어가 추가한 하이라이트된 경로들을 주목해 보세요. 이는 피어 구성의 AllowedIPs에 해당합니다.

다음 wg 명령어를 사용하여 피어에서 터널 상태를 확인할 수 있습니다:

sudo wg

interface: wg0
 public key: PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg=
 private key: (hidden)
 listening port: 49338
 fwmark: 0xca6c

peer: U9uE2kb/nrrzsEU58GD3pKFU3TLYDMCbetIsnV8eeFE=
 endpoint: 203.0.113.1:51820
 allowed ips: 10.8.0.0/24, fd0d:86fa:c3bc::/64
 latest handshake: 1 second ago
 transfer: 6.50 KiB received, 15.41 KiB sent

서버에서 상태를 다시 확인할 수도 있으며, 비슷한 결과를 받게 될 것입니다.

동료가 VPN을 사용하고 있는지 확인하려면 ip route 및 ip -6 route 명령어를 사용하세요. VPN을 모든 인터넷 트래픽의 게이트웨이로 사용 중이라면, CloudFlare의 1.1.1.1 및 2606:4700:4700::1111 DNS 해석기로 향하는 트래픽에 어떤 인터페이스가 사용되는지 확인하세요.

ip route get 1.1.1.1

1.1.1.1 dev wg0 table 51820 src 10.8.0.2 uid 1000
   cache

사용된 wg0 장치와 피어에 할당한 IPv4 주소 10.8.0.2를 확인하세요. 마찬가지로, IPv6를 사용하는 경우 다음을 실행합니다:

ip -6 route get 2606:4700:4700::1111

2606:4700:4700::1111 from :: dev wg0 table 51820 src fd0d:86fa:c3bc::2 metric 1024 pref medium

다시 한 번 wg0 인터페이스와 피어에게 할당한 IPv6 주소 fd0d:86fa:c3bc::2를 확인하세요.

만약 상대방이 브라우저를 설치했다면, ipleak.net과 ipv6-test.com을 방문하여 상대방이 VPN을 통해 트래픽을 라우팅하고 있는지 확인할 수도 있습니다.

피어에서 VPN 연결을 종료할 준비가 되면 wg-quick 명령어를 사용하세요:

sudo wg-quick down wg0

VPN 터널이 종료되었음을 나타내는 다음과 같은 출력이 표시됩니다:

[#] ip link delete dev wg0
[#] resolvconf -d tun.wg0 -f

만약 상대방(peer)에 AllowedIPs를 0.0.0.0/0 및 ::/0로 설정하거나 VPN에서 선택한 범위 외의 다른 범위를 사용하면, 출력은 다음과 비슷하게 나타납니다:

[#] ip rule delete table 200 from 203.0.113.5
[#] ip route delete table 200 default via 203.0.113.1
[#] ip -4 rule delete table 51820
[#] ip -4 rule delete table main suppress_prefixlength 0
[#] ip -6 rule delete table 51820
[#] ip -6 rule delete table main suppress_prefixlength 0
[#] ip link delete dev wg0
[#] resolvconf -d tun.wg0 -f
[#] iptables-restore -n
[#] ip6tables-restore -n

VPN에 다시 연결하려면 피어에서 wg-quick up wg0 명령을 다시 실행하세요. WireGuard 서버에서 피어의 구성을 완전히 제거하려면 다음 명령을 실행할 수 있으며, 제거하려는 피어의 올바른 공개 키를 대체해야 합니다:

sudo wg set wg0 peer PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg= remove

일반적으로 피어(peer) 구성을 제거해야 하는 경우는 피어가 더 이상 존재하지 않거나, 암호화 키가 손상되었거나 변경된 경우입니다. 그렇지 않은 경우에는 구성을 그대로 두는 것이 좋습니다. 이렇게 하면 매번 키와 allowed-ips를 추가하지 않고도 피어가 VPN에 다시 연결할 수 있습니다.

WireGuard 키 관리 및 교체

WireGuard는 인증 및 암호화를 위해 정적 공개 키와 개인 키 쌍에 의존합니다. 이러한 설계는 구성 복잡성을 크게 줄여주지만, 키 관리에 대한 책임을 전적으로 관리자에게 부과합니다. 장기 실행 VPN 배포, 공유 인프라 또는 여러 피어가 있는 환경에서는 보안과 운영 안정성을 유지하기 위해 신중한 키 관리가 필수적입니다.

WireGuard 키 유형 이해

각 WireGuard 피어는 두 가지 종류의 암호화 키를 사용합니다.

• 장기 개인 키: 개인 키는 피어를 고유하게 식별하며 항상 비밀로 유지되어야 합니다. 이 키는 암호화된 핸드셰이크 동안 피어를 인증하고 단기 세션 키를 생성하는 데 사용됩니다. 개인 키가 노출되면 해당 키를 보유한 모든 시스템이 피어를 가장할 수 있습니다.

• 장기 공개 키: 공개 키는 개인 키에서 파생되며 다른 피어와 공유됩니다. 중앙 허브에서는 공개 키를 통해 어떤 피어가 통신할 수 있는지, 그리고 어떤 IP 주소를 사용할 수 있는지를 결정합니다.

이러한 장기 키 외에도, WireGuard는 암호화된 핸드셰이크 동안 자동으로 일시적인 세션 키를 생성합니다. 이 세션 키는 주기적으로 교체되며, 관리자의 개입 없이도 완벽한 순방향 비밀(Perfect Forward Secrecy)을 제공합니다.

권장 키 관리 관행

다음과 같은 관행은 위험을 줄이고 지속적인 운영을 간소화하는 데 도움이 됩니다:

• 각 피어에 고유한 키 쌍 할당: 각 장치는 고유한 개인 키와 공개 키 쌍을 가져야 합니다. 고유 키를 사용하면 한 장치에 대한 접근을 취소해도 다른 장치에는 영향을 주지 않습니다. 여러 시스템에서 키를 재사용하면 침해 시 영향이 커지고 감사가 어려워집니다.

• 개인 키 자료에 대한 접근 제한: 개인 키 파일은 루트 사용자만 읽을 수 있도록 해야 합니다. Linux 시스템에서는 일반적으로 chmod 600 /etc/wireguard/private.key와 같은 명령어를 사용하여 권한을 600으로 설정하는 것을 의미합니다. 파일 접근을 제한하면 백업, 로그 또는 비특권 사용자를 통해 발생할 수 있는 우발적인 유출을 방지하는 데 도움이 됩니다.

• 명확한 피어 목록 유지: 각 피어의 공개 키를 해당 장치 이름, 할당된 IPv4 및 IPv6 주소, 그리고 의도된 용도와 매핑하는 기록을 유지하세요. 피어 수가 많아질수록 이 문서는 점점 더 중요해지며, 문제 해결, 감사 및 정기 유지보수를 쉽게 만듭니다.

• 사용하지 않거나 비활성화된 피어는 신속히 제거: 장치가 폐기되었거나 더 이상 VPN 접근이 필요하지 않은 경우, 중앙 피어 구성에서 해당 장치의 공개 키를 제거하세요. 사용하지 않는 키를 그대로 두면 공격 표면이 늘어나고 이후 검토가 더 어려워집니다.

키 교체가 필요한 상황

키 회전은 여러 일반적인 시나리오에서 수행되어야 합니다:

• 의심되거나 확인된 키 노출: 개인 키가 복사되었거나 유출되었거나 권한 없는 사람이 접근했을 가능성이 있는 경우, 사칭을 방지하기 위해 즉시 키를 교체해야 합니다.

• 분실되거나 도난당한 장치: 장치를 분실하거나 도난당한 경우, 키를 교체하면 원래 설정이 복구되더라도 장치가 더 이상 VPN에 연결되지 않도록 할 수 있습니다.

• 조직 보안 요구사항: 일부 환경에서는 침해가 의심되지 않더라도 내부 정책이나 준수 기준을 충족하기 위해 주기적인 키 교체가 필요합니다.

• 장치 소유권 또는 역할 변경: 피어가 다른 사용자나 용도로 재할당될 때, 키를 교체하면 의도치 않은 지속적인 접근을 방지할 수 있습니다.

동료의 키 안전하게 교체하기

WireGuard는 내부 IP 주소를 특정 공개 키에 매핑하기 위해 암호 키 라우팅 테이블을 사용합니다. 이러한 설계 때문에 동일한 내부 IP 주소를 두 개의 공개 키에 동시에 안전하게 할당할 수 없습니다. 따라서 키 회전은 일반적으로 구성이 업데이트되는 동안 잠시 연결이 끊기는 것을 수반합니다.

동료의 키를 회전하려면 다음 절차를 따르세요:

1. 피어에서 새로운 개인 키와 공개 키 쌍을 생성합니다.
2. 중앙 피어의 구성을 업데이트하여 이전 공개 키를 새 키로 교체하되, 동일한 AllowedIPs 값은 유지하세요. 아직 인터페이스를 재시작하지 마세요.
3. 피어의 구성 파일을 새 개인 키를 사용하도록 업데이트하세요.
4. 중앙 피어에 업데이트된 구성을 적용합니다. 예를 들어, WireGuard 서비스를 다시 로드하거나 wg syncconf를 사용할 수 있습니다. 이 시점에서 피어는 일시적으로 연결이 끊길 수 있습니다.
5. 피어에서 WireGuard 인터페이스를 재시작하여 새 개인 키를 사용하도록 합니다.
6. 새 핸드셰이크가 완료되고 트래픽이 정상적으로 흐르는지 확인하세요.
7. 아직 남아 있는 경우, 이전 키에 대한 모든 참조를 제거하세요.

이 교체 기반 접근 방식은 WireGuard가 암호화 라우팅을 구현하고 모호하거나 충돌하는 구성을 피하는 방법을 반영합니다.

중앙 피어의 키 회전

중앙 피어의 개인 키를 교체하면 모든 연결된 피어에 영향을 줍니다. 연결을 복원하기 전에 각 피어 구성은 새로운 공개 키로 업데이트되어야 합니다.

이 변경은 모든 피어에 동시에 영향을 미치므로 중앙 피어 키 교체는 신중하게 계획하고 유지보수 시간 동안 수행해야 합니다. 실제로 중앙 키는 피어 키보다 교체 빈도가 낮습니다.

사전 공유 키 관리(선택 사항)

공개 키와 개인 키 쌍 외에도, WireGuard는 각 피어에 대해 선택적으로 사전 공유 키(PSK)를 지원합니다. PSK는 WireGuard의 기존 암호화 위에 추가적인 대칭 암호화 계층을 제공합니다.

사전에 공유된 키(PSK)는 향후 암호학적 발전에 대한 방어 수단으로 고보안 환경에서 일반적으로 사용됩니다. 오늘날 암호화된 트래픽이 기록되고 나중에 기본 공개 키 알고리즘이 손상되더라도, PSK는 과거 세션의 복호화를 여전히 방지할 수 있습니다.

PSK를 사용하는 경우, 이를 민감한 비밀로 취급하고 주기적으로 교체해야 합니다. PSK를 교체하는 절차는 피어 키를 교체하는 운영 패턴과 동일하며, 연결 양쪽 모두에서 조정되어야 합니다.

회전 주기 선택

WireGuard는 고정된 키 교체 일정을 강제하지 않습니다. 적절한 교체 간격은 환경에 따라 다릅니다.

• 개인용 또는 단기간 배치는 정기적인 교체가 필요하지 않을 수 있습니다.
• 공유 환경이나 운영 환경에서는 일반적으로 키를 6개월에서 12개월마다 교체합니다.
• 고보안 환경에서는 정책에 따라 더 자주 교체가 필요할 수 있습니다.

정기적인 교체는 장기 사용 자격 증명과 관련된 위험을 줄이고 WireGuard 배포를 일반적인 보안 관행에 맞춥니다.

WireGuard와 OpenVPN: 실제적인 차이점

WireGuard와 OpenVPN은 모두 널리 사용되는 VPN 기술이지만, 암호화, 구성, 네트워크 동작 방식에서 매우 다른 접근 방식을 취합니다. 이러한 차이를 이해하면 개발자가 자신의 운영 환경에 가장 적합한 솔루션을 선택하는 데 도움이 됩니다.

구성 및 운영 모델

WireGuard는 공개 키와 개인 키 쌍을 기반으로 하는 정적 구성 모델을 사용합니다. 모든 피어는 명시적으로 정의되며 라우팅 동작은 고정된 구성 값을 통해 제어됩니다. 제어 채널, 인증 기관, 또는 매개변수의 동적 협상은 없습니다.

OpenVPN은 TLS와 X.509 인증서를 기반으로 합니다. 클라이언트를 인증하고, 암호화 설정을 협상하며, 세션을 관리하기 위해 제어 채널을 사용합니다. 이 모델은 유연성을 제공하지만 구성과 운영의 복잡성을 증가시킵니다.

실제로 WireGuard 설정은 더 짧고, 감사가 쉽고, 미묘한 잘못된 구성에 덜 취약합니다. 반면 OpenVPN 설정은 더 많은 제어를 제공하지만 안전하고 일관되게 유지하려면 신중한 관리가 필요합니다.

암호학 및 보안 설계

WireGuard는 고정된 최신 암호화 방법 세트를 사용합니다. 이러한 선택은 구성할 수 없습니다. 이 설계는 암호화 다운그레이드 공격을 방지하고 암호화 모음 선택의 필요성을 제거합니다.

OpenVPN은 다양한 암호화 알고리즘과 인증 방식을 지원합니다. 이러한 유연성은 기존 시스템과의 호환성을 가능하게 하지만, 동시에 약하거나 일관되지 않은 구성의 위험도 증가시킵니다.

두 솔루션 모두 완벽한 순방향 비밀(Perfect Forward Secrecy)을 지원합니다. WireGuard는 핸드셰이크 메커니즘을 통해 키 회전을 자동으로 수행하는 반면, OpenVPN은 TLS 세션 동작에 의존합니다.

성능 특성

WireGuard는 높은 성능과 낮은 지연 시간을 위해 설계되었습니다. Linux 커널에서 실행되며 코드베이스가 작아 오버헤드와 컨텍스트 전환을 줄입니다. 대부분의 환경에서 WireGuard는 최소한의 조정만으로 더 높은 처리량과 보다 일관된 지연 시간을 제공합니다.

역사적으로 OpenVPN은 사용자 공간에서 실행되며 컨텍스트 전환과 프로토콜 처리로 인해 추가적인 오버헤드를 발생시킵니다. 최신 버전의 OpenVPN은 성능을 크게 향상시키는 커널 데이터 채널 오프로딩(DCO)을 지원하지만, 이 기능은 기본 배포 환경에서는 항상 활성화되거나 사용 가능한 것은 아닙니다.

DCO를 사용하더라도 WireGuard는 일반적으로 적은 구성 변수로 강력한 성능을 발휘합니다.

네트워크 로밍 및 방화벽 통과

WireGuard는 네트워크 변경을 원활하게 처리합니다. 피어의 IP 주소가 WiFi와 모바일 네트워크 간 전환처럼 변경되더라도 터널은 재협상 없이 계속 작동합니다.

그러나 WireGuard는 오직 UDP를 통해서만 작동합니다. UDP는 효율적이지만, 제한적인 공용 WiFi 네트워크, 기업 방화벽 또는 기관 네트워크에서는 가끔 차단되기도 합니다. UDP 트래픽이 차단될 경우 WireGuard에는 기본적인 대체 수단이 없습니다.

OpenVPN은 UDP와 TCP를 모두 지원합니다. UDP를 사용할 수 없는 경우, OpenVPN을 TCP 포트 443에서 실행되도록 구성할 수 있으며, 이때 VPN 트래픽은 일반적인 HTTPS 트래픽과 비슷하게 나타납니다. 이러한 기능 덕분에 OpenVPN은 엄격한 방화벽 규칙이나 검열이 있는 환경에서도 더욱 신뢰할 수 있습니다.

제한적인 네트워크 환경에서 운영하는 사용자에게는 TCP 지원 여부가 WireGuard보다 OpenVPN을 선택하는 결정적인 요인이 되는 경우가 많습니다.

기능 범위 및 확장성

OpenVPN에는 WireGuard가 의도적으로 제공하지 않는 기능들이 포함되어 있습니다. 여기에는 사용자 기반 인증, 동적 주소 할당, 외부 인증 시스템과의 통합이 포함됩니다.

WireGuard는 오로지 안전한 터널링에만 집중합니다. 인증 워크플로, 접근 제어 및 동적 구성은 프로토콜 외부에서 처리해야 합니다.

이로 인해 OpenVPN은 복잡한 인증이나 중앙 집중식 사용자 관리를 요구하는 환경에 더 적합한 반면, WireGuard는 인프라 수준의 VPN과 피어 기반 접근에 더 적합합니다.

요약 비교

WireGuard와 OpenVPN 중에서 선택하기

WireGuard는 인프라 VPN, 사이트 간 터널, 모바일 클라이언트, 단순성, 성능, 예측 가능성이 중요한 환경에 적합합니다.

OpenVPN은 TCP 기반 터널링, 고급 인증 또는 제한적인 방화벽 뒤에서의 안정적인 작동이 필요한 기업 환경에서 여전히 강력한 선택입니다.

많은 현대적인 배포 환경에서 WireGuard가 OpenVPN을 대체하는 이유는 더 많은 기능을 제공하기 때문이 아니라, 기능은 적지만 동작이 더 명확하기 때문입니다.

성능 조정 및 최적화

WireGuard는 기본 설정에서도 성능이 좋지만, 실제 네트워크 환경에서는 신뢰성과 처리량에 영향을 줄 수 있습니다. 패킷 크기, 라우팅 범위, NAT 동작, DNS 해석 등의 요소가 지속적이거나 간헐적인 사용 시 터널의 동작에 영향을 미칩니다.

가장 일반적인 조정 영역과 조정이 적절한 시기를 살펴보겠습니다.

MTU 선택 및 패킷 분할

최대 전송 단위(MTU)는 분할 없이 전송할 수 있는 가장 큰 패킷 크기를 정의합니다. WireGuard는 패킷을 암호화하고 캡슐화하므로 물리적 네트워크 인터페이스에 비해 유효 MTU가 줄어듭니다.

기본적으로 WireGuard는 1420의 MTU를 사용합니다. 이 값은 IPv6 헤더, UDP, WireGuard 캡슐화의 결합된 오버헤드를 고려한 것으로, 대부분의 이더넷 기반 네트워크에서 잘 작동합니다. 일부 환경에서는 더 작은 MTU가 필요합니다. 이는 모바일 네트워크, PPPoE 연결, 추가 캡슐화 계층이 있는 클라우드 플랫폼에서 흔히 발생합니다. MTU가 너무 크면 패킷이 손실되거나 분할될 수 있습니다. 이는 작은 요청에서는 연결이 작동하지만, 큰 전송에서는 지연되거나 실패하는 결과를 초래하는 경우가 많습니다. 이러한 증상이 발생하면 MTU를 점진적으로 낮추는 것이 권장됩니다. 1360과 같은 값이나, 제한된 환경에서는 IPv6 최소 MTU인 1280이 이러한 문제를 최소한의 처리량 영향으로 해결하는 경우가 종종 있습니다.

일관된 동작을 보장하기 위해 MTU는 구성 파일의 [Interface] 섹션에 명시적으로 설정해야 합니다.

AllowedIPs의 범위와 영향

AllowedIPs 지시문은 라우팅 동작과 성능 모두에 영향을 줍니다. 광범위한 주소 범위를 사용하면 더 많은 트래픽이 터널을 통과하게 되어 암호화 오버헤드와 서버 부하가 증가합니다. 좁은 AllowedIPs 값을 사용하면 보호가 필요한 트래픽만 터널을 통과하도록 제한할 수 있습니다. 이는 CPU 사용량을 줄이고 불필요한 캡슐화를 피하는 데 도움이 됩니다.

0.0.0.0/0 또는 ::/0가 구성되면 모든 트래픽이 VPN을 통해 라우팅됩니다. 이 구성은 개인 정보 보호, 중앙 집중식 egress 제어 또는 신뢰할 수 없는 네트워크를 고려할 때 적합하지만, 일반 인터넷 트래픽에 대한 지연 시간과 리소스 사용이 증가합니다.

성능 최적화는 가능한 경우 AllowedIPs를 좁히고, 필요하지 않은 한 전체 터널 라우팅을 피하는 경우가 많습니다.

NAT 트래버설 및 연결 안정성 (PersistentKeepalive)

WireGuard는 데이터가 전송되지 않을 때 의도적으로 침묵합니다. 기본적으로 주기적인 유지 확인 패킷을 보내지 않습니다. 홈 라우터, 모바일 네트워크 또는 많은 클라우드 네트워크와 같이 NAT를 사용하는 환경에서는 이러한 침묵으로 인해 NAT 장치가 연결 매핑을 종료할 수 있습니다. 이런 일이 발생하면 피어가 다시 트래픽을 보낼 때까지 서버로부터의 수신 트래픽이 차단됩니다. 이 동작은 종종 지연, 연결 지연 또는 간헐적인 실패로 인식됩니다.

이를 방지하기 위해 WireGuard는 PersistentKeepalive 설정을 제공합니다. 이 옵션은 피어 구성의 [Peer] 섹션에 추가할 수 있습니다. 이 설정은 피어가 NAT 매핑을 열어 두기 위해 일정 간격으로 작은 킵얼라이브 패킷을 보내도록 합니다. 일반적으로 25초 값을 사용하며 대부분의 NAT 장치에서 잘 작동합니다. 연결이 처음에는 작동하지만 유휴 상태 후에 실패하는 경우, PersistentKeepalive=25를 활성화하는 것이 가장 주요하고 권장되는 해결 방법입니다.

DNS 해석 및 터널 동작

DNS 구성은 인지되는 VPN 성능에 큰 영향을 미칩니다. DNS 해석기가 터널을 통해 올바르게 라우팅되지 않으면, 터널 자체가 정상적으로 작동하더라도 애플리케이션이 느리거나 신뢰할 수 없게 보일 수 있습니다.

게이트웨이 구성에서는 일관된 라우팅을 보장하고 누수를 방지하기 위해 DNS 쿼리를 VPN을 통해 보내야 합니다. 이를 위해 피어 구성에서 DNS 해석기를 명시적으로 정의해야 합니다. DNS가 잘못 구성되면 일반적인 증상으로는 페이지 로딩 지연, 불규칙한 연결 상태, 활성 터널이 있음에도 불구하고 트래픽이 VPN 밖으로 라우팅되는 현상이 포함됩니다.

터널을 통해 접근할 수 있고 빠르게 응답하는 리졸버를 선택하면 신뢰성과 사용자 경험이 모두 향상됩니다.

IPv4와 IPv6 성능 차이

듀얼 스택 환경에서는 IPv4와 IPv6가 다르게 동작할 수 있습니다. IPv6 경로는 서로 다른 MTU 제한, 라우팅 정책 또는 방화벽 동작을 가질 수 있습니다.

두 프로토콜을 독립적으로 테스트하면 프로토콜별 문제를 식별하는 데 도움이 됩니다. ping, tracepath, ip route get와 같은 도구는 각 주소 패밀리의 라우팅 및 MTU 동작을 검증하는 데 유용합니다.

IPv6 성능이 불안정하게 보이면 ICMPv6 트래픽이 허용되는지 확인하세요. ICMPv6는 경로 MTU 탐지를 위해 필요하며, 이를 차단하면 큰 패킷에서 연결이 중단될 수 있습니다.

CPU 및 암호화 오버헤드

WireGuard는 대부분의 시스템에서 효율적인 최신 암호화를 사용합니다. 그러나 암호화는 여전히 CPU 자원을 소비합니다.

작은 가상 머신, 임베디드 라우터 또는 하드웨어 가속이 없는 시스템에서는 전체 터널 구성은 지속적인 부하에서 CPU를 포화시킬 수 있습니다.

트래픽이 많은 동안 CPU 사용량을 모니터링하면 성능 문제가 네트워크 구성보다는 암호화 오버헤드로 인해 발생하는지 확인하는 데 도움이 됩니다. 이러한 경우 터널링된 트래픽을 줄이거나 서버 인스턴스를 업그레이드해야 할 수도 있습니다.

성능 변경 검증

성능 조정은 점진적으로 이루어져야 합니다. 각 변경 후에는 추가 조정을 적용하기 전에 연결성과 안정성을 확인해야 합니다.

유용한 검증 단계에는 wg로 핸드셰이크 안정성을 확인하고, 변경 전후의 지연 시간과 처리량을 측정하며, ip route와 ip -6 route로 라우팅 동작을 확인하는 것이 포함됩니다. 이 접근 방식은 위험을 최소화하고 문제 해결을 단순화합니다.

자주 묻는 질문

1. WireGuard란 무엇이며 Ubuntu에서 어떻게 작동하나요?

WireGuard는 OpenVPN이나 IPsec과 같은 기존 옵션보다 훨씬 빠르고 설정이 쉬운 최신 VPN 기술입니다. 이를 장치들을 직접 연결하는 안전한 터널로 생각할 수 있습니다. 무겁고 복잡한 기존 VPN과 달리 WireGuard는 매우 가볍습니다. Ubuntu에서는 Linux 커널, 즉 운영 체제의 핵심 '엔진' 안에서 직접 실행됩니다. 별도의 응용 프로그램으로서가 아닌 시스템 깊숙이에서 실행되기 때문에 배터리 소모가 거의 없고 데이터를 매우 빠르게 처리합니다.

연결을 설정하기 위해 WireGuard는 SSH와 매우 유사한 방식을 사용합니다. 각 장치마다 한 쌍의 ‘키’를 생성하는데, 개인 키는 장치에 비밀로 유지되고, 공개 키는 연결하려는 다른 장치들과 공유됩니다. 키가 완벽하게 일치해야만 연결이 이루어지므로 핸드셰이크가 빠르고 안전합니다.

2. WireGuard가 OpenVPN보다 더 안전한가요?

대부분의 사용자에게 WireGuard는 단순하고 현대적인 설계 덕분에 더 안전한 것으로 간주됩니다. 주된 이유는 코드의 규모입니다. WireGuard는 약 4,000줄의 코드로만 작성되었지만, OpenVPN은 10만 줄이 넘습니다. 이 엄청난 차이 덕분에 보안 전문가들이 WireGuard 코드를 읽고 악의적인 사용자가 발견하기 전에 취약점(버그)을 찾는 것이 훨씬 더 쉽습니다.

WireGuard는 또한 사용자가 오늘날 사용 가능한 최신의 가장 강력한 암호화 표준을 사용하도록 강제합니다. 기존 VPN은 크립토 유연성을 허용하여 오래된 장치를 지원하기 위해 약한 암호화 방식으로 다운그레이드할 수 있습니다. WireGuard는 이러한 선택권을 제거하여 공격자가 VPN을 속여 약한 보안을 사용하지 못하도록 합니다. 또한 WireGuard는 기본적으로 은밀하게 작동합니다; 권한 없는 장치가 서버로 패킷을 보내면 WireGuard는 단순히 응답하지 않습니다. 이는 해커가 열린 포트를 스캔할 때 서버를 보이지 않게 만듭니다.

3. 우분투에서 Docker 없이 WireGuard를 설정할 수 있나요?

네, Docker 컨테이너를 사용하지 않고도 시스템에서 직접 쉽게 설정할 수 있습니다. 사실, Ubuntu에서는 소프트웨어가 표준 Ubuntu 소프트웨어 저장소에 포함되어 있기 때문에 직접 실행하는 것이 종종 권장되는 방법입니다. 일반적으로 아래에 있는 표준 설치 명령어만 실행하면 되며, 이는 필요한 소프트웨어를 Ubuntu 공식 소스로부터 바로 가져옵니다.

sudo apt update
sudo apt install wireguard

4. 여러 개의 WireGuard 클라이언트(피어)를 어떻게 추가하나요?

WireGuard는 피어 투 피어(peer-to-peer) 개념을 사용합니다. 즉, 연결하는 모든 장치를 '피어'로 취급합니다. 노트북, 스마트폰, 태블릿과 같이 여러 장치를 추가하려면 서버의 구성 파일(보통 /etc/wireguard/wg0.conf에 위치)을 단순히 편집하면 됩니다.

새로운 장치마다 [Peer]로 표시된 새로운 텍스트 블록을 추가해야 합니다. 이 블록 안에는 해당 장치의 공개 키를 붙여넣고 고유한 내부 IP 주소를 할당해야 합니다(첫 번째 장치는 10.0.0.2, 두 번째 장치는 10.0.0.3 등). 이러한 내부 IP 주소가 겹치지 않도록 하는 것이 매우 중요합니다.

간단한 예제 구성 블록은 다음과 같습니다:

[Interface]
# Server settings...
Address = 10.0.0.1/24
ListenPort = 51820
PrivateKey = <Server_Private_Key>

[Peer]
# Client 1 (Laptop)
PublicKey = <Laptop_Public_Key>
AllowedIPs = 10.0.0.2/32

[Peer]
# Client 2 (Phone)
PublicKey = <Phone_Public_Key>
AllowedIPs = 10.0.0.3/32

5. WireGuard는 어떤 포트를 사용합니까?

WireGuard는 기본적으로 UDP 포트 51820를 사용합니다. 이는 TCP보다 터널링 데이터 전송에 더 빠르기 때문에 UDP 프로토콜에만 의존합니다. TCP는 전송되는 각 데이터 패킷에 대해 확인을 요구하여 VPN 연결 속도를 크게 늦출 수 있습니다. UDP는 수신 확인을 기다리지 않고 데이터를 전송하므로 WireGuard의 고속 특성에 적합합니다. Ubuntu 방화벽(UFW)을 설정할 때는 반드시 이 UDP 포트의 트래픽을 허용해야 하며, 그렇지 않으면 연결 요청이 VPN 소프트웨어에 도달하기 전에 차단됩니다.

6. WireGuard 연결 문제를 어떻게 해결하나요?

WireGuard 문제 해결은 이동 부품이 적기 때문에 일반적으로 간단합니다. 연결할 수 없는 경우, 다음 순서대로 점검을 수행해야 합니다:

먼저 서버에서 sudo wg show 명령을 실행하여 핸드셰이크 상태를 확인하세요. 연결이 정상이라면 latest handshake라는 문구와 함께 시간이 표시된 줄이 보일 것입니다(예: “1분 전”). 이 줄이 보이지 않는다면, 기기들이 전혀 통신하고 있지 않은 것입니다. 이는 거의 대부분 방화벽이 UDP 포트를 차단했거나 공개/개인 키가 일치하지 않아서 발생합니다.

둘째, 핸드셰이크가 정상적으로 작동하지만 인터넷을 사용할 수 없는 경우 문제는 IP 포워딩일 가능성이 높습니다. Ubuntu 서버가 VPN에서 인터넷으로 트래픽을 라우팅할 수 있도록 허용되어 있는지 확인해야 합니다. /etc/sysctl.conf 파일을 확인하고 net.ipv4.ip_forward=1 줄이 활성화되어 있는지(주석 처리되지 않았는지) 확인하면 이를 검증할 수 있습니다.

7. WireGuard는 Ubuntu에서 IPv6를 지원하나요?

네, WireGuard는 IPv6에 대한 뛰어난 지원을 제공합니다. 매우 유연하며 다양한 유형의 트래픽을 캡슐화(래핑)할 수 있습니다. 예를 들어, IPv6 연결을 통해 IPv4 전용 웹사이트에 접속하거나 그 반대로도 가능합니다. 이를 활성화하려면 구성 파일에 일반 IPv4 주소와 함께 쉼표로 구분된 IPv6 주소를 포함시키면 됩니다. 이 주소들은 서버 자체의 IP를 위한 Address 필드와 클라이언트 IP를 위한 AllowedIPs 필드 모두에 추가해야 합니다.

8. 부팅 시 WireGuard를 자동으로 시작하려면 어떻게 해야 하나요?

Ubuntu 서버를 다시 시작할 때 VPN이 자동으로 켜지도록 하려면 Linux의 시스템 관리자 역할을 하는 systemd를 사용해야 합니다. enable 명령을 사용하여 시스템에 특정 구성 파일(예: wg0)을 찾아 시작 시 로드하도록 지정할 수 있습니다. 이를 통해 서버가 업데이트로 재부팅되더라도 VPN 연결이 수동으로 시작할 필요 없이 자동으로 다시 온라인 상태가 됩니다.

sudo systemctl enable wg-quick@wg0

결론

이 튜토리얼에서는 Ubuntu 서버에 WireGuard VPN을 설정하고 IPv4와 IPv6를 모두 사용하여 피어를 연결했습니다. 과정 중에 키를 구성하고, 터널 주소를 할당하며, 서버가 트래픽을 안전하게 라우팅하도록 설정했습니다. 그 결과 이해하고 운영하기 쉬운 작업 가능한 VPN을 갖추게 되었습니다.

이 가이드는 또한 VPN을 일상적으로 사용할 때 중요한 몇 가지 실용적인 세부 사항도 다루었습니다. 예를 들어, 시간이 지남에 따라 키를 관리하는 방법, IPv6 및 듀얼 스택 네트워킹 처리, MTU 조정, keepalive, DNS 설정을 통해 신뢰성과 성능을 향상시키는 방법 등이 포함됩니다. 이러한 요소들을 갖추면 실제 환경에서 WireGuard를 원활하게 운영하거나 필요에 따라 조정할 준비가 충분히 된 것입니다.

WireGuard에 대해 더 배우고 싶다면, 더 고급 터널을 구성하는 방법이나 컨테이너와 함께 WireGuard를 사용하는 방법도 포함하여, 공식 WireGuard 문서를 방문하세요. Ubuntu 시스템 보안을 위한 추가 튜토리얼은 다음 글들을 확인해보세요:

• 우분투에서 UFW로 방화벽 설정하는 방법
• UFW 필수 사항: 리눅스 보안을 위한 일반적인 방화벽 규칙과 명령어
• VPC vs VPN: 어떤 것이 당신의 안전한 네트워킹 요구에 맞을까요?
• 우분투에서 OpenVPN 서버 설정 및 구성 방법

Linux-Console.net 커뮤니티와 함께 학습해 주셔서 감사합니다.