가이드

작성자 Matt Connor 2026-10-10

Linux VPS에 WireGuard VPN 직접 구축하기

Q: WireGuard 핸드셰이크가 완료되지 않는 이유는 무엇입니까?

wg show에서 피어를 나열했음에도 latest handshake이 없는 것은 패킷이 도착하지 않거나 수락되지 않음을 의미합니다. VPS 방화벽과 제공업체의 별도 네트워크 방화벽에서 UDP 51820 포트를 확인하고, Endpoint 호스트와 포트가 정확한지 확인하십시오. 그 후 키가 서로 바뀌지 않았는지 확인하십시오. 클라이언트의 [Peer] 블록에는 반드시 서버의 공개 키가 포함되어야 합니다. 서버에서 sudo tcpdump -ni any udp port 51820를 실행하면 패킷이 실제로 도착하는지 확인할 수 있습니다. dmesg는 동적 디버그(echo module wireguard +p | sudo tee /sys/kernel/debug/dynamic_debug/control)를 활성화한 후에만 WireGuard의 핸드셰이크 실패를 보고하며, 이때 키가 일치하지 않으면 invalid-MAC 드롭으로 표시됩니다.

Q: 터널은 연결되는데 인터넷이 되지 않습니다. 무엇이 문제입니까?

ping 10.8.0.1은 작동하는데 ping 1.1.1.1에서 시간 초과가 발생한다면 포워딩이나 NAT 설정 문제일 가능성이 큽니다. sysctl net.ipv4.ip_forward 값이 1으로 설정되어 있는지 확인하고, 단순히 sysctl -w 명령어로 설정하여 재부팅 시 초기화되지 않도록 /etc/sysctl.d/에 영구적으로 설정하십시오. 그 후 ip route show default, enp1s0 또는 ens3(드물게 eth0)에서 실제 외부 통신용 인터페이스를 찾아 매스커레이드(masquerade) 규칙을 확인하십시오.

Q: 클라이언트 설정에 DNS = 줄이 꼭 필요합니까?

전체 터널링을 사용하면서 DNS = 줄이 없으면, 클라이언트는 로컬 네트워크에서 학습한 리졸버를 그대로 유지합니다. 이 경우 다른 모든 데이터는 터널을 통하지만 DNS 쿼리는 로컬 링크를 통해 평문으로 전송됩니다. DNS를 공개 리졸버로 지정하거나, 10.8.0.1에 바인딩된 unbound/dnsmasq을 실행하고 입력 체인에서 udp dport 53 iifname "wg0"을 여십시오.

Q: AllowedIPs는 실제로 어떤 역할을 합니까?

이 설정은 두 가지 작업을 수행합니다. 아웃바운드 측면에서는 라우팅 테이블 역할을 하여, 피어의 AllowedIPs와 일치하는 트래픽을 암호화한 뒤 해당 피어로 전송합니다. 인바운드 측면에서는 접근 제어 목록(ACL) 역할을 하여, 복호화된 패킷의 발신지가 해당 피어의 AllowedIPs 범위를 벗어나면 패킷을 폐기합니다. 이것이 서버 측에서는 클라이언트마다 /32을 나열하고, 클라이언트 측에서는 0.0.0.0/0을 나열할 수 있는 이유입니다.

Linux VPS에서 WireGuard VPN을 직접 구축하는 방법을 상세히 안내합니다. 키 생성과 wg0.conf 설정부터 IP 포워딩, NAT 규칙, 방화벽 구성 및 흔히 발생하는 핸드셰이크 오류 해결법까지 실무적인 핵심 설정 과정을 모두 다룹니다.

구축할 내용

직접 소유한 서버에 WireGuard VPN을 구축하는 과정은 약 40줄의 설정으로 이루어집니다. 키 쌍 1개, 인터페이스 파일 1개, sysctl 설정 1개, NAT 규칙 1개, 방화벽 포트 개방 1개가 필요합니다. 설치 자체는 간단하므로, 이 가이드의 대부분은 발생 가능한 문제, 키 권한, AllowedIPs, 포워딩 및 DNS 설정에 할애합니다.

