wg-quick casse le DNS à la connexion : lisez l’erreur de configuration

Le tunnel monte, la poignée de main se termine et la résolution de noms s’arrête. Rien dans la configuration du pair n’a changé, car la ligne DNS n’a jamais fait partie de cette configuration. Elle appartient à l’assistant de configuration, ce qui signifie que la panne vit dans l’outillage du résolveur de l’hôte et non dans les clés de WireGuard.

Lisez le premier message imprimé par l’assistant, pas le dernier, et la différence entre un utilitaire manquant et un serveur injoignable devient évidente.

La ligne DNS est une fonction de l’assistant

Les champs de base de la configuration décrivent les pairs, les clés et les adresses autorisées. La résolution se rajoute par-dessus, par le script qui monte l’interface, et chaque implémentation le fait différemment. Un client de bureau peut gérer le DNS via son propre service, un script de distribution peut appeler l’un des divers utilitaires de résolveur, et un conteneur peut ne faire ni l’un ni l’autre. Le fichier de configuration ne peut pas vous dire lequel de ces chemins est en jeu.

C’est pourquoi un fichier de configuration peut être valide pour le protocole et échouer tout de même pendant la configuration : la panne appartient à un crochet que le protocole ne voit jamais.

Écrire un champ étendu dans une configuration de base et attendre que l’outil du protocole l’accepte produit la même confusion dans l’autre sens. Les deux analyseurs lisent des fichiers différents.

Savoir lequel s’exécute est la première étape du diagnostic, et cela se voit généralement dans la commande tapée plutôt que dans le fichier de configuration.

Lisez la première erreur imprimée par l’assistant

Montez l’interface au premier plan et lisez la sortie dans l’ordre. Un utilitaire de résolveur manquant, un crochet en échec et un serveur injoignable arrêtent la même commande à des endroits différents, et chacun a sa propre réparation.

wg-quick up wg0
resolvectl status wg0
ip route get 10.66.0.1

La première commande rapporte la progression de la configuration, la deuxième montre quels serveurs l’interface revendique désormais, et la troisième montre si l’adresse du résolveur est réellement joignable à travers le tunnel. Un résolveur configuré mais non routable produit des délais d’attente plutôt que des erreurs de configuration, c’est pourquoi les deux vérifications vont ensemble. Ne lire que la sortie d’état produit une conclusion assurée et fausse.

Si la configuration s’est terminée et que la résolution échoue encore, comparez le résolveur installé par l’assistant avec celui que le réseau utilisait auparavant. Un résolveur privé a besoin d’une route à travers le tunnel, et une configuration qui le liste sans couvrir son préfixe laisse chaque requête en attente.

Quel résolveur l’hôte a réellement

Les hôtes Linux modernes exécutent souvent un résolveur stub local, si bien que l’adresse installée par l’assistant est consommée par ce stub et non directement par les applications. Modifier à la main un fichier généré peut sembler fonctionner jusqu’à la reconnexion suivante, quand l’assistant le réécrit.

Utilisez l’intégration prise en charge pour la distribution et laissez un seul composant posséder l’état du résolveur. Deux propriétaires produisent la même course que deux propriétaires d’une adresse d’interface, et le symptôme est un hôte qui résout correctement pendant quelques minutes après chaque changement.

Les noms internes méritent leur propre vérification. Un résolveur public peut rétablir la navigation générale tout en faisant échouer chaque nom d’entreprise, ce qui est l’inverse de ce à quoi le tunnel servait. Interrogez le nom interne sur le serveur prévu avant de conclure que le DNS est réparé.

Le nettoyage compte autant que la configuration

Descendez l’interface et inspectez à nouveau l’état du résolveur. Un assistant qui restaure la configuration précédente laisse l’hôte utilisable ; celui qui laisse ses propres serveurs derrière lui crée la panne suivante, souvent des heures plus tard, alors que le tunnel a depuis longtemps disparu.

L’état périmé est facile à repérer dès qu’on le cherche. Une liste de résolveurs peut pointer vers une adresse sur une interface qui n’existe plus, et un domaine de recherche peut survivre à un réseau que vous avez quitté ce matin. L’un ou l’autre rend la prochaine connexion imprévisible, et aucun n’apparaît dans la sortie d’état du tunnel lui-même. La vérification prend dix secondes et en épargne une heure à la personne suivante.

Gardez le diagnostic séparé de la réparation. Si toute destination échoue et pas seulement les recherches de noms, les routes et le transfert sont les suspects et la ligne DNS est une distraction. Le manuel de wg-quick documente les champs qu’il traite et ceux qui appartiennent au protocole, et cette frontière est toute la réponse à la plupart de ces rapports.