Форум проекта Matuntu
Поддержка => Сети/Интернет => Тема начата: ivm от 16 Августа 2015, 18:21:22
-
Последнее время в системе применяется механизм автоматического выбора dns. Изменение файла /etc/resolv.conf сохраняются до перезагрузки.
Нашлось хорошее решение, позволяющее "сохранить" нужные изменения. sudo touch /etc/network/if-up.d charge_dns
sudo nano /etc/network/if-up.d/charge_dns и вставляем в него желаемый сервер(ы)#! /bin/sh
echo "nameserver Х.Х.Х.Х" > /etc/resolv.conf
echo "nameserver 8.8.8.8" >> /etc/resolv.conf
echo "nameserver 8.8.4.4" >> /etc/resolv.conf
остаётся дать права на исполнение полученному скрипту
sudo chmod +x /etc/network/if-up.d/charge_dns
решение найдено на Форуме русскоязычного сообщества Ubuntu (http://forum.ubuntu.ru/index.php?topic=64786.0)
-
Есть ещё другой путь.
Заходим в /run/resolvconf/ и смотрим на файл resolv.conf. Открываем его от администратора в Pluma и изменяем цифры, указанные в строке nameserver, на 8.8.8.8, т.е. приводим к виду # 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 8.8.8.8Работает до перезагрузки.
-
Как говорит мой друг, интересно девки пляшут... :)
Ещё более интересно выглядит картина с сетевым соединением в тестовой 17.04.
Gradio работает, пинги есть, т.е. связь с интернетом нормальная. А в браузере может возникнуть такое сообщение: Не удается получить доступ к сайту
Не удается найти DNS-адрес сервера forum.matuntu.org.
Попробуйте сделать следующее:
Проверьте настройки прокси-сервера, брандмауэра и DNS.
DNS_PROBE_FINISHED_BAD_CONFIG
При этом resolv.conf следующего содержания:
cat /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
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
nameserver 127.0.0.53
Ух ты, какой сервер! Насколько я знаю, связь между DNS-серверами осуществляется через 53-й порт. Но тогда в записи сервера порт намесервера должен быть отделён от адреса двоеточием. Попробовал банально заменить на четыре восьмёрки и проблема исчерпана до следующей перезагрузки.
Проблема связи оказывается в неправильном механизме конфигурирования resolv.conf. Но мы знаем, как бороться с этой проблемой.
-
Пользователям, тестирующим Ubuntu 17.04, на убунтовском форуме до устранения проблемы разработчиками подсказали откатить версию NM с последующей блокировкой от обновления (http://forum.ubuntu.ru/index.php?topic=282959.msg2263259#msg2263259).
-
Мне приходилось сталкиваться с ситуацией, когда провайдер очень долго настраивал свои DNS-сервера. И сервер, который ещё вчера работал, сегодня мог тупить. Второй DNS при этом в связи с возникшей нагрузкой также через некоторое время начинал тормозить. При переходе на альтернативные сервера всегда возникал вопрос, как померить качество доступа к серверу. Нашёл такое решение (https://wiki.archlinux.org/index.php/Resolv.conf).
Для оценки DNS в линуксе есть пакет ldnsutils и его нужно установить: sudo apt install ldnsutilsПосле его установки станут доступны инструменты для тестирования DNS.
Можно указать IP-адрес конкретного сервера имен, минуя настройки в файле /etc/resolv.conf: drill @ip.of.name.server www5.yahoo.com
Например, drill @8.8.8.8 www5.yahoo.com вывод: ;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 11185
;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;; www5.yahoo.com. IN A
;; ANSWER SECTION:
;; AUTHORITY SECTION:
yahoo.com. 10 IN SOA ns1.yahoo.com. hostmaster.yahoo-inc.com. 2017031203 3600 300 1814400 600
;; ADDITIONAL SECTION:
;; Query time: 169 msec
;; SERVER: 8.8.8.8
;; WHEN: Mon Mar 13 14:09:55 2017
;; MSG SIZE rcvd: 93
Можно заметить, что в новом resolv.conf Ubuntu 17.04 прописан nameserver 127.0.0.53, его тест в локальной сети после роутера секунд через 15-20 завершится ошибкой: Error: error sending query: Could not send or receive, because of network error
Но при проверке в провайдерской сети напрямую без роутера показывает:
;; ->>HEADER<<- opcode: QUERY, rcode: SERVFAIL, id: 9410
;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; www5.yahoo.com. IN A
;; ANSWER SECTION:
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 133 msec
;; SERVER: 127.0.0.53
;; WHEN: Mon Mar 13 14:39:33 2017
;; MSG SIZE rcvd: 32
При выполнении с учётом реальных настроек локальной сети к DNS, прописанным в роутере, выглядит так:
drill @192.168.1.1 www5.yahoo.com
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 6957
;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;; www5.yahoo.com. IN A
;; ANSWER SECTION:
;; AUTHORITY SECTION:
yahoo.com. 600 IN SOA ns1.yahoo.com. hostmaster.yahoo-inc.com. 2017031203 3600 300 1814400 600
;; ADDITIONAL SECTION:
;; Query time: 241 msec
;; SERVER: 192.168.1.1
;; WHEN: Mon Mar 13 13:36:34 2017
;; MSG SIZE rcvd: 93
Теперь можно сравнить полученные параметры DNS серверов, например, время запроса (Query time) и т.д.
Время доступа к DNS, прописанный в роутере, с ума сойти какой большой.
-
В Matuntu-X64-M116 на основе Ubuntu 16.04.2 (выход в интернет через Wi-Fi)
cat /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 127.0.1.1
Никаких проблем с DNS серверами нет. Проверка этого IP при помощи интрумента drill drill @127.0.1.1 www5.yahoo.com; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 39285
;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;; www5.yahoo.com. IN A
;; ANSWER SECTION:
;; AUTHORITY SECTION:
yahoo.com. 600 IN SOA ns1.yahoo.com. hostmaster.yahoo-inc.com. 2017031300 3600 300 1814400 600
;; ADDITIONAL SECTION:
;; Query time: 108 msec
;; SERVER: 127.0.1.1
;; WHEN: Mon Mar 13 15:11:58 2017
;; MSG SIZE rcvd: 93
Проблемы с настройками DNS появились только в тестовых версиях Ubuntu 17.04.
-
Есть такая статья от 2015 года в переводе на русский Как заменить менеджер сетевых соединений NetworkManager на systemd-networkd в Linux (http://rus-linux.net/MyLDP/admin/switch-from-networkmanager-to-systemd-networkd.html).
Может рекомендации из статьи окажутся лучше, чем совет в "ортопедической клинике" форума Ubuntu.ru - вернуться к старому пакету NM и заблокировать его версию от обновления.
-
Обратил внимание на то, что в новом пакете resolvconf дефолтным nameserver числится 127.0.0.53 (127.0.0.53 is the systemd-resolved stub resolver).
Нашёл объяснение (https://translate.google.ru/translate?hl=ru&sl=en&u=https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html&prev=search), что /usr/lib/systemd/resolv.conf файл /usr/lib/systemd/resolv.conf , который перечисляет заглушку DNS 127.0.0.53 (см. Выше) как только DNS-сервер. Этот файл может быть символически связан с /etc/resolv.conf для того, чтобы /etc/resolv.conf клиенты, которые обходят /etc/resolv.conf DNS-API, для разрешения systemd . Этот режим работы рекомендуется.
В локальной сети это решение не работает, только напрямую через сеть провайдера. Поэтому вспоминается песня из Кин-Дза-Дза: "Мама, мама, что я буду делать?!"
-
Сейчас у меня в Zesty интернет через роутер работает без проблем.
Проблему надеялся решить, создав файл resolv.conf в /etc взамен ссылочного как это работало раньше. Прописал гугловский PDNS, но это не помогло. Посмотрел в свойствах проводного соединения. Оказалось, что там есть возможность во вкладке IPv4 прописать дополнительные DNS, что я и сделал, прописал любимые четыре восьмёрки.
После перезагрузки созданный файл /etc/resolv.conf остался, но содержание его изменилось на такое: # Generated by NetworkManager
nameserver 127.0.1.1
Ранее я пробовал прописывать вручную адрес этого сервера, но преобразование доменных имён не работало. Теперь же сеть заработала нормально. Проверка настроек проводного соединения показала, что прописанный мной дополнительный DNS остался после перезагрузки. Судя по всему это и есть решение возникшей проблемы и даёт возможность прописать нужный DNS.
-
Данное решение оказалось весьма простым и эффективным также при использовании Wi-Fi соединения.
Огромное спасибо!
-
Некоторые варианты решения проблем в связи с переходом в Ubuntu 17.04 на использование systemd-resolved приведены здесь (http://forum.ubuntu.ru/index.php?topic=288822.0) и здесь (http://www.hecticgeek.com/2017/04/ubuntu-17-04-systemd-dns-issues/). Хотя из комментариев по второй ссылке от 24 апреля следует вывод:
ошибка была устранена последними обновлениями
-
Сейчас всё нормализовалось, только небольшая задержка в самом начале работы с DNS. Причина очевидно кроется в том, что служба кэширования и проверки DNS (DNSSEC) в целях безопасности поставляется в предустановленной Ubuntu 17.04 и от неё производных дистрибутивов. Эту службу можно отключить, но DNSSEC предназначена для защиты от проникновения извне. Поэтому лучше подождать немного после входа в веббраузер, а затем всё будет функционировать в штатном режиме.
-
Выявлена уязвимость в systemd-resolved, поставляемом в составе systemd кэширующем DNS-резолвере, которая потенциально может привести к выполнению кода при обработке специально оформленного ответа от DNS-сервера, подконтрольного злоумышленнику. Проблема вызвана ошибкой в расчёте размера памяти для обработки запроса, которая может привести к тому, что TCP-ответ не уместится в выделенный буфер.
Как утверждается на сайте OpenNet, Проблеме подвержены версии systemd с 223 по 233 включительно. Обновление с устранением проблемы выпущено для Fedora Linux и Ubuntu, но пока недоступно для Debian Stretch. Проблема не затрагивает Red Hat Enterprise Linux 7 и производные дистрибутивы. (http://www.opennet.ru/opennews/art.shtml?num=46771)
Для проверки версии systemd достаточно в терминале ввести команду: systemd --vВ Matuntu-Z64 получен такой вывод: systemd 232
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN
Сегодняшние обновления коснулись и systemd.
P.s.: Сторонний репозиторий ppa:pitti/systemd (https://launchpad.net/~pitti/+archive/ubuntu/systemd?field.series_filter=zesty) после подключения позволяет в Ubuntu 17.04 (zesty) повысить версию systemd на сегодняшний момент до 233+upstream20170510-0.master, но мне понравилось предупреждение: Этот PPA регулярно получает пакеты для текущего ведущего устройства systemd и другие экспериментальные изменения.
ПРЕДУПРЕЖДЕНИЕ! Не используйте это, если вы не знаете, что делаете!
-
Интересные статьи по рассматриваемой теме можно почитать здесь (https://www.shellhacks.com/ru/setup-dns-resolution-resolvconf-example/) и на Хабрахабре (https://habrahabr.ru/post/280037/).
-
Интересный опыт по изменению настроек DNS для ускорения соединений в интернете я проделал после ознакомления с информацией по ссылке https://it-tuner.ru/kak-uskorit-internet-izmeniv-odnu-nastroyku.html У меня используется доступ в интернет через роутер по wi-fi (провайдер Ростелеком) .По щелчку ПК мыши по значку соединения по wi-fi, далее "изменить соединение" вошел в настройки и на вкладке "Параметры IPv4" в строке "Метод" выбрал "Вручную",потом "Добавить" и в поле Адрес,Маска и Шлюз вписал данные из сведений о текущем соединении,а в строке "Серверы DNS" внес 8.8.4.4 , 8.8.8.8 и сохранил изменения. После перезагрузки в маске сведения 255.255.255.0 изменились на 24.Соединения с адресами в FF заметно ускорились. Для эксперимента я выбрал ОС Astra CE "Orel". Не имея глубоких знаний что в итоге в настройках изменилось, считаю что опытнейшие форумчане мне подробно разъяснят , а может и еще кому нибудь понадобиться зтот опыт.
-
Здесь палка о двух концах. С одной стороны, гугловский PDNS очень мощный и содержит заведомо правильную таблицу доменных имён/адресов. С другой стороны, DNS-сервер провайдера гораздо ближе и, когда он правильно работает без перегрузки, то запрос от провайдерского DNS приходит гораздо быстрее. Для наглядности сравните пинги 8.8.8.8 и провайдерский. У меня DNS "вшит" в оборудование Ростелекома и тесты показывают порядка 2-4 мс. Но ростелекомовский содержит искажение таблицы имён/адресов согласно решениям Московского суда о блокировке определённых ресурсов.