WireGuard는 Linux 5.6 버전부터 메인라인에 포함된 커널 수준의 Layer 3 터널입니다. 따라서 Ubuntu 24.04나 Debian 13에서는 별도의 외부 모듈 없이 바로 사용할 수 있습니다. 암호화 방식 협상, 인증 기관(CA), 사용자 이름/비밀번호 단계가 없으며, 피어는 공개 키와 해당 키가 사용할 수 있는 IP 주소의 조합으로 정의됩니다. MAC 검사에 실패한 패킷은 응답 없이 폐기되므로, 포트 스캔을 수행해도 아무런 응답을 하지 않습니다. 반면, 별도의 인증 서버가 존재하지 않으므로 접근 권한을 제거하려면 서버에서 해당 피어를 삭제해야 합니다.

가상화 환경을 먼저 확인하십시오

WireGuard는 커널 모듈을 로드할 수 있는 환경이 필요하며, KVM VPS에서는 별도의 설정 없이 바로 작동합니다. 호스트 커널을 공유하는 컨테이너 가상화 방식인 OpenVZ나 LXC에서는 첫 번째 명령이 RTNETLINK answers: Operation not supported 오류와 함께 실패하며, 이 경우 wireguard-go 사용자 공간 구현을 대체제로 사용해야 합니다. 먼저 sudo modprobe wireguard && echo ok 명령으로 확인하십시오.

키를 유출하지 않고 생성하기

읽기 권한이 모두에게 열린 /etc/wireguard/server.key는 VPN을 전혀 사용하지 않는 것과 같습니다. 일반적인 umask 077 && wg genkey | sudo tee ... 명령 줄은 정상적으로 작동합니다. sudoers에서 umask_override를 설정하지 않으면(기본값은 꺼짐) sudo는 사용자의 umask와 자체 기본값인 0022를 결합하며, 이보다 권한을 낮추지 않습니다. 따라서 tee가 생성하는 파일은 모드 600이 됩니다. 키가 유출되는 경우는 umask 077 없이 일반적인 022 umask 환경에서 해당 파이프를 실행하거나, sudoers에서 umask_override을 켠 서버에서 실행할 때 발생합니다. 모드를 명시적으로 설정하면 이러한 문제는 더 이상 중요하지 않습니다.

sudo apt update && sudo apt install -y wireguard nftables
sudo install -d -m 700 /etc/wireguard
sudo sh -c 'umask 077; wg genkey > /etc/wireguard/server.key'
sudo sh -c 'wg pubkey < /etc/wireguard/server.key > /etc/wireguard/server.pub'
sudo chmod 600 /etc/wireguard/server.key

클라이언트 키 쌍도 같은 방식으로 생성하십시오. wg genpsk는 선택 사항인 사전 공유 키(pre-shared key)를 추가하며, 각 설정 파일에 한 줄씩 입력합니다.

서버 인터페이스: /etc/wireguard/wg0.conf

[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = <contents of /etc/wireguard/server.key>

[Peer]
PublicKey = <laptop public key>
PresharedKey = <psk, optional>
AllowedIPs = 10.8.0.2/32

chmod 600 설정을 마친 뒤에는 파일 권한을 확인하십시오. 파일이 모든 사용자에게 읽기 권한이 있다는 경고가 시작 시 출력된다면 권한 설정을 건너뛴 것입니다. Address는 터널 내부에서 사용할 서버의 주소이며, 전체 VPN 서브넷의 마스크를 포함합니다. 실제 네트워크 환경에서 마주치지 않을 대역을 선택하십시오. 192.168.1.0/24는 클라이언트가 위치한 가정용 공유기의 절반과 충돌하며, 이 경우 터널은 로컬 경로와의 통신에서 조용히 실패하게 됩니다.

서버 측에서 피어의 AllowedIPs는 해당 클라이언트가 소유한 단일 터널 주소인 /32로 설정해야 합니다. 두 피어에 동일한 허용 IP를 부여하면 마지막으로 설정된 피어로 연결이 이동하며, 먼저 설정된 피어는 아무런 오류 메시지 없이 트래픽 수신이 중단됩니다. SaveConfig는 설정하지 않은 상태로 두십시오. 그렇지 않으면 wg-quick down이 현재 실행 중인 상태를 바탕으로 이 파일을 덮어씁니다.

서버를 라우터로 전환하기

Linux 서버는 자신에게 향하지 않은 패킷을 폐기합니다. 기본적으로 패킷 포워딩과 소스 NAT 기능은 비활성화되어 있습니다.

printf 'net.ipv4.ip_forward = 1\nnet.ipv6.conf.all.forwarding = 1\n' \
  | sudo tee /etc/sysctl.d/99-wireguard.conf
sudo sysctl --system
sysctl net.ipv4.ip_forward

단순한 sysctl -w 설정은 재부팅 전까지만 작동하며 이후에는 조용히 중단됩니다. NAT 설정에는 wg0가 아닌 인터넷에 연결된 외부 인터페이스(egress interface)가 필요합니다. eth0을 가정하지 마십시오. 최신 이미지에서는 enp1s0 또는 ens3와 같은 이름을 사용하므로 ip route show default에서 직접 확인해야 합니다.

방화벽: 포트와 전달 경로

하나의 nftables 파일에서 필터와 NAT를 모두 설정한다. /etc/nftables.conf를 실행하면 기존 ruleset이 flush되므로, 이미 ufw 또는 Docker가 관리하는 서버에서는 이 작업을 건너뛴다.

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    iif lo accept
    tcp dport 22 accept
    udp dport 51820 accept
  }
  chain forward {
    type filter hook forward priority filter; policy drop;
    ct state established,related accept
    iifname "wg0" oifname "enp1s0" accept
  }
}

