J'utilise Arch Linux sur un Raspberry Pi.
Tout à coup:
J'ai deux autres ordinateurs (tous exécutant Arch Linux) connectés à Internet, où je peux cingler et utiliser Internet. Aussi, /etc/resolv.conf
est identique sur les autres ordinateurs:
nameserver 10.230.252.252
nameserver 203.147.88.2
nameserver 8.8.8.8
search domain.name
Je peux utiliser VNC. Je peux également envoyer une requête ping à 8.8.8.8. Lorsque j'essaie d'accéder à DuckDuckGo sur Chromium, j'obtiens:
This site can’t be reached
duckduckgo.com’s server IP address could not be found.
DNS_PROBE_FINISHED_NXDOMAIN
J'ai une connexion Internet active. Qu'est-ce qui ne va pas?
Bien que je n'ai jamais eu de problème avec mes autres PC x86_64 fonctionnant tous sous Arch Linux, cela se produit fréquemment jusqu'à la date avec Arch Linux ARM lors de l'exécution de NetworkManager.
Le problème est que vous êtes connecté au wifi, mais vous ne pouvez pas cingler ou utiliser Internet mais vous pouvez accéder à tous les ordinateurs du réseau local et même utiliser un logiciel de partage de bureau à distance.
Il y a de fortes chances que quelque chose se soit mal passé pendant que votre ping ou votre navigateur tente de résoudre l'hôte. Je peux penser à 3 solutions:
Je pense que c'est un problème sur les milliers de systèmes Raspberry Pi exécutant Archlinux ARM et utilisant NetworkManger.
Dans mon cas, /etc/resolv.conf était un lien symbolique cassé vers ../run/systemd/resolve/stub-resolv.conf
.
NetworkManager ne peut pas remplir le lien symbolique et /etc/resolv.conf est vide. Nous devons:
# rm /etc/resolv.conf
/etc/NetworkManager/conf.d/dns.conf
fichier avec le contenu:[main]
dns=none
main.systemd-resolved=false
Sudo systemctl restart NetworkManager
Cela devrait résoudre le problème, sinon suivre la solution 2.
Dans le cas où ce qui précède n'a pas résolu le problème pour vous, vous pouvez remplir temporairement /etc/resolv.conf en:
Sudo systemctl restart systemd-resolved && Sudo systemctl stop systemd-resolved
La raison pour laquelle cela fonctionne est parce que quelque chose gâche probablement le /etc/resolv.conf
fichier. La commande ci-dessus doit remplacer le contenu, mais encore une fois, vous devez rechercher la cause du problème.
Si vous ne pouvez pas obtenir votre /etc/resolv.conf
retour, créez simplement un nouveau /etc/resolv.conf
(supprimer s'il existe un ancien lien vide ou un lien symbolique) et coller le code:
search domain.name
nameserver 8.8.8.8
nameserver 1.1.1.1
nameserver 1.0.0.1
Un peu bizarre, ici j'utilise le DNS principal de Google et le DNS principal de cloudflare, vous pouvez utiliser 8.8.8.8 avec 8.8.4.4 ou 1.1.1.1 avec 1.0.0.1.
Ils ont travaillé pour mes installations sur Raspberry Pi 3 modèle B. J'espère que cela fonctionnera aussi pour vous.
Je viens d'avoir des problèmes avec les mêmes effets. Vérifiez si l'heure est correctement réglée. DNSSEC semble être activé par défaut et bloquer les demandes en raison de certificats "expirés".
D'autres problèmes liés à cela peuvent être diagnostiqués avec journalctl -u systemd-resolved -b -0
.
J'ai eu ce problème sur Raspberry Pi 4 sous Arch Linux.
Les symptômes étaient qu'il n'y avait pas de DNS, produisant le message d'erreur ping
.
J'ai remarqué en appelant date
que le temps était très court, environ deux jours auparavant.
Je me suis assuré que synchronisation de l'heure était activé avec systemctl status systemd-timesyncd
mais remarqué par la sortie de timedatectl timesync-status
que le service n'avait pas d'adresse IP pour le serveur NTP (il indiquait Server: Null
).
Utilisation de astuce de jaku255 de vérification journalctl -u systemd-resolved -b -0
, J'ai vu que la synchronisation de l'heure ne fonctionnait pas car DNS échouait:
Échec de la validation DNSSEC pour la question ntp.org IN DS: signature expirée
C'est un peu une impasse: le DNS ne fonctionne pas parce que le temps est mauvais et le temps est mauvais parce que le DNS ne fonctionne pas.
Tentant de régler l'heure manuellement, j'ai émis
timedatectl set-time "2020-02-29 10:51:55"
mais cela a produit une erreur:
Échec de la définition de l'heure: la synchronisation automatique de l'heure est activée
Pour résoudre ce problème, j'ai temporairement (hehe ^^) désactivé la synchronisation de l'heure avec
timedatectl set-ntp 0
et appelé timedatectl set-time
encore une fois, cette fois avec succès.
Ensuite, j'ai réactivé la synchronisation horaire avec timedatectl set-ntp 1
et assurez-vous d'utiliser timedatectl timesync-status
que la synchronisation fonctionne maintenant:
Serveur: 212.69.166.153 (0.Arch.pool.ntp.org)
De plus, ping
et curl
fonctionnent bien maintenant avec la réussite du DNS.