Al menos desde hace una semana mi ubuntu 18.04 a veces no tiene acceso a internet. A pesar de eso, muestra en la GUI el ícono de wifi como de costumbre.
Curiosamente, dig @8.8.8.8 google.comfunciona, pero ping google.comno. Los sitios web en el navegador tampoco se cargan.
(Tengo la intención de actualizar esta pregunta con descripciones más detalladas de lo que significa "no funciona" la próxima vez que vea los mensajes de error).
Cuando esto sucede, generalmente un dhclient -r wlp0s20f3no lo solucionará, pero sudo dhclient wlp0s20f3lo solucionará temporalmente.
A veces eso sale RTNETLINK answers: File existsy en ese caso parece que (¿a veces?) Necesito usar la interfaz gráfica de usuario para apagar y encender el wifi. Parece que hacer lo mismo con ifdown/ ifupo sudo ifconfig wlp0s20f3 down/ uphacenofunciona de manera confiable para eso, pero usar la interfaz gráfica de usuario sí.
¿Cómo solucionar esto y ya no tener que salir manualmente de este estado?
Los intentos a continuación enumeran lo que he probado y alguna información adicional, posiblemente útil. Creo que la Observación 7 es la más reveladora hasta el momento, así que desplácese hacia abajo :)
Intento 1
encontréen algún lugarla sugerencia de modificar /etc/network/interfacespara que se vea así:
# 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
pero eso no pareció ayudar, así que eliminé esos cambios nuevamente después de reiniciar.
Intento 2
Este problema parece común1,2,3pero todas las respuestas parecen no explicar mucho.esta respuestasugiere que podría estar relacionado con /etc/resolv.confyesta respuestahabla de comprobar si existe una ruta predeterminada.
De hecho, no tenía una ruta predeterminada (una vez) antes de reiniciar el wifi. Una vez funcionó lo siguiente:
# 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???
pero la próxima vez no fue así:
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 el final, en funcionamiento, ip routemuestra la ruta que inicialmente no estaba allí. Entonces algo cambió de alguna manera.
Enfoque 3
Mi /etc/resolv.conftambién se ve turbio de vez en cuando:
# 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
Pero tengo mi propio solucionador de DNS que dnscrypt-proxyse ejecuta en localhost. Así que en realidad debería ser algo como
nameserver 127.0.0.1
options edns0
Este es un problema que he tenido antes en algún momento, según mis notas.esta respuestasugiere agregar dns=nonea /etc/NetworkManager/NetworkManager.conf, pero eso no funcionó en absoluto en ese entonces, hasta que siguió el comentario deChris Moorepara correr también sudo service network-manager restart.
Sin embargo, en este momento, dns=noneestá configurado como tal en mi 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
Puedo intentar realizarlo sudo service network-manager restartuna vez más, pero me sorprendería si realmente ayudara.
También vale la pena señalar que mi /etc/resolv.confes un enlace simbólico. De acuerdo asombrero rojoesto también haría que NetworkManager no modifique ese archivo. Pero evidentemente así fue, porque mantuve un registro de cómo había configurado el contenido de ese archivo.
No sé qué intentar a continuación y me gustaría entender qué sucedió y por qué, además de cómo solucionarlo.
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
Observación 3
Sucedió de nuevo, así que apagué y encendí el wifi. Sigue sin funcionar. En este punto ejecuté los siguientes 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 ver que todo lo que sudo dhclient wlp0s20f3cambió fue eliminarlo proto dhcp metric 600de la defaultruta. Después de eso, Internet funciona.
NetworkManager o systemd-networkd
Un comentario sugiere que puede haber diferentes métodos de configuración en conflicto. Creo que estoy usando NetworkManager y creo que este resultado respalda esa creencia:
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
Observación 4
En este momento tuve el problema de que la interfaz gráfica de usuario pensaba que estaba conectado, pero ni siquiera dig @8.8.8.8 google.comfuncionó. Entonces sospecho que tengo varios problemas a la vez.
En ese momento no existía una ruta predeterminada. Utilicé la interfaz gráfica de usuario para apagar y encender wifi nuevamente y ahora la conexión funcionó nuevamente, con una ruta predeterminada 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
Encontré algunas respuestas [5,6] mencionando /etc/NetworkManager/NetworkManager.confal buscar nuevamente el problema de que falta una ruta predeterminada. En mi computadora portátil, contiene managed=false. Parece que esto debería ser trueasí, así que lo cambié por ahora. Sin embargo, estas respuestas parecen inseguras de si esto debería ser así managed=trueo 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
Las respuestas dicen que requiere a service network-manager restart, lo cual estoy haciendo ahora. Hice una systemctl restart NetworkManagery, sorprendentemente, mi ruta predeterminada ya no está, pero la conexión a Internet sigue funcionando. Una línea vacía en mis rutas desapareció.
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
~~ Informaré cómo afectó eso al comportamiento, si es que lo afectó. ~~ Sin embargo, esto no impidió que ocurriera el problema de la ruta predeterminada faltante. Ese problema se soluciona temporalmente apagando el wifi en la interfaz gráfica de usuario y encendiéndolo nuevamente, pero no mediante sudo dhclient wlp0s20f3.
Como parecía no tener ningún efecto observable, pronto volví a cambiar esto a managed=false.
Observación 5
Creo que mi sospecha se confirma. Después de este cambio, ahora tenía una ruta predeterminada en mi punto de acceso, pero todavía había algunos problemas.
- Los sitios web no se cargan, los dominios no se resuelven con ping.
- Telegrama funcionó
dig @8.8.8.8 google.comresolviendo correctamentedig google.comno resolviendo
Por lo tanto, tendría que ser un problema con mi solucionador de DNS local o algún otro problema de red.
Las rutas quedaron de esta manera:
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 que mi DoH local volviera a funcionar temporalmente, sudo dhclient -r wlp0s20f3hice el truco una vez más.
Observación 6
systemctl status systemd-resolvedreveló que estaba cargado, deshabilitado y activo (en ejecución).
Debería serlo disabled, eso es correcto. Porque lo estoy usando dnscrypt-proxycomo código auxiliar local y no lo necesito systemd-resolved. Pero no debería estar ejecutándose... No sé por qué estaba ejecutándose, pero ahora lo detuve nuevamente.
Ahora también he eliminado mi /etc/network/interfacesarchivo, ya queesta respuestaindica que no lo quiero. Lo usaría ifupdownpero yo estoy usando el administrador de red.
Observación 7
Siguienteesta respuesta, He configurado la auditoría para el archivo /etc/resolv.confal que apunta mi enlace simbólico.
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
Muy poco después, ya veo actividad en ese archivo:
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 cada tres minutos, algún proceso bajo mi nombre de usuario ( generic) actúa como root para mover un archivo a /etc/resolv.conf.localdns. Y la fuente es /etc/resolv.conf.localdns.dhclient-new.22822, lo que indica que dhclientes el culpable.
Supongo que me vendría bien chattr +i /etc/resolv.confhacerlo no editable, pero parece un enfoque sucio. Por ahora, estoy haciendo eso y parece evitar con éxito que dhclient cambie el archivo, pero me gustaría entender qué salió mal y cómo evitar el mismo problema en el futuro, tal vez incluso una solución más limpia.
Además, realmente no entiendo por qué dhclientme ayudó la ejecución manual. Supongo que ese fue el problema con la ruta predeterminada que falta, que ya no aparece desde hace un tiempo.
Respuesta1
Después de hacer que el /etc/resolv.confarchivo fuera inmutable usando chattr +i /etc/resolv.conf, dhclientdejé de modificar mi archivo porque no pudo hacerlo, pero no dejó de intentarlo. Eso era visible en los auditdregistros.
Sin embargo, en algún momento de hoy intenté solucionar algunos otros problemas y también realicé
- an
apt upgradeyapt autoremovethat también agregaron y eliminaron algunos encabezados del kernel - un reinicio de Windows, donde utilicé Lenovo Vantage para actualizar una gran cantidad de controladores y el BIOS
Aunque un reinicio normal no ayudó en absoluto hasta ahora, la combinación de esas cosas parece haber impedido que dhclientlo intentaran. Mis reglas de auditoría ahora solo informan mis intentos manuales de cambiar el archivo, ya no hay fallas por dhclient. El último fracaso dhclientocurrió antes de esos dos puntos.
Entonces, parece que el problema probablemente fue introducido por una actualización del kernel y solucionado por otra.
Edición 2 de mayo de 2022: Esto ya no es cierto. Esta mañana el problema no estaba presente. Ahora mismo volvió a pasar, sin ningún reinicio de por medio.
Mi solución inicial de usar chattrpara hacer que el archivo fuera inmutable ya no estaba presente (tal vez lo había eliminado nuevamente una vez que la auditoría mostró que dhclient dejó de intentarlo) y mi enlace simbólico de /etc/resolv.confa /etc/resolv.conf.localdnsdesapareció. El archivo contenía valores incorrectos para la red actual (según el ISP de la red en la que estaba antes). Arreglar manualmente el archivo y configurar la inmutabilidad nuevamente lo arregló nuevamente... por ahora.
Parece que Cisco Anyconnect estambiénentrometerse en este asunto! Después de configurar los registros de auditoría como se explica en la pregunta, ahora veo esto cuando lo uso para conectarme:
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
Por lo tanto, es posible que Cisco Anyconnect a veces cambie el nombre de resolv.conf /etc/resolv.conf.vpnbackupy luego, por alguna razón, no lo solucione después de perder la conexión... Mi "solución" actual significa chattrque no puedo conectarme a la VPN. Parece que esto es unproblema conocido