table ip nat {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    ip saddr 10.8.0.0/24 oifname "enp1s0" masquerade
  }
}

두 번째 SSH 세션을 열어 둔 상태에서 sudo systemctl enable --now nftables로 적용한다. policy drop와 SSH 규칙의 오타가 겹치면 자신의 서버에 접속하지 못하게 된다. forward chain이 허용하지 않는 항목, 즉 wg0에서 wg0로의 전달을 확인한다. 피어는 서로가 아니라 인터넷에 접근한다. 피어 간 VPN이 필요하면 iifname "wg0" oifname "wg0" accept을 추가한다. 피어가 서버 자체에서 접근할 수 있는 대상을 결정하는 것은 이 chain의 역할이 아니다. 서버를 대상으로 한 패킷은 forward가 아니라 input hook을 통과하므로 input chain이 결정한다. 현재 설정에서는 피어가 SSH에만 접근할 수 있고 다른 항목은 허용하지 않는다. 10.8.0.1로 ping을 보내는 것도 허용하지 않는다. 여기에 iifname "wg0" icmp type echo-request accept를 추가하고, 터널을 통해서만 접근할 수 있어야 하는 서비스마다 iifname "wg0" 규칙을 하나씩 추가한다. 이는 서버를 tmux에서 Claude Code를 실행하는 원격 개발 서버로도 사용하는 경우에 중요하다. 서버의 해당 부분을 외부에 공개하지 않는 편이 낫기 때문이다.

ufw를 사용하는 서버에서는 ufw allow 51820/udp, /etc/default/ufw에 DEFAULT_FORWARD_POLICY="ACCEPT"를 추가하고, /etc/ufw/before.rules 맨 위에 *nat POSTROUTING MASQUERADE 규칙을 추가한다.

systemd를 통한 서비스 구동

sudo systemctl enable --now wg-quick@wg0
sudo wg show

wg-quick는 인터페이스를 생성하고 주소를 추가하며 AllowedIPs에서 파생된 경로를 설치합니다. enable --now는 중요한 절반의 역할을 합니다. 수동으로 실행한 wg-quick up wg0는 재부팅 후 사라지며, 커널 업그레이드 시에는 재부팅이 필수적입니다. 재부팅 후 다시 시작되지 않는 유닛은 누군가 연결을 시도하기 전까지 침묵을 지킵니다. 따라서 자신의 ntfy 서버를 가리키는 wg-quick@wg0의 OnFailure= 드롭인 설정은, 차단된 사용자로부터 연락을 받기 전에 휴대폰으로 문제를 인지할 수 있는 가장 저렴한 방법입니다.

클라이언트 설정과 모두가 실수하는 설정

[Interface]
PrivateKey = <laptop private key>
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

AllowedIPs은 두 가지 작업을 동시에 수행하며, 이 둘을 혼동하는 것이 WireGuard 설정에서 발생하는 대부분의 혼란의 원인입니다.

