16.10 не удается разрешить DNS

После обновления 16.04 до 16.10 у меня возникли проблемы с DNS.

Сначала у меня пару раз возникали проблемы при подключении к WiFi, пока он работал по Ethernet. Теперь, кажется, работает и по WiFi. Не уверен, почему, и если это каким-либо образом связано с проблемой, с которой я сталкиваюсь сейчас:

При подключении к хосту VPN с Cisco AnyConnect VPN , это добавляет строку в «/etc/resolv.conf» . Я понимаю, что в Ubuntu сейчас используется systemd-resolver , и на странице руководства сказано, что есть три разных режима для работы с /etc/resolv.conf. Мой /etc/resolv.conf не является символической ссылкой и не перечисляет 127.0.0.53 в качестве DNS-сервера, поэтому, насколько я понимаю, systemd-resolved должен «прочитать его для данных конфигурации DNS». Однако, это, кажется, не заботится об этом.

копать землю

Странная вещь (для меня) заключается в том dig host.customer.tld, что возвращает хороший ответ с РАЗДЕЛОМ ОТВЕТА, показывающим IP запрашиваемого хоста, и ссылается на сервер DNS, добавленный в /etc/resolv.conf клиентом vpn, в качестве СЕРВЕРА. Когда vpn соединение отключено, я не получаю ответа. Т.е. dig читает /etc/resolv.conf .

пинг

Браузер, с другой стороны, не попадает в /etc/resolv.conf и не может определить имя хоста. Между прочим, это не пинг / завиток.

nmcli

Я нашел соответствующий пост и попытался запустить

nmcli device show <interfacename> | grep IP4.DNS

но в нем нет DNS для устройства cscotun0. (Однако в 16.04 этого не происходит.) Кроме того, nmcli перечисляет мой dhcp-сервер (мой маршрутизатор) как хост IP4.DNS для моих соединений eth / wlan. Использование dig @192.168.0.1 xxxдля любого общественного достояния работает нормально.

конфигурация

В моем /run/systemd/resolve/resolv.conf перечислены некоторые другие DNS-серверы:

nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 2001:4860:4860::8888
# Too many DNS servers configured, the following entries may be ignored.
nameserver 2001:4860:4860::8844

Они не обслуживаются моим сервером DHCP. файл /etc/systemd/resolved.conf содержит только закомментированные строки, кроме заголовка раздела:

[Resolve]
#DNS=
#FallbackDNS=8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844

Страница man для resolved.conf говорит, что

DNS = список разделенных пробелами адресов IPv4 и IPv6 для использования в качестве системных DNS-серверов. ... По соображениям совместимости, если этот параметр не указан, вместо него используются DNS-серверы, указанные в /etc/resolv.conf, если этот файл существует и в нем настроены все серверы. Этот параметр по умолчанию равен пустому списку.

FallbackDNS = разделенный пробелами список адресов IPv4 и IPv6 для использования в качестве резервных DNS-серверов. Любые DNS-серверы для каждой ссылки, полученные из systemd-networkd.service (8), имеют приоритет над этим параметром, как и любые серверы, установленные с помощью DNS = выше или /etc/resolv.conf. Следовательно, этот параметр используется только в том случае, если другая информация DNS-сервера не известна. Если эта опция не указана, вместо нее используется скомпилированный список DNS-серверов.

Похоже, запасной вариант в моем случае заканчивается в /run/systemd/resolve/resolv.conf.

РЕДАКТИРОВАТЬ: Я не был уверен, в чем была проблема, и, честно говоря, я до сих пор не знаю точно, как это работает, но по крайней мере оказалось, что решение в моем случае было отключить systemd-resolvedслужбу. Я думал, что эта услуга необходима, что это компонент, который обеспечивает DNS-сервис для всех локальных приложений, но, видимо, в этой работе есть что-то еще.

