16.10 nie można rozwiązać DNS

Po uaktualnieniu mojej instalacji 16.04 do 16.10 mam problemy z DNS.

Najpierw kilka razy miałem problemy po podłączeniu do Wi-Fi, podczas gdy działało ono na eterze. Teraz wydaje się, że działa również na Wi-Fi. Nie jestem pewien, dlaczego i jeśli jest to w jakikolwiek sposób związane z problemem, z którym się teraz spotykam:

Podczas łączenia się z hostem VPN Cisco Anyconnect VPN , to dodaje się wiersz w „/etc/resolv.conf” . Rozumiem, że Ubuntu używa teraz systemd-resolver , a strona man mówi, że istnieją trzy różne tryby obsługi /etc/resolv.conf. Mój plik /etc/resolv.conf nie jest dowiązaniem symbolicznym i nie zawiera 127.0.0.53 jako serwera DNS, o ile rozumiem systemd-rozwiązany powinien „odczytać go dla danych konfiguracyjnych DNS”. Wydaje się jednak, że to nie obchodzi.

kopać

Dziwne (dla mnie) jest to dig host.customer.tld, że zwraca miłą odpowiedź z SEKCJĄ ODPOWIEDZI pokazującą adres IP żądanego hosta i odnosi się do serwera dns dodanego do /etc/resolv.conf przez klienta VPN jako SERWERA. Gdy połączenie VPN jest wyłączone, nie otrzymuję odpowiedzi. Czyli dig czyta /etc/resolv.conf .

świst

Z drugiej strony przeglądarka nie uzyskuje dostępu do /etc/resolv.conf i nie jest w stanie rozpoznać nazwy hosta. Nawiasem mówiąc, nie jest też ping / curl.

nmcli

Znalazłem powiązany post i próbowałem uruchomić

nmcli device show <interfacename> | grep IP4.DNS

ale nie wyświetla żadnych dns dla urządzenia cscotun0. (Jednak nie ma go również w 16.04.) Ponadto nmcli wymienia mój serwer dhcp (mój router) jako host IP4.DNS dla moich połączeń eth / wlan. Za pomocądig @192.168.0.1 xxx z dowolnej domeny publicznej działa dobrze.

konfiguracja

Istnieje kilka innych serwerów DNS wymienionych w moim /run/systemd/resolve/resolv.conf:

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

Nie są one obsługiwane przez mój serwer DHCP. plik /etc/systemd/resolved.conf zawiera tylko wiersze z komentarzem, z wyjątkiem nagłówka sekcji:

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

Tak mówi strona man dla resolved.conf

DNS = Rozdzielona spacjami lista adresów IPv4 i IPv6 do wykorzystania jako systemowe serwery DNS. ... Ze względu na kompatybilność, jeśli to ustawienie nie jest określone, zamiast tego używane są serwery DNS wymienione w /etc/resolv.conf, jeśli plik ten istnieje i skonfigurowano w nim jakiekolwiek serwery. Domyślne ustawienie to pusta lista.

FallbackDNS = Rozdzielona spacjami lista adresów IPv4 i IPv6 do wykorzystania jako rezerwowe serwery DNS. Wszystkie serwery DNS na łącze otrzymane z systemd-networkd.service (8) mają pierwszeństwo przed tym ustawieniem, podobnie jak wszystkie serwery ustawione przez DNS = powyżej lub /etc/resolv.conf. To ustawienie jest zatem używane tylko wtedy, gdy nie są znane żadne inne informacje o serwerze DNS. Jeśli ta opcja nie zostanie podana, zamiast niej zostanie użyta skompilowana lista serwerów DNS.

Wygląda na to, że awaria kończy się w /run/systemd/resolve/resolv.conf w moim przypadku.

EDYCJA: Nie byłem pewien, na czym polega problem, i szczerze mówiąc nadal nie wiem dokładnie, jak to działa, ale przynajmniej okazało się, że rozwiązaniem w moim przypadku było wyłączenie systemd-resolvedusługi. Myślałem, że ta usługa jest wymagana, że ​​to składnik zapewnił usługę DNS wszystkim lokalnym aplikacjom, ale najwyraźniej jest tam coś jeszcze, co wykonuje tę pracę.