아웃바운드 측면에서 이는 라우팅 테이블입니다. 대상 주소가 피어의 AllowedIPs와 일치하는 패킷은 암호화되어 해당 피어로 전송됩니다. 0.0.0.0/0, ::/0은 모든 트래픽을 터널로 보내는 풀 터널(full tunnel) 방식으로, 서버를 기본 경로로 설정합니다. 스플릿 터널(split tunnel)은 더 좁은 범위의 목록을 사용합니다. AllowedIPs = 10.8.0.0/24, 10.20.0.0/16은 VPN 트래픽과 서버 뒤의 사설 네트워크 하나를 처리하며, 그 외의 모든 트래픽은 기존 로컬 경로를 유지합니다. 이러한 좁은 범위의 목록을 사용하면 서비스를 공용 인터넷에서 완전히 격리할 수 있습니다. 예를 들어 터널 주소에 바인딩된 VPS의 비공개 Nextcloud 인스턴스나 동일한 장비에서 실행 중인 중첩 가상화 랩 VM은 피어에게는 접근 가능하게 유지하면서 다른 외부 사용자에게는 보이지 않게 할 수 있습니다.

인바운드 측면에서 이는 접근 제어 목록(ACL)입니다. 피어로부터 복호화된 패킷의 출발지 주소가 해당 피어의 AllowedIPs에 포함되어 있지 않으면 패킷은 폐기됩니다. 서버가 노트북을 위해 10.8.0.2/32을 나열하는 이유가 바로 이것입니다. 만약 여기에 0.0.0.0/0를 설정하면 해당 클라이언트가 터널 내의 어떤 주소로든 스푸핑(spoofing)할 수 있게 됩니다.

PersistentKeepalive는 NAT 뒤에 있는 클라이언트를 위한 설정입니다. NAT 환경에서는 패킷이 흐를 때만 라우터가 UDP 매핑을 유지하기 때문입니다. 매핑이 만료되면 서버는 더 이상 클라이언트에 도달할 수 없습니다. PersistentKeepalive = 25는 이 매핑을 유지하는 역할을 합니다. 이 설정은 공인 IP를 가진 서버가 아닌 클라이언트에 적용하십시오.

DNS와 아무도 눈치채지 못하는 유출

AllowedIPs = 0.0.0.0/0이 있고 DNS = 라인이 없으면, 클라이언트는 로컬 네트워크에서 학습한 리졸버인 192.168.1.1의 카페 라우터를 계속 사용합니다. 해당 경로는 기본 경로보다 더 구체적이므로, 다른 모든 트래픽은 터널링되지만 DNS 쿼리는 로컬 링크를 통해 평문으로 전송됩니다. 트래픽은 비공개 상태이지만, 조회한 도메인 이름 목록은 그렇지 않습니다.

두 가지 정직한 방법이 있습니다. DNS를 퍼블릭 리졸버(DNS = 9.9.9.9)로 지정하면 쿼리가 터널을 타고 서버에서 나가게 되지만, 해당 리졸버는 여전히 쿼리 내용을 볼 수 있습니다. 또는 unbound이나 dnsmasq를 10.8.0.1에 바인딩하여 실행하고, DNS = 10.8.0.1를 설정한 뒤, 입력 체인(input chain)에 udp dport 53 iifname "wg0" accept를 추가하십시오. 해당 라인을 설정하고 리졸버를 잊어버리면, 아무것도 해석되지 않습니다.

Linux 클라이언트에서 wg-quick은 DNS을 통해 resolvconf을 적용합니다. 이 설정이 없으면 resolvconf: command not found가 적용됩니다. openresolv을 설치하거나, systemd-resolved를 사용하는 클라이언트라면 PostUp = resolvectl dns %i 10.8.0.1을 설정하십시오.

터널 연결을 끊지 않고 피어 추가 및 제거하기

인터페이스를 재시작하여 사용자를 추가하면 연결된 모든 사용자의 접속이 끊깁니다. [Peer] 블록을 wg0.conf에 추가한 다음, 피어 세트를 현재 상태에서 다시 로드하십시오.

sudo bash -c 'wg syncconf wg0 <(wg-quick strip wg0)'

