少なくとも 1 週間前から、私の Ubuntu 18.04 は時々インターネットにアクセスできなくなります。GUI には Wi-Fi アイコンが通常どおり表示されますが。
興味深いことに、dig @8.8.8.8 google.com動作しますが、ping google.com動作しません。ブラウザの Web サイトも読み込まれません。
(次回エラー メッセージが表示されたときに、「動作しない」の意味をより詳しく説明してこの質問を更新するつもりです。)
このような場合、通常は ではdhclient -r wlp0s20f3修正されませんが、 ではsudo 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、この答えデフォルトルートがあるかどうかを確認する方法について説明します。
実際、Wi-Fi を再起動する前はデフォルト ルートがありませんでした (1 回)。1 回は次のように動作しました。
# 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
最後の「working」には、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が、実際に効果があるかどうかはわかりません。
/etc/resolv.confまた、myはシンボリックリンクであることも指摘しておく価値がある。レッドハットこれによって、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 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 を使用して 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=truemanaged=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 で 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-proxysystemd-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
およそ 3 分ごとに、ユーザー名 ( ) のプロセスがgenericルートとして動作し、ファイルを に移動します/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これら 2 つの箇条書きの前に発生しました。
したがって、この問題はカーネルのアップグレードによって導入され、別のアップグレードによって修正された可能性が高いようです。
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に接続できません。これは既知の問題