Sé libre de compartir nuestros tutoriales y códigos en tus redes sociales, necesitamos tu ayuda para hacer crecer esta comunidad.
Solución:
Aunque nunca he tenido problemas con mi otra PC x86_64 que ejecuta Arch Linux, esto sucede con frecuencia hasta la fecha con Arch Linux ARM cuando se ejecuta NetworkManager.
El problema es que está conectado a wifi, pero no puede hacer ping ni usar Internet, pero puede acceder a todas las computadoras en la red local e incluso usar software de uso compartido de escritorio remoto.
Existe una gran posibilidad de que algo haya salido mal mientras su ping o su navegador intentan resolver el host. Se me ocurren 3 soluciones:
Solución 1
Creo que este es un problema en los miles de sistemas Raspberry Pi que ejecutan Archlinux ARM y usan NetworkManger.
En mi caso, /etc/resolv.conf era un enlace simbólico roto a ../run/systemd/resolve/stub-resolv.conf.
NetworkManager no puede completar el enlace simbólico y /etc/resolv.conf está vacío. Tenemos que:
- Eliminar el enlace simbólico roto:
# rm /etc/resolv.conf
- Crear un
/etc/NetworkManager/conf.d/dns.confarchivo con el contenido:
[main]
dns=none
main.systemd-resolved=false
- Reinicie NetworkManager:
sudo systemctl restart NetworkManager
Esto debería solucionar el problema, si no sigue la Solución 2.
Solución 2
En caso de que lo anterior no haya solucionado el problema, puede completar temporalmente /etc/resolv.conf de la siguiente manera:
sudo systemctl restart systemd-resolved && sudo systemctl stop systemd-resolved
La razón por la que esto funciona es porque probablemente algo esté estropeando el /etc/resolv.conf expediente. El comando anterior debería sobrescribir el contenido, pero nuevamente, debe ver qué está causando el problema.
Solución 3
Si no puede obtener su /etc/resolv.conf atrás, solo crea uno nuevo /etc/resolv.conf (borrar si existe uno antiguo vacío o un enlace simbólico) y pegar el código:
search domain.name
nameserver 8.8.8.8
nameserver 1.1.1.1
nameserver 1.0.0.1
Tenga en cuenta que en la primera línea, también puede usar la dirección IP de su enrutador, por ejemplo (nameserver 192.168.43.1 en mi caso) que hará que se pueda hacer ping a otros sistemas en la misma red. No es una buena idea generar una resolución como esta, pero tuve un mal momento con la resolución generada automáticamente por NetworkManager. Systemd-resolvd también genera errores, incluso en mi PC.
Un poco raro, aquí estoy usando el dns primario de google y el dns primario de cloudflare, puedes usar 8.8.8.8 con 8.8.4.4 o 1.1.1.1 con 1.0.0.1.
Aunque ese paso funciona, es posible que desee evitar que NetworkManager sobrescriba el archivo cada vez que se reinicia:
Añadir esta entrada a /etc/NetworkManager/NetworkManager.conf
[main]
dns=none
systemd-resolved=false
Funcionaron para mis instalaciones en Raspberry Pi 3 modelo B. Espero que esto también funcione para usted.
Acabo de tener un problema con los mismos efectos. Compruebe si la hora está configurada correctamente. DNSSEC parece estar habilitado de forma predeterminada y bloqueando solicitudes debido a certificados “caducados”.
Algunos otros problemas relacionados con esto se pueden diagnosticar con journalctl -u systemd-resolved -b -0.
Tuve este problema en Raspberry Pi 4 con Arch Linux.
Los síntomas eran que no había DNS, produciéndose el ping mensaje de error.
Observé llamando date que el tiempo estaba severamente apagado, hace unos dos días.
Me aseguré de que la sincronización de tiempo estuviera activada con systemctl status systemd-timesyncd pero se dio cuenta de la salida de timedatectl timesync-status que el servicio no tenía una dirección IP para el servidor NTP (decía Server: Null).
Usando la punta de verificación de jaku255 journalctl -u systemd-resolved -b -0vi que la sincronización de tiempo no funcionaba porque el DNS estaba fallando:
Falló la validación de DNSSEC para la pregunta ntp.org IN DS: firma caducada
Es un poco un punto muerto: el DNS no funciona porque la hora es incorrecta y la hora es incorrecta porque el DNS no funciona.
Intentando configurar la hora manualmente, emití
timedatectl set-time "2020-02-29 10:51:55"
pero esto produjo un error:
No se pudo establecer la hora: la sincronización horaria automática está habilitada
Para arreglar esto, deshabilité temporalmente (jeje^^) la sincronización de tiempo con
timedatectl set-ntp 0
y llamó timedatectl set-time de nuevo, esta vez con éxito.
Posteriormente, reactivé la sincronización horaria con timedatectl set-ntp 1 y se aseguró de usar timedatectl timesync-status que la sincronización funciona ahora:
Servidor: 212.69.166.153 (0.arch.pool.ntp.org)
También, ping y curl funciona bien ahora con el éxito de DNS.
Si estás de acuerdo, tienes el poder dejar una división acerca de qué te ha gustado de este ensayo.