적어도 일주일 전부터 내 우분투 18.04는 때때로 인터넷에 접속할 수 없습니다. 그럼에도 불구하고 GUI에는 정상적으로 Wi-Fi 아이콘이 표시됩니다.
흥미롭게도 dig @8.8.8.8 google.com작동하지만 작동 ping google.com하지 않습니다. 브라우저의 웹사이트도 로드되지 않습니다.
(다음에 오류 메시지가 표시되면 "작동하지 않음"이 무엇을 의미하는지에 대한 자세한 설명으로 이 질문을 업데이트할 예정입니다.)
이런 일이 발생하면 대개는 dhclient -r wlp0s20f3수정되지 않지만 sudo dhclient wlp0s20f3임시로 수정됩니다.
때로는 출력이 나오고 RTNETLINK answers: File exists그 경우 (때때로?) Wi-Fi를 껐다가 다시 켜려면 GUI를 사용해야 하는 것처럼 보입니다. ifdown/ ifup또는 sudo ifconfig wlp0s20f3 down/ 와 동일한 작업을 수행 up하는 것 같습니다.~ 아니다안정적으로 작동하지만 GUI를 사용하면 됩니다.
이 문제를 해결하고 더 이상 이 상태에서 수동으로 벗어날 필요가 없도록 하려면 어떻게 해야 합니까?
아래의 시도에는 제가 시도한 것과 유용한 추가 정보가 나열되어 있습니다. 저는 Observation 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,삼하지만 모든 답변이 많이 설명되지 않는 것 같습니다.이 답변/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
dnscrypt-proxy하지만 나는 localhost에서 실행되는 자체 DNS 확인자를 가지고 있습니다 . 그래서 실제로는 다음과 같아야 합니다.
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.confmy 가 심볼릭 링크 라는 점도 지적할 가치가 있습니다 . 에 따르면빨간 모자이로 인해 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
그런 일이 또 생겨서 와이파이를 껐다가 다시 켰어요. 그래도 작동이 안되는. 이 시점에서 다음 명령을 실행했습니다.
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=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에서 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저는 네트워크 관리자를 사용하고 있습니다.
관찰 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두 개의 중요 항목 이전에 발생했습니다.
따라서 이 문제는 커널 업그레이드로 인해 발생하고 다른 업그레이드로 해결된 것 같습니다.
02. 2022년 5월 수정: 이는 더 이상 사실이 아닙니다. 오늘 아침에는 문제가 발생하지 않았습니다. 지금은 재부팅하지 않고 다시 발생했습니다.
파일을 불변으로 만드는 데 사용한 초기 해결 방법 chattr은 더 이상 존재하지 않으며(감사 결과 dhclient가 시도를 중지한 것으로 나타나면 다시 제거했을 수도 있음) /etc/resolv.confto to 의 심볼릭 링크 /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다음 어떤 이유로 연결이 끊어진 후 수정하지 않을 수도 있습니다. 현재 "수정"은 chattrVPN에 연결할 수 없다는 의미입니다. 이것은 것 같습니다알려진 문제