wireguard docs
1.0.0
예제와 함께 설정, 구성, 사용법을 포함한 WireGuard용 API 참조 가이드입니다.
모든 크레딧은 WireGuard 프로젝트인 zx2c4와 원본 소프트웨어의 오픈 소스 기여자에게 돌아갑니다.
이것은 보다 포괄적인 문서, API 참조 및 예제를 제공하려는 나의 단독 비공식 시도입니다.
이러한 문서, 예제 코드 및 문제 추적기의 소스: https://github.com/pirate/wireguard-docs 더 나은 HTML 페이지 버전: https://docs.sweeting.me/s/wireguard
WireGuard는 Jason Donenfeld와 다른 사람들이 C로 작성한 오픈 소스 VPN 솔루션으로, IPSec/IKEv2, OpenVPN 또는 L2TP와 같은 다른 최신 서버 간 VPN 제품을 괴롭힌 많은 문제를 해결하는 것을 목표로 합니다. Tinc 및 MeshBird와 같은 다른 최신 VPN 제품과 몇 가지 유사점, 즉 우수한 암호화 제품군 및 최소 구성을 공유합니다. 2020-01년 현재 Linux 커널 5.6 버전에 병합되었습니다. 즉, 대부분의 Linux 시스템과 함께 기본적으로 제공됩니다.
공식 링크
wg , wg-quickWireGuard 목표
예제 코드 및 문서 소스는 https://github.com/pirate/wireguard-docs를 참조하세요.
중국의 만리장성 뒤에 거주하든 단순히 서버 간에 네트워크를 형성하려고 하든 WireGuard는 훌륭한 옵션이며 네트워크 구축을 위한 "레고 블록" 역할을 합니다(ZFS가 파일 시스템 구축을 위한 레고 블록인 것과 거의 같습니다). ).
WireGuard가 수행하지 않는 작업:
하지만 내부적으로 WireGuard(예: Tailscale 또는 AltheaNet)를 사용하여 이러한 문제에 대한 솔루션을 직접 작성할 수 있습니다.
이는 설명서 및 예제 구성에 사용되는 데모 호스트 이름, 도메인 이름, IP 주소 및 범위입니다. 자체 설정을 수행할 때 원하는 값으로 바꾸십시오.
example-vpn.dev 는 귀하가 제어하는 공개적으로 액세스 가능한 도메인으로 대체될 수 있습니다.public-server1 , public-server2 , home-server , laptop , phone 장치 호스트 이름으로 변경할 수 있습니다.192.0.2.1/24 , 192.0.2.3 , 192.0.2.3/32 , 2001:DB8::/64 원하는 서브넷 및 주소로 바꿀 수 있습니다(예: 192.168.5.1/24 )아래에서 이러한 문자열을 볼 때마다 예를 설명하기 위한 자리 표시자 값으로 사용되며 특별한 의미는 없습니다.
구성에서 IP 주소를 변경하세요! 이 문서에 사용된 블록은 IETF에서 예시 목적으로 예약되어 있으므로 실제 네트워크 설정에서는 절대 사용해서는 안 됩니다.
192.0.2.0/24 ) IPv4 예제 범위 RFC57372001:DB8::/32 IPv6 예제 범위 RFC3849 자신의 설정에 원하는 개인 범위(예: 10.0.44.0/24 를 사용할 수 있습니다. 피어가 있는 LAN 서브넷 범위와 충돌하지 않는지 확인하세요.
VPN에 연결하고 자신을 위해 192.0.2.3 과 같은 VPN 서브넷 주소를 등록하는 호스트입니다. 또한 선택적으로 쉼표로 구분된 CIDR 표기법으로 서브넷 범위를 지정하여 자체 주소 이상으로 트래픽을 라우팅할 수도 있습니다.
NAT 뒤의 다른 VPN 피어에 대한 릴레이 트래픽에 대한 대체 역할을 하는 공개적으로 연결 가능한 피어/노드입니다. 반송 서버는 특별한 유형의 서버가 아니며 다른 모든 서버와 마찬가지로 일반 피어입니다. 유일한 차이점은 공용 IP가 있고 커널 수준 IP 전달이 켜져 있어 트래픽을 VPN으로 다시 반송할 수 있다는 것입니다. 다른 고객에게.
자세히 보기: https://tailscale.com/blog/how-nat-traversal-works/(Tailscale은 내부적으로 Wireguard를 사용합니다)
공용 인터넷과 분리된 IP 그룹입니다(예: 192.0.2.1-255 또는 192.168.1.1/24). 일반적으로 라우터가 제공하는 NAT 뒤에 있습니다(예: 사무실 인터넷 LAN 또는 홈 Wi-Fi 네트워크).
"마스크"를 사용하여 서브넷과 그 크기를 정의하는 방법으로, 더 작은 마스크 = 서브넷에서 사용할 수 있는 더 많은 주소 비트 및 범위 내 더 많은 IP입니다. 가장 일반적인 것:
192.0.2.1/32 (단일 IP 주소, 192.0.2.1 ) 넷마스크 = 255.255.255.255192.0.2.1/24 - 192.0.2.255 192.0.2.0 255개 IP) 넷마스크 = 255.255.255.0192.0.2.1/16 - 192.0.255.255 192.0.0.0 IP 65,536개) 넷마스크 = 255.255.0.0192.0.2.1/8 - 192.255.255.255 의 IP 192.0.0.0 개) 넷마스크 = 255.0.0.00.0.0.1/0 ( 0.0.0.0 - 255.255.255.255 의 4,294,967,296 IP) 넷마스크 = 0.0.0.02001:DB8::/64https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing
이제 막 시작한 사람들에게는 192.0.2.1/32 단일 IP를 참조하는 이상하고 혼란스러운 방법처럼 보일 수 있습니다. 하지만 이 디자인은 여러 표기법 없이도 필요한 경우 피어가 여러 IP를 노출할 수 있기 때문에 좋습니다. 192.0.2.3/32 와 같은 것을 볼 수 있는 곳은 실제로 192.0.2.3 의미한다는 점만 알아두세요.
네트워크 주소 변환을 수행하는 앞에 있는 라우터에서 제공하는 개인 IP가 있는 서브넷, 개별 노드는 인터넷에서 공개적으로 액세스할 수 없습니다. 대신 라우터는 나가는 연결을 추적하고 응답을 올바른 내부 IP(예: 표준 사무실 네트워크)로 전달합니다. , 가정용 Wi-Fi 네트워크, 무료 공용 Wi-Fi 네트워크 등)
공개적으로 액세스할 수 있는 주소: 노드의 포트(예: 123.124.125.126:1234 또는 some.domain.tld:1234 (공용 인터넷을 통해 액세스할 수 있어야 하며 일반적으로 192.0.2.1 또는 192.168.1.1 과 같은 개인 IP일 수 없습니다. 동일한 서브넷의 다른 피어가 해당 주소를 사용하여 직접 액세스할 수 있습니다.
다음을 사용하여 생성된 단일 노드에 대한 WireGuard 개인 키: wg genkey > example.key (생성된 노드를 떠나지 않음)
다음을 사용하여 생성된 단일 노드에 대한 WireGuard 공개 키: wg pubkey < example.key > example.key.pub (다른 피어와 공유)
DNS 요청이 VPN 외부로 유출되어 트래픽이 노출되는 것을 허용하는 대신 VPN 클라이언트의 호스트 이름을 IP로 확인하는 데 사용되는 도메인 이름 서버. 누출은 http://dnsleak.com에서 테스트할 수 있습니다.
공개 릴레이는 NAT 뒤의 VPN 클라이언트 사이에서 중간 릴레이 서버 역할을 할 수 있는 일반 VPN 피어일 뿐이며, 시스템 수준에서 수신하는 모든 VPN 서브넷 트래픽을 올바른 피어로 전달할 수 있습니다(WireGuard는 이것이 어떻게 발생하는지 상관하지 않습니다). , 커널 net.ipv4.ip_forward = 1 및 iptables 라우팅 규칙에 의해 처리됩니다.
모든 피어에 공개적으로 액세스할 수 있는 경우 그 중 하나를 릴레이 서버로 만들기 위해 특별한 처리를 걱정할 필요가 없으며 NAT 뒤에서 연결하는 피어가 있는 경우에만 필요합니다.
각 클라이언트는 해당 구성에서 공개적으로 액세스 가능한 서버/피어만 정의하면 됩니다. NAT 뒤의 다른 피어에 바인딩된 모든 트래픽은 공개 릴레이 AllowedIPs 경로의 포괄 VPN 서브넷(예: 192.0.2.1/24 )으로 이동하여 그에 따라 전달됩니다. 일단 릴레이 서버에 도달하면.
요약: 클라이언트 간의 직접 연결만 구성해야 하며, 바운스가 필요한 모든 연결은 피어로 정의되어서는 안 됩니다. 먼저 바운스 서버로 향하고 거기에서 다시 VPN을 통해 올바른 클라이언트로 라우팅되어야 하기 때문입니다.
더 복잡한 토폴로지도 가능하지만 일반적인 WireGuard 설정에 사용되는 기본 라우팅 방법은 다음과 같습니다.
Endpoint 주소 및 포트로 직접 액세스 가능한 노드를 정의합니다.public-server2 에 연결되는 경우) 하드코딩된 Endpoint 로 공개적으로 액세스 가능한 노드를 정의하고 엔드포인트가 없는 NAT 노드를 정의합니다. NAT 클라이언트 -> 퍼블릭 클라이언트에서 연결이 열리고, NAT 클라이언트에서 나가는 PersistentKeepalive 핑을 통해 연결이 유지되는 한 트래픽은 양방향으로 직접 라우팅됩니다.public-server1 에 대한 연결을 열어야 하며 연결이 유지되는 한 트래픽은 중간 바운스 서버를 통해 전달됩니다. 살아있습니다. 사용 가능한 경우 다른 피어가 제공하는 보다 구체적인(일반적으로 보다 직접적인) 경로가 우선 적용됩니다. 그렇지 않으면 트래픽은 가장 덜 구체적인 경로로 대체되고 192.0.2.1/24 캐치올을 사용하여 트래픽을 바운스 서버로 전달합니다. 릴레이 서버의 시스템 라우팅 테이블( net.ipv4.ip_forward = 1 )에 의해 VPN을 통해 해당 트래픽에 대한 경로를 허용하는 특정 피어로 라우팅됩니다. WireGuard는 가장 빠른 경로를 자동으로 찾거나 아직 정의되지 않은 경우 피어 간의 직접 연결을 형성하려고 시도하지 않으며 단지 [Peers] 에서 가장 구체적인 경로에서 가장 덜 구체적인 경로로 이동합니다.
핑 시간을 측정하여 각 홉의 고유한 길이를 파악하고 다음의 출력을 검사하여 WireGuard가 특정 주소에 대해 어떤 라우팅 방법을 사용하고 있는지 알아낼 수 있습니다.
wg show wg0WireGuard는 모든 트래픽에 암호화된 UDP 패킷을 사용하지만, 암호화된 터널 내의 TCP 연결에 의해 처리되므로 패킷 전달이나 순서에 대한 보장을 제공하지 않습니다.
추가 자료:
WireGuard는 대부분의 다른 경쟁 VPN 솔루션보다 더 빠른 성능을 주장하지만 정확한 숫자는 때때로 논쟁의 여지가 있으며 특정 암호화 암호에 하드웨어 수준 가속을 사용할 수 있는지 여부에 따라 달라질 수 있습니다.
WireGuard의 성능 향상은 커널 수준에서 라우팅을 처리하고 모든 코어에서 실행되는 최신 암호 제품군을 사용하여 트래픽을 암호화함으로써 달성됩니다. 또한 WireGuard는 배달/주문 보장 없이 UDP를 사용함으로써 상당한 이점을 얻습니다(TCP를 통해 실행되거나 자체 보장된 배달 메커니즘을 구현하는 VPN과 비교).
추가 자료:
WireGuard는 다음 프로토콜과 기본 요소를 사용하여 트래픽을 보호합니다.
WireGuard의 암호화는 본질적으로 Trevor Perrin의 Noise 프레임워크를 인스턴스화한 것입니다. 현대적이며 다시 한번 단순해졌습니다. 다른 모든 VPN 옵션은 협상과 핸드셰이킹이 복잡하고 상태 시스템이 복잡합니다. WireGuard는 VPN의 Signal/Axolotl과 유사합니다. 단, 이중 래칫 메시징 프로토콜보다 추론하기가 훨씬 더 간단하고 쉽습니다(이 경우 암호화 방식으로). 기본적으로 VPN 소프트웨어의 큐메일입니다. 그리고 그것은 ~4000줄의 코드입니다. 경쟁사보다 훨씬 작은 규모입니다.
https://news.ycombinator.com/item?id=14599834
추가 자료:
양방향 인증은 각 피어에 대한 간단한 공개/개인 키 쌍을 통해 달성됩니다. 각 피어는 설정 단계에서 이러한 키를 생성하고 공개 키만 다른 피어와 공유합니다.
각 노드의 공개/개인 키 외에 다른 인증서나 사전 공유 키가 필요하지 않습니다.
Ansible 또는 Kubernetes Secrets와 같은 별도의 서비스를 사용하여 대규모 배포에서 키 생성, 배포 및 해지를 처리할 수 있습니다.
키 배포 및 배포에 도움이 되는 일부 서비스:
wg0.conf 에 하드코딩하고 싶지 않은 경우 파일이나 명령을 통해 키를 읽을 수도 있습니다. 이렇게 하면 타사 서비스를 통해 키를 관리하는 것이 훨씬 쉬워집니다.
[Interface]
...
PostUp = wg set %i private-key /etc/wireguard/wg0.key <(cat /some/path/%i/privkey)기술적으로 클라이언트가 동일한 키를 가진 두 서버에 동시에 연결되지 않는 한 여러 서버가 동일한 개인 키를 공유할 수 있습니다. 이것이 합리적인 설정 시나리오의 예는 라운드 로빈 DNS를 사용하여 단일 서버인 것처럼 가장하는 두 서버 간의 연결 부하를 분산하는 경우입니다. 그러나 대부분의 경우 모든 피어에는 자체 공개/개인 키 쌍이 있어야 피어가 서로의 트래픽을 읽을 수 없고 개별적으로 취소될 수 있습니다.
일반 프로세스 개요:
apt install wireguard 또는 pkg/brew install wireguard-tools 설치합니다.wg genkey + wg pubkey 에서 로컬로 공개 및 개인 키 생성wg0.conf WireGuard 구성 파일을 생성합니다.[Interface] 서버가 Address = 192.0.2.1/24 에 대한 경로를 허용하는 주소를 정의할 때 전체 VPN 서브넷에 대해 CIDR 범위를 지정해야 합니다.[Peer] 해당 원격 공개 키를 사용하여 VPN에 참여하는 모든 클라이언트에 대한 피어 섹션을 만듭니다.wg0.conf 생성합니다.[Interface] 트래픽을 릴레이하지 않는 클라이언트 피어에 대해 단일 IP만 지정해야 합니다 Address = 192.0.2.3/32 .[Peer] NAT 뒤에 있지 않은 각 공용 피어에 대한 피어 섹션을 생성하고, 바운스 서버 AllowedIPs = 192.0.2.1/24 역할을 하는 원격 피어를 정의할 때 전체 VPN 서브넷에 대한 CIDR 범위를 지정해야 합니다. 트래픽을 릴레이하지 않고 단순 클라이언트 역할만 수행하는 원격 피어에 대해 개별 IP를 지정해야 합니다 AllowedIPs = 192.0.2.3/32 .wg-quick up /full/path/to/wg0.conf 사용하여 기본 릴레이 서버에서 WireGuard를 시작합니다.wg-quick up /full/path/to/wg0.conf 사용하여 모든 클라이언트 피어에서 WireGuard를 시작합니다.ping 192.0.2.3 먼저 AllowedIPs = 192.0.2.3/32 인 피어에 대한 직접 경로를 확인한 다음 IP를 허용하는 릴레이 서버로 폴백합니다. 전체 서브넷에서 # install on Ubuntu
sudo add-apt-repository ppa:wireguard/wireguard
apt install wireguard
# install on macOS
brew install wireguard-tools
# install on FreeBSD
pkg install wireguard
# install on iOS/Android using Apple App Store/Google Play Store
# install on other systems using https://www.wireguard.com/install/#installation # to enable the kernel relaying/forwarding ability on bounce servers
echo " net.ipv4.ip_forward = 1 " | sudo tee -a /etc/sysctl.conf
echo " net.ipv4.conf.all.proxy_arp = 1 " | sudo tee -a /etc/sysctl.conf
sudo sysctl -p /etc/sysctl.conf
# to add iptables forwarding rules on bounce servers
sudo iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i wg0 -o wg0 -m conntrack --ctstate NEW -j ACCEPT
sudo iptables -t nat -A POSTROUTING -s 192.0.2.0/24 -o eth0 -j MASQUERADEnano wg0.conf # can be placed anywhere, must be referred to using absolute path (usually placed in /etc/wireguard/wg0.conf on most Linux systems) # generate private key
wg genkey > example.key
# generate public key
wg pubkey < example.key > example.key.pubwg-quick up /full/path/to/wg0.conf
wg-quick down /full/path/to/wg0.conf
# Note: you must specify the absolute path to wg0.conf, relative paths won't work
# If wg0.conf is in /etc/wireguard you can use the simpler:
wg-quick up wg0 # start/stop VPN network interface
ip link set wg0 up
ip link set wg0 down
# register/unregister VPN network interface
ip link add dev wg0 type wireguard
ip link delete dev wg0
# register/unregister local VPN address
ip address add dev wg0 192.0.2.3/32
ip address delete dev wg0 192.0.2.3/32
# register/unregister VPN route
ip route add 192.0.2.3/32 dev wg0
ip route delete 192.0.2.3/32 dev wg0 # show system LAN and WAN network interfaces
ip address show
# or if ip is not available:
ifconfig
# show system VPN network interfaces
ip link show wg0
# or
ifconfig wg0
# show WireGuard VPN interfaces
wg show all
wg show wg0 # show public IP address
ip address show eth0
# or
ifconfig eth0
# or
dig -4 +short myip.opendns.com @resolver1.opendns.com
# show VPN IP address
ip address show wg0 # show WireGuard routing table and peer connections
wg show
wg show wg0 allowed-ips
# show system routing table
ip route show table main
ip route show table local
# show system route to specific address
ip route get 192.0.2.3추가 로깅을 활성화하려면 다음을 실행하세요.
modprobe wireguard
echo module wireguard +p > /sys/kernel/debug/dynamic_debug/control로그를 따르려면 다음 안내를 따르세요.
dmesg -wH최신 커널 및 안전 부팅을 사용하는 시스템에서는 커널 로그에 액세스하려면 보안 부팅 DKMS 서명 확인을 비활성화해야 할 수도 있습니다.
mokutil --disable-verification
reboot # check that the main relay server is accessible directly via public internet
ping public-server1.example-vpn.dev
# check that the main relay server is available via VPN
ping 192.0.2.1
# check that public peers are available via VPN
ping 192.0.2.2
# check that remote NAT-ed peers are available via VPN
ping 192.0.2.3
# check that NAT-ed peers in your local LAN are available via VPN
ping 192.0.2.4 # install iperf using your preferred package manager
apt/brew/pkg/opkg install iperf
# check bandwidth over public internet to relay server
iperf -s # on public relay server
iperf -c public-server1.example-vpn.dev # on local client
# check bandwidth over VPN to relay server
iperf -s # on public relay server
iperf -c 192.0.2.1 # on local client
# check bandwidth over VPN to remote public peer
iperf -s # on remote public peer
iperf -c 192.0.2.2 # on local client
# check bandwidth over VPN to remote NAT-ed peer
iperf -s # on remote NAT-ed peer
iperf -c 192.0.2.3 # on local client
# check bandwidth over VPN to local NAT-ed peer (on same LAN)
iperf -s # on local NAT-ed peer
iperf -c 192.0.2.4 # on local client http://dnsleak.com을 사용하거나 조회 시 확인자를 확인하여 DNS 누출을 확인하세요.
dig example.com A WireGuard 구성은 일반적으로 wg0.conf 라는 파일에 정의된 INI 구문으로 되어 있습니다. 이는 시스템의 어느 곳에나 배치될 수 있지만 /etc/wireguard/wg0.conf 에 배치되는 경우가 많습니다.
구성 경로는 wg-quick 명령을 실행할 때 인수로 지정됩니다. 예:
wg-quick up /etc/wireguard/wg0.conf (항상 전체 절대 경로 지정)
구성 파일 이름은 ${name of the new WireGuard interface}.conf 형식이어야 합니다. WireGuard 인터페이스 이름은 일반적으로 wg 접두사가 붙고 0 부터 시작하는 번호가 지정되지만 정규식 ^[a-zA-Z0-9_=+.-]{1,15}$ 와 일치하는 모든 이름을 사용할 수 있습니다.
구성 파일은 WireGuard를 시작하는 데 선호되는 명령에 따라 제한된 wg 구성 옵션 세트 또는 더 확장된 wg-quick 옵션을 사용하도록 선택할 수 있습니다. 이 문서에서는 더 강력하고 사용자 친화적인 구성 경험을 제공하는 wg-quick 사용할 것을 권장합니다.
정의로 이동:
¶ [Interface]
¶ # Name = node1.example.tld
¶ Address = 192.0.2.3/32
¶ ListenPort = 51820
¶ PrivateKey = localPrivateKeyAbcAbcAbc=
¶ DNS = 1.1.1.1,8.8.8.8
¶ Table = 12345
¶ MTU = 1500
¶ PreUp = /bin/example arg1 arg2 %i
¶ PostUp = /bin/example arg1 arg2 %i
¶ PreDown = /bin/example arg1 arg2 %i
¶ PostDown = /bin/example arg1 arg2 %i
¶ [Peer]
¶ # Name = node2-node.example.tld
¶ AllowedIPs = 192.0.2.1/24
¶ Endpoint = node1.example.tld:51820
¶ PublicKey = remotePublicKeyAbcAbcAbc=
¶ PersistentKeepalive = 25
[Interface]로컬 노드에 대한 VPN 설정을 정의합니다.
예
[Interface]
# Name = phone.example-vpn.dev
Address = 192.0.2.5/32
PrivateKey = <private key for phone.example-vpn.dev> [Interface]
# Name = public-server1.example-vpn.tld
Address = 192.0.2.1/24
ListenPort = 51820
PrivateKey = <private key for public-server1.example-vpn.tld>
DNS = 1.1.1.1# Name이는 어떤 구성 섹션이 어떤 노드에 속하는지 추적하는 데 사용되는 INI 구문의 표준 주석일 뿐이며 WireGuard에서는 완전히 무시되며 VPN 동작에 영향을 주지 않습니다.
참고: # Name 포함한 모든 주석은 특정 작업 및 응용 프로그램에 의해 .conf 파일에서 제거됩니다. 피어를 식별해야 하는 경우 호스트의 공개 키에 호스트 이름을 포함할 수 있는 wireguard-vanity-keygen 또는 wireguard-vanity-address와 같은 wireguard 배니티 키 생성기 사용을 고려하세요. 키 생성에는 몇 분(4자), 몇 시간(5자) 이상이 걸릴 수 있으므로 이름이 긴 호스트에는 약어를 사용하는 것이 좋습니다.
Address로컬 노드가 트래픽을 라우팅해야 하는 주소 범위를 정의합니다. 노드가 VPN 서브넷에 가입하는 단순 클라이언트인지, 여러 클라이언트 간에 트래픽을 중계하는 바운스 서버인지에 따라 노드 자체의 단일 IP(CIDR 표기법으로 지정)로 설정할 수 있습니다(예: 192.0.2.3/32). ) 또는 노드가 트래픽을 라우팅할 수 있는 IPv4/IPv6 서브넷 범위입니다.
예
노드는 자신에게만 트래픽을 라우팅하는 클라이언트입니다.
Address = 192.0.2.3/32
노드는 트래픽을 다른 피어에게 전달할 수 있는 공용 바운스 서버입니다.
노드가 공용 바운스 서버로 작동하는 경우 이를 자체적으로 단일 IP가 아닌 트래픽을 라우팅할 수 있는 전체 서브넷으로 설정해야 합니다.
Address = 192.0.2.1/24
Address = 192.0.2.1/24,2001:DB8::/64ListenPort노드가 공용 바운스 서버로 작동하는 경우 공용 인터넷에서 들어오는 VPN 연결을 수신하기 위해 포트를 하드코딩해야 합니다. 릴레이 역할을 하지 않는 클라이언트는 이 값을 설정하면 안 됩니다.
예
ListenPort = 51820ListenPort = 7000PrivateKey이는 로컬 노드의 개인 키이며 다른 서버와 공유되지 않습니다. 모든 노드에는 트래픽을 릴레이하는 공개 바운스 서버인지, VPN에 참여하는 단순 클라이언트인지에 관계없이 개인 키 세트가 있어야 합니다.
이 키는 wg genkey > example.key 로 생성할 수 있습니다.
예
PrivateKey = somePrivateKeyAbcdAbcdAbcdAbcd=
DNSDHCP를 통해 VPN 클라이언트에 알리는 DNS 서버. 대부분의 클라이언트는 VPN을 통한 DNS 요청에 이 서버를 사용하지만 클라이언트는 노드에서 로컬로 이 값을 재정의할 수도 있습니다.
예
DNS = 1.1.1.1DNS = 1.1.1.1,8.8.8.8Table선택적으로 WireGuard 경로에 사용할 라우팅 테이블을 정의합니다. 대부분의 설정에서는 구성할 필요가 없습니다.
두 가지 특수 값이 있습니다. 'off'는 경로 생성을 완전히 비활성화하고 'auto'(기본값)는 기본 테이블에 경로를 추가하고 기본 경로의 특수 처리를 활성화합니다.
https://git.zx2c4.com/WireGuard/about/src/tools/man/wg-quick.8
예
Table = 1234MTU선택적으로 피어에 연결할 때 사용할 최대 전송 단위(MTU, 즉 패킷/프레임 크기)를 정의하며 대부분의 설정에서는 구성할 필요가 없습니다.
MTU는 일반적으로 올바른 선택인 엔드포인트 주소 또는 시스템 기본 경로에서 자동으로 결정됩니다.
https://git.zx2c4.com/WireGuard/about/src/tools/man/wg-quick.8
예
MTU = 1500PreUp선택적으로 인터페이스가 시작되기 전에 명령을 실행하십시오. 이 옵션은 파일에 나타나는 순서대로 명령을 실행하여 여러 번 지정할 수 있습니다.
예
PreUp = ip rule add ipproto tcp dport 22 table 1234 PostUp선택적으로 인터페이스가 시작된 후 명령을 실행하십시오. 이 옵션은 PreUp과 마찬가지로 여러 번 나타날 수 있습니다.
예
파일이나 일부 명령의 출력에서 구성 값을 읽습니다.
PostUp = wg set %i private-key /etc/wireguard/wg0.key <(some command here)
파일에 한 줄 기록
PostUp = echo "$(date +%s) WireGuard Started" >> /var/log/wireguard.log
다른 서버에서 웹훅 적중
PostUp = curl https://events.example.dev/wireguard/started/?key=abcdefg
시스템 라우팅 테이블에 경로 추가
PostUp = ip rule add ipproto tcp dport 22 table 1234
WireGuard 인터페이스에서 패킷 전달을 활성화하려면 iptables 규칙을 추가하세요.
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
WireGuard가 피어 도메인의 IP 주소를 다시 확인하도록 강제
PostUp = resolvectl domain %i "~."; resolvectl dns %i 192.0.2.1; resolvectl dnssec %i yes
PreDown선택적으로 인터페이스가 종료되기 전에 명령을 실행합니다. 이 옵션은 PreUp과 마찬가지로 여러 번 나타날 수 있습니다.
예
파일에 한 줄 기록
PostDown = echo "$(date +%s) WireGuard Going Down" >> /var/log/wireguard.log
다른 서버에서 웹훅 적중
PostDown = curl https://events.example.dev/wireguard/stopping/?key=abcdefg
PostDown선택적으로 인터페이스가 종료된 후 명령을 실행합니다. 이 옵션은 PreUp과 마찬가지로 여러 번 나타날 수 있습니다.
예
파일에 한 줄 기록
PostDown = echo "$(date +%s) WireGuard Stopped" >> /var/log/wireguard.log
다른 서버에서 웹훅 적중
PostDown = curl https://events.example.dev/wireguard/stopped/?key=abcdefg
WireGuard 인터페이스에서 패킷을 전달하는 iptables 규칙을 제거합니다.
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
[Peer]하나 이상의 주소(자체 및/또는 다른 피어)에 대한 트래픽을 라우팅할 수 있는 원격 피어에 대한 VPN 설정을 정의합니다. 피어는 트래픽을 다른 피어로 릴레이하는 공용 바운스 서버이거나 NAT 뒤에 있지 않고 자체 트래픽만 라우팅하는 LAN/인터넷을 통해 직접 액세스할 수 있는 클라이언트일 수 있습니다.
모든 클라이언트는 공용 바운스 서버에서 피어로 정의되어야 합니다. 자신에 대한 트래픽만 라우팅하는 간단한 클라이언트는 공개 릴레이 및 직접 액세스할 수 있는 다른 노드에 대한 피어만 정의하면 됩니다. 별도의 NAT 뒤에 있는 노드는 공용 서버 구성 외부의 피어로 정의되어서는 안 됩니다. 별도의 NAT 간에는 직접 경로를 사용할 수 없기 때문입니다. 대신 NAT 뒤의 노드는 공용 릴레이 서버 및 기타 공용 클라이언트만 피어로 정의해야 하며 VPN 서브넷에 대한 경로를 허용하고 원격 NAT 연결로의 트래픽을 반송하는 공용 서버에서 AllowedIPs = 192.0.2.1/24 지정해야 합니다. 동료.
요약하면 모든 노드는 기본 바운스 서버에 정의되어야 합니다. 클라이언트 서버에서는 노드에서 직접 액세스할 수 있는 피어만 해당 노드의 피어로 정의되어야 하며, 바운스 서버에 의해 중계되어야 하는 모든 피어는 제외되어야 하며 중계 서버의 캐치올 경로에 의해 처리됩니다.
아래 문서에 설명된 구성에서 단일 서버 public-server1 공개적으로 액세스 가능한 클라이언트와 NAT 클라이언트가 혼합된 릴레이 바운스 서버 역할을 하며 그에 따라 각 노드에 피어가 구성됩니다.
public-server1 wg0.conf (바운스 서버)
[peer] 목록: public-server2 , home-server , laptop , phone
public-server2 wg0.conf (간단한 공용 클라이언트)
[peer] 목록: public-server1
home-server wg0.conf (NAT 뒤의 단순 클라이언트)
[peer] 목록: public-server1 , public-server2
laptop wg0.conf (NAT 뒤의 단순 클라이언트)
[peer] 목록: public-server1 , public-server2
phone wg0.conf (NAT 뒤의 단순 클라이언트)
[peer] 목록: public-server1 , public-server2
예
[Peer]
# Name = public-server2.example-vpn.dev
Endpoint = public-server2.example-vpn.dev:51820
PublicKey = <public key for public-server2.example-vpn.dev>
AllowedIPs = 192.0.2.2/32 [Peer]
# Name = home-server.example-vpn.dev
Endpoint = home-server.example-vpn.dev:51820
PublicKey = <public key for home-server.example-vpn.dev>
AllowedIPs = 192.0.2.3/32 [Peer]
# Name = public-server1.example-vpn.tld
Endpoint = public-server1.example-vpn.tld:51820
PublicKey = <public key for public-server1.example-vpn.tld>
# routes traffic to itself and entire subnet of peers as bounce server
AllowedIPs = 192.0.2.1/24
PersistentKeepalive = 25# Name이는 어떤 구성 섹션이 어떤 노드에 속하는지 추적하는 데 사용되는 INI 구문의 표준 주석일 뿐이며 WireGuard에서는 완전히 무시되며 VPN 동작에 영향을 주지 않습니다.
Endpoint 원격 피어에 대해 공개적으로 액세스 가능한 주소를 정의합니다. 이는 NAT 뒤의 피어 또는 공개적으로 액세스 가능한 안정적인 IP:PORT 쌍이 없는 피어의 경우 제외되어야 합니다. 일반적으로 이는 기본 바운스 서버에서만 정의하면 되지만 아래 구성 예에서는 public-server2 와 같은 안정적인 IP를 사용하는 다른 공용 노드에서도 정의할 수 있습니다.
예
Endpoint = 123.124.125.126:51820 도 지원됨)Endpoint = public-server1.example-vpn.tld:51820AllowedIPs 이는 피어가 트래픽을 라우팅할 IP 범위를 정의합니다. 단순 클라이언트에서 이는 일반적으로 단일 주소(단순 클라이언트 자체의 VPN 주소)입니다. 바운스 서버의 경우 이는 릴레이 서버가 트래픽을 라우팅할 수 있는 IP 또는 서브넷의 범위입니다. 쉼표로 구분된 IPv4 또는 IPv6 CIDR 표기법을 사용하여 여러 IP 및 서브넷을 지정할 수 있습니다(단일 /32 또는 /128 주소부터 최대 0.0.0.0/0 까지 및 ::/0 모든 주소를 보낼 기본 경로를 나타냄). 해당 피어를 통한 인터넷 및 VPN 트래픽). 이 옵션은 여러 번 지정할 수 있습니다.
패킷 라우팅 방법을 결정할 때 시스템은 가장 구체적인 경로를 먼저 선택한 다음 더 넓은 경로로 대체합니다. 따라서 192.0.2.3 으로 향하는 패킷의 경우 시스템은 먼저 구체적으로 192.0.2.3/32 광고하는 피어를 찾고 다음과 같이 192.0.2.1/24 또는 0.0.0.0/0 과 같은 더 큰 범위를 광고하는 피어로 폴백합니다. 최후의 수단.
예
피어는 자신과의 트래픽만 허용하는 간단한 클라이언트입니다.
AllowedIPs = 192.0.2.3/32
피어는 VPN 트래픽을 다른 모든 피어로 반송할 수 있는 릴레이 서버입니다.
AllowedIPs = 192.0.2.1/24
피어는 IPv6를 포함하여 모든 인터넷 및 VPN 트래픽(예: 프록시)을 반송하는 릴레이 서버입니다.
AllowedIPs = 0.0.0.0/0,::/0
피어는 자신과 다른 피어 중 하나만 라우팅하는 릴레이 서버입니다.
AllowedIPs = 192.0.2.3/32,192.0.2.4/32
피어는 자신과 로컬 LAN의 모든 노드로 라우팅하는 릴레이 서버입니다.
AllowedIPs = 192.0.2.3/32,192.168.1.1/24
PublicKey이는 모든 피어와 공유할 수 있는 원격 노드의 공개 키입니다. 모든 노드에는 트래픽을 릴레이하는 공개 바운스 서버인지, VPN에 참여하는 단순 클라이언트인지에 관계없이 공개 키 세트가 있어야 합니다.
이 키는 wg pubkey < example.key > example.key.pub 사용하여 생성할 수 있습니다. (개인 키 example.key 를 생성하는 방법은 위를 참조하세요)
예
PublicKey = somePublicKeyAbcdAbcdAbcdAbcd=
PersistentKeepalive연결이 NAT 피어에서 공개 피어로 진행되는 경우 NAT 뒤의 노드는 NAT 라우터의 연결 테이블에서 양방향 연결을 유지하기 위해 정기적으로 나가는 핑을 보내야 합니다.
예
로컬 공용 노드에서 원격 공용 노드로
지속적인 핑이 필요하지 않으므로 이 값은 정의되지 않은 상태로 두어야 합니다.
로컬 공용 노드에서 원격 NAT 노드로
시간이 초과되면 서버가 클라이언트에 대한 끊어진 연결을 다시 열 수 없기 때문에 연결을 유지하는 것은 클라이언트의 책임이므로 이 값은 정의되지 않은 상태로 두어야 합니다.
로컬 NAT 노드에서 원격 공용 노드로
PersistentKeepalive = 25 이는 로컬 NAT 라우터의 연결 테이블에서 연결을 열어둔 상태로 25초마다 ping을 보냅니다.
이 문서의 예제는 주로 IPv4를 사용하지만 Wireguard는 기본적으로 IPv6 CIDR 표기법을 지원하고 IPv4를 지원하는 모든 곳에서 주소를 지원하므로 다른 서브넷 범위 또는 주소와 마찬가지로 추가하십시오.
예
[Interface]
Address = 192.0.2.3/24, 2001:DB8::/64
[Peer]
...
AllowedIPs = 0.0.0.0/0, ::/0 VPN을 통해 모든 인터넷 트래픽을 전달하려면 서버 간 서브넷으로 사용하지 않으려면 파이프하려는 피어의 AllowedIPs 정의에 0.0.0.0/0, ::/0 추가 할 수 있습니다. 당신의 트래픽.
VPN 외부의 IPv6 패킷 누출을 피하기 위해 IPv4 트래픽 만 전달할 때에도 IPv6 포획을 지정하십시오.
https://www.reddit.com/r/wireguard/comments/b0m5g2/ipv6_leaks_psa_for_anyone_here_using_wireguard_to/
예
[Interface]
# Name = phone.example-vpn.dev
Address = 192.0.2.3/32
PrivateKey = <private key for phone.example-vpn.dev>
[Peer]
# Name = public-server1.example-vpn.dev
PublicKey = <public key for public-server1.example-vpn.dev>
Endpoint = public-server1.example-vpn.dev:51820
AllowedIPs = 0.0.0.0/0, ::/0Wireguard는 때때로 공개 릴레이 서버가 필요없이 NAT 뒤에있는 두 클라이언트간에 기본적으로 연결할 수 있지만 대부분의 경우에는 불가능합니다. NAT-to-NAT 연결은 적어도 하나의 호스트가 안정적이고 공개적으로 접근 가능한 IP 주소를 갖는 경우에만 가능합니다. 포트 쌍은 미리 하드 코딩 할 수있는 포트 쌍, 동적 DNS로 업데이트 된 FQDN 또는 정적 공개 IP를 사용하는지 여부에 관계없이 미리 하드 코딩 할 수 있습니다. 나가는 패킷으로 열린 비 랜덤 화 된 NAT 포트는 모든 동료가 미리 전달할 수 있고 연결이 시작되면 변경되지 않는 한 모든 것이 작동합니다.
Wireguard에는 다른 호스트를 동적으로 검색하는 데 사용할 수있는 신호 레이어 또는 공개 스턴 서버가 없기 때문에 알려진 포트 및 주소는 미리 구성해야합니다. WebRTC는 두 NAT 간의 연결을 동적으로 구성 할 수있는 프로토콜의 예이지만 대역 외 신호 서버를 사용하여 각 호스트의 IP : 포트 콤보를 감지하여이를 수행합니다. Wireguard에는 이것을 가지고 있지 않으므로 하드 코딩 된 Endpoint + ListenPort (및 PersistentKeepalive 가 있으므로 비 활동 후 떨어지지 않음)에서만 작동합니다.
Tailscale의 Nat Traversal의 성경에서 자세히 알아보십시오 : https://tailscale.com/blog/how-nat-traversal-works/
Endpoint 정의해야합니다. 안정적인 IP 주소가없는 NAT 뒤에있는 경우 동적 DNS 또는 다른 솔루션을 사용하여 하나 이상의 피어를위한 안정되고 공개적으로 도메인/IP를 사용해야합니다.ListenPort 정의되어 있어야하며, NAT 라우터는 UDP 소스 포트 랜덤 화를 수행해서는 안됩니다. 그렇지 않으면 리턴 패킷이 하드 코드 된 ListenPort 로 전송되고 라우터가 로우터에 의해 떨어지는 대신 라우터에 의해 떨어지게됩니다. 나가는 패킷의 NatPersistentKeepalive 유지되는 것이 있어야하므로 NAT의 라우팅 테이블에 연결을 유지하기 위해 나가는 핑을 지속적으로 보내야합니다. 거부되는 초기 패킷을 보내는이 프로세스를 거부 한 다음 라우터가 응답을 수락하기위한 전달 규칙을 만들었다는 사실을 사용하여 "UDP 홀 펀칭"이라고합니다.
UDP 패킷을 전송하면 라우터 (일반적으로)는 소스 주소와 포트를 대상 주소 및 포트에 매핑하는 임시 규칙을 만듭니다. 대상 주소와 포트에서 돌아 오는 UDP 패킷 (및 다른 사람은 없음)이 원래 소스 주소 및 포트 (및 다른 사람도)로 전달됩니다. 이것은 대부분의 UDP 응용 프로그램이 NATS (예 : Bittorrent, Skype 등) 뒤에서 작동하는 방식입니다. 이 규칙은 몇 분 동안 비활성화 된 후 시간 초과되므로 NAT 뒤의 클라이언트는 정기적 인 나가는 패킷을 보내서 열어 두어야합니다 ( PersistentKeepalive 참조).
두 엔드 포인트가 NAT 또는 방화벽 뒤에있을 때이 작업을 수행하려면 두 엔드 포인트가 거의 동시에 각 영역에 패킷을 보내야합니다. 이는 양측이 각자의 공개 IP 주소와 포트 번호를 미리 알아야 함을 의미합니다. Wireguard의 경우 wg0.conf 의 양쪽에 대한 사전 정의 된 포트를 하드 코딩하여 달성됩니다.
2019 년 현재, 작동하는 데 사용되는 오래된 구멍 펀칭 방법은 더 이상 효과적이지 않습니다. 한 가지 예는 PWNAT에 의해 개척 된 새로운 방법으로, ICMP 시간이 Nat 외부에서 응답을 초과하여 패킷을 NAT의 피어에게 다시 통과시켜 자체 소스 포트를 누출했습니다. NAT-NAT 연결의 양쪽에 대한 하드 코딩 UDP 포트 및 공개 IP (위에서 설명한대로)는 여전히 소수의 네트워크에서 작동합니다. 일반적으로 네트워크가 "엔터프라이즈"가 많을수록 공개 UDP 포트 (상업용 공개 Wi-Fi 및 셀 데이터 NAT는 종종 작동하지 않음)를 구멍을 뚫을 가능성이 줄어 듭니다.
모든 엔드 포인트가 엄격한 UDP 소스 포트 무작위 화 (예 : 대부분의 셀룰러 데이터 네트워크)가있는 NAT 뒤에있는 경우 NAT-to-NAT 연결이 불가능합니다. 어느 쪽 어느 쪽도 ListenPort 하드 코드 할 수 없으며 NAT가 나가는 핑 후 해당 포트의 트래픽을 수락 할 것을 보장하기 때문에 피어 사이의 초기 구멍 펀치에 대한 포트를 조정할 수 없으며 연결이 실패 할 수 없습니다. 이러한 이유로 일반적으로 LTE/3G 네트워크에서 전화 간 연결을 수행 할 수는 없지만 사무실이나 홈에 안정적인 공개 IP가 있고 Dogn에서 전화 간 또는 전화 간 집을 할 수 있습니다. 'T는 소스 포트 무작위 배정을 수행합니다.
엄격한 소스 포트 무작위 배정이있는 NAT 뒤에서 NAT-to-NAT 연결이 가능하므로 각면에 상대방의 IP를 알리려면 신호 서버가 필요합니다 : 포트 튜플. 다음은 Wireguard를 사용하여이를 달성하는 몇 가지 구현입니다.
많은 사용자가 동적 IP가 변경 될 때마다 시작시 호스트 이름 만 해결하기 때문에 Wireguard를 다시 시작해야한다고보고합니다. Wireguard가 동적 DNS Endpoint 호스트 이름을 더 자주 재산하도록 강요하려면 PostUp 후크를 사용하여 몇 분 또는 몇 시간마다 Wireguard를 다시 시작할 수 있습니다.
클라이언트 및 서버에서 NetCat을 사용하여 구멍 펀칭 설정이 가능하는지 확인하여 양방향 연결을 열기 위해 포트 및 연결 순서가 작동하는 작업을 확인하십시오 : nc -v -u -p 51820 <address of peer2> 51820 실행하십시오. PEER1) 및 nc -v -u -l 0.0.0.0 51820 (PEER2)에서 두 창을 입력하여 양방향 트래픽이 발생할 수 있는지 확인하십시오. 어떤 피어가 초기 패킷을 보내는 지에 관계없이 작동하지 않으면 Wireguard가 공개 릴레이 서버 없이는 피어간에 작동 할 수 없습니다.
NAT-to-NAT 연결은 종종 더 불안정하고 다른 제한 사항이 있으므로 폴백 공개 릴레이 서버를 갖는 것이 여전히 권장됩니다.
예
Peer1 :
[Interface]
...
ListenPort 12000
[Peer]
...
Endpoint = peer2.example-vpn.dev:12000
PersistentKeepalive = 25Peer2 :
[Interface]
...
ListenPort 12000
[Peer]
...
Endpoint = peer1.example-vpn.dev:12000
PersistentKeepalive = 25 참고 :이 섹션은 동적 공개 Endpoint 주소가 아닌 VPN 서브넷 내 동적 피어 IP에 관한 것입니다 .
피어 IP (고정 된 피어 만있는 대신)의 동적 할당이 개발되고 있으며 WIP 구현은 여기에서 사용할 수 있습니다 : https://github.com/wireguard/wg-dynamic
PostUp 사용하여 런타임시 파일의 IP 값을 읽어 동적 할당 시스템을 직접 구축 할 수도 있습니다 (아래 참조).
예
[Interface]
...
PostUp = wg set %i allowed-ips /etc/wireguard/wg0.key <(some command) https://git.zx2c4.com/wireguard-go/about/
GO에 작성된 준수 사용자 랜드 와이어 가드 구현.
https://git.zx2c4.com/wireguard-rs/about/
Rust로 작성된 Wireguard의 불완전하고 불완전한 사용자 공간 구현 (대중을 대비하지 않음).
https://git.zx2c4.com/wireguard-hs/about/
Haskell (대중을 대비하지 않음)으로 작성된 Wireguard의 불완전하고 안전하지 않은 사용자 공간 구현.
https://github.com/cloudflare/boringtun
Rust (CloudFlare가 쓴 별도 포크)로 작성된 비준수의 독립적 인 와이어 가드 구현. https://blog.cloudflare.com/boringtun-userspace-wireguard-rust/를 참조하십시오.
플랫폼 별 와이어 가우드 앱
https://git.zx2c4.com/wireguard-ios/about/
https://git.zx2c4.com/wireguard-endroid/about/
https://git.zx2c4.com/wireguard-windows/about/
모든 사용자 공간 구현은 Kernel-Land에서 실행되는 기본 C 버전보다 느리지 만 사용자 랜드에서 실행하여 다른 이점을 제공합니다 (예 : 더 쉬운 컨테이너화, 호환성 등).
이들은 구성, 배포, 키 관리 및 연결을 지원하기 위해 Wireguard를 감싸는 일부 GUI 및 CLI 도구입니다.
이 바로 가기에 대한 크레딧은 https://www.ericlight.com/new-things-i-didnt-know-about-wireguard.html로 이동합니다
Wireguard는 공개 키가 인터페이스의 개인 키와 일치하는 피어를 무시합니다. 따라서 모든 곳에서 단일 피어 목록을 배포하고 각 서버에서 [Interface] 별도로 정의 할 수 있습니다.
https://lists.zx2c4.com/pipermail/wireguard/2018-december/003703.html을 참조하십시오
이것을 다음과 같은 wg addconf 와 결합 할 수 있습니다.
각 피어에는 자체 /etc/wireguard/wg0.conf 파일이 있으며 [Interface] 섹션 만 포함합니다.
각 피어에는 공유 /etc/wireguard/peers.conf 파일이 있으며 모든 피어가 포함되어 있습니다.
wg0.conf 파일에는 PostUp hook도 있습니다 : PostUp = wg addconf /etc/wireguard/peers.conf .
peers.conf , 적절한 오케스트레이션 플랫폼, Dropbox와 같은 보행자 또는 Ceph와 같은 야생의 것들을 통해 어떻게 공유하고 싶은지 결정하는 것은 당신에게 달려 있습니다. 나는 몰라도, 그러나 인터페이스와 동일인지 걱정하지 않고 피어 섹션을 격렬하게 날아갈 수 있다는 것은 꽤 좋습니다.
임의의 명령에서 구성 값을 설정하거나 파일의 값을 읽음으로써 Kubernetes Secrets 또는 AWS KMS와 같은 타사 서비스의 런타임 키에서 키를 읽을 수 있으므로 키 관리 및 배포를 훨씬 쉽게 할 수 있습니다.
https://lists.zx2c4.com/pipermail/wireguard/2018-december/003702.html을 참조하십시오
예
다음과 같은 작업을 수행하여 파일로 PrivateKey 읽을 수 있습니다.
PostUp = wg set %i private-key /etc/wireguard/wg0.key <(some command)
와이어 가드는 다양한 정도의 편안함으로 Docker에서 실행할 수 있습니다. 가장 간단한 경우, --privileged 및 --cap-add=all 인수를 Docker 명령에 추가하여 커널 모듈의로드를 활성화 할 수 있습니다.
설정은 다소 복잡해 질 수 있으며 달성하려는 것에 크게 의존합니다. 와이어 가드 자체가 컨테이너로 실행되고 호스트에 네트워크 인터페이스를 노출 시키거나 호스트에서 특정 컨테이너에 인터페이스를 노출시키는 와이어 가드를 실행할 수 있습니다.
Docker 컨테이너 vpn_test 의 예를 들어 Wireguard 릴레이 서버를 통해 모든 트래픽을 라우팅하는 예는 아래를 참조하십시오.
version : ' 3 '
services :
wireguard :
image : linuxserver/wireguard
ports :
- 51820:51820/udp
cap_add :
- NET_ADMIN
- SYS_MODULE
volumes :
- /lib/modules:/lib/modules
- ./wg0.conf:/config/wg0.conf:ro wg0.conf :
[Interface]
# Name = relay1.wg.example.com
Address = 192.0.2.1/24
ListenPort = 51820
PrivateKey = oJpRt2Oq27vIB5/ UVb7BRqCwad2YMReQgH5tlxz8YmI =
DNS = 1.1.1.1,8.8.8.8
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT ; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; ip6tables -A FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT ; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE; ip6tables -D FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
[Peer]
# Name = peer1.wg.example.com
PublicKey = I+hXRAJOG/UE2IQvIHsou2zTgkUyPve2pzvHTnd/ 2Gg =
AllowedIPs = 192.0.2.2/32 이 예에서는 speedtest 컨테이너 내부의 모든 트래픽이 Wireguard VPN을 통과합니다. 트래픽 만 라우팅하려면 아래 wg0.conf 의 0.0.0.0/0 VPN을 통해 라우팅하려는 서브넷 범위로 교체하십시오.
docker-compose.yml :
version : ' 3 '
services :
wireguard :
image : linuxserver/wireguard
cap_add :
- NET_ADMIN
- SYS_MODULE
volumes :
- /lib/modules:/lib/modules
- ./wg0.conf:/config/wg0.conf:ro
vpn_test :
image : curlimages/curl
entrypoint : curl -s http://whatismyip.akamai.com/
network_mode : ' service:wireguard ' wg0.conf :
[Interface]
# Name = peer1.wg.example.com
Address = 192.0.2.2/32
PrivateKey = YCW76edD4W7nZrPbWZxPZhcs32CsBLIi1sEhsV/ sgk8 =
DNS = 1.1.1.1,8.8.8.8
[Peer]
# Name = relay1.wg.example.com
Endpoint = relay1.wg.example.com:51820
PublicKey = zJNKewtL3gcHdG62V3GaBkErFtapJWsAx+ 2um0c0B1s =
AllowedIPs = 192.0.2.1/24,0.0.0.0/0
PersistentKeepalive = 21자세한 내용은 자세한 내용을 참조하십시오 : 아래 Docker Section.
자세한 지침은 위의 QuickStart 안내서 및 API 참조를 참조하십시오. 여기에서 전체 예제 설정을 여기에서 다운로드 할 수도 있습니다 : https://github.com/pirate/wireguard-example.
변경 사항 제안 : https://github.com/pirate/wireguard-docs/issues
