netplan: nameservers в netplan yaml. Какой эффект?

Вы можете проверить результаты для iwconfig, поскольку wlan0 не будет существовать по умолчанию из-за Predicatable Interface Naming и внести необходимые корректировки в команду macchanger

2
задан 19 May 2018 в 13:08

6 ответов

ПРИМЕЧАНИЕ. Это может дублировать информацию из chili555, однако при обсуждении с ними вышеупомянутый человек предложил опубликовать «авторитетный» ответ, поскольку я работал с этой точной проблемой / вопросом раньше.

Поведение, наблюдаемое в вашей среде, это systemd-resolved эквивалент того, что делал dnsmasq до 18.04. Обновления netplan влияют на серверы имен, которые systemd-resolved используют для поиска. Это подробно описано в последнем разделе ответа.

Но сначала для любопытной истории о таком поведении и о том, как она отличается от «более старых» версий Ubuntu, использующих Network Manager и dnsmasq , (Невозможно пропустить следующий раздел этого ответа, если вы хотите только связать 18.04)

До 18.04: dnsmasq в качестве локального распознавателя кэширования [!d5 ]

До 18.04, когда вы использовали GUI Ubuntu, он установил dnsmasq вместе с Network Manager. Интеграция с сетевым менеджером с dnsmasq обновила список dnsmasq серверов «следующего перехода» (восходящие DNS-серверы) для отправки запроса.

Поэтому DNS-запрос для google.com перейдите из любого приложения, запрашивающего разрешение, в dnsmasq, и если dnsmasq не знает IP-адрес или имеет истечение срока действия кэшированной записи, он затем передаст запрос DNS на любой восходящий DNS-сервер (для этого примера, 8.8.8.8 или 8.8.4.4). Затем вам нужно будет проверить Network Manager или конфигурацию dnsmasq, чтобы увидеть, где находятся DNS-серверы вверх.

Это типичное поведение в графическом Ubuntu, установленном с ISO ISO.

Установленная по умолчанию установка из ISO-файлов сервера, наоборот, следовала традиционному методу «update /etc/resolv.conf» через пакет resolvconf и использовала /etc/resolv.conf непосредственно вместо связи через dnsmasq.

До 18.04: dnsmasq в качестве локального распознавателя кэширования

С 18.04 по умолчанию система DNS systemd-resolved. Это работает, как и dnsmasq старого, за исключением того, что это делается как для настольных, так и для серверных ISO-установок. Он также может интегрироваться с Network Manager (используется в средах GUI для управления Wi-Fi и т. Д.), А с Netplan (который лучше обрабатывает ethernets)

systemd-resolved передается из netplan списка DNS-серверов для отправки запросов. Поэтому, используя тот же пример выше, DNS-запрос к google.com будет проходить через systemd-resolved 'sub resolver, который либо вернет значение кэшированного поиска, либо передаст его на восходящие DNS-серверы.

Это эмулирует поведение по умолчанию dnsmasq, но также добавляет некоторую дополнительную обработку поиска для того, как «localhost» и другие локальные адреса могут быть запрошены.

С NetPlan или Network Manager вы можете получить список восходящих DNS-серверов через systemd-resolved со следующей командой:

systemd-resolve --status

, которая даст вам кучу вывода. Соответствующий раздел будет выглядеть так (взятый из ответа chili555 для целесообразности):

DNS Servers: 8.8.8.8
             8.8.4.4
             2600:1700:5aa0:830::1
