Lire une configuration WireGuard ligne par ligne, d'Interface à Peer

La plupart des configurations WireGuard cassées ne se trompent pas de valeur ; elles placent la bonne valeur du mauvais côté. Une clé privée appartient à cette machine, un peer porte la clé publique de l'autre machine, et une adresse se tient dans le bloc interface alors qu'elle décrit où vit le tunnel. Lisez le fichier comme deux directions qui se rencontrent, puis vérifiez ce que le script d'assistance a ajouté par-dessus. Le protocole lui-même a moins de champs que le fichier, et les champs en plus méritent d'être connus séparément.

Les clés d'interface décrivent cette machine

Le bloc interface détient l'identité propre de cette extrémité. PrivateKey est cette identité et ne quitte jamais l'hôte ; la clé publique correspondante en est dérivée et c'est elle que les autres peers listent. ListenPort est l'endroit où ce côté reçoit les handshakes, donc deux clients derrière une même adresse ont besoin de ports différents.

Address est l'adresse du tunnel sur laquelle cet hôte répond, écrite avec une longueur de préfixe parce qu'elle est aussi la source qu'il utilisera. Se tromper de préfixe ici change les destinations que l'hôte croit directement liées, ce qui produit des pannes qui ressemblent à du routage et non à de la configuration.

Tout le reste dans un [Interface] bloc avec un client réel est généralement ajouté par wg-quick : DNS, MTU, Table, et les lignes de crochet. Ce ne sont pas des champs du protocole, et une installation wg nue les ignore complètement.

Chaque entrée peer décrit un autre côté

Un [Peer] bloc est la partie distante. PublicKey est la clé dérivée de cette partie, jamais sa clé privée, et PresharedKey est un secret supplémentaire facultatif que les deux côtés doivent détenir à l'identique. Endpoint est où envoyer, et PersistentKeepalive demande à cet hôte d'envoyer un paquet après l'intervalle quand rien d'autre ne sort.

Deux erreurs expliquent l'essentiel de la confusion ici. Copier sa propre clé privée dans un bloc peer fait que les deux extrémités partagent une identité, et le handshake échoue d'une manière qui se journalise mal. Omettre Endpoint sur un client est généralement volontaire, car le serveur apprend l'adresse du handshake entrant ; l'omettre sur un serveur qui doit initier ne l'est pas. Rappelez-vous aussi que keepalive garde une correspondance NAT ouverte, et qu'il n'améliore pas le débit ni ne réduit la latence, donc trente secondes de paquets en plus n'achètent rien quand le trafic circule déjà.

AllowedIPs est du routage, pas une liste d'autorisations

AllowedIPs est le routage par clé cryptographique de WireGuard. En sortie, il décide quel peer reçoit un paquet selon sa destination. En entrée, il décide si un paquet venant de ce peer est accepté selon sa source. Le même champ fait les deux, c'est pourquoi ce n'est pas une liste de contrôle d'accès ni une liste de sites autorisés.

Un AllowedIPs étroit sur le serveur pour un client signifie que le serveur n'acceptera que les paquets revendiquant ces sources et n'enverra que ces destinations à ce client. Élargissez un côté sans élargir l'autre, et vous obtenez un tunnel qui monte et ne laisse rien passer.

Ce que wg-quick ajoute autour du protocole

wg-quick lit le même fichier et effectue les étapes réseau que le protocole laisse au système d'exploitation. Il attribue l'adresse de l'interface, ajoute des routes dérivées de AllowedIPs, écrit les réglages du résolveur et exécute les commandes de crochet dans l'ordre.

Cette couche explique l'asymétrie classique. Un fichier avec 0.0.0.0/0 et une ligne DNS donne au client une route par défaut et un résolveur, et il ne fait absolument rien aux règles de transfert ou de NAT du serveur. Celles-ci relèvent de la configuration du serveur lui-même, et aucun fichier client ne peut les fournir.

Gardez un seul propriétaire pour le fichier. L'éditer à la main alors que SaveConfig est activé signifie que votre modification disparaît la prochaine fois que l'interface tombe, et l'interface ne vous dira pas que c'est arrivé.

Vérifiez l'état appliqué, pas le fichier

Le fichier est une intention. L'état appliqué est ce que le noyau détient, et ils divergent chaque fois qu'un assistant, un drop-in ou un crochet a modifié quelque chose après l'activation.

Lisez l'état vivant et l'adressage ensemble, puis comparez les deux avec ce que vous avez écrit :

sudo wg show
ip -4 addr show dev wg0
ip -4 route show dev wg0
grep -v "^#" /etc/wireguard/wg0.conf

Si la liste des peers est vide, l'interface a été créée sans que sa configuration soit appliquée. Si des adresses et des routes existent mais que les compteurs restent à zéro, le fichier s'est chargé et le handshake échoue, ce qui est un problème de clé ou d'extrémité et non d'ordre des sections. Comparez les deux vues avant d'éditer, car l'écart entre elles est généralement la vraie panne.