wireguard docs
1.0.0
Guide de référence API pour WireGuard, y compris l'installation, la configuration et l'utilisation, avec des exemples.
Tout le mérite revient au projet WireGuard, à zx2c4 et aux contributeurs open source du logiciel original,
il s'agit de ma tentative non officielle personnelle de fournir une documentation plus complète, des références API et des exemples.
Source de ces documents, exemple de code et outil de suivi des problèmes : https://github.com/pirate/wireguard-docs Version de la page HTML plus agréable : https://docs.sweeting.me/s/wireguard
WireGuard est une solution VPN open source écrite en C par Jason Donenfeld et d'autres, visant à résoudre de nombreux problèmes qui ont affecté d'autres offres VPN de serveur à serveur modernes comme IPSec/IKEv2, OpenVPN ou L2TP. Il partage certaines similitudes avec d'autres offres VPN modernes comme Tinc et MeshBird, à savoir de bonnes suites de chiffrement et une configuration minimale. Depuis le 2020-01, il a été fusionné dans la version 5.6 du noyau Linux, ce qui signifie qu'il sera livré avec la plupart des systèmes Linux prêts à l'emploi.
Liens officiels
wg , wg-quickObjectifs de WireGuard
Voir https://github.com/pirate/wireguard-docs pour un exemple de code et de source de documentation.
Que vous viviez derrière la Grande Muraille de Chine ou que vous essayiez simplement de former un réseau entre vos serveurs, WireGuard est une excellente option et sert de « bloc Lego » pour construire des réseaux (de la même manière que ZFS est un bloc Lego pour construire des systèmes de fichiers. ).
Choses que WireGuard ne fait pas :
Mais vous pouvez écrire vos propres solutions à ces problèmes en utilisant WireGuard sous le capot (comme Tailscale ou AltheaNet).
Il s'agit de noms d'hôtes de démonstration, de noms de domaine, d'adresses IP et de plages utilisés dans la documentation et dans les exemples de configuration. Remplacez-les par vos valeurs préférées lorsque vous effectuez votre propre configuration.
example-vpn.dev peut être remplacé par n'importe quel domaine accessible au public que vous contrôlezpublic-server1 , public-server2 , home-server , laptop , phone peuvent être remplacés par les noms d'hôte de votre appareil192.0.2.1/24 , 192.0.2.3 , 192.0.2.3/32 , 2001:DB8::/64 peuvent être remplacées par vos sous-réseaux et adresses préférés (par exemple 192.168.5.1/24 )Partout où vous voyez ces chaînes ci-dessous, elles sont simplement utilisées comme valeurs d'espace réservé pour illustrer un exemple et n'ont aucune signification particulière.
Assurez-vous de changer les adresses IP dans vos configurations ! Les blocs utilisés dans ces documents sont réservés à titre d'exemple par l'IETF et ne doivent jamais être utilisés dans des configurations réseau réelles.
192.0.2.0/24 (TEST-NET-1) Exemple de plage IPv4 RFC57372001:DB8::/32 Exemple de plage IPv6 RFC3849 Vous pouvez utiliser n'importe quelle plage privée de votre choix pour vos propres configurations, par exemple 10.0.44.0/24 , assurez-vous simplement qu'elle n'entre en conflit avec aucune des plages de sous-réseau LAN sur lesquelles se trouvent vos pairs.
Un hôte qui se connecte au VPN et enregistre pour lui-même une adresse de sous-réseau VPN telle que 192.0.2.3 . Il peut également éventuellement acheminer le trafic vers d'autres adresses que sa ou ses propres adresses en spécifiant des plages de sous-réseaux en notation CIDR séparées par des virgules.
Un homologue/nœud accessible publiquement qui sert de solution de secours pour relayer le trafic pour d'autres homologues VPN derrière les NAT. Un serveur de rebond n'est pas un type spécial de serveur, c'est un homologue normal comme tous les autres, la seule différence est qu'il a une adresse IP publique et que le transfert IP au niveau du noyau est activé, ce qui lui permet de renvoyer le trafic vers le VPN. à d'autres clients.
Pour en savoir plus : https://tailscale.com/blog/how-nat-traversal-works/ (Tailscale utilise Wireguard sous le capot)
Un groupe d'adresses IP distinctes de l'Internet public, par exemple 192.0.2.1-255 ou 192.168.1.1/24. Généralement derrière un NAT fourni par un routeur, par exemple dans un réseau local Internet de bureau ou un réseau Wi-Fi domestique.
Une manière de définir un sous-réseau et sa taille avec un "masque", un masque plus petit = plus de bits d'adresse utilisables par le sous-réseau & plus d'IP dans la plage. Les plus courants :
192.0.2.1/32 (une seule adresse IP, 192.0.2.1 ) masque de réseau = 255.255.255.255192.0.2.1/24 (255 IP de 192.0.2.0 à 192.0.2.255 ) masque de réseau = 255.255.255.0192.0.2.1/16 (65 536 IP de 192.0.0.0 à 192.0.255.255 ) masque de réseau = 255.255.0.0192.0.2.1/8 (16 777 216 adresses IP de 192.0.0.0 à 192.255.255.255 ) masque de réseau = 255.0.0.00.0.0.1/0 (4 294 967 296 adresses IP de 0.0.0.0 à 255.255.255.255 ) masque de réseau = 0.0.0.02001:DB8::/64https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing
Pour les personnes qui débutent, 192.0.2.1/32 peut sembler une façon étrange et déroutante de faire référence à une seule adresse IP. Cette conception est intéressante car elle permet aux pairs d'exposer plusieurs adresses IP si nécessaire sans avoir besoin de plusieurs notations. Sachez simplement que partout où vous voyez quelque chose comme 192.0.2.3/32 , cela signifie simplement 192.0.2.3 .
Un sous-réseau avec des adresses IP privées fournies par un routeur situé devant eux effectuant la traduction d'adresses réseau, les nœuds individuels ne sont pas accessibles publiquement depuis Internet, mais le routeur garde une trace des connexions sortantes et transmet les réponses à l'adresse IP interne correcte (par exemple, les réseaux de bureau standard , réseaux Wi-Fi domestiques, réseaux Wi-Fi publics gratuits, etc.)
L'adresse accessible publiquement : le port d'un nœud, par exemple 123.124.125.126:1234 ou some.domain.tld:1234 (doit être accessible via l'Internet public, ne peut généralement pas être une adresse IP privée comme 192.0.2.1 ou 192.168.1.1 sauf si il est directement accessible en utilisant cette adresse par d'autres pairs sur le même sous-réseau).
Une clé privée WireGuard pour un seul nœud, générée avec : wg genkey > example.key (ne quitte jamais le nœud sur lequel elle est générée)
Une clé publique WireGuard pour un seul nœud, générée avec : wg pubkey < example.key > example.key.pub (partagée avec d'autres pairs)
Serveur de noms de domaine, utilisé pour résoudre les noms d'hôte en adresses IP pour les clients VPN, au lieu de permettre aux requêtes DNS de s'échapper en dehors du VPN et de révéler le trafic. Les fuites sont testables avec http://dnsleak.com.
Les relais publics ne sont que des homologues VPN normaux capables d'agir comme un serveur de relais intermédiaire entre tous les clients VPN derrière les NAT. Ils peuvent transférer tout trafic de sous-réseau VPN qu'ils reçoivent au bon homologue au niveau du système (WireGuard ne se soucie pas de la manière dont cela se produit). , il est géré par le noyau net.ipv4.ip_forward = 1 et les règles de routage iptables).
Si tous les pairs sont accessibles publiquement, vous n'avez pas à vous soucier d'un traitement spécial pour faire de l'un d'eux un serveur relais, cela n'est nécessaire que si vous avez des pairs qui se connectent derrière un NAT.
Chaque client n'a qu'à définir les serveurs/pairs accessibles au public dans sa configuration, tout trafic lié à d'autres pairs derrière les NAT ira vers le sous-réseau VPN fourre-tout (par exemple 192.0.2.1/24 ) dans la route des relais publics AllowedIPs et sera transmis en conséquence. une fois qu'il atteint le serveur relais.
En résumé : seules les connexions directes entre les clients doivent être configurées, toutes les connexions qui doivent être renvoyées ne doivent pas être définies comme des pairs, car elles doivent d'abord se diriger vers le serveur de rebond et être acheminées de là vers le VPN vers le bon client.
Des topologies plus complexes sont certainement réalisables, mais voici les méthodes de routage de base utilisées dans les configurations WireGuard typiques :
Endpoint codés en dur afin que WireGuard puisse se connecter directement au port ouvert et acheminer les paquets UDP sans sauts intermédiaires.public-server2 ), définissez le nœud accessible publiquement avec un Endpoint codé en dur et le nœud NAT sans. La connexion sera ouverte à partir du client NAT -> client public, puis le trafic sera acheminé directement entre eux dans les deux sens tant que la connexion est maintenue active par les pings PersistentKeepalive sortants du client NAT.public-server1 , et le trafic sera transmis via le serveur de rebond intermédiaire tant que les connexions sont maintenus en vie. Les routes plus spécifiques (également généralement plus directes) fournies par d'autres pairs auront la priorité lorsqu'elles seront disponibles, sinon le trafic reviendra à la route la moins spécifique et utilisera le fourre-tout 192.0.2.1/24 pour transférer le trafic vers le serveur de rebond, où il le fera. à son tour être acheminé par la table de routage système du serveur relais ( net.ipv4.ip_forward = 1 ) vers le VPN vers le homologue spécifique qui accepte les routes pour ce trafic. WireGuard ne trouve pas automatiquement l'itinéraire le plus rapide ni ne tente d'établir des connexions directes entre pairs s'il n'est pas déjà défini, il passe simplement de l'itinéraire le plus spécifique dans [Peers] au moins spécifique.
Vous pouvez déterminer quelle méthode de routage WireGuard utilise pour une adresse donnée en mesurant les temps de ping pour déterminer la longueur unique de chaque saut et en inspectant la sortie de :
wg show wg0WireGuard utilise des paquets UDP cryptés pour tout le trafic. Il ne fournit aucune garantie concernant la livraison ou la commande des paquets, car cela est géré par les connexions TCP au sein du tunnel crypté.
Lectures complémentaires :
WireGuard revendique des performances plus rapides que la plupart des autres solutions VPN concurrentes, bien que les chiffres exacts soient parfois débattus et puissent dépendre de la disponibilité ou non d'une accélération au niveau matériel pour certains chiffrements cryptographiques.
Les gains de performances de WireGuard sont obtenus en gérant le routage au niveau du noyau et en utilisant des suites de chiffrement modernes exécutées sur tous les cœurs pour chiffrer le trafic. WireGuard bénéficie également d'un avantage significatif en utilisant UDP sans garantie de livraison/commande (par rapport aux VPN qui fonctionnent sur TCP ou implémentent leurs propres mécanismes de livraison garantie).
Lectures complémentaires :
WireGuard utilise les protocoles et primitives suivants pour sécuriser le trafic :
La cryptographie de WireGuard est essentiellement une instanciation du framework Noise de Trevor Perrin. C'est moderne et, encore une fois, simple. Toutes les autres options VPN sont un gâchis de négociation, de prise de contact et de machines à états compliquées. WireGuard est comme le Signal/Axolotl des VPN, sauf qu'il est beaucoup plus simple et plus facile à raisonner (cryptographiquement, dans ce cas) que les protocoles de messagerie à double cliquet. Il s’agit essentiellement du qmail du logiciel VPN. Et c'est environ 4 000 lignes de code. Il est plusieurs ordres de grandeur inférieurs à ceux de ses concurrents.
https://news.ycombinator.com/item?id=14599834
Lectures complémentaires :
L'authentification dans les deux sens est réalisée avec une simple paire de clés publique/privée pour chaque homologue. Chaque homologue génère ces clés pendant la phase de configuration et partage uniquement la clé publique avec d'autres homologues.
Aucun autre certificat ou clé pré-partagée n'est nécessaire au-delà des clés publiques/privées pour chaque nœud.
La génération, la distribution et la révocation de clés peuvent être gérées dans des déploiements plus importants à l'aide d'un service distinct comme Ansible ou Kubernetes Secrets.
Certains services qui facilitent la distribution et le déploiement des clés :
Vous pouvez également lire les clés à partir d'un fichier ou via une commande si vous ne souhaitez pas les coder en dur dans wg0.conf , cela facilite grandement la gestion des clés via un service tiers :
[Interface]
...
PostUp = wg set %i private-key /etc/wireguard/wg0.key <(cat /some/path/%i/privkey)Techniquement, plusieurs serveurs peuvent partager la même clé privée tant que les clients ne sont pas connectés simultanément à deux serveurs avec la même clé. Un exemple de scénario dans lequel il s'agit d'une configuration raisonnable est si vous utilisez un DNS à tour de rôle pour équilibrer la charge des connexions entre deux serveurs qui prétendent être un seul serveur. Cependant, la plupart du temps, chaque homologue doit avoir sa propre paire de clés publique/privée afin que les homologues ne puissent pas lire le trafic des autres et puissent être révoqués individuellement.
Aperçu du processus général :
apt install wireguard ou pkg/brew install wireguard-tools sur chaque nœudwg genkey + wg pubkeywg0.conf WireGuard sur le serveur relais principal[Interface] Assurez-vous de spécifier une plage CIDR pour l'ensemble du sous-réseau VPN lors de la définition de l'adresse pour laquelle le serveur accepte les routes pour Address = 192.0.2.1/24[Peer] Créez une section peer pour chaque client rejoignant le VPN, en utilisant leurs clés publiques distantes correspondanteswg0.conf sur chaque nœud client[Interface] Assurez-vous de spécifier une seule adresse IP pour les homologues clients qui ne relayent pas le trafic Address = 192.0.2.3/32 .[Peer] Créez une section homologue pour chaque homologue public non derrière un NAT, assurez-vous de spécifier une plage CIDR pour l'ensemble du sous-réseau VPN lors de la définition de l'homologue distant agissant en tant que serveur de rebond AllowedIPs = 192.0.2.1/24 . Assurez-vous de spécifier des adresses IP individuelles pour les homologues distants qui ne relaient pas le trafic et agissent uniquement comme de simples clients 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 vérifie d'abord une route directe vers un homologue avec AllowedIPs = 192.0.2.3/32 , puis revient à un serveur relais qui accepte les adresses IP. dans tout le sous-réseau # 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.3Pour activer une journalisation supplémentaire :
modprobe wireguard
echo module wireguard +p > /sys/kernel/debug/dynamic_debug/controlPour suivre les journaux :
dmesg -wHLes systèmes dotés d'un noyau moderne et de Safe Boot peuvent nécessiter la désactivation de la vérification de signature DKMS de démarrage sécurisé pour autoriser l'accès aux journaux du noyau.
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 Recherchez les fuites DNS à l'aide de http://dnsleak.com ou en vérifiant le résolveur lors d'une recherche :
dig example.com A La configuration WireGuard est dans la syntaxe INI, définie dans un fichier généralement appelé wg0.conf . Il peut être placé n'importe où sur le système, mais il est souvent placé dans /etc/wireguard/wg0.conf .
Le chemin de configuration est spécifié comme argument lors de l'exécution d'une commande wg-quick , par exemple :
wg-quick up /etc/wireguard/wg0.conf (spécifiez toujours le chemin complet et absolu)
Le nom du fichier de configuration doit être au format ${name of the new WireGuard interface}.conf . Les noms d'interface WireGuard sont généralement préfixés par wg et numérotés commençant à 0 , mais vous pouvez utiliser n'importe quel nom qui correspond à l'expression régulière ^[a-zA-Z0-9_=+.-]{1,15}$ .
Les fichiers de configuration peuvent choisir d'utiliser l'ensemble limité d'options de configuration wg , ou les options wg-quick plus étendues, selon la commande préférée pour démarrer WireGuard. Ces documents recommandent de s'en tenir à wg-quick car il offre une expérience de configuration plus puissante et plus conviviale.
Aller à la définition :
¶ [Interface]
¶ # Name = node1.example.tld
¶ Address = 192.0.2.3/32
¶Port 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]Définit les paramètres VPN pour le nœud local.
Exemples
[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# NameIl s'agit simplement d'un commentaire standard dans la syntaxe INI utilisé pour aider à savoir quelle section de configuration appartient à quel nœud, il est complètement ignoré par WireGuard et n'a aucun effet sur le comportement du VPN.
REMARQUE : Tous les commentaires, y compris # Name , sont supprimés des fichiers .conf par certaines opérations et applications. Si vous avez besoin d'identifier des pairs, envisagez d'utiliser un générateur de clé personnalisée wireguard, tel que wireguard-vanity-keygen ou wireguard-vanity-address, qui vous permettra d'inclure le nom d'hôte dans la clé publique de l'hôte. La génération de clé peut prendre des minutes (4 caractères), des heures (5 caractères) ou plus, pensez donc à utiliser une abréviation pour les hôtes avec des noms plus longs.
AddressDéfinit la plage d'adresses pour laquelle le nœud local doit acheminer le trafic. Selon que le nœud est un simple client rejoignant le sous-réseau VPN ou un serveur de rebond qui relaye le trafic entre plusieurs clients, cela peut être défini sur une seule adresse IP du nœud lui-même (spécifiée avec la notation CIDR), par exemple 192.0.2.3/32. ), ou une plage de sous-réseaux IPv4/IPv6 pour lesquels le nœud peut acheminer le trafic.
Exemples
Node est un client qui achemine uniquement le trafic pour lui-même
Address = 192.0.2.3/32
Node est un serveur de rebond public qui peut relayer le trafic vers d'autres pairs
Lorsque le nœud agit en tant que serveur de rebond public, il doit définir l'intégralité du sous-réseau sur lequel il peut acheminer le trafic, et non une seule adresse IP pour lui-même.
Address = 192.0.2.1/24
Address = 192.0.2.1/24,2001:DB8::/64ListenPortLorsque le nœud agit comme un serveur de rebond public, il doit coder en dur un port pour écouter les connexions VPN entrantes depuis l'Internet public. Les clients n'agissant pas en tant que relais ne doivent pas définir cette valeur.
Exemples
ListenPort = 51820ListenPort = 7000PrivateKeyIl s'agit de la clé privée du nœud local, jamais partagée avec d'autres serveurs. Tous les nœuds doivent disposer d'un ensemble de clés privées, qu'il s'agisse de serveurs de rebond publics relayant le trafic ou de simples clients rejoignant le VPN.
Cette clé peut être générée avec wg genkey > example.key
Exemples
PrivateKey = somePrivateKeyAbcdAbcdAbcdAbcd=
DNSLe(s) serveur(s) DNS à annoncer aux clients VPN via DHCP. La plupart des clients utiliseront ce serveur pour les requêtes DNS via le VPN, mais les clients peuvent également remplacer cette valeur localement sur leurs nœuds.
Exemples
DNS = 1.1.1.1DNS = 1.1.1.1,8.8.8.8TableDéfinit éventuellement la table de routage à utiliser pour les routes WireGuard, dont la configuration n'est pas nécessaire pour la plupart des configurations.
Il existe deux valeurs spéciales : "off" désactive complètement la création de routes et "auto" (valeur par défaut) ajoute des routes à la table par défaut et active une gestion spéciale des routes par défaut.
https://git.zx2c4.com/WireGuard/about/src/tools/man/wg-quick.8
Exemples
Table = 1234MTUDéfinit éventuellement l'unité de transmission maximale (MTU, c'est-à-dire taille de paquet/trame) à utiliser lors de la connexion au homologue, qu'il n'est pas nécessaire de configurer pour la plupart des configurations.
La MTU est automatiquement déterminée à partir des adresses des points de terminaison ou de la route par défaut du système, ce qui constitue généralement un choix judicieux.
https://git.zx2c4.com/WireGuard/about/src/tools/man/wg-quick.8
Exemples
MTU = 1500PreUpExécutez éventuellement une commande avant que l'interface ne soit affichée. Cette option peut être spécifiée plusieurs fois, avec des commandes exécutées dans l'ordre dans lequel elles apparaissent dans le fichier.
Exemples
PreUp = ip rule add ipproto tcp dport 22 table 1234 PostUpExécutez éventuellement une commande une fois l’interface affichée. Cette option peut apparaître plusieurs fois, comme avec PreUp
Exemples
Lire une valeur de configuration à partir d'un fichier ou de la sortie d'une commande
PostUp = wg set %i private-key /etc/wireguard/wg0.key <(some command here)
Enregistrer une ligne dans un fichier
PostUp = echo "$(date +%s) WireGuard Started" >> /var/log/wireguard.log
Accédez à un webhook sur un autre serveur
PostUp = curl https://events.example.dev/wireguard/started/?key=abcdefg
Ajouter une route à la table de routage du système
PostUp = ip rule add ipproto tcp dport 22 table 1234
Ajoutez une règle iptables pour activer le transfert de paquets sur l'interface 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
Forcer WireGuard à re-résoudre l'adresse IP pour le domaine homologue
PostUp = resolvectl domain %i "~."; resolvectl dns %i 192.0.2.1; resolvectl dnssec %i yes
PreDownExécutez éventuellement une commande avant que l'interface ne soit désactivée. Cette option peut apparaître plusieurs fois, comme avec PreUp
Exemples
Enregistrer une ligne dans un fichier
PostDown = echo "$(date +%s) WireGuard Going Down" >> /var/log/wireguard.log
Accédez à un webhook sur un autre serveur
PostDown = curl https://events.example.dev/wireguard/stopping/?key=abcdefg
PostDownExécutez éventuellement une commande après la suppression de l'interface. Cette option peut apparaître plusieurs fois, comme avec PreUp
Exemples
Enregistrer une ligne dans un fichier
PostDown = echo "$(date +%s) WireGuard Stopped" >> /var/log/wireguard.log
Accédez à un webhook sur un autre serveur
PostDown = curl https://events.example.dev/wireguard/stopped/?key=abcdefg
Supprimez la règle iptables qui transfère les paquets sur l'interface 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]Définit les paramètres VPN pour un homologue distant capable d'acheminer le trafic vers une ou plusieurs adresses (lui-même et/ou d'autres homologues). Les pairs peuvent être soit un serveur de rebond public qui relaie le trafic vers d'autres pairs, soit un client directement accessible via LAN/Internet qui n'est pas derrière un NAT et achemine uniquement le trafic pour lui-même.
Tous les clients doivent être définis comme pairs sur le serveur de rebond public. Les clients simples qui acheminent uniquement le trafic pour eux-mêmes n'ont qu'à définir des pairs pour le relais public et tout autre nœud directement accessible. Les nœuds situés derrière des NAT distincts ne doivent pas être définis comme pairs en dehors de la configuration du serveur public, car aucune route directe n'est disponible entre des NAT distincts. Au lieu de cela, les nœuds derrière les NAT doivent uniquement définir les serveurs de relais publics et les autres clients publics comme leurs pairs, et doivent spécifier AllowedIPs = 192.0.2.1/24 sur le serveur public qui accepte les routes et renvoie le trafic du sous-réseau VPN vers le NAT distant. pairs.
En résumé, tous les nœuds doivent être définis sur le serveur de rebond principal. Sur les serveurs clients, seuls les homologues directement accessibles depuis un nœud doivent être définis comme homologues de ce nœud. Tous les homologues qui doivent être relayés par un serveur de rebond doivent être laissés de côté et seront gérés par la route fourre-tout du serveur relais.
Dans la configuration décrite dans la documentation ci-dessous, un seul serveur public-server1 fait office de serveur de rebond relais pour un mélange de clients accessibles publiquement et NAT, et les homologues sont configurés sur chaque nœud en conséquence :
dans public-server1 wg0.conf (serveur de rebond)
Liste [peer] : public-server2 , home-server , laptop , phone
dans public-server2 wg0.conf (client public simple)
Liste [peer] : public-server1
dans home-server wg0.conf (client simple derrière NAT)
Liste [peer] : public-server1 , public-server2
dans laptop wg0.conf (client simple derrière NAT)
Liste [peer] : public-server1 , public-server2
dans phone wg0.conf (client simple derrière NAT)
Liste [peer] : public-server1 , public-server2
Exemples
[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# NameIl s'agit simplement d'un commentaire standard dans la syntaxe INI utilisé pour aider à savoir quelle section de configuration appartient à quel nœud, il est complètement ignoré par WireGuard et n'a aucun effet sur le comportement du VPN.
Endpoint Définit l’adresse accessible publiquement pour un homologue distant. Cela doit être laissé de côté pour les pairs derrière un NAT ou pour les pairs qui ne disposent pas d'une paire IP:PORT stable et accessible au public. En règle générale, cela doit uniquement être défini sur le serveur de rebond principal, mais cela peut également être défini sur d'autres nœuds publics avec des adresses IP stables comme public-server2 dans l'exemple de configuration ci-dessous.
Exemples
Endpoint = 123.124.125.126:51820 (IPv6 est également pris en charge)Endpoint = public-server1.example-vpn.tld:51820AllowedIPs Ceci définit les plages IP pour lesquelles un homologue acheminera le trafic. Sur les clients simples, il s'agit généralement d'une adresse unique (l'adresse VPN du client simple lui-même). Pour les serveurs de rebond, il s'agira d'une plage d'adresses IP ou de sous-réseaux pour lesquels le serveur relais est capable d'acheminer le trafic. Plusieurs adresses IP et sous-réseaux peuvent être spécifiés à l'aide de la notation CIDR IPv4 ou IPv6 séparée par des virgules (à partir d'une seule adresse /32 ou /128, jusqu'à 0.0.0.0/0 et ::/0 pour indiquer une route par défaut pour envoyer tous les trafic Internet et VPN via ce homologue). Cette option peut être spécifiée plusieurs fois.
Lorsqu'il décide comment acheminer un paquet, le système choisit d'abord l'itinéraire le plus spécifique et revient à des itinéraires plus larges. Ainsi, pour un paquet destiné à 192.0.2.3 , le système rechercherait d'abord un homologue annonçant 192.0.2.3/32 spécifiquement, et reviendrait à un homologue annonçant 192.0.2.1/24 ou une plage plus large comme 0.0.0.0/0 comme un dernier recours.
Exemples
peer est un client simple qui n'accepte que le trafic vers/depuis lui-même
AllowedIPs = 192.0.2.3/32
peer est un serveur relais qui peut renvoyer le trafic VPN vers tous les autres pairs
AllowedIPs = 192.0.2.1/24
peer est un serveur relais qui renvoie tout le trafic Internet et VPN (comme un proxy), y compris IPv6
AllowedIPs = 0.0.0.0/0,::/0
le homologue est un serveur relais qui se dirige vers lui-même et vers un seul autre homologue
AllowedIPs = 192.0.2.3/32,192.0.2.4/32
le homologue est un serveur relais qui se dirige vers lui-même et vers tous les nœuds de son réseau local local
AllowedIPs = 192.0.2.3/32,192.168.1.1/24
PublicKeyIl s'agit de la clé publique du nœud distant, partageable avec tous les pairs. Tous les nœuds doivent disposer d'un ensemble de clés publiques, qu'il s'agisse de serveurs de rebond publics relayant le trafic ou de simples clients rejoignant le VPN.
Cette clé peut être générée avec wg pubkey < example.key > example.key.pub . (voir ci-dessus pour savoir comment générer la clé privée example.key )
Exemples
PublicKey = somePublicKeyAbcdAbcdAbcdAbcd=
PersistentKeepaliveSi la connexion passe d'un homologue NAT à un homologue public, le nœud derrière le NAT doit régulièrement envoyer un ping sortant afin de maintenir la connexion bidirectionnelle active dans la table de connexion du routeur NAT.
Exemples
nœud public local vers nœud public distant
Cette valeur ne doit pas être définie car les pings persistants ne sont pas nécessaires.
nœud public local vers nœud NAT distant
Cette valeur ne doit pas être définie car il est de la responsabilité du client de maintenir la connexion active car le serveur ne peut pas rouvrir une connexion morte avec le client en cas d'expiration.
nœud NAT local vers nœud public distant
PersistentKeepalive = 25 cela enverra un ping toutes les 25 secondes en gardant la connexion ouverte dans la table de connexion du routeur NAT local.
Les exemples de ces documents utilisent principalement IPv4, mais Wireguard prend en charge Nativement IPv6 CIDR et les adresses partout où il prend en charge IPv4, ajoutez-les simplement comme vous le feriez pour toute autre plage de sous-réseau ou adresse.
Exemple
[Interface]
Address = 192.0.2.3/24, 2001:DB8::/64
[Peer]
...
AllowedIPs = 0.0.0.0/0, ::/0 Si vous souhaitez transférer tout le trafic Internet via le VPN, et pas seulement l'utiliser comme sous-réseau de serveur à serveur, vous pouvez ajouter 0.0.0.0/0, ::/0 à la définition AllowedIPs du pair que vous souhaitez tuer votre trafic.
Assurez-vous de spécifier également un IPv6 Catchall même lorsque vous ne transmettant que le trafic IPv4 afin d'éviter de fuir les paquets IPv6 en dehors du VPN, voir:
https://www.reddit.com/r/wireguard/comments/b0m5g2/ipv6_leaks_psa_for_anyone_here_using_wireguard_to/
Exemple
[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 peut parfois établir des connexions entre deux clients derrière Nats sans avoir besoin d'un serveur de relais public, mais dans la plupart des cas, cela n'est pas possible. Les connexions NAT-TO NAT ne sont possibles que si au moins un hôte a une adresse IP stable et accessible publiquement: Paire de port qui peut être codé en dur à l'avance, qu'il s'agisse d'utiliser un FQDN mis à jour avec DNS dynamique, ou une IP publique statique avec Un port NAT non randomisé ouvert par des paquets sortants, tout fonctionne tant que tous les pairs peuvent le communiquer au préalable et qu'il ne change pas une fois la connexion initiée.
Un port et une adresse connus doivent être configurés à l'avance car WireGuard n'a pas de calque de signalisation ou de serveurs publiques d'étourdissement qui peuvent être utilisés pour rechercher d'autres hôtes dynamiquement. WeBrTC est un exemple de protocole qui peut configurer dynamiquement une connexion entre deux NAT, mais il le fait en utilisant un serveur de signalisation hors bande pour détecter le combo IP: Port de chaque hôte. WireGuard n'a pas cela, donc cela ne fonctionne qu'avec un Endpoint codé en dur + ListenPort (et PersistentKeepalive donc il ne baisse pas après l'inactivité).
En savoir plus sur TailScale's Bible of Nat Traversal: https://tailscale.com/blog/how-nat-traversal-works/
Endpoint codé par le codé et directement défini. S'ils sont tous les deux derrière NATS sans adresses IP stables, vous devrez utiliser DNS dynamique ou une autre solution pour avoir un domaine / IP accessible et accessible publiquement pour au moins un pairListenPort UDP à codé à codé à code, et son routeur NAT ne doit pas faire de randomisation du port source UDP, sinon les paquets de retour seront envoyés ListenPort en dur et déposés par le routeur, au lieu d'utiliser le port aléatoire attribué par la Nat sur le paquet sortantPersistentKeepalive activés sur tous les autres pairs, afin qu'ils envoient continuellement des pings sortants pour garder les liens persistants dans la table de routage de leur NAT Ce processus d'envoi d'un paquet initial qui est rejeté, puis en utilisant le fait que le routeur a maintenant créé une règle de transfert pour accepter les réponses est appelée "Punching de trous UDP".
Lorsque vous envoyez un paquet UDP, le routeur crée (généralement) une règle temporaire mappant votre adresse source et votre port sur l'adresse et le port de destination, et vice versa. Les paquets UDP renvoyant de l'adresse et du port de destination (et aucun autre) sont passés par l'adresse source et le port d'origine (et aucun autre). C'est ainsi que la plupart des applications UDP fonctionnent derrière Nats (par exemple BitTorrent, Skype, etc.). Cette règle sera déloyée après quelques minutes d'inactivité, de sorte que le client derrière le NAT doit envoyer des paquets sortants réguliers pour le garder ouvert (voir PersistentKeepalive ).
Faire fonctionner cela lorsque les deux points finaux sont derrière Nats ou les pare-feu nécessitent que les deux points finaux envoient à peu près les paquets. Cela signifie que les deux parties doivent connaître à l'avance les adresses IP publiques de chacun et les numéros de port, dans le cas de Wireguard, celle-ci est réalisée par des ports prédéfinis en codage dur pour les deux parties dans wg0.conf .
En 2019, bon nombre des anciennes méthodes de coup de trou utilisées utilisées pour travailler ne sont plus efficaces. Un exemple a été une nouvelle méthode lancée par PWNAT qui a simulé un temps ICMP a dépassé la réponse de l'extérieur du NAT pour récupérer un paquet à un pair nat'ed, divulguant ainsi son propre port source. Les ports UDP et les IP publics à codage en dur pour les deux côtés d'une connexion NAT-TO-NAT (comme décrit ci-dessus) fonctionnent toujours sur un petit pourcentage de réseaux. Généralement, plus un réseau est «Enterprisey», moins vous pourrez tracer des ports UDP publics (les données publiques commerciales et les données de cellules ne fonctionnent souvent pas par exemple).
Les connexions NAT-TO NAT ne sont pas possibles si tous les points de terminaison sont derrière NAT avec une randomisation de port source UDP stricte (par exemple, la plupart des réseaux de données cellulaires). Étant donné qu'aucune des parties n'est capable de coder en hard ListenPort et de garantir que leur NAT acceptera le trafic sur ce port après le ping sortant, vous ne pouvez pas coordonner un port pour le punch de trou initial entre les pairs et les connexions échoueront. Pour cette raison, vous ne pouvez généralement pas effectuer des connexions téléphoniques sur les réseaux LTE / 3G, mais vous pourriez être en mesure de faire du téléphone au bureau ou du téléphone à la maison où le bureau ou la maison a une IP publique stable et ne fait pas «Je ne fais pas la randomisation du port source.
Les connexions NAT-TO NAT de derrière Nats avec une randomisation de port source stricte sont possibles, vous avez juste besoin d'un serveur de signalisation pour dire à chaque côté le tuple IP: Port de l'autre. Voici quelques implémentations qui y parviennent avec Wireguard:
De nombreux utilisateurs rapportent avoir à redémarrer Wire GuadGuard chaque fois qu'une IP dynamique change, car elle ne résout que les noms d'hôtes au démarrage. Pour forcer Wireguard à re-résolution des noms d' Endpoint dynamiques DNS plus souvent, vous voudrez peut-être utiliser un crochet PostUp pour redémarrer Wire Guard toutes les quelques minutes ou heures.
Vous pouvez voir si une configuration de coup de trou est possible en utilisant NetCat sur le client et le serveur pour voir quels ports et commande de connexion fonctionnent pour que l'ouverture d'une connexion bidirectionnelle: exécutez nc -v -u -p 51820 <address of peer2> 51820 ( Sur Peer1) et nc -v -u -l 0.0.0.0 51820 (sur Peer2), puis saisissez les deux fenêtres pour voir si vous pouvez faire fonctionner le trafic bidirectionnel. Si cela ne fonctionne pas, quel que soit le pair qui envoie le paquet initial, Wireguard ne sera pas en mesure de travailler entre les pairs sans serveur de relais public.
Les connexions NAT-TO NAT sont souvent plus instables et ont d'autres limitations, c'est pourquoi avoir un serveur de relais public de secours est toujours conseillé.
Exemple
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 Remarque: Cette section concerne les IPs pair dynamiques dans le sous-réseau VPN, pas les adresses Endpoint publiques dynamiques .
L'allocation dynamique des IP de pairs (au lieu d'avoir uniquement des pairs fixes) est en cours de développement, l'implémentation WIP est disponible ici: https://github.com/wireguard/wg-dynamic
Vous pouvez également créer vous-même un système d'allocation dynamique en lisant les valeurs IP à partir de fichiers à l'exécution en utilisant PostUp (voir ci-dessous).
Exemple
[Interface]
...
PostUp = wg set %i allowed-ips /etc/wireguard/wg0.key <(some command) https://git.zx2c4.com/wireguard-go/about/
Une implémentation de Wireguard conforme Userland écrite en Go.
https://git.zx2c4.com/wireguard-rs/about/
Une implémentation incomplète et insécurité de l'espace de Wireguard écrit en rouille (pas prêt pour le public).
https://git.zx2c4.com/wireguard-hs/about/
Une implémentation incomplète et insécurité de l'espace de Wireguard écrit dans Haskell (pas prêt pour le public).
https://github.com/cloudflare/boringtun
Une implémentation de fil de câble non conforme et indépendante écrite en rouille (une fourche séparée écrite par CloudFlare). Voir https://blog.cloudflare.com/boringtun-userspace-wireguard-rust/
Applications Wireguard spécifiques à la plate-forme
https://git.zx2c4.com/wireguard-ios/about/
https://git.zx2c4.com/wireguard-android/about/
https://git.zx2c4.com/wireguard-windows/about/
Toutes les implémentations de l'espace utilisateur sont plus lentes que la version C native qui s'exécute dans le noyau-land, mais offre d'autres avantages en fonctionnant dans Userland (par exemple, la conteneurisation, la compatibilité, etc.).
Ce sont des outils d'interface graphique et de CLI qui enveloppent Wireguard pour aider à la configuration, au déploiement, à la gestion des clés et à la connexion.
Le crédit pour ces raccourcis revient à: https://www.ericlight.com/new-things-i-didnt-know-about-wireguard.html
Wireguard ignorera un pair dont la clé publique correspond à la clé privée de l'interface. Vous pouvez donc distribuer une seule liste de pairs partout et ne définir que [Interface] séparément sur chaque serveur.
Voir: https://lists.zx2c4.com/pipermail/wireguard/2018-dember/003703.html
Vous pouvez combiner cela avec wg addconf comme ceci:
Chaque pair a son propre fichier /etc/wireguard/wg0.conf , qui ne contient que sa section [Interface] .
Chaque pair a également un fichier partagé /etc/wireguard/peers.conf , qui contient tous les pairs.
Le fichier wg0.conf a également un crochet PostUp : PostUp = wg addconf /etc/wireguard/peers.conf .
C'est à vous de décider comment vous voulez partager les peers.conf , que ce soit via une plate-forme d'orchestration appropriée, quelque chose de beaucoup plus piéton comme Dropbox, ou quelque chose de sauvage comme Ceph. Je ne sais pas, mais c'est plutôt génial que vous puissiez simplement lancer une section de pairs, sans vous soucier de la même chose que l'interface.
Vous pouvez définir des valeurs de configuration à partir de commandes arbitraires ou en lisant dans des valeurs à partir de fichiers, ce qui facilite la gestion et le déploiement des clés car vous pouvez lire dans les clés lors d'un service d'exécution à partir d'un service tiers comme Kubernetes Secrets ou AWS KMS.
Voir: https://lists.zx2c4.com/pipermail/wireguard/2018-dember/003702.html
Exemple
Vous pouvez lire dans un dossier en tant que PrivateKey en faisant quelque chose comme:
PostUp = wg set %i private-key /etc/wireguard/wg0.key <(some command)
Wireguard peut être exécuté dans Docker avec divers degrés de facilité. Dans le cas le plus simple, --privileged et --cap-add=all les arguments peuvent être ajoutés aux commandes Docker pour activer le chargement du module du noyau.
Les configurations peuvent devenir quelque peu complexes et dépendent fortement de ce que vous essayez de réaliser. Vous pouvez faire fonctionner lui-même dans un conteneur et exposer une interface réseau à l'hôte, ou vous pouvez avoir Wireguard en cours d'exécution sur l'hôte exposant une interface à des conteneurs spécifiques.
Voir ci-dessous pour un exemple de contenant Docker vpn_test ROUTING TOUT son trafic via un serveur de relais 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 Dans cet exemple, tout le trafic de l'intérieur du conteneur speedtest passera par le VPN Wireguard. Pour acheminer uniquement un peu de trafic, remplacez 0.0.0.0/0 dans wg0.conf ci-dessous par les gammes de sous-réseau que vous souhaitez acheminer via le 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 = 21Pour plus de détails, consultez la lecture plus approfondie: Section Docker ci-dessous.
Pour des instructions plus détaillées, consultez le guide QuickStart et la référence API ci-dessus. Vous pouvez également télécharger la configuration complète de l'exemple ici: https://github.com/pirate/wireguard-example.
Suggérer des changements: https://github.com/pirate/wireguard-docs/issues