3
ответ дан 22 May 2018 в 10:48
  • 1
    Я использую 18.04. Я что-то упускаю. С вашего поста я понимаю, что с netplan разрешение имен выполняется с помощью systemd-разрешен с использованием конфигурации в конфигурации netplan (файл yaml, используемый netplan, генерирует и применяет). Используя это понимание, я отключил resolvconf и перезагрузился. Думаю, я должен избавиться от пути. (Я установил resolvconf, потому что он не стал стандартным в 18.04.) Systemd-resolve --status отображает некоторые IP-адреса add-arpa, но не имеет поля DNS-сервера или домена. Итак ... Нужен ли нам resolvconf? Или что-то? – Stephen Boston 12 May 2018 в 03:36
  • 2
    @StephenBoston. Не видя конкретной конфигурации в вашей системе и конкретного вывода вашего systemd-resolve --status, на который вы ссылаетесь, я не могу дать вам ответ. Рассмотрим этот пример output , хотя из одного из моих контейнеров LXD - DNS-серверы имен связаны на основе ссылок - строка 36 этого вывода - это то, где запускаются DNS-серверы имен ... – Thomas Ward♦ 12 May 2018 в 08:06
  • 3
    Есть еще одна проблема, о которой я расскажу здесь, но которая, я думаю, должна, вероятно, быть другим вопросом. Однако, возможно, у вас есть понимание. Это означает, что поле поиска в netplan yaml не имеет эффекта. Я должен ввести это в resolv.conf. – Stephen Boston 12 May 2018 в 16:43
  • 4
    Конфигурируемые серверы имен Netplan отображаются на выходе systemd-resol с отключенным resolvconf. У меня есть доступ через эти серверы имен. Однако я обнаружил, что мне нужно создать /etc/resolv.conf и поставить nameserver 127.0.0.53. Я подозреваю, что это неправильно. Файл должен быть сгенерирован, правда? – Stephen Boston 12 May 2018 в 17:01
ПРИМЕЧАНИЕ. Это может дублировать информацию из chili555, однако при обсуждении с ними вышеупомянутый человек предложил опубликовать «авторитетный» ответ, поскольку я работал с этой точной проблемой / вопросом раньше.

Поведение, наблюдаемое в вашей среде, это systemd-resolved эквивалент того, что делал dnsmasq до 18.04. Обновления netplan влияют на серверы имен, которые systemd-resolved используют для поиска. Это подробно описано в последнем разделе ответа.

Но сначала для любопытной истории о таком поведении и о том, как она отличается от «более старых» версий Ubuntu, использующих Network Manager и dnsmasq , (Невозможно пропустить следующий раздел этого ответа, если вы хотите только связать 18.04)

До 18.04: dnsmasq в качестве локального распознавателя кэширования

До 18.04, когда вы использовали GUI Ubuntu, он установил dnsmasq вместе с Network Manager. Интеграция с сетевым менеджером с dnsmasq обновила список dnsmasq серверов «следующего перехода» (восходящие DNS-серверы) для отправки запроса.

Поэтому DNS-запрос для google.com перейдите из любого приложения, запрашивающего разрешение, в dnsmasq, и если dnsmasq не знает IP-адрес или имеет истечение срока действия кэшированной записи, он затем передаст запрос DNS на любой восходящий DNS-сервер (для этого примера, 8.8.8.8 или 8.8.4.4). Затем вам нужно будет проверить Network Manager или конфигурацию dnsmasq, чтобы увидеть, где находятся DNS-серверы вверх.

Это типичное поведение в графическом Ubuntu, установленном с ISO ISO.

Установленная по умолчанию установка из ISO-файлов сервера, наоборот, следовала традиционному методу «update /etc/resolv.conf» через пакет resolvconf и использовала /etc/resolv.conf непосредственно вместо связи через dnsmasq.

До 18.04: dnsmasq в качестве локального распознавателя кэширования

С 18.04 по умолчанию система DNS systemd-resolved. Это работает, как и dnsmasq старого, за исключением того, что это делается как для настольных, так и для серверных ISO-установок. Он также может интегрироваться с Network Manager (используется в средах GUI для управления Wi-Fi и т. Д.), А с Netplan (который лучше обрабатывает ethernets)

systemd-resolved передается из netplan списка DNS-серверов для отправки запросов. Поэтому, используя тот же пример выше, DNS-запрос к google.com будет проходить через systemd-resolved 'sub resolver, который либо вернет значение кэшированного поиска, либо передаст его на восходящие DNS-серверы.

Это эмулирует поведение по умолчанию dnsmasq, но также добавляет некоторую дополнительную обработку поиска для того, как «localhost» и другие локальные адреса могут быть запрошены.

С NetPlan или Network Manager вы можете получить список восходящих DNS-серверов через systemd-resolved со следующей командой:

systemd-resolve --status

, которая даст вам кучу вывода. Соответствующий раздел будет выглядеть так (взятый из ответа chili555 для целесообразности):

