свяжитесь локальный (fe80::), адреса без объема превращают свой путь в/etc/resolv.conf и вызывают проблемы

Я отвечаю на свой собственный вопрос и даю объяснение и патч для ссылки.

Проблема находится в dhcp6c сценариях, которым предоставляют пакет wide-dhcpv6-client. dhcp6c выполнения как демон в моей системе (запущенный /etc/init.d/wide-dhcpv6-client) и отсылает запросы DHCPv6 каждые несколько минут. Я не думаю wide-dhcpv6-client установлен по умолчанию в рабочем столе человечности. Его конфигурация (/etc/wide-dhcpv6/dhcp6c.conf) набор должен вызвать сценарий /etc/wide-dhcpv6/dhcp6c-script когда обновление должно быть сделано. Этот сценарий является багги:

1. Это игнорирует объем в случае локальных для ссылки адресов

2. В случаях, где /etc/resolv.conf не управляется resolvconf (т.е. не символьная ссылка), он приводит к search X строки, добавляемые, не проверяя, присутствуют ли строки уже (затем файл когда-либо растет).

Принятие Вас имеет единственный интерфейс, контролируемый dhcp6c **, исправляя файл /etc/wide-dhcpv6/dhcp6c-script с патчем ниже решит проблему:

--- /etc/wide-dhcpv6/dhcp6c-script.orig 2016-09-04 17:12:35.405042056 -0700
+++ /etc/wide-dhcpv6/dhcp6c-script.new  2016-09-04 22:57:05.213169351 -0700
@@ -6,20 +6,48 @@

 [ -f /etc/default/wide-dhcpv6-client ] && . /etc/default/wide-dhcpv6-client

+# Guess interface to use as scope_id. Ideally, dhcp6c would pass the
+# name of the interface on which the DHCPv6 reply was received.
+scope=""
+for IFACE in $INTERFACES; do
+    scope="$IFACE"
+    break;
+done
+
+# exact line match. grep would interpret domain periods as special
+# chars.  The naive loop avoids relying on other non-coreutils
+# commands (sed, awk, etc.).
+has_line () {
+    local line
+    while read line; do
+    if [ "$line" = "$1" ]; then
+       return 0
+    fi
+    done
+    return 1
+}
+    
+
 if [ -n "$new_domain_name" -o -n "$new_domain_name_servers" ]; then
     old_resolv_conf=/etc/resolv.conf
     new_resolv_conf=/etc/resolv.conf.dhcp6c-new
     rm -f $new_resolv_conf
     if [ -n "$new_domain_name" ]; then
-        echo search $new_domain_name >> $new_resolv_conf
+   has_line "search $new_domain_name" < $old_resolv_conf || {
+       echo "search $new_domain_name" >> $new_resolv_conf
+   }
     fi
     if [ -n "$new_domain_name_servers" ]; then
         for nameserver in $new_domain_name_servers; do
+       if [ -n "$scope" -a "${nameserver##fe80::}" != "$nameserver" ]; then
+          nameserver="$nameserver%$scope"
+       fi
+
             # No need to add an already existing nameserver
-            res=$(grep "nameserver $nameserver" $old_resolv_conf)
-            if [ -z "$res" ]; then
-                echo nameserver $nameserver >> $new_resolv_conf
-            fi
+       has_line "nameserver $nameserver" < $old_resolv_conf || {
+                echo "nameserver $nameserver" >> $new_resolv_conf
+       }
         done
     fi