wg-quick strip는 wg-quick 전용 키(Address, DNS, PostUp)를 제외한 설정을 출력하며, syncconf은 라이브 세션을 유지하면서 변경 사항을 적용합니다. 이 명령은 피어만 업데이트합니다. Address가 변경된 경우에는 여전히 전체 down/up 과정이 필요합니다. sudo wg set wg0 peer <public key> remove으로 피어 권한을 취소한 뒤, 파일에서 해당 블록을 삭제하십시오. 삭제하지 않으면 다음 번 다시 로드 시 해당 피어가 다시 생성됩니다.

실패 유형 및 확인 가능한 메시지

핸드셰이크가 완료되지 않음. wg show은 피어를 나열하지만 latest handshake이 없으며, 클라이언트 로그에는 다음이 기록됩니다.

Handshake for peer 1 (10.0.0.10:51820) did not complete after 5 seconds, retrying (try 2)

데이터가 도착하지 않거나 수락되지 않는 경우입니다. 다음 순서대로 확인하십시오. VPS 방화벽과 제공업체의 네트워크 방화벽(대부분의 제어판에서 별도로 관리됨)에서 UDP 51820 포트가 열려 있는지 확인합니다. Endpoint 주소와 포트가 올바른지, 키가 서로 바뀌지 않았는지 확인하십시오. 클라이언트의 [Peer] 블록에 있는 키는 반드시 서버의 공개 키여야 하며, 그 반대도 마찬가지입니다. 개인 키를 붙여넣거나 클라이언트 자신의 공개 키를 넣으면 정확히 이 증상이 나타납니다. 서버에서 sudo tcpdump -ni any udp port 51820를 실행하면 패킷이 실제로 도착하는지 확인할 수 있습니다. 커널 모듈은 기본적으로 아무것도 기록하지 않습니다. WireGuard 메시지는 동적 디버그(echo module wireguard +p | sudo tee /sys/kernel/debug/dynamic_debug/control)를 활성화한 후에만 dmesg에 나타나며, 이 상태에서 키가 일치하지 않으면 잘못된 MAC으로 인한 폐기 메시지가 표시됩니다.

핸드셰이크는 성공하나 인터넷이 안 됨. ping 10.8.0.1은 성공하지만 ping 1.1.1.1에서 시간 초과가 발생한다면 포워딩이나 NAT 설정이 누락된 것입니다. sysctl net.ipv4.ip_forward의 값이 1인지 확인하고, 클라이언트가 핑을 보내는 동안 sudo nft list ruleset 또는 sudo iptables -t nat -L POSTROUTING -n -v를 사용하여 카운터 변화를 관찰하십시오. 매스커레이드(masquerade) 규칙의 패킷 카운터가 0이라면 송신 인터페이스 이름이 잘못된 것입니다. 카운터는 올라가는데 응답이 없다면 포워드 체인 정책을 확인해야 합니다.

인터넷은 되는데 도메인 이름 해석이 안 됨. ping 1.1.1.1은 성공하지만 curl https://example.com가 Could not resolve host를 반환하는 경우입니다. DNS 줄이 누락되었거나, 터널 내부에서 도달할 수 없는 리졸버를 지정한 것입니다.

일부 HTTPS 사이트에서 응답이 없음. SSH와 핑은 정상인데 큰 페이지를 불러올 때 멈추는 현상입니다. 이는 경로 MTU 문제입니다. 터널은 오버헤드를 추가하는데, 중간의 링크가 ICMP 메시지 반환 없이 너무 큰 패킷을 폐기하기 때문입니다. 클라이언트 [Interface]에 MTU을 설정하십시오. 일반적인 1500바이트 링크에서는 wg-quick가 이미 1420(1500에서 오버헤드 80바이트를 뺀 값)을 선택하므로 1420을 적어도 변화가 없습니다. 1380를 시도한 뒤 1280을 시도하십시오. MTU를 낮춰서 멈춤 현상이 해결되었는데도 처리량이 만족스럽지 않다면, 임의의 숫자를 추측하지 말고 이분법으로 실제 경로 MTU를 찾아 TCP MSS를 고정하는 방법을 따르십시오. 이 방법은 터널 외적인 원인도 배제할 수 있게 해줍니다.