DNS Servers: 8.8.8.8 8.8.4.4 2600:1700:5aa0:830::1
3
ответ дан 17 July 2018 в 14:35
ПРИМЕЧАНИЕ. Это может дублировать информацию из chili555, однако при обсуждении с ними вышеупомянутый человек предложил опубликовать «авторитетный» ответ, поскольку я работал с этой точной проблемой / вопросом раньше.

Поведение, наблюдаемое в вашей среде, это systemd-resolved эквивалент того, что делал dnsmasq до 18.04. Обновления netplan влияют на серверы имен, которые systemd-resolved используют для поиска. Это подробно описано в последнем разделе ответа.

Но сначала для любопытной истории о таком поведении и о том, как она отличается от «более старых» версий Ubuntu, использующих Network Manager и dnsmasq , (Невозможно пропустить следующий раздел этого ответа, если вы хотите только связать 18.04)

До 18.04: dnsmasq в качестве локального распознавателя кэширования

До 18.04, когда вы использовали GUI Ubuntu, он установил dnsmasq вместе с Network Manager. Интеграция с сетевым менеджером с dnsmasq обновила список dnsmasq серверов «следующего перехода» (восходящие DNS-серверы) для отправки запроса.

Поэтому DNS-запрос для google.com перейдите из любого приложения, запрашивающего разрешение, в dnsmasq, и если dnsmasq не знает IP-адрес или имеет истечение срока действия кэшированной записи, он затем передаст запрос DNS на любой восходящий DNS-сервер (для этого примера, 8.8.8.8 или 8.8.4.4). Затем вам нужно будет проверить Network Manager или конфигурацию dnsmasq, чтобы увидеть, где находятся DNS-серверы вверх.

Это типичное поведение в графическом Ubuntu, установленном с ISO ISO.

Установленная по умолчанию установка из ISO-файлов сервера, наоборот, следовала традиционному методу «update /etc/resolv.conf» через пакет resolvconf и использовала /etc/resolv.conf непосредственно вместо связи через dnsmasq.

До 18.04: dnsmasq в качестве локального распознавателя кэширования

С 18.04 по умолчанию система DNS systemd-resolved. Это работает, как и dnsmasq старого, за исключением того, что это делается как для настольных, так и для серверных ISO-установок. Он также может интегрироваться с Network Manager (используется в средах GUI для управления Wi-Fi и т. Д.), А с Netplan (который лучше обрабатывает ethernets)

systemd-resolved передается из netplan списка DNS-серверов для отправки запросов. Поэтому, используя тот же пример выше, DNS-запрос к google.com будет проходить через systemd-resolved 'sub resolver, который либо вернет значение кэшированного поиска, либо передаст его на восходящие DNS-серверы.

Это эмулирует поведение по умолчанию dnsmasq, но также добавляет некоторую дополнительную обработку поиска для того, как «localhost» и другие локальные адреса могут быть запрошены.

С NetPlan или Network Manager вы можете получить список восходящих DNS-серверов через systemd-resolved со следующей командой:

systemd-resolve --status

, которая даст вам кучу вывода. Соответствующий раздел будет выглядеть так (взятый из ответа chili555 для целесообразности):

DNS Servers: 8.8.8.8 8.8.4.4 2600:1700:5aa0:830::1
2
ответ дан 20 July 2018 в 14:39

Отказ от ответственности: это хорошо продуманная догадка, а не канонический документированный ответ.

Любое приложение, которое я пробовал, использует серверы имен /etc/resolv.conf.

В моей системе 18.04 незакомментированный, то есть фактически действующий раздел /etc/resolv.conf говорит:

nameserver 127.0.0.53

То есть, я считаю, симптом использования dnsmasq, системы, которая кэширует информацию DNS. Это означает, что, я считаю, сначала загляните в локальный кеш, прежде чем запрашивать внешние серверы имен.