У меня возникли похожие проблемы, например, с добавлением дополнительного USB-ключа Wi-Fi. Сначала я отключил dnsmasq в сетевом менеджере, как описано выше, и остановил dnsmasq (остановка службы dnsmasq)

Я заметил, что при устранении проблем во время моего VPN-соединения таблица маршрутизации выглядит немного иначе (вывод команды route). Имя шлюза - DD-WRT в случае, если он не работает, и просто «шлюз», когда он работает. Вывод этого не изменился:

nmcli device show wlp1s0 | grep IP4.DNS

Это продолжало показывать мой маршрутизатор IP. Обходной путь, чтобы заставить это работать некоторое время, должен перезапустить systemd-resolvd:

sudo service systemd-resolved restart

Поскольку dnsmasq выходит за рамки уравнения, причиной проблемы является либо systemd-resolvd, либо что-либо, изменяющее таблицу маршрутизации.

Так что это единственное отличие, которое я вижу:

ubuntu@ubuntu-Lenovo-Yoga-2-11:~$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         gateway         0.0.0.0         UG    601    0        0 

который работает. И это, когда это не работает:

ubuntu@ubuntu-Lenovo-Yoga-2-11:~$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         DD-WRT          0.0.0.0         UG    601    0        0 wlp1s0

И такая же разница в именах на линии VPN:

vpn-dns.name gateway         255.255.255.255 UGH   0      0        0 wlp1s0

Кто знает, что может повлиять на таблицу маршрутизации? Было бы здорово, если бы мы могли это определить, чтобы можно было подать отчет об ошибке. Я серьезно заболел и устал от преследования всех этих ошибок, но я хотел бы исправить их, чтобы будущие пользователи и мы были счастливы :).

[обновление] Кажется, что остановка systemd-resolved может исправить это и не оказать негативного влияния на другие вещи. Вы можете попробовать это и дать ему знать, если это что-то сломает. Я видел при запуске systemd-resolvd в отладке, когда он сломался:

Removing scope on link wlp1s0, protocol llmnr, family AF_INET
Removing scope on link wlp1s0, protocol llmnr, family AF_INET6
Removing scope on link *, protocol dns, family *

Отключить:

sudo systemctl disable systemd-resolved.service

Я обновил отчет Ubuntu с предложениями. [/ update] Добавить: Примечание: отчет об ошибке: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1624317 содержит патч для 17.04 для некоторых проблем. Пожалуйста, проверьте отчет об ошибке и, если возможно, протестируйте патч. Спасибо!

[Обновить]

Пожалуйста, проверьте вышеупомянутый отчет об ошибке, проблема, кажется, решена для 17.10, и с помощью простой команды утечка DNS также может быть отключена.

[/Обновить]

Поведение DNS во время соединения OpenVPN сразу улучшилось, когда я последовал предложению на ubuntuforums:

1. Откройте /etc/NetworkManager/NetworkManager.confв редакторе с правами root.
2. Удалить (или закомментировать хеш #) строку, которая читаетdns=dnsmasq
3. Перезапустите NetworkManager через sudo service NetworkManager restart

Столкнулся с той же проблемой. Каким-то образом я должен был установить DNSmasq с некоторым приложением. Простое удаление dnsmasq решило проблему для меня.

sudo apt-get remove dnsmasq 

С тех пор больше нет отключений или некоторые сайты больше не могут загружаться (у меня возникла проблема с загрузкой gmail, то есть внезапно он не смог подключиться к gmail, хотя другие сайты работали).

Изменить /etc/nsswitch.confи изменить

hosts:          files mdns4_minimal [NOTFOUND=return] dns

в

hosts:          files dns mdns4_minimal [NOTFOUND=return]

Редактировать:

У меня такие же проблемы уже довольно давно. Я был в состоянии разрешить доменные имена из vpn, но я не мог пинговать или свернуть их или использовать их в других приложениях. Описанное выше изменение решило это для меня.