openfortivpn écrase-t-il sans cesse le DNS ? Trouvez le vrai propriétaire

Suivez la connexion dès l'instant où elle monte : le client s'authentifie, pppd négocie, puis quelque chose écrit la configuration DNS dans le système d'exploitation. Si vous savez seulement que le VPN a changé votre résolveur, vous ne savez pas encore laquelle de ces étapes l'a fait. Deux d'entre elles le peuvent, et sur un client qui utilise l'intégration pppd documentée elles s'exécutent assez près l'une de l'autre pour ressembler à un seul acteur. Nommer l'écrivain est la première étape ; choisir son remplaçant est la seconde, et c'est une décision distincte avec ses propres modes de défaillance.

La séquence ci-dessous suit le client vers l'extérieur : ce que la connexion a changé, quel commutateur fait taire quel écrivain, qui est censé prendre le relais et comment confirmer que le résultat survit à une reconnexion. Chaque étape laisse une trace différente, et c'est la trace qui vous dit si la passation a réellement eu lieu.

Commencez par ce que la connexion a réellement changé

Connectez-vous une fois avec votre invocation habituelle et comparez la résolution avant et après. Sur un hôte Linux exécutant systemd-resolved, resolvectl status affiche les serveurs DNS et les domaines de recherche par lien, et un nouveau lien tun ou ppp portant ses propres serveurs est l'empreinte d'une mise à jour côté client. Sur macOS, scutil --dns montre la configuration du résolveur dans l'ordre où les applications la consultent.

Comparez cela au fichier dont vous attendiez la modification. Une entrée liée à la connexion dans la vue par lien et un /etc/resolv.conf réécrit sont deux résultats différents, et le second peut être un lien symbolique que gère entièrement autre chose. Notez l'adresse du résolveur, les domaines de recherche et le nom de l'interface au même instant ; un changement dans l'un d'eux pointe vers un autre écrivain. Sans cette base, chaque correction ultérieure est une supposition sur lequel de trois composants a bougé.

Les deux commutateurs et l'écrivain que chacun fait taire

openfortivpn documente un fragment d'options qui désactive les deux écrivains qu'il peut contrôler, et chaque commutateur a un équivalent entièrement écrit que le manuel traite comme le même réglage.

openfortivpn gw.example.com:443 --no-dns --pppd-no-peerdns
# written out in long form
openfortivpn gw.example.com:443 --set-dns=0 --pppd-use-peerdns=0

--no-dns empêche le client d'appliquer les serveurs DNS qu'il a appris de la passerelle, tandis que --pppd-no-peerdns empêche pppd de pousser le DNS du pair dans le système. Le manuel d'upstream avertit que les mises à jour DNS via PPP peuvent entrer en concurrence avec les propres mises à jour DNS du client, et c'est pourquoi les deux commutateurs appartiennent au fragment au lieu que l'un ou l'autre soit considéré comme suffisant.

Aucun commutateur ne nomme de résolveur de remplacement, et aucun n'empêche un gestionnaire de réseau, un client DHCP ou une intégration VPN séparée d'écrire la résolution ensuite. Faire taire deux écrivains laisse le champ ouvert plutôt que possédé. Si un troisième composant gère déjà le DNS, le fragment ne change rien que vous puissiez observer ; si rien ne le gère, vous venez de retirer la seule source de résolution de noms privés. C'est un arrangement valable seulement lorsque le propriétaire de remplacement a été choisi d'abord et testé seul.

Choisissez le propriétaire avant de désactiver quoi que ce soit

Décidez d'abord qui répond aux requêtes pour les noms de travail, car ce choix conditionne tout ce qui suit. Conserver le résolveur existant signifie que la zone privée doit déjà être joignable d'où que se trouve le client, et un résolveur privé dans le bureau a besoin d'une route qui survit au montage du tunnel. Envoyer chaque requête à un seul service interne est une troisième politique au mode de défaillance plus tranchant : quand ce service est injoignable, les noms publics échouent avec les privés.

La propriété des routes reste séparée à dessein. Les options de route ne sont pas nécessaires parce que vous avez changé le DNS, et désactiver l'installation de routes sans installer de remplaçant peut rendre injoignable le résolveur que vous venez de choisir. Vérifiez la table de routage spécifiquement pour l'adresse du résolveur, pas seulement pour le sous-réseau de l'application que vous avez testé par hasard.

Vérifiez la résolution par lien, pas par fichier

Un seul /etc/resolv.conf n'est pas un inventaire de ce que les applications utilisent réellement sur un hôte à résolution limitée ou par domaine, alors lisez l'état du résolveur comme la plateforme l'expose.

resolvectl status
resolvectl query vpn.internal.example.com
resolvectl query example.com
ip route get 10.20.0.53

Interrogez un nom privé et un nom public une fois la connexion montée, et notez quel lien a répondu à chacun. Là où le lien VPN porte une liste de recherche par domaine, un nom privé peut se résoudre correctement tandis qu'un nom public va encore au résolveur local, et cette séparation est le dessein qui fonctionne, pas une panne. Si la requête privée échoue, inspectez la route vers le résolveur avant de toucher au DNS de nouveau ; si elle réussit alors qu'une application échoue encore, l'application lit peut-être un résolveur à elle, mis en cache ou configuré séparément.

Reconnectez-vous et confirmez l'état déconnecté

Coupez la connexion et répétez les deux requêtes. Ce que le propriétaire choisi a installé doit être retiré ou restauré par ce propriétaire, et non laissé derrière par le client que vous avez fait taire. Une entrée par lien obsolète qui survit au tunnel continue d'envoyer des requêtes privées vers une adresse qui n'est plus joignable.

Reconnectez-vous ensuite et relisez les trois mêmes valeurs : adresse du résolveur, domaines de recherche, interface.

Si elles correspondent à la politique que vous avez notée, la passation est complète et le client VPN n'est plus l'un des écrivains. Si une valeur revient en arrière quelques secondes après le montage du lien, autre chose applique encore de la configuration, et l'étape suivante est d'identifier ce composant plutôt que d'ajouter un autre indicateur. L'état final que vous voulez est sans incident : un propriétaire, une politique documentée et un hôte déconnecté qui résout exactement comme avant l'existence du tunnel.