По крайней мере с недели назад мой ubuntu 18.04 иногда не имеет доступа к интернету. Несмотря на это, в графическом интерфейсе отображается значок wifi, как обычно.
Интересно, dig @8.8.8.8 google.comработает, но ping google.comне работает. Сайты в браузере тоже не загружаются.
(Я собираюсь обновить этот вопрос более подробными описаниями того, что означает «не работает» в следующий раз, когда увижу сообщения об ошибках.)
Когда это происходит, обычно a dhclient -r wlp0s20f3не устраняет проблему, но a sudo dhclient wlp0s20f3устраняет ее временно.
Иногда это выводит RTNETLINK answers: File exists, и в этом случае кажется (иногда?) что мне нужно использовать gui, чтобы выключить и снова включить Wi-Fi. Кажется, что делать то же самое с ifdown/ ifupили sudo ifconfig wlp0s20f3 down/ upненетдля этого это работает надежно, но использование графического интерфейса — нет.
Как это исправить и больше не выходить из этого состояния вручную?
Ниже перечислены попытки, которые я пробовал, и дополнительная, возможно, полезная информация. Я считаю, что Наблюдение 7 является самым проницательным на данный момент, поэтому, пожалуйста, прокрутите вниз :)
Попытка 1
я нашелгде-топредложение изменить /etc/network/interfacesтак, чтобы оно выглядело так:
# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback
# adding this in th ehopes that it will help me avoiding
# that issue where i have to run
# `sudo dhclient wlp...` every time.
auto wlp0s20f3
iface wlp0s20f3 inet dhcp
auto enp0s31f6
iface enp0s31f6 inet dhcp
но это, похоже, не помогло, поэтому я снова удалил эти изменения после перезагрузки.
Попытка 2
Эта проблема кажется распространенной1,2,3но все ответы, похоже, не объясняют многого.Этот ответпредполагает, что это может быть связано с /etc/resolv.confиэтот ответговорит о проверке наличия маршрута по умолчанию.
Действительно, у меня не было маршрута по умолчанию (один раз) до перезагрузки Wi-Fi. Один раз сработало следующее:
# down interface and delete dhcp leases, then up it again
sudo ifdown wlp0s20f3 ; sudo ifconfig wlp0s20f3 down ; sudo rm /var/lib/dhcp/dhclient.* ; sudo ifup wlp0s20f3 ;
# view routes
ip route
# still broken
# try this:
sudo ifconfig wlp0s20f3 down
sudo ifconfig wlp0s20f3 up
ip route
# now it works???
но в следующий раз этого не произошло:
generic@motorbrot:~$ echo "bad:" && ip route
bad:
169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
generic@motorbrot:~$ echo "bad:" && ip route
bad:
169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
generic@motorbrot:~$ ping 1.1.1.1 -
ping: -: Name or service not known
generic@motorbrot:~$ ping 1.1.1.1
connect: Network is unreachable
generic@motorbrot:~$ dig @8.8.8.8 google.com
^Cgeneric@motorbrot:~echo "after down:" && ip route
after down:
169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
generic@motorbrot:~$ echo "after up:" && ip route
after up:
169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.0.0/24 dev wlp0s20f3 proto kernel scope link src 192.168.0.37
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
generic@motorbrot:~$ echo "after down-rm-up:" && ip route
after down-rm-up:
169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.0.0/24 dev wlp0s20f3 proto kernel scope link src 192.168.0.37
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
generic@motorbrot:~$ echo "after gui turnoff turnon:" && ip route
after gui turnoff turnon:
default via 192.168.0.1 dev wlp0s20f3 proto dhcp metric 600
169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.0.0/24 dev wlp0s20f3 proto kernel scope link src 192.168.0.37 metric 600
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
Обратите внимание, что финал, работающий, ip routeпоказывает маршрут, которого изначально не было. Значит, что-то как-то изменилось.
Подход 3
У меня /etc/resolv.confтоже время от времени что-то не так:
# this was the state of the /etc/resolv.conf
# file at the time when my network was currently working after a
# wifi-off-wifi-on action in the gui, but generally had issues
# after some time when I reconnected to a wifi...
domain v.cablecom.net
search v.cablecom.net
nameserver 62.2.17.61
nameserver 62.2.24.158
Но у меня есть свой DNS-резолвер, dnscrypt-proxyработающий на localhost. Так что это должно быть что-то вроде
nameserver 127.0.0.1
options edns0
Судя по моим записям, эта проблема уже возникала у меня в какой-то момент.Этот ответпредлагает добавить dns=noneв /etc/NetworkManager/NetworkManager.conf, но тогда это вообще не сработало, пока не последовал комментарий отКрис Муртакже запустить sudo service network-manager restart.
Однако на текущий момент dns=noneв моем NetworkManager.conf:
[main]
plugins=ifupdown,keyfile
# Added 30.07.2020 by LucidBrot to avoid /etc/resolv.conf being overwritten and hence breaking the DNS resolving.
dns=none
[ifupdown]
managed=false
[device]
wifi.scan-rand-mac-address=no
Я могу попробовать выполнить это sudo service network-manager restartеще раз, но я буду удивлен, если это действительно поможет.
Также стоит отметить, что my /etc/resolv.conf— это символическая ссылка. СогласноКрасная Шапкаэто также заставило бы NetworkManager не изменять этот файл. Но он, очевидно, изменил, потому что я отслеживал, что я установил в этом файле.
Я не знаю, что делать дальше, и мне хотелось бы понять, что произошло и почему, а также как это исправить.
generic@motorbrot:/etc$ ls -la | grep resolv
drwxr-xr-x 3 root root 3 Mai 7 2020 resolvconf
lrwxrwxrwx 1 root root 25 Mär 31 10:21 resolv.conf -> /etc/resolv.conf.localdns
-rw-r--r-- 1 root root 737 Jul 29 2020 resolv.conf.backup
-rw-r--r-- 1 root root 74 Jul 30 2020 resolv.conf.backup2
-rw-r--r-- 1 root root 364 Mär 31 10:17 resolv.conf.backup3
-rw-r--r-- 1 root root 89 Apr 5 00:06 resolv.conf.localdns
Наблюдение 3
Это произошло снова, поэтому я выключил и снова включил Wi-Fi. Все еще не работает. В этот момент я выполнил следующие команды:
generic@motorbrot:~$ ip route
default via 192.168.43.68 dev wlp0s20f3 proto dhcp metric 600
169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.43.0/24 dev wlp0s20f3 proto kernel scope link src 192.168.43.143 metric 600
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
generic@motorbrot:~$ sudo dhclient wlp0s20f3
[sudo] password for generic:
generic@motorbrot:~$ ip route
default via 192.168.43.68 dev wlp0s20f3
169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.43.0/24 dev wlp0s20f3 proto kernel scope link src 192.168.43.143
192.168.43.0/24 dev wlp0s20f3 proto kernel scope link src 192.168.43.143 metric 600
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
Мы видим, что все, что sudo dhclient wlp0s20f3изменилось, это удаление proto dhcp metric 600из defaultмаршрута. После этого интернет работает.
NetworkManager или systemd-networkd
Комментарий предполагает, что могут быть конфликты различных методов конфигурации. Я считаю, что использую NetworkManager, и я считаю, что этот вывод подтверждает это убеждение:
generic@motorbrot:~$ systemctl list-unit-files | grep networkd
networkd-dispatcher.service enabled
systemd-networkd-wait-online.service disabled
systemd-networkd.service disabled
systemd-networkd.socket disabled
generic@motorbrot:~$ systemctl list-unit-files | grep NetworkManager
NetworkManager-dispatcher.service enabled
NetworkManager-wait-online.service enabled
NetworkManager.service
Наблюдение 4
Сейчас у меня была проблема, что gui думал, что я подключен, но даже dig @8.8.8.8 google.comне работал. Так что я подозреваю, что у меня несколько проблем одновременно.
В то время не было маршрута по умолчанию. Я использовал графический интерфейс, чтобы выключить и снова включить Wi-Fi, и теперь соединение снова заработало, с присутствующим маршрутом по умолчанию:
# before restarting wifi:
generic@motorbrot:~$ ip route
169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
# after restarting wifi:
generic@motorbrot:~$ ip route
default via 192.168.0.1 dev wlp0s20f3 proto dhcp metric 600
169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.0.0/24 dev wlp0s20f3 proto kernel scope link src 192.168.0.37 metric 600
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
Я нашел некоторые ответы [5,6] упоминая /etc/NetworkManager/NetworkManager.confпри повторном поиске проблемы с отсутствующим маршрутом по умолчанию. На моем ноутбуке он содержит managed=false. Кажется, что это должно быть trueвместо этого, поэтому я изменил его на данный момент. Однако эти ответы, похоже, сами не уверены, должно ли это быть managed=trueили managed=false...
[main]
plugins=ifupdown,keyfile
# Added 30.07.2020 by LucidBrot to avoid /etc/resolv.conf being overwritten and hence breaking the DNS resolving.
dns=none
[ifupdown]
managed=true
[device]
wifi.scan-rand-mac-address=no
Ответы говорят, что требуется service network-manager restart, что я сейчас и делаю. Я сделал systemctl restart NetworkManagerи, что интересно, мой маршрут по умолчанию теперь пропал, но интернет-соединение все еще работает. Пустая строка в моих маршрутах исчезла.
generic@motorbrot:~$ systemctl status NetworkManager
● NetworkManager.service - Network Manager
Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled; vendor p
Active: active (running) since Tue 2022-04-05 00:12:28 CEST; 1 weeks 0 days a
Docs: man:NetworkManager(8)
Main PID: 16747 (NetworkManager)
Tasks: 4 (limit: 4915)
CGroup: /system.slice/NetworkManager.service
├─16747 /usr/sbin/NetworkManager --no-daemon
└─32449 /sbin/dhclient -d -q -sf /usr/lib/NetworkManager/nm-dhcp-help
generic@motorbrot:~$ ip route
default via 192.168.0.1 dev wlp0s20f3 proto dhcp metric 600
169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.0.0/24 dev wlp0s20f3 proto kernel scope link src 192.168.0.37 metric 600
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
generic@motorbrot:~$ systemctl restart NetworkManager
generic@motorbrot:~$ ip route
169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
~~Я сообщу, как это повлияло на поведение, если вообще повлияло.~~ Это не предотвратило возникновение проблемы с отсутствующим маршрутом по умолчанию. Эта проблема временно устраняется отключением Wi-Fi в графическом интерфейсе и его повторным включением, но не sudo dhclient wlp0s20f3.
Поскольку это, по-видимому, не дало заметного эффекта, я вскоре изменил его обратно на managed=false.
Наблюдение 5
Думаю, мои подозрения подтвердились. После этого изменения у меня теперь был маршрут по умолчанию на моей точке доступа, но все еще были некоторые проблемы.
- веб-сайты не загружаются, домены не разрешаются с помощью ping
- Телеграм работал
dig @8.8.8.8 google.comправильное решениеdig google.comне решается
Так что это должно быть проблема с моим локальным DNS-резолвером или какая-то другая проблема с сетью.
Маршруты выглядели так:
generic@motorbrot:~$ ip route
default via 192.168.43.143 dev wlp0s20f3 proto dhcp metric 600
169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.43.0/24 dev wlp0s20f3 proto kernel scope link src 192.168.43.144 metric 600
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
generic@motorbrot:~$ ping google.com
^C
generic@motorbrot:~$ dig google.com
; <<>> DiG 9.11.3-1ubuntu1.17-Ubuntu <<>> google.com
;; global options: +cmd
;; connection timed out; no servers could be reached
generic@motorbrot:~$ dig @8.8.8.8 google.com
; <<>> DiG 9.11.3-1ubuntu1.17-Ubuntu <<>> @8.8.8.8 google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17464
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 59 IN A 142.250.203.110
;; Query time: 44 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Apr 13 09:01:30 CEST 2022
;; MSG SIZE rcvd: 55
Чтобы временно возобновить работу местного DoH, sudo dhclient -r wlp0s20f3проделал этот трюк еще раз.
Наблюдение 6
systemctl status systemd-resolvedпоказало, что он загружен, отключен и активен (работает).
Он должен быть disabled, это правильно. Потому что я использую его dnscrypt-proxyкак локальную заглушку и не нуждаюсь в systemd-resolved. Но он не должен быть запущен... Я не знаю, почему он был запущен, но я остановил его снова сейчас.
Я теперь тоже удалил свой /etc/network/interfacesфайл, так какэтот ответуказывает, что я не хочу этого. Он будет использоваться, ifupdownно я использую network-manager.
Наблюдение 7
Следующийэтот ответЯ настроил аудит для файла, /etc/resolv.confна который указывает моя символическая ссылка.
sudo apt install auditd
sudo systemctl status auditd
# shows it is running and enabled
# Set up a rule to watch the file
# and use an arbitrary key for later grepping it:
sudo auditctl -w /etc/resolv.conf.localdns -p wa -k lb_dhclient_issue
# list rules
sudo auditctl -l
# to remove the watch, use the same command but with -W instead of -w and match each other field in the rule.
# i.e.
# sudo auditctl -W /etc/resolv.conf.localdns -p wa -k lb_dhclient_issue
Вскоре после этого я уже вижу активность по этому файлу:
sudo ausearch -f /etc/resolv.conf.localdns --format text
At 13:47:15 25.04.2022 generic, acting as root, successfully renamed /etc/resolv.conf.localdns.dhclient-new.13892 to /etc/resolv.conf.localdns using /bin/mv
At 13:49:39 25.04.2022 generic, acting as root, successfully renamed /etc/resolv.conf.localdns.dhclient-new.15462 to /etc/resolv.conf.localdns using /bin/mv
At 13:53:08 25.04.2022 generic, acting as root, successfully renamed /etc/resolv.conf.localdns.dhclient-new.17715 to /etc/resolv.conf.localdns using /bin/mv
At 13:56:52 25.04.2022 generic, acting as root, successfully renamed /etc/resolv.conf.localdns.dhclient-new.20232 to /etc/resolv.conf.localdns using /bin/mv
At 13:59:51 25.04.2022 generic, acting as root, successfully renamed /etc/resolv.conf.localdns.dhclient-new.22822 to /etc/resolv.conf.localdns using /bin/mv
Примерно каждые три минуты какой-то процесс под моим именем пользователя ( generic) действует как root, чтобы переместить файл в /etc/resolv.conf.localdns. А источником является /etc/resolv.conf.localdns.dhclient-new.22822, что указывает на то, что dhclientэто виновник.
Думаю chattr +i /etc/resolv.conf, я мог бы сделать его нередактируемым, но это кажется грязным подходом. Сейчас я так и делаю, и это, кажется, успешно предотвращает изменение файла dhclient, но я хотел бы понять, что пошло не так и как избежать той же проблемы в будущем, возможно, даже более чистое исправление.
Также я не совсем понимаю, почему dhclientмне помог ручной запуск. Думаю, проблема была в отсутствующем маршруте по умолчанию, который уже давно не появляется.
решение1
После того, как сделал /etc/resolv.confфайл неизменяемым с помощью chattr +i /etc/resolv.conf, dhclientперестал изменять мой файл, потому что он не смог этого сделать, но не прекратил попытки. Это было видно в auditdлогах.
Однако в какой-то момент сегодня я попытался исправить некоторые другие проблемы и также выполнил
- и
apt upgradeчтоapt autoremoveтакже добавлены и удалены некоторые заголовки ядра - перезагрузка в windows, где я использовал lenovo vantage для обновления большого количества драйверов и BIOS
Хотя обычная перезагрузка пока не помогла, сочетание этих вещей, похоже, остановило попытки dhclient. Мои правила аудита теперь сообщают только о моих ручных попытках изменить файл, больше никаких сбоев по dhclient. Последний сбой dhclientпроизошел до этих двух пунктов.
Похоже, проблема возникла из-за обновления ядра и была устранена в другом обновлении.
Редактировать 02. Май 2022: Это больше не так. Сегодня утром проблема не проявлялась. Сейчас она снова возникла, без какой-либо перезагрузки.
Мой первоначальный обходной путь с использованием , chattrчтобы сделать файл неизменяемым, больше не присутствовал (возможно, я удалил его снова, когда аудит показал, что dhclient прекратил попытки), и моя символическая ссылка с /etc/resolv.confна /etc/resolv.conf.localdnsисчезла. Файл содержал неверные значения для текущей сети (на основе ISP сети, в которой я был раньше). Ручное исправление файла и повторная настройка неизменяемости снова исправили это ... на данный момент.
Кажется, что Cisco Anyconnect — этотакжевмешиваться в это дело! После настройки журналов аудита, как описано в вопросе, я теперь вижу это, когда использую его для подключения:
At 18:19:09 02.05.2022 system, acting as root, unsuccessfully opened-file /etc/resolv.conf using /opt/cisco/anyconnect/bin/vpnagentd
At 18:19:09 02.05.2022 system, acting as root, unsuccessfully renamed /etc/resolv.conf.vpnbackup using /opt/cisco/anyconnect/bin/vpnagentd
At 18:19:09 02.05.2022 system, acting as root, unsuccessfully changed-file-ownership-of /etc/resolv.conf to root using /opt/cisco/anyconnect/bin/vpnagentd
At 18:19:09 02.05.2022 system, acting as root, unsuccessfully renamed /etc/resolv.conf.vpnbackup using /opt/cisco/anyconnect/bin/vpnagentd
At 18:19:10 02.05.2022 system, acting as root, unsuccessfully changed-file-ownership-of /etc/resolv.conf to root using /opt/cisco/anyconnect/bin/vpnagentd
At 18:19:10 02.05.2022 system, acting as root, unsuccessfully renamed /etc/resolv.conf.vpnbackup using /opt/cisco/anyconnect/bin/vpnagentd
At 18:19:10 02.05.2022 system, acting as root, unsuccessfully changed-file-ownership-of /etc/resolv.conf to root using /opt/cisco/anyconnect/bin/vpnagentd
Так что возможно, что Cisco Anyconnect иногда переименовывает resolv.conf в /etc/resolv.conf.vpnbackupи затем по какой-то причине не исправляет его после потери соединения... Мое текущее "исправление" означает, chattrчто я не могу подключиться к VPN. Кажется, этоизвестная проблема