至少从一周前开始，我的 ubuntu 18.04 有时无法访问互联网。尽管它在 GUI 中正常显示 wifi 图标。
有趣的是，dig @8.8.8.8 google.com它能工作，但ping google.com不能。浏览器中的网站也无法加载。
（下次看到错误消息时，我打算更新这个问题，提供更详细的描述，说明“不能工作”的含义。）
当这种情况发生时，通常adhclient -r wlp0s20f3不会去修复它，但是asudo dhclient wlp0s20f3会暂时修复它。
有时会出现输出RTNETLINK answers: File exists，在这种情况下，似乎（有时？）我需要使用 GUI 关闭并重新打开 wifi。似乎使用ifdown/ifup或sudo ifconfig wlp0s20f3 down/执行相同up操作不是可以可靠地完成此工作，但是使用 GUI 却可以。
如何解决这个问题并且不再需要手动退出这种状态？
下面的尝试列出了我尝试过的方法以及一些额外的、可能有用的信息。我认为观察 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
但这似乎没有帮助，所以我重新启动后再次删除了这些更改。
第二次尝试
这个问题似乎很常见1，2，3但所有的答案似乎都没有解释太多。这个答案表明它可能与/etc/resolv.conf和这个答案讨论检查是否存在默认路由。
确实，在重启 wifi 之前，我没有默认路由（有一次）。有一次，以下方法奏效了：
# 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在本地主机上运行。所以它实际上应该是这样的
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
又发生了这种情况，所以我关闭了 wifi 然后再打开。仍然不起作用。此时我运行了以下命令：
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 600default
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不起作用。所以我怀疑我同时遇到了多个问题。
当时没有默认路由。我使用 GUI 关闭并重新打开 wifi，现在连接又可以正常工作了，并且有默认路由：
# 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
~~我会报告这对行为有何影响（如果有的话）。~~但这并不能阻止默认路由缺失问题的发生。该问题可以通过在 GUI 中关闭 wifi 并再次打开来暂时解决，但不能通过 来解决sudo dhclient wlp0s20f3。
由于似乎没有明显的效果，我很快将其改回managed=false。
观察5
我想我的怀疑得到了证实。经过这次更改后，我的热点上现在有了默认路由，但仍然存在一些问题。
- 网站无法加载，无法通过 ping 解析域名
- Telegram 已运行
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但我正在使用网络管理器。
观察 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发生在这两个要点之前。
因此，该问题似乎是由内核升级引起的，并由另一次内核升级修复。
编辑 2022 年 5 月 2 日：现在情况已经不再如此。今天早上，这个问题没有出现。现在又出现了，中间没有重启。
我最初用来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。这似乎是一个已知问题