Toute personne utilisant Wireguard avec des pairs dont l'adresse IP change (par exemple parce qu'ils sont sur une connexion DSL privée) doit vérifier régulièrement l'adresse IP.
Wireguard lui-même ne fait qu'une résolution DNS lors du démarrage de l'interface afin d'obtenir l'adresse IP actuelle de l'homologue. Toutefois, si l'adresse du serveur change, par exemple, la connexion échouera à un moment donné.
Heureusement, cela peut être intercepté avec un petit script qui est exécuté toutes les 10 minutes, par exemple. L'une des approches est le Script dans la documentation Ubuntu pour Wireguardqui, cependant, ne fonctionnait pas facilement sur mon client Debian (et me semblait également un peu compliqué).
#!/bin/bash
# Vérifier l'état de l'interface
# wg0-client : nom de l'interface à vérifier
# meinpeer.dyndns.net : le nom du pair dont l'IP doit être vérifiée.
cip=$(wg show wg0-client endpoints | grep -E -o "([0-9]{1,3}[\.]){3}[0-9]{1,3}")
echo "$cip"
digIP=$(dig +short meinpeer.dyndns.net) # L'adresse de l'homologue doit être ajustée.
echo "$digIP"
if [ "$digIP" != "$cip" ]
puis
echo "Les données sont différentes"
/usr/sbin/service wg-quick@wg0-client redémarre
sinon
echo "Les données sont les mêmes"
#To do nothing
fi
Les éléments essentiels du script ci-dessus : à la ligne 6, l'adresse IP actuelle utilisée par l'interface est déterminée à l'aide des outils wireguard et grep. La ligne 8 vérifie l'adresse IP que possède actuellement le pair. Si ces deux valeurs diffèrent, l'interface wireguard est redémarrée à la ligne 13 - la résolution de l'adresse IP est alors également effectuée à nouveau et la connexion est rétablie.
Le redémarrage de l'interface wireguard à la ligne 13 peut devoir être ajusté, en fonction du nom réel de l'interface dans votre configuration.
Il existe, bien sûr, d'autres approches de la résolution d'IP, mais pour mon installation, c'est une méthode très simple. Un inconvénient : s'il y a plusieurs pairs, cette approche ne fonctionne pas si facilement - il faudrait alors d'abord déterminer le bon pair via une expression rationnelle afin d'y lire les données correspondantes.
Ce script est nécessaire pour maintenir la connexion dans ma Configuration des réplications FreeNASqui fonctionne maintenant avec Wireguard.
Ajout : vérification de l'IP avec plusieurs pairs
Si vous avez entré plusieurs pairs dans votre configuration Wireguard (par exemple, une connexion statique et une fois la connexion via un smartphone pour un VPN), il se peut que vous ne souhaitiez effectuer la vérification de l'IP décrite ici que pour un seul pair. La façon la plus simple de le faire est de vérifier en plus un pair spécifique. En partant de la configuration de pair suivante (dont les valeurs ne correspondent pas à un pair réel) :
[Pair] PublicKey = mhzqblUOAzxVhOypkidxLnxp5rfYD7uRtvyj0sOi4GE= IPs autorisés = 0.0.0.0/0, ::/0 Point final = mypeer.dyndns.net:51820
La première ligne du script de contrôle doit être adaptée en conséquence :
cip=$(wg show wg0-client endpoints | grep -E "mhzqblUO" | grep -E -o "([0-9]{1,3}[\.]){3}[0-9]{1,3}")
Complètement, ça ressemble à ça :
#!/bin/bash
# Vérifier l'état de l'interface
# wg0-client : nom de l'interface à vérifier
# meinpeer.dyndns.net : le nom du pair dont l'IP doit être vérifiée.
cip=$(wg show wg0-client endpoints | grep -E "mhzqblUO" | grep -E -o "([0-9]{1,3}[\.]){3}[0-9]{1,3}")
echo "$cip"
digIP=$(dig +short meinpeer.dyndns.net) # L'adresse de l'homologue doit être ajustée.
echo "$digIP"
if [ "$digIP" != "$cip" ]
puis
echo "Les données sont différentes"
/usr/sbin/service wg-quick@wg0-client redémarre
sinon
echo "Les données sont les mêmes"
#To do nothing
fi
Il est important de noter que le script de vérification ne fonctionnera pas dans la variante avec certains pairs si vous ne remplacez pas la valeur correspondante par celle de votre configuration. Dans ma configuration, je l'exécute toutes les 5 minutes, jusqu'à présent il a rempli son rôle. Étant donné que l'adresse IP est uniquement appariée, cela devrait également fonctionner dans une configuration IPv6 - mais comme j'utilise toujours une connexion télécom classique avec IPv4, je n'ai pas examiné la question en détail. Si l'un des lecteurs a une expérience dans ce domaine (également en ce qui concerne DynDNS et IPv6 sur la Fritzbox), il est le bienvenu de laisser quelque chose dans les commentaires !
Français 
Deutsch 
English 
Español
Merci pour la contribution ! Il existe également un script prêt à l'emploi dans le paquet wireguard-tools : https://wiki.archlinux.org/index.php/WireGuard#Endpoint_with_changing_IP
Avec celui-ci, il suffit de modifier le point de terminaison (ligne 40) : ENPOINT="xyz.de:Port" ; continue ; ;
Le script est en fait également disponible pour Debian, et est alors situé dans
/usr/share/doc/wireguard-tools/examples/reresolve-dns/reresolve-dns.sh
(le chemin est très peu différent que sous Arch)
Je vais devoir regarder de plus près, si je me souviens bien, il y avait un problème avec le script lorsque je l'ai mis en place.
Cela devrait être plus facile à résoudre avec l'aide de l'option "PersistentKeepalive =".
Je lance la connexion depuis la route (par exemple, depuis l'iPhone) vers une adresse DynDNS. Grâce à Keepalive, un paquet est envoyé à l'autre côté toutes les 25 secondes. On peut supposer qu'il est très peu probable que l'adresse change des deux côtés en même temps. Ainsi, au moins un côté du tunnel est toujours atteint.
Si l'homologue concerné reçoit le paquet à partir d'une adresse IP externe différente, mais que le routage de la clé cryptographique correspond (combinaison de l'adresse IP privée et de la clé publique), le mappage de l'IP externe de l'homologue est mis à jour et les réponses suivantes arrivent à nouveau correctement.
Il faudrait que je force les changements d'adresse et que je les teste explicitement pour pouvoir en être sûr, mais dans l'utilisation quotidienne, je n'ai jamais eu de problèmes de tunnels cassés ou morts avec l'iPhone/iPad, Linux ou macOS.
Cela fonctionne parce que les adresses IP correspondent lorsque la connexion est établie. Un appareil mobile s'initialise ensuite souvent, par exemple si la réception était trop mauvaise, etc.
Si vous travaillez avec une configuration de deux connexions DSL fixes, il est tout à fait possible qu'une extrémité change sans que la connexion soit rétablie. Dans ce cas, la résolution de l'adresse DynDNS ne correspond plus et la connexion aboutit à une mauvaise IP. Pour cela, vous avez besoin de l'ajustement, soit comme posté ici, soit avec le script de Michael.
Avec l'iPhone, je n'ai jamais eu à le faire non plus, mais la réplication n'aboutit à rien au plus tard le troisième jour.
Ce n'est pas le cas. L'adresse DynDNS qui est stockée dans wg0.conf est utilisée pour la configuration initiale de la connexion. Cependant, pendant qu'une connexion est établie, l'attribution de l'IP publique à l'homologue est aussi constamment mise à jour sur le serveur par les nouveaux paquets qui arrivent (voir https://www.wireguard.com/#cryptokey-routing, section "Itinérance intégrée" ; voir https://www.wireguard.com/papers/wireguard.pdfsection 2.1). Wireguard se comporte comme mosh et devrait être très robuste lorsqu'il s'agit de changer les adresses IP. Cependant, il est effectivement important que le pair dont l'adresse publique a changé lance toujours rapidement une communication pour informer les autres de ce changement. En fait, le serveur ne devrait pas le faire si souvent.
Ce que je viens d'apprendre : le Keepalive n'est envoyé que lorsqu'un pair a reçu des paquets mais ne doit pas réellement répondre. Avant que la minuterie KeepAlive n'expire, un paquet de réponse Wireguard vide est alors envoyé. Ainsi, le pair doit effectivement envoyer régulièrement quelque chose pour que le mécanisme fonctionne de manière fiable. Pris isolément, il n'est donc pas adapté à la mise à jour permanente des tables d'adresses des pairs. J'avais donc tort. Vous avez donc également raison au sujet de l'iPhone. Ici, les connexions sont certainement rétablies complètement plus souvent, ce qui signifie que le problème du changement d'IP du serveur n'est pas si perceptible. Mais on a l'impression que le tunnel est toujours là tant qu'il y a une connexion internet.
Cependant, si vous vous assurez dans la configuration NAT DSL avec des IP de serveur changeantes qu'un message est régulièrement envoyé depuis les réseaux des deux partenaires, par exemple par des pings mutuels réguliers toutes les minutes (tâche cron sur les deux FreeNAS ?!), alors la connexion VPN ne doit jamais ou seulement brièvement aller nulle part, parce que l'adresse IP actuelle sera connue rapidement. La rapidité dépend de la fréquence des pings.
Ainsi, vous n'avez pas besoin de retirer régulièrement l'interface réseau et de modifier le routage. Cela semble un peu plus élégant (à mon avis).
Un autre problème est que, dans le pire des cas, avec une configuration à deux connexions DSL, un pair essaie de résoudre l'IP de l'autre pendant que la reconnexion automatique (que certains fournisseurs font encore) est exécutée - Wireguard abandonne probablement complètement assez rapidement ici : https://lists.zx2c4.com/pipermail/wireguard/2019-February/003866.html
Une fois qu'il s'est arrêté, le redémarrage de l'interface est assez fiable pour obtenir à nouveau une connexion. Dans mon cas, les données ne sont transmises qu'une fois par heure.
Mais c'est là toute la beauté de la chose : en fonction de l'application spécifique, différents chemins mènent au but 😉 .
Bonjour,
J'ai aussi exactement ce scénario.
J'ai installé l'application Android sur mon téléphone. Le DynDns de ma FritzBox est entré dans le fichier de conf pour ce peer. Le serveur Wireguard est situé à la maison dans le réseau derrière la FritzBox sur un Raspberry. KeepAlive est entré sur les deux avec 25. L'application a démarré et tout fonctionne bien.
Jusqu'à la déconnexion et la reconnexion forcées par le fournisseur DSL. Le tunnel est interrompu, pas de connexion, rien.
J'ai configuré l'unité de temporisation avec le script ci-dessus reresolve-dns.sh - sans succès.
Je suis un peu perdu.
Salutations
Harald
Je peux confirmer l'observation d'Harald.
À mon avis, le client Android devrait tester la connectivité et se réinitialiser avec la nouvelle résolution des pairs du "serveur". Il faudrait donc avoir une application Android qui implémente également ce qui a été dit ici sous Ubuntu / Debian.
Ou est-ce que je me trompe complètement ? Quoi qu'il en soit, il me semble que nous ne pouvons pas changer de comportement sans modifier l'application Android.
Salutations
Markus
Salut Falk, merci pour le script ! L'avant-dernière ligne ne peut pas être correcte, je suppose qu'elle est censée dire "echo 'Nothing to do'". Ou est-ce que je rate quelque chose ? Cheers Philipp
C'est juste un commentaire sur la mauvaise ligne - bien sûr, vous pouvez ajouter un texte supplémentaire, mais ce n'est pas nécessaire.
Bonjour Falk,
J'ai été confronté au problème du changement d'adresse IP et j'ai lu quelques conseils/scripts. Je ne suis pas encore très expérimenté dans le domaine de Linux et la plupart des conseils étaient totalement confus. Mais j'ai pu utiliser votre script avec deux petits changements sur le Raspberry avec pivpn et wireguard. Et donc je voulais juste vous dire MERCI d'avoir pris la peine de créer ce post.
Il est juste trop court pendant cette période. Vous m'avez épargné quelques cheveux blancs 😉 .
Merci beaucoup pour cet article - Matthias
Pls fixer pour utiliser docker 😉
Pont de la mode
Un redémarrage n'est pas nécessaire, il est possible de modifier l'adresse du point final avec :
wg set wg0 endpoint :
à nouveau.
Avec :
PUB=$(wg | grep peer | awk '{print $2}')
permet de le déterminer. Si l'adresse est une adresse IPv6, elle doit être entourée de '[' et ']'.