Два наиболее популярных ответа, nmcli dev list iface <interfacename> | grep IP4
и nm-tool
оба предполагают, что сетевой менеджер находится под контролем. Который это - на настольных машинах большую часть времени по крайней мере. Но более полный ответ заключается в том, что иногда сетевой менеджер не контролирует ситуацию. Например, vpnc
портится /etc/resolv.conf
напрямую.
Итак: Сначала проверьте, используется ли 127.0.0.1/localhost. Это можно сделать с помощью dig
:
> dig something.unknown | grep SERVER:
;; SERVER: 127.0.0.1#53(127.0.0.1)
Теперь вы знаете , что мы являемся используя локальные. Продолжайте с одним из популярных ответов. Мне нравится:
> nm-tool | grep DNS:
DNS: 8.8.8.8
Но если 127.0.0.1/localhost не используется, вывод nm-tool
's and nmcli
' будет вводить в заблуждение:
> dig something.unknown | grep SERVER:
;; SERVER: 172.22.216.251#53(172.22.216.251)
> nm-tool | grep DNS:
DNS: 8.8.8.8
Здесь, dig
это правильно и nm-tool
информация вводит в заблуждение. На самом деле адреса, локальные для среды, в которую я подключился по VPN, разрешены правильно. Все, о чем DNS Google 8.8.8.8
не знает.
Это связано с тем, что после подключения к VPN vpnc
он добавляет строку, /etc/resolv.conf
которая выглядит следующим образом:
# 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