인터페이스가 시작되지 않음. Address already in use는 다른 프로세스가 UDP 51820 포트를 점유하고 있음을 의미합니다. up 실패 후 Cannot find device wg0가 나타난다면 설정이 거부된 것이므로 journalctl -u wg-quick@wg0 -n 50을 읽어보십시오.

Streisand 또는 OpenVPN에서 마이그레이션

Streisand는 더 이상 유지보수되지 않으며 저장소도 보관 처리되었습니다. 업데이트가 중단된 자동화 도구로 VPN을 운영하는 것은 보안상 심각한 위험을 초래합니다. 제자리 업그레이드는 불가능하며, OpenVPN의 PKI는 변환할 수 없습니다. WireGuard는 인증서, CA, 만료 개념이 없으므로 모든 클라이언트는 새로운 키 쌍을 발급받아야 합니다.

병렬로 마이그레이션을 진행하십시오. UDP 51820 포트의 WireGuard는 동일한 서버에서 1194 포트의 OpenVPN과 공존할 수 있습니다. wg0을 구축하고 클라이언트를 하나씩 이동시킨 뒤, 기존 서비스를 중단하십시오. OpenVPN의 사용자 이름/비밀번호 및 폐기 모델은 그대로 이전되지 않습니다. 계정 관리나 감사 추적이 필요하다면 WireGuard 상위 계층에서 해당 기능을 구현하십시오.

백업, 업그레이드 및 규모 확장에서 발생하는 부담

/etc/wireguard이 서버다. 이를 백업하고(sudo tar czf wg-backup.tgz -C /etc wireguard, mode 600, 서버 외부에 보관) 새 VPS에서 몇 분 안에 다시 구축할 수 있다. 서버의 private key를 잃으면 모든 클라이언트 설정을 다시 발급해야 한다. 클라이언트가 서버의 public key를 고정하기 때문이다. 업그레이드는 일반적인 apt upgrade에 커널 업데이트를 위한 재부팅을 더하는 방식이다. wg-quick@wg0을 활성화했다면 재부팅 후 자동으로 다시 실행된다.

피어별 상태 정보는 작고 암호화 연산은 kernel에서 실행되므로, 한계는 이 설정의 요소가 아니라 VPS의 CPU와 bandwidth 할당량이다. 공개된 수치를 그대로 믿지 말고 터널을 통해 iperf3을 실행해 측정한다. 규모가 커질 때 부담이 되는 부분은 운영이다. 모든 피어에는 고유한 tunnel IP가 필요하다. 60개의 [Peer] 블록을 수동으로 편집하면 AllowedIPs 중복이 생기기 쉬우므로 설정을 script로 생성한다. 서버 하나는 UDP endpoint 하나이자 단일 장애 지점이다. WireGuard에는 clustering 기능이 없으므로 redundancy를 구성하려면 자체 key를 사용하는 두 번째 서버가 필요하다. key rotation은 수동으로 수행해야 한다. 어떤 사용자가 어떤 key를 보유하는지와 해당 key를 폐기하는 방법을 기록한다. 이러한 관리 정보가 text file로 감당하기 어려워지면, 일반적으로 같은 kernel data plane 위에 control plane을 추가한다. self-hosted NetBird server는 수동으로 처리하던 address allocation, peer distribution 및 setup key 관리를 수행한다. control plane을 직접 운영하는 것이 서버 한 대를 더 관리하는 일이 된다면 Tailscale이 대신 하나를 운영한다. Tailscale의 무료 Personal plan은 6명의 사용자와 사용자별 무제한 기기를 지원하며, 시작할 때 최대 50개의 서버 같은 tagged resource도 지원하므로 대부분의 개인용 환경에서는 비용을 지불할 필요가 없다. 이 범위를 넘으면 비용은 머신 수가 아니라 사용자 수를 기준으로 증가한다. 따라서 가정이나 소규모 팀이 실제로 지불하는 비용은 wg0.conf에 수동으로 입력했을 피어 수가 아니라 login을 보유한 사람 수에 따라 결정된다. 이 환경에서는 split-tunnel AllowedIPs 관리가 subnet router에서 private range를 advertising하는 방식으로 바뀐다. 한 VPS에서 한 번만 공지하고 중앙에서 승인하므로 모든 client file에 내용을 붙여 넣을 필요가 없다. 이 방식이 적합한지는 hosted control plane이 실제로 접근할 수 있는 범위에 따라 달라진다. control plane은 트래픽을 암호화하는 key를 보유하지 않지만 어떤 피어가 서로의 정보를 학습할지는 결정한다.

