至少從一週前開始，我的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
但這似乎沒有幫助，所以我在重新啟動後再次刪除了這些變更。
嘗試2
這個問題似乎很常見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 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
現在我遇到的問題是圖形使用者介面認為我已連接，但甚至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
答案是需要 a 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 進行解析
- 電報有效
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
為了讓我當地的衛生部暫時恢復工作，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 月 02 日編輯：這不再是事實。今天早上，這個問題不存在。現在又發生了，中間沒有任何重啟。
我最初使用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。看來這是一個已知問題