Les deux réponses plus haut score, nmcli dev list iface <interfacename> | grep IP4et les nm-tooldeux partent du principe que le réseau gestionnaire est en contrôle. C'est ce qui se passe - du moins sur les ordinateurs de bureau. Mais la réponse plus complète est que parfois, le gestionnaire de réseau n’est pas en contrôle. Par exemple, vpncavec /etc/resolv.confdirectement.
Donc: vérifiez d'abord si 127.0.0.1/localhost est utilisé. Cela pourrait être fait avec dig:
> dig something.unknown | grep SERVER:
;; SERVER: 127.0.0.1#53(127.0.0.1)
Maintenant , vous savez que nous sommes utilisons localhost. Allez-y avec l'une des réponses populaires. J'aime:
> nm-tool | grep DNS:
DNS: 8.8.8.8
Mais si 127.0.0.1/localhost n'est pas utilisé, les résultats de then nm-toolet nmclide seront trompeurs:
> dig something.unknown | grep SERVER:
;; SERVER: 172.22.216.251#53(172.22.216.251)
> nm-tool | grep DNS:
DNS: 8.8.8.8
Ici, digest correct et nm-toolles informations sont trompeuses. En réalité, les adresses locales à l'environnement dans lequel le VPN est édité sont résolues correctement. Le DNS de Google 8.8.8.8 ne le sait pas .
En effet, après la connexion à un réseau VPN avec vpnc, il insère une ligne /etc/resolv.confpour ressembler à ceci:
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 1.2.3.4
nameserver 127.0.0.1
search MyDomain