wireguard docs
1.0.0
Справочное руководство по API для WireGuard, включая настройку, настройку и использование, с примерами.
Вся заслуга принадлежит проекту WireGuard, zx2c4 и разработчикам открытого исходного кода оригинального программного обеспечения.
это моя единственная неофициальная попытка предоставить более полную документацию, ссылки на API и примеры.
Источник этой документации, пример кода и система отслеживания проблем: https://github.com/pirate/wireguard-docs. Удобная версия HTML-страницы: https://docs.sweeting.me/s/wireguard.
WireGuard — это VPN-решение с открытым исходным кодом, написанное на языке C Джейсоном Доненфельдом и другими и призванное исправить многие проблемы, с которыми сталкиваются другие современные предложения VPN типа «сервер-сервер», такие как IPSec/IKEv2, OpenVPN или L2TP. Он имеет некоторое сходство с другими современными предложениями VPN, такими как Tinc и MeshBird, а именно хорошие наборы шифров и минимальная конфигурация. Начиная с 2020-01 года он был объединен с версией ядра Linux 5.6, что означает, что он будет поставляться с большинством систем Linux «из коробки».
Официальные ссылки
wg , wg-quickЦели WireGuard
См. https://github.com/pirate/wireguard-docs для примера кода и источника документации.
Независимо от того, живете ли вы за Великой китайской стеной или просто пытаетесь создать сеть между вашими серверами, WireGuard является отличным вариантом и служит «блоком LEGO» для построения сетей (во многом так же, как ZFS является блоком LEGO для создания файловых систем). ).
Чего 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 (TEST-NET-1) Пример диапазона IPv4 RFC57372001:DB8::/32 Пример диапазона IPv6 RFC3849 Вы можете использовать любой частный диапазон для своих собственных настроек, например 10.0.44.0/24 , просто убедитесь, что они не конфликтуют ни с одним из диапазонов подсети локальной сети, в которых находятся ваши одноранговые узлы.
Хост, который подключается к VPN и регистрирует для себя адрес подсети VPN, например 192.0.2.3 . Он также может дополнительно маршрутизировать трафик не только по своему собственному адресу, указав диапазоны подсетей в нотации CIDR, разделенной запятыми.
Общедоступный узел/узел, который служит резервом для ретрансляции трафика для других узлов VPN за NAT. Сервер отказов не является особым типом сервера, это обычный одноранговый узел, как и все остальные, с той лишь разницей, что он имеет общедоступный 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, предоставляемым маршрутизатором, например, в офисной локальной сети Интернет или домашней сети Wi-Fi.
Способ определения подсети и ее размера с помощью «маски», меньшая маска = больше адресных битов, используемых подсетью, и больше IP-адресов в диапазоне. Наиболее распространенные:
192.0.2.1/32 (один IP-адрес, 192.0.2.1 ) маска сети = 255.255.255.255192.0.2.1/24 (255 IP-адресов от 192.0.2.0 до 192.0.2.255 ) маска сети = 255.255.255.0192.0.2.1/16 (65 536 IP-адресов от 192.0.0.0 до 192.0.255.255 ) маска сети = 255.255.0.0192.0.2.1/8 (16 777 216 IP-адресов от 192.0.0.0 до 192.255.255.255 ) сетевая маска = 255.0.0.00.0.0.1/0 (4 294 967 296 IP-адресов от 0.0.0.0 до 255.255.255.255 ) сетевая маска = 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 (должен быть доступен через общедоступный Интернет, обычно не может быть частным IP-адресом, например 192.0.2.1 или 192.168.1.1 если только он доступен напрямую по этому адресу другим узлам в той же подсети).
Закрытый ключ WireGuard для одного узла, сгенерированный с помощью: wg genkey > example.key (никогда не покидает узел, на котором он сгенерирован)
Открытый ключ WireGuard для одного узла, сгенерированный с помощью: wg pubkey < example.key > example.key.pub (совместно с другими узлами)
Сервер доменных имен, используемый для разрешения имен хостов в IP-адреса для VPN-клиентов, вместо того, чтобы позволять DNS-запросам просачиваться за пределы VPN и раскрывать трафик. Утечки можно проверить с помощью http://dnsleak.com.
Публичные ретрансляторы — это обычные узлы VPN, которые могут выступать в качестве промежуточного сервера ретрансляции между любыми VPN-клиентами за NAT. Они могут пересылать любой трафик подсети VPN, который они получают, правильному узлу на системном уровне (WireGuard не заботится о том, как это происходит). , это обрабатывается ядром net.ipv4.ip_forward = 1 и правилами маршрутизации iptables).
Если все узлы общедоступны, вам не нужно беспокоиться о специальной обработке, чтобы сделать один из них сервером ретрансляции, это необходимо только в том случае, если у вас есть узлы, подключающиеся из-за NAT.
Каждому клиенту необходимо только определить общедоступные серверы/узлы в своей конфигурации, любой трафик, связанный с другими узлами за NAT, будет направляться в общую подсеть VPN (например, 192.0.2.1/24 ) по маршруту AllowedIPs общедоступных реле и будет пересылаться соответствующим образом. как только он попадет на сервер ретрансляции.
Вкратце: следует настраивать только прямые соединения между клиентами, любые соединения, которые необходимо отклонить, не следует определять как одноранговые, поскольку они должны сначала направляться на сервер отказов, а оттуда направляться обратно по VPN к нужному клиенту.
Определенно возможны более сложные топологии, но это основные методы маршрутизации, используемые в типичных установках WireGuard:
Endpoint , чтобы WireGuard мог подключаться напрямую к открытому порту и маршрутизировать UDP-пакеты без промежуточных переходов.public-server2 ), определите общедоступный узел с жестко закодированной Endpoint и узел с NAT без него. Соединение будет открыто из клиента NAT -> общедоступный клиент, затем трафик будет маршрутизироваться напрямую между ними в обоих направлениях, пока соединение поддерживается за счет исходящих пингов PersistentKeepalive от клиента с поддержкой NAT.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 без каких-либо гарантий доставки/упорядочения (по сравнению с VPN, которые работают через TCP или реализуют свои собственные механизмы гарантированной доставки).
Дальнейшее чтение:
WireGuard использует следующие протоколы и примитивы для защиты трафика:
Криптография WireGuard, по сути, представляет собой реализацию фреймворка Noise Тревора Перрина. Это современно и, опять же, просто. Любой другой вариант VPN — это путаница переговоров, установлений связи и сложных конечных автоматов. WireGuard похож на Signal/Axolotl среди VPN, за исключением того, что его гораздо проще и легче рассуждать (в данном случае с точки зрения криптографии), чем протоколы обмена сообщениями с двойным храповым механизмом. По сути, это qmail программного обеспечения 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 pubkeywg0.conf WireGuard на главном сервере ретрансляции.[Interface] Обязательно укажите диапазон CIDR для всей подсети VPN при определении адреса, который сервер принимает маршруты для Address = 192.0.2.1/24[Peer] Создайте одноранговый раздел для каждого клиента, подключающегося к VPN, используя соответствующие удаленные открытые ключи.wg0.conf на каждом клиентском узле.[Interface] Обязательно укажите только один IP-адрес для узлов клиента, которые не ретранслируют трафик Address = 192.0.2.3/32 .[Peer] Создайте раздел однорангового узла для каждого общедоступного узла, не находящегося за NAT. Обязательно укажите диапазон CIDR для всей подсети VPN при определении удаленного узла, действующего в качестве сервера возврата, AllowedIPs = 192.0.2.1/24 . Обязательно укажите отдельные IP-адреса для удаленных узлов, которые не ретранслируют трафик и действуют только как простые клиенты. AllowedIPs = 192.0.2.3/32 .wg-quick up /full/path/to/wg0.confwg-quick up /full/path/to/wg0.confping 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 Secure Boot, чтобы разрешить доступ к журналам ядра.
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 Проверьте наличие утечек DNS с помощью http://dnsleak.com или проверив преобразователь при поиске:
dig example.com A Конфигурация WireGuard имеет синтаксис INI и определяется в файле, обычно называемом wg0.conf . Его можно разместить в любом месте системы, но часто он размещается в /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}$ .
Файлы конфигурации могут использовать ограниченный набор параметров конфигурации wg или более расширенные параметры wg-quick , в зависимости от того, какая команда предпочтительнее для запуска WireGuard. В этой документации рекомендуется придерживаться 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, например Wireguard-vanity-keygen или Wireguard-vanity-address, который позволит вам включить имя хоста в открытый ключ хоста. Генерация ключа может занять минуты (4 символа), часы (5 символов) или дольше, поэтому рассмотрите возможность использования сокращения для хостов с более длинными именами.
AddressОпределяет, для какого диапазона адресов локальный узел должен маршрутизировать трафик. В зависимости от того, является ли узел простым клиентом, присоединяющимся к подсети VPN, или сервером возврата, который ретранслирует трафик между несколькими клиентами, для него можно установить один IP-адрес самого узла (указанный в нотации CIDR), например 192.0.2.3/32. ) или диапазон подсетей IPv4/IPv6, для которых узел может маршрутизировать трафик.
Примеры
Node — это клиент, который маршрутизирует трафик только для себя.
Address = 192.0.2.3/32
Node — это общедоступный сервер возврата, который может ретранслировать трафик другим узлам.
Когда узел действует как общедоступный сервер возврата, он должен указать всю подсеть, в которую он может маршрутизировать трафик, а не только один 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=
DNSDNS-сервер(ы), которые будут объявлять VPN-клиентам через DHCP. Большинство клиентов будут использовать этот сервер для DNS-запросов через VPN, но клиенты также могут переопределить это значение локально на своих узлах.
Примеры
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
Добавьте правило iptables, чтобы включить пересылку пакетов на интерфейсе WireGuard.
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
Удалите правило iptables, которое пересылает пакеты на интерфейс WireGuard.
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 и маршрутизирует трафик только для себя.
Все клиенты должны быть определены как одноранговые узлы на общедоступном сервере возврата. Простым клиентам, которые маршрутизируют трафик только для себя, нужно только определить одноранговые узлы для общедоступного ретранслятора и любые другие узлы, доступные напрямую. Узлы, находящиеся за отдельными NAT, не следует определять как одноранговые узлы за пределами конфигурации общедоступного сервера, поскольку между отдельными NAT нет прямого маршрута. Вместо этого узлы за NAT должны определять только общедоступные серверы ретрансляции и других общедоступных клиентов в качестве своих одноранговых узлов и должны указывать AllowedIPs = 192.0.2.1/24 на общедоступном сервере, который принимает маршруты и перенаправляет трафик для подсети VPN на удаленный NAT. сверстники.
Таким образом, все узлы должны быть определены на главном сервере возврата. На клиентских серверах только одноранговые узлы, которые напрямую доступны из узла, должны быть определены как одноранговые узлы этого узла; любые одноранговые узлы, которые должны ретранслироваться сервером отказов, должны быть исключены и будут обрабатываться перехватывающим маршрутом сервера ретрансляции.
В конфигурации, описанной в документации ниже, один сервер 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. Обычно это необходимо определить только на главном сервере возврата, но его также можно определить на других общедоступных узлах со стабильными IP-адресами, например public-server2 в примере конфигурации ниже.
Примеры
Endpoint = 123.124.125.126:51820 (также поддерживается IPv6)Endpoint = public-server1.example-vpn.tld:51820AllowedIPs Это определяет диапазоны IP-адресов, для которых партнер будет маршрутизировать трафик. В простых клиентах это обычно один адрес (VPN-адрес самого простого клиента). Для серверов возврата это будет диапазон IP-адресов или подсетей, для которых сервер ретрансляции может маршрутизировать трафик. Несколько IP-адресов и подсетей могут быть указаны с использованием нотации IPv4 или IPv6 CIDR, разделенной запятыми (от одного адреса /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
одноранговый узел — это ретрансляционный сервер, который перенаправляет весь интернет-трафик и VPN-трафик (например, прокси), включая IPv6.
AllowedIPs = 0.0.0.0/0,::/0
одноранговый узел — это сервер ретрансляции, который маршрутизируется к самому себе и только к одному другому узлу.
AllowedIPs = 192.0.2.3/32,192.0.2.4/32
одноранговый узел — это сервер ретрансляции, который маршрутизирует к себе и ко всем узлам в своей локальной сети.
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 должен регулярно отправлять исходящий ping, чтобы поддерживать двунаправленное соединение в таблице соединений маршрутизатора NAT.
Примеры
локальный общедоступный узел к удаленному общедоступному узлу
Это значение следует оставить неопределенным, поскольку постоянные пинги не нужны.
локальный общедоступный узел на удаленный узел с NAT
Это значение следует оставить неопределенным, поскольку ответственность за поддержание соединения лежит на клиенте, поскольку сервер не может повторно открыть неработающее соединение с клиентом, если время ожидания истекло.
локальный узел с NAT на удаленный общедоступный узел
PersistentKeepalive = 25 будет отправлять пинг каждые 25 секунд, сохраняя соединение открытым в таблице подключений локального маршрутизатора NAT.
Примеры в этих документах в первую очередь используют IPv4, но Wireguard изначально поддерживает нотацию IPv6 CIDR и адресат везде, где он поддерживает IPv4, просто добавьте их, как и любой другой диапазон подсети или адрес.
Пример
[Interface]
Address = 192.0.2.3/24, 2001:DB8::/64
[Peer]
...
AllowedIPs = 0.0.0.0/0, ::/0 Если вы хотите переслать весь интернет-трафик через VPN, а не просто использовать его в качестве подсети сервера к серверу, вы можете добавить 0.0.0.0/0, ::/0 в определение AllowedIPs определения сверстника, который вы хотите Ваш трафик через.
Обязательно укажите улов IPv6, даже при пересылке трафика IPv4, чтобы избежать утечки пакетов IPv6 за пределами VPN, см.
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-Nat возможны только в том случае, если хотя бы у одного хоста есть стабильный, общедоступный IP-адрес: пара портов, которые могут быть жестко кодированы заранее, независимо от того, использует ли он FQDN, обновленный с помощью динамического DNS или статический публичный IP с Непонсируемый порт NAT, открытый исходящими пакетами, все работает, пока все сверстники могут передать его заранее, и он не меняется после начала соединения.
Известный порт и адрес должны быть настроены заранее, потому что у Wireguard нет сигнального уровня или общедоступных оглушенных серверов, которые можно использовать для динамического поиска других хостов. WEBRTC является примером протокола, который может динамически настроить соединение между двумя NAT, но он делает это с помощью внеполосного сигнального сервера для обнаружения комбо IP: порт каждого хоста. У Wireguard этого нет, поэтому он работает только с жесткой Endpoint + ListenPort (и PersistentKeepalive поэтому он не падает после бездействия).
Узнайте больше из Библии Tailscale от Nat Traversal: https://tailscale.com/blog/how-nat-traversal-works/
Endpoint . Если они оба позади Nats без стабильных IP -адресов, вам нужно использовать динамический DNS или другое решение, чтобы иметь стабильный, общедоступный домен/IP, по крайней мере, для одного узлаListenPort , и его маршрутизатор NAT не должен делать рандомизацию источника порта UDP, в противном случае возвратные пакеты будут отправлены на жесткий кодированный ListenPort и отброшены на маршрутизатор вместо использования случайного порта, назначенного Nat на исходящем пакетеPersistentKeepalive включенные для всех других сверстников, чтобы они постоянно посылали исходящих пингов, чтобы сохранить соединения, сохраняющиеся в таблице маршрутизации их NAT. Этот процесс отправки первоначального пакета, который отклоняется, а затем с использованием того факта, что маршрутизатор теперь создал правило пересылки для принятия ответов, называется «UDP-ударом».
Когда вы отправляете пакет UDP, маршрутизатор (обычно) создает временное сопоставление правил вашего адреса источника и порта на адрес назначения и порт, и наоборот. Пакеты UDP, возвращающиеся с адреса назначения и порта (и никакого другого), передаются по исходному адресу источника и порту (и никакого другого). Так функционирует большинство приложений UDP за NAT (например, BitTorrent, Skype и т. Д.). Это правило будет тайм -аутом после нескольких минут бездействия, поэтому клиент, стоящий за NAT, должен отправлять регулярные исходящие пакеты, чтобы держать его в открытии (см. PersistentKeepalive ).
Получение этого для работы, когда оба конечных точки находятся за NATS или брандмауэрами, требуется, чтобы оба конечных точки отправляли пакеты друг на друга примерно в одно и то же время. Это означает, что обе стороны должны заранее знать общедоступные IP-адреса и номера портов, в случае Wireguard это достигается за счет жестких предварительно определенных портов для обеих сторон в wg0.conf .
По состоянию на 2019 год, многие из старых методов, используемых для работы, которые использовались для работы, больше не эффективны. Одним из примеров был новый метод, впервые заправленный PWNAT, который подделал время ICMP, превысил ответ извне NAT, чтобы вернуть пакет обратно на национальный сверстник, тем самым протекая свой собственный исходный порт. В твердом кодировании портов UDP и публичных IPS для обеих сторон соединения Nat-Nat (как описано выше) все еще работает на небольшом проценте сетей. Как правило, чем больше «предприятия» сеть, тем меньше вероятность вы сможете ударить публичные порты UDP (коммерческие публичные Wi-Fi и ячейки, например, не работают).
Соединения NAT-NAT невозможно, если все конечные точки находятся позади NAT со строгой рандомизацией источника порта UDP (например, большинство сотовых сетей данных). Поскольку ни одна из сторон не способна жесткой кодировки ListenPort и гарантирует, что их NAT примет трафик на этом порту после исходящего пинга, вы не можете координировать порт для начального удара отверстий между коллегами, и соединения потерпят неудачу. По этой причине вы, как правило, не можете выполнять подключения по телефону в сети LTE/3G, но вы можете сделать телефон на посох или домохозяйки, где в офисе или дома есть стабильный публичный IP и не делает Это сделает рандомизацию источника порта.
Подключения Nat-Nat из-за NAT со строгим рандомизацией исходного порта возможны, вам просто нужен сервер сигнализации, чтобы сообщить каждой стороне IP: порт. Вот несколько реализаций, которые достигают этого с помощью Wireguard:
Многие пользователи сообщают, что необходимо перезапустить Wireguard всякий раз, когда меняется динамический IP -адрес, поскольку он разрешает только имена хост при запуске. Чтобы заставлять Wireguard чаще для повторного обеспечения динамических имен Endpoint DNS DNS, вы можете использовать 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-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 ПРИМЕЧАНИЕ. Этот раздел о динамических однозначных IPS в подсети VPN, а не динамические адреса общедоступной Endpoint .
Разрабатывается динамическое распределение IPS (вместо того, чтобы иметь только фиксированные одноранговые коллеги), реализация WIP доступна здесь: https://github.com/wireguard/wg-dynamic
Вы также можете создать систему динамического распределения самостоятельно, прочитав значения IP из файлов во время выполнения, используя PostUp (см. Ниже).
Пример
[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/
Неполная, небезопасная внедрение пользовательского пространства Wireguard, написанную в Rust (не готово для общественности).
https://git.zx2c4.com/wireguard-hs/about/
Неполная, небезопасная внедрение пользовательского пространства Wireguard, написанную в Haskell (не готово для общественности).
https://github.com/cloudflare/boringtun
Несоответствующая независимая реализация Wireguard, написанная в Rust (отдельная вилка, написанная Cloudflare). См. Https://blog.cloudflare.com/boringtun-userspace-wireguard-rust/
Платформа для приложений Wireguard
https://git.zx2c4.com/wireguard-ios/about/
https://git.zx2c4.com/wireguard-android/about/
https://git.zx2c4.com/wireguard-windows/about/
Все реализации пользователя более медленнее, чем нативная версия C, которая работает в ядрах, но предоставляет другие преимущества, работая в пользовательской части (например, проще контейнеризация, совместимость и т. Д.).
Это некоторые инструменты с графическим интерфейсом и CLI, которые обертывают Wireguard, чтобы помочь с конфигурацией, развертыванием, управлением ключами и соединением.
Кредит на эти ярлыки идет по адресу: https://www.ericlight.com/new-tings-i-didnt-conce-aboutwireguard.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 : PostUp = wg addconf /etc/wireguard/peers.conf .
Вы должны решить, как вы хотите поделиться peers.conf , будь то через правильную платформу для оркестровки, что -то гораздо более пешеходное, например, Dropbox, или что -то вроде дикого, как Ceph. Я не знаю, но это довольно здорово, что вы можете просто дико бросить коллегию секцию, не беспокоясь о том, такой же, как и интерфейс.
Вы можете установить значения конфигурации из произвольных команд или, читая значения из файлов, это делает управление ключами и развертывание намного проще, как вы можете прочитать в ключах во время выполнения из сторонней службы, таких как секреты Kubernetes или KMS AWS.
См.: Https://lists.zx2c4.com/pipermail/wireguard/2018-december/003702.html
Пример
Вы можете прочитать в файле как PrivateKey сделав что -то вроде:
PostUp = wg set %i private-key /etc/wireguard/wg0.key <(some command)
Wireguard можно запустить в докере с различной степенью легкости. В простейшем случае- --privileged и --cap-add=all аргументы могут быть добавлены в команды Docker, чтобы включить загрузку модуля ядра.
Установки могут стать несколько сложными и сильно зависят от того, чего вы пытаетесь достичь. Вы можете попросить самого Wireguard работать в контейнере и разоблачить сетевой интерфейс на хост, или вы можете заставить Wireguard работать на хосте, выявляя интерфейс на определенные контейнеры.
См. Ниже пример контейнера 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 пройдет через VPN Wireguard. Чтобы направить лишь немного трафика, замените 0.0.0.0/0 в wg0.conf ниже на диапазоны подсети, которые вы хотите направить через 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 ниже.
Более подробные инструкции см. Руководство по QuickStart и ссылку на API выше. Вы также можете загрузить полную настройку примера здесь: https://github.com/pirate/wireguard-example.
Предложите изменения: https://github.com/pirate/wireguard-docs/issues