이 모든 작업에는 사용자가 제어하는 Linux 서버, public IP, module을 load할 수 있는 kernel, 그리고 처음부터 끝까지 직접 관리하는 firewall이 필요하다.

FAQ

WireGuard 핸드셰이크가 완료되지 않는 이유는 무엇입니까?

wg show에서 피어를 나열했음에도 latest handshake이 없는 것은 패킷이 도착하지 않거나 수락되지 않음을 의미합니다. VPS 방화벽과 제공업체의 별도 네트워크 방화벽에서 UDP 51820 포트를 확인하고, Endpoint 호스트와 포트가 정확한지 확인하십시오. 그 후 키가 서로 바뀌지 않았는지 확인하십시오. 클라이언트의 [Peer] 블록에는 반드시 서버의 공개 키가 포함되어야 합니다. 서버에서 sudo tcpdump -ni any udp port 51820를 실행하면 패킷이 실제로 도착하는지 확인할 수 있습니다. dmesg는 동적 디버그(echo module wireguard +p | sudo tee /sys/kernel/debug/dynamic_debug/control)를 활성화한 후에만 WireGuard의 핸드셰이크 실패를 보고하며, 이때 키가 일치하지 않으면 invalid-MAC 드롭으로 표시됩니다.

터널은 연결되는데 인터넷이 되지 않습니다. 무엇이 문제입니까?

ping 10.8.0.1은 작동하는데 ping 1.1.1.1에서 시간 초과가 발생한다면 포워딩이나 NAT 설정 문제일 가능성이 큽니다. sysctl net.ipv4.ip_forward 값이 1으로 설정되어 있는지 확인하고, 단순히 sysctl -w 명령어로 설정하여 재부팅 시 초기화되지 않도록 /etc/sysctl.d/에 영구적으로 설정하십시오. 그 후 ip route show default, enp1s0 또는 ens3(드물게 eth0)에서 실제 외부 통신용 인터페이스를 찾아 매스커레이드(masquerade) 규칙을 확인하십시오.

클라이언트 설정에 `DNS =` 줄이 꼭 필요합니까?

전체 터널링을 사용하면서 DNS = 줄이 없으면, 클라이언트는 로컬 네트워크에서 학습한 리졸버를 그대로 유지합니다. 이 경우 다른 모든 데이터는 터널을 통하지만 DNS 쿼리는 로컬 링크를 통해 평문으로 전송됩니다. DNS를 공개 리졸버로 지정하거나, 10.8.0.1에 바인딩된 unbound/dnsmasq을 실행하고 입력 체인에서 udp dport 53 iifname "wg0"을 여십시오.

`AllowedIPs`는 실제로 어떤 역할을 합니까?

이 설정은 두 가지 작업을 수행합니다. 아웃바운드 측면에서는 라우팅 테이블 역할을 하여, 피어의 AllowedIPs와 일치하는 트래픽을 암호화한 뒤 해당 피어로 전송합니다. 인바운드 측면에서는 접근 제어 목록(ACL) 역할을 하여, 복호화된 패킷의 발신지가 해당 피어의 AllowedIPs 범위를 벗어나면 패킷을 폐기합니다. 이것이 서버 측에서는 클라이언트마다 /32을 나열하고, 클라이언트 측에서는 0.0.0.0/0을 나열할 수 있는 이유입니다.

모든 VPS에서 WireGuard를 실행할 수 있습니까?

KVM 기반 VPS에서는 커널 모듈을 통해 별도의 추가 설정 없이 작동합니다. OpenVZ나 LXC처럼 호스트 커널을 공유하는 컨테이너 가상화 환경에서는 modprobe wireguard가 Operation not supported 오류와 함께 실패할 수 있으며, 이 경우 wireguard-go 사용자 공간 구현체를 대체 수단으로 사용할 수 있습니다. 다른 작업을 수행하기 전에 sudo modprobe wireguard && echo ok를 먼저 실행하십시오.

#wireguard #vpn #linux-networking #nftables #systemd #self-hosting