Le 11/03/2024 à 09:32, Toussaint OTTAVI a écrit :
Salut la liste,
Bonjour,
Des sites distants montent des VPN Wireguard vers un hub central, défini
par un FQDN. L'adresse IP du hub change. L'enregistrement DNS
correspondant est mis à jour. Mais sur les sites distants, Wireguard
reste "accroché" à l'ancienne IP, il ne fait jamais de nouvelle
résolution DNS, il ne s'aperçoit pas que son remote ne répond plus, et
ne re-négocie jamais son tunnel. La seule solution est de redémarrer
Wireguard (pour peu que l'on ait encore accès au site).
Wireguard ne retente pas de résolution DNS tant que le tunnel est monté.
Je me souviens m'être heurté à cette limitation dans une vie antérieure.
J'avais lu qu'au démarrage du tunnel, WG fait sa résolution et ouvre le
socket de connexion vers l'adresse IP elle-même.
En fouillant dans la doc de Wireguard, je ne trouve pas de fonction
"Dead Peer Detection", qui aurait permis de réinitialiser un tunnel qui
ne répond plus. Certes, le DPD en général n'a jamais été une science
exacte :-) Mais dans Wireguard, apparemment, c'est déterministe : il n'y
en a pas :-)
WG a vraiment une volonté de rester hyper centré sur le montage du
tunnel. Mon avis étant que c'était pour pouvoir être intégré rapidement
dans le kernel (ce qui a bien boosté son adoption d'ailleurs).
La solution trouvée à l'époque était de monitorer + restart du tunnel en
cas d'indispo du peer (*). Jamais trouvé de mécanisme interne.
Peut être que des solutions packagées sont apparues des 2 dernières années.
Julien
* : trop tôt pour les trolls mais pour le coup, ca se fait bien avec
systemd ;-)
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