Но локальный кеш не будет содержать информацию о сервере имен, которая никогда ранее не была посещена. В этом случае система использует объявленные внешние DNS-серверы имен. Они могут быть объявлены в / etc / network / interfaces в старых системах; в /etc/netplan/*.yaml в новых системах или почти во всех настольных установках в Network Manager.

Фактически, /etc/resolv.conf сообщает нам, как можно найти внешние серверы имен.

Любое приложение, которое я пробовал, использует /etc/resolv.conf nameserver.

Запустите «systemd-resolve -status», чтобы просмотреть сведения о DNS-серверах восходящей линии связи, которые в настоящее время используются.

DNS Servers: 8.8.8.8
             8.8.4.4
             2600:1700:5aa0:830::1

В моей системе отчет говорит, в частности:

2
ответ дан 22 May 2018 в 10:48
  • 1
    systemd-resolved, а не dnsmasq. systemd-resolved запускает «заглушку» DNS-преобразователя, который делает большую часть того, что dnsmasq делал в до 18.04 для разрешений DNS как «промежуточный» сервер, который затем передает запросы на восходящие DNS-серверы, определенные в сетевых конфигурациях или из DHCP. Помимо этого, остальная часть этой информации является более точной / точечной. (У меня есть несколько серверов 18.04 и выкопали это довольно сильно) – Thomas Ward♦ 11 May 2018 в 17:40

Отказ от ответственности: это хорошо продуманная догадка, а не канонический документированный ответ.

Любое приложение, которое я пробовал, использует серверы имен /etc/resolv.conf.

В моей системе 18.04 незакомментированный, то есть фактически действующий раздел /etc/resolv.conf говорит:

nameserver 127.0.0.53

То есть, я считаю, симптом использования dnsmasq, системы, которая кэширует информацию DNS. Это означает, что, я считаю, сначала загляните в локальный кеш, прежде чем запрашивать внешние серверы имен.

Но локальный кеш не будет содержать информацию о сервере имен, которая никогда ранее не была посещена. В этом случае система использует объявленные внешние DNS-серверы имен. Они могут быть объявлены в / etc / network / interfaces в старых системах; в /etc/netplan/*.yaml в новых системах или почти во всех настольных установках в Network Manager.

Фактически, /etc/resolv.conf сообщает нам, как можно найти внешние серверы имен.

Любое приложение, которое я пробовал, использует /etc/resolv.conf nameserver.

Запустите «systemd-resolve -status», чтобы просмотреть сведения о DNS-серверах восходящей линии связи, которые в настоящее время используются.

DNS Servers: 8.8.8.8 8.8.4.4 2600:1700:5aa0:830::1

В моей системе отчет говорит, в частности:

2
ответ дан 17 July 2018 в 14:35

Отказ от ответственности: это хорошо продуманная догадка, а не канонический документированный ответ.

Любое приложение, которое я пробовал, использует серверы имен /etc/resolv.conf.

В моей системе 18.04 незакомментированный, то есть фактически действующий раздел /etc/resolv.conf говорит:

nameserver 127.0.0.53

То есть, я считаю, симптом использования dnsmasq, системы, которая кэширует информацию DNS. Это означает, что, я считаю, сначала загляните в локальный кеш, прежде чем запрашивать внешние серверы имен.

Но локальный кеш не будет содержать информацию о сервере имен, которая никогда ранее не была посещена. В этом случае система использует объявленные внешние DNS-серверы имен. Они могут быть объявлены в / etc / network / interfaces в старых системах; в /etc/netplan/*.yaml в новых системах или почти во всех настольных установках в Network Manager.

Фактически, /etc/resolv.conf сообщает нам, как можно найти внешние серверы имен.

Любое приложение, которое я пробовал, использует /etc/resolv.conf nameserver.

Запустите «systemd-resolve -status», чтобы просмотреть сведения о DNS-серверах восходящей линии связи, которые в настоящее время используются.

DNS Servers: 8.8.8.8 8.8.4.4 2600:1700:5aa0:830::1

В моей системе отчет говорит, в частности:

2
ответ дан 20 July 2018 в 14:39
  • 1
    systemd-resolved, а не dnsmasq. systemd-resolved запускает «заглушку» DNS-преобразователя, который делает большую часть того, что dnsmasq делал в до 18.04 для разрешений DNS как «промежуточный» сервер, который затем передает запросы на восходящие DNS-серверы, определенные в сетевых конфигурациях или из DHCP. Помимо этого, остальная часть этой информации является более точной / точечной. (У меня есть несколько серверов 18.04 и выкопали это довольно сильно) – Thomas Ward♦ 11 May 2018 в 17:40

Другие вопросы по тегам:

Похожие вопросы: