Pelo menos há uma semana, meu Ubuntu 18.04 às vezes não tem acesso à internet. Apesar disso mostra na GUI o ícone do wifi normalmente.
Curiosamente, dig @8.8.8.8 google.comfunciona, mas ping google.comnão funciona. Os sites no navegador também não carregam.
(Pretendo atualizar esta questão com descrições mais detalhadas do que "não funciona" significa na próxima vez que vir as mensagens de erro.)
Quando isso acontece, geralmente a dhclient -r wlp0s20f3não resolverá o problema, mas sudo dhclient wlp0s20f3corrigirá temporariamente.
Às vezes isso dá certo RTNETLINK answers: File existse nesse caso parece que (às vezes?) Preciso usar a interface gráfica para desligar e ligar o wifi novamente. Parece que fazer o mesmo com ifdown/ ifupou sudo ifconfig wlp0s20f3 down/ upfaznãofunciona de forma confiável para isso, mas usar o gui funciona.
Como consertar isso e não precisar mais sair manualmente desse estado?
As tentativas abaixo listam o que tentei e algumas informações adicionais, possivelmente úteis. Acredito que a Observação 7 é a mais esclarecedora até agora, então role para baixo :)
Tentativa 1
eu encontreiem algum lugara sugestão de modificar /etc/network/interfacespara ficar assim:
# 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
mas isso não pareceu ajudar, então removi essas alterações novamente após a reinicialização.
Tentativa 2
Este problema parece comum1,2,3mas todas as respostas parecem não explicar muito.Esta respostasugere que pode estar relacionado /etc/resolv.confeesta respostafala sobre como verificar se existe uma rota padrão.
Na verdade, eu não tinha nenhuma rota padrão (uma vez) antes de reiniciar o wifi. Uma vez funcionou o seguinte:
# 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???
mas da próxima vez não aconteceu:
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
Observe que o final, funcionando, ip routemostra a rota que inicialmente não existia. Então, algo mudou de alguma forma.
Abordagem 3
O meu /etc/resolv.conftambém parece sombrio de vez em quando:
# 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
Mas eu tenho meu próprio resolvedor de DNS dnscrypt-proxyrodando em localhost. Então deveria ser algo como
nameserver 127.0.0.1
options edns0
Este é um problema que já tive em algum momento, de acordo com minhas anotações.Esta respostasugere adicionar dns=nonea /etc/NetworkManager/NetworkManager.conf, mas isso não funcionou naquela época, até seguir o comentário deChris Moorepara também executar sudo service network-manager restart.
No entanto, no momento atual, dns=noneestá definido como tal no meu 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
Posso tentar fazer isso sudo service network-manager restartmais uma vez, mas ficaria surpreso se realmente ajudasse.
Também vale ressaltar que my /etc/resolv.confé um link simbólico. De acordo comchapéu vermelhoisso também faria com que o NetworkManager não modificasse esse arquivo. Mas evidentemente aconteceu, porque eu acompanhei como havia definido o conteúdo daquele arquivo.
Não sei o que tentar a seguir e gostaria de entender o que aconteceu e por quê, além de como consertar.
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
Observação 3
Aconteceu de novo, então desliguei o wifi e liguei novamente. Ainda não funciona. Neste ponto executei os seguintes comandos:
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
Podemos perceber que tudo o que sudo dhclient wlp0s20f3mudou foi retirar o proto dhcp metric 600da defaultrota. Depois disso, a internet está funcionando.
NetworkManager ou systemd-networkd
Um comentário sugere que pode haver conflitos entre diferentes métodos de configuração. Acredito que estou usando o NetworkManager e acredito que esta saída apoia essa crença:
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
Observação 4
No momento tive o problema do gui achar que eu estava conectado, mas dig @8.8.8.8 google.comnem funcionou. Portanto, suspeito que tenho vários problemas ao mesmo tempo.
Não havia rota padrão naquele momento. Usei o gui para desligar e ligar o wifi novamente e agora a conexão funcionou novamente, com uma rota padrão presente:
# 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
Encontrei algumas respostas [5,6] mencionando /etc/NetworkManager/NetworkManager.confao pesquisar novamente o problema de uma rota padrão ausente. No meu laptop, ele contém arquivos managed=false. Parece que deveria ser trueassim, então mudei por enquanto. No entanto, essas respostas parecem inseguras se isso deveria ser managed=trueou 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
As respostas estão dizendo que isso requer um service network-manager restart, o que estou fazendo agora. Eu fiz um systemctl restart NetworkManagere, fascinantemente, minha rota padrão desapareceu, mas a conexão com a Internet ainda está funcionando. Uma linha vazia em minhas rotas desapareceu.
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
~~ Vou relatar como isso afetou o comportamento, se é que afetou. ~~ Isso não impediu que o problema da rota padrão ausente acontecesse. Esse problema é temporariamente corrigido desligando o wifi na interface gráfica e ligando-o novamente, mas não por sudo dhclient wlp0s20f3.
Como parecia não ter nenhum efeito observável, logo mudei de volta para managed=false.
Observação 5
Acho que minha suspeita está confirmada. Após essa mudança, agora eu tinha uma rota padrão no meu hotspot, mas ainda com alguns problemas.
- sites não carregam, domínios não resolvem com ping
- Telegrama funcionou
dig @8.8.8.8 google.comresolvendo corretamentedig google.comnão resolvendo
Portanto, teria que ser um problema com meu resolvedor de DNS local ou com algum outro problema de rede.
As rotas eram assim:
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
Para fazer meu DoH local funcionar temporariamente novamente, sudo dhclient -r wlp0s20f3fiz o truque mais uma vez.
Observação 6
systemctl status systemd-resolvedrevelou que estava carregado, desabilitado e ativo (em execução).
Deveria ser disabled, está correto. Porque estou usando dnscrypt-proxycomo um stub local e não preciso do systemd-resolved. Mas não deveria estar rodando... Não sei por que estava rodando, mas parei de novo agora.
Agora também excluí meu /etc/network/interfacesarquivo, poisesta respostaindica que eu não quero isso. Seria usado por, ifupdownmas estou usando o gerenciador de rede.
Observação 7
Seguindoesta resposta, configurei a auditoria para o arquivo para o qual meu /etc/resolv.conflink simbólico está apontando.
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
Logo depois, já vejo atividade nesse arquivo:
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
Aproximadamente a cada três minutos, algum processo sob meu nome de usuário ( generic) atua como root para mover um arquivo para /etc/resolv.conf.localdns. E a fonte é /etc/resolv.conf.localdns.dhclient-new.22822, o que indica que esse dhclienté o culpado.
Acho que poderia chattr +i /etc/resolv.conftorná-lo não editável, mas parece uma abordagem suja. Por enquanto, estou fazendo isso e parece evitar com sucesso que o formulário dhclient altere o arquivo, mas gostaria de entender o que deu errado e como evitar o mesmo problema no futuro, talvez até uma correção mais limpa.
Além disso, eu realmente não entendo por que a execução manual dhclientme ajudou. Acho que esse foi o problema da rota padrão ausente, que não aparece mais há algum tempo.
Responder1
Depois de tornar o /etc/resolv.confarquivo imutável usando chattr +i /etc/resolv.conf, dhclientparei de modificar meu arquivo porque não conseguiu, mas não parou de tentar. Isso ficou visível nos auditdlogs.
Porém, em algum momento hoje tentei consertar alguns outros problemas e também executei
- an
apt upgradeeapt autoremoveque também adicionou e removeu alguns cabeçalhos do kernel - uma reinicialização do Windows, onde usei o lenovo vantage para atualizar um grande número de drivers e o BIOS
Embora uma reinicialização normal não tenha ajudado em nada até agora, a combinação dessas coisas parece ter impedido a dhclienttentativa. Minhas regras de auditoria relatam apenas minhas tentativas manuais de alterar o arquivo agora, sem mais falhas por dhclient. A última falha dhclientaconteceu antes desses dois marcadores.
Portanto, parece que o problema provavelmente foi introduzido por uma atualização do kernel e corrigido por outra.
Editar 02 de maio de 2022: Isso não é mais verdade. Esta manhã, o problema não estava presente. Agora aconteceu de novo, sem nenhuma reinicialização no meio.
Minha solução inicial chattrpara tornar o arquivo imutável não estava mais presente (talvez eu o tenha removido novamente quando a auditoria mostrou que o dhclient parou de tentar) e meu link simbólico de /etc/resolv.confpara /etc/resolv.conf.localdnsdesapareceu. O arquivo continha valores errados para a rede atual (com base no ISP da rede em que eu estava antes). Corrigir manualmente o arquivo e definir a imutabilidade novamente corrigiu-o novamente... por enquanto.
Parece que o Cisco Anyconnect étambémintrometendo-se neste assunto! Depois de configurar os logs de auditoria conforme explicado na pergunta, agora vejo isso quando o uso para conectar:
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
Portanto, é possível que o Cisco Anyconnect às vezes renomeie o resolv.conf para /etc/resolv.conf.vpnbackupe, por algum motivo, não o corrija após perder a conexão... Minha "correção" atual significa chattrque não consigo me conectar à VPN. Parece que este é umproblema conhecido