** Код выше выберет первый интерфейс из списка интерфейсов в /etc/default/wide-dhcpv6-client, и снабдите суффиксом его к любому серверу имен, запускающемуся с fe80::. Это подобно тому, в чем выполняют /etc/dhcp/dhclient-enter-hooks.d/resolvconf. Это не идеально, особенно если у Вас есть несколько интерфейсов. dhcp6c не передает название интерфейса в среде, таким образом, мы можем только предположить. (ошибка зарегистрировала: https://bugs.launchpad.net/ubuntu / + source/wide-dhcpv6 / + ошибка/1620221)

Если Вы имеете несколько зарубок и нуждаетесь в этом, чтобы быть более устойчивыми, можно вместо этого настроить /etc/wide-dhcpv6/dhcp6c.conf запустить другую копию сценария в зависимости от имени интерфейса и hardcode название интерфейса в сценарии.

Прежде чем я выяснил проблему, я обнаружил два обходных решения, которые не решают вопрос, но избегают признаков.

Обходное решение 1: отключите dnsmasq локальный сопоставитель.

Записи в resolv.conf заполняются правильно, когда dnsmasq сервис NetworkManager отключен. Таким образом, я теряю его льготы. Не прекрасный.

Выполненные шаги в том, Как я могу отключить DNS тот Администратор сети использование?. Кроме того, см. список безопасности и последствия производительности отключения локального сопоставителя.

После перезапуска NM ссылка локальному адресу добавили объем, правильно:

# 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 192.168.1.1
nameserver fe80::beef%eth0
search lan

Я не абсолютно уверен, почему это работает, но я подозреваю, что это - потому что и NetworkManager и dhcp6c пишут в resolvconv, и сценарий обновления способствует fe80:: beef%eth0 (переданный NetworkManager) по сравнению с тем же адресом без объема (переданный dhcp6c).

Обходное решение 2: Настройте OpenWrt для рекламы дополнительного dhcpv6 сервера как части RDNSS. Этот сервер будет иметь приоритет по ссылке локальная в/etc/resolv.conf. Я чувствую, что это - немного лучшее решение, чем обходное решение № 1, потому что это сохраняет локальный сопоставитель (по крайней мере, для ipv4), но это более сложно.

1. Установите OpenWrt с ULA-префиксом IPv6, скажите fd00:cafe::/48. (Menu -> Network -> Interfaces -> bottom of page). Маршрутизатор получит локальный ipv6 fd00::cafe::1 на LAN. (Я попробовал это на более спокойном хаосе OpenWRT 15.05.1).

2. Сообщите odhcpd (который предоставляет dhcpv6 услугу на той версии openwrt) также рекламировать IP как (дополнительный) сервер DNS. odhcpd (версия 2015-11-19-01d3f...) предлагает флаг конфигурации, названный dhcp.lan.dns (описание флага). В luci UI это находится под Menu -> Network -> Interfaces -> LAN (click edit) -> DHCP Server section -> IPv6 Settings tab -> Announced DNS Servers. Добавьте, что ULA маршрутизатора адресуют к полю. Я также добавил ipv4 адрес подсети маршрутизатора к списку серверов DNS (192.168.1.1) ради симметрии.

С этим на месте, odhcpd будет рекламировать оба адреса как часть РА, но NM, в наших интересах, только пишет, что ULA адресуют к resolv.conf. Локальный для ссылки адрес никогда не добавляется к 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 fd00:cafe::1
nameserver 127.0.1.1
search lan

Смотря на трассировки wireshark при конфигурировании этот путь сообщение РА от openwrt перечислит оба адреса сервера DNS, но его DHCPv6 отвечает, только имеют fd00:cafe::1 один, таким образом, ошибки в dhcp6c сценариях избегают.

Если у Вас есть хост Unix в сети не выполнение локального сопоставителя (например, если бы Вы применили обходное решение 1 и 2 на человечности), то 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 192.168.1.1
nameserver fd00:cafe::1
nameserver fe80::beef%eth0
search lan

Алгоритм по умолчанию в сопоставителе libc должен попробовать каждую запись от resolv.conf в свою очередь, испытав таймаут на каждом. Также - несколько псевдонимов к тому же серверу DNS могли вызвать дополнительные задержки, когда/если проблемы возникают. В моем случае то наиболее вероятное означает мой целый маршрутизатор вниз, не только его сервер DNS, таким образом, это - надуманный вопрос. но Ваш пробег может варьироваться.

дополнительный я использовал следующий сценарий для отладки изменений, внесенных в resolvconf. Это позволило мне выяснять, какой демон отправлял неправильные изменения:

#!/bin/bash

# logs all interactions to /sbin/resolvconf into syslog
# this script is named /sbin/resolvconf, temporarily.
# moved resolvconv binary to resolvconf.real, temporarily.

BIN=/sbin/resolvconf.real
LOGGER=/usr/bin/logger

ppid () { ps -p ${1:-$$} -o ppid= 2>/dev/null | sed 's/ //g'; }

PROC=$$

"$LOGGER" "resolvconf.wrapper args: $@"

for ((i=0; i<4; i++)); do
    PROC=$(ppid $PROC)
    if [[ "$PROC" == 0 || "$PROC" == "" ]]; then
    break;
    fi
    if [[ "$i" -eq 0 ]]; then
    "$LOGGER" "resolvconf.wrapper invoked by: pid=$PROC $(/bin/ps -p $PROC -o command=)"
    else
    "$LOGGER" "resolvconf.wrapper child of: pid=$PROC $(/bin/ps -p $PROC -o command=)"
    fi
done

# peek at stdin (which contains the config)
if [[ "$1" == "-a" ]] && [[ -n "$2" ]]; then
    tmp=$(/bin/mktemp)
    while read REST; do
    logger "resolvconf.wrapper feeding: $REST"
    echo $REST >> "$tmp"
    done
    exec < "$tmp"
    rm "$tmp"
fi

exec -a /sbin/resolvconf "$BIN" "$@"

С этим на месте, системный журнал содержит блоки как так:

Sep  3 02:32:29 calm logger: resolvconf.wrapper invoked by: pid=12610 sh -c /sbin/resolvconf -a NetworkManager
Sep  3 02:32:29 calm logger: resolvconf.wrapper child of: pid=11910 NetworkManager
Sep  3 02:32:29 calm logger: resolvconf.wrapper child of: pid=1 /sbin/init
Sep  3 02:32:29 calm logger: resolvconf.wrapper feeding: # Generated by NetworkManager
Sep  3 02:32:29 calm logger: resolvconf.wrapper feeding: domain base
Sep  3 02:32:29 calm logger: resolvconf.wrapper feeding: search base base.
Sep  3 02:32:29 calm logger: resolvconf.wrapper feeding: nameserver 127.0.1.1
...
Sep  3 02:14:23 calm logger: resolvconf.wrapper gparent: pid=1553 /usr/sbin/dhcp6c -Pdefault eth0
Sep  3 02:14:23 calm logger: resolvconf.wrapper invoked by: pid=15926 /bin/sh /etc/wide-dhcpv6/dhcp6c-script
Sep  3 02:14:23 calm logger: resolvconf.wrapper args: -a eth0
Sep  3 02:14:23 calm logger: resolvconf.wrapper feeding: search base.
Sep  3 02:14:23 calm logger: resolvconf.wrapper feeding: nameserver fd00:cafe::1