Wystąpiły podobne problemy, na przykład dodanie dodatkowego klucza WiFi USB. Najpierw wyłączyłem dnsmasq w menedżerze sieci jak opisano powyżej i zatrzymałem dnsmasq (usługa dnsmasq stop)

Zauważyłem, że podczas rozwiązywania problemu podczas połączenia VPN, tabela routingu wygląda nieco inaczej (wyjście polecenia route). Nazwa bramki to DD-WRT w przypadku, gdy nie działa i po prostu „brama”, gdy działa. Wynik tego nie zmienił się:

nmcli device show wlp1s0 | grep IP4.DNS

Ciągle pokazywał adres IP mojego routera. Obejściem tego problemu jest ponowne uruchomienie systemd-resolvd:

sudo service systemd-resolved restart

Ponieważ dnsmasq jest poza równaniem, przyczyną problemu jest systemd-resolvd lub cokolwiek zmieniającego tablicę routingu.

To jedyna różnica, jaką widzę:

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 

który działa. A gdy to NIE działa:

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

I ta sama różnica nazw w linii VPN:

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

Kto wie, co może wpłynąć na tablicę routingu? Byłoby wspaniale, gdybyśmy mogli to zidentyfikować, aby umożliwić zgłoszenie błędu. Mam już dość znużenia się tymi wszystkimi błędami, ale chciałbym je naprawić, aby przyszli użytkownicy i my będziemy szczęśliwi :).

[aktualizacja] Wydaje się, że zatrzymanie rozwiązania systemd może rozwiązać ten problem i nie wpływać negatywnie na inne rzeczy. Możesz spróbować i dać znać, jeśli coś psuje. Widziałem, gdy uruchomiłem systemd-resolvd podczas debugowania, gdy się zepsuł:

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 *

Wyłączyć:

sudo systemctl disable systemd-resolved.service

Zaktualizowałem raport Ubuntu o sugestie. [/ update] Dodaj: Uwaga: raport błędów: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1624317 zawiera łatkę na 17.04 dotyczącą niektórych problemów. Sprawdź raport o błędzie i jeśli to możliwe przetestuj łatkę. Dziękuję Ci!

[aktualizacja]

Sprawdź wyżej wspomniany raport o błędzie, problem wydaje się rozwiązany w wersji 17.10 i za pomocą prostej komendy można również wyłączyć wyciek DNS.

[/aktualizacja]

Zachowanie DNS podczas połączenia OpenVPN poprawiło się natychmiast, gdy zastosowałem się do sugestii dotyczącej ubuntuforums:

1. Otwórz /etc/NetworkManager/NetworkManager.confw edytorze z prawami root.
2. Usuń (lub skomentuj za pomocą skrótu #) wiersz, który czytadns=dnsmasq
3. Uruchom ponownie NetworkManager przez sudo service NetworkManager restart

Wpadłem na ten sam problem. Jakoś musiałem zainstalować DNSmasq z jakąś aplikacją. Usunięcie dnsmasq rozwiązało problem dla mnie.

sudo apt-get remove dnsmasq 

Od tego czasu nie ma już rozłączeń lub niektóre strony nie mogą już się ładować (miałem problem z ładowaniem Gmaila, tzn. Nagle nie mógł się połączyć z Gmailem, chociaż inne strony działały).

Edytuj /etc/nsswitch.confi zmień

hosts:          files mdns4_minimal [NOTFOUND=return] dns

do

hosts:          files dns mdns4_minimal [NOTFOUND=return]

Edytować:

Od dłuższego czasu mam te same problemy. Byłem w stanie rozwiązać nazwy domen z VPN, ale nie byłem w stanie pingować lub zwinąć ich ani używać ich w innych aplikacjach. Opisana powyżej zmiana rozwiązała to dla mnie.