Início / unix / Perguntas / 518266
Accepted
S.Goswami
Asked: 2019-05-11 07:52:04 +0800 CST

ping exibe "Nome ou serviço não conhecido"

  • 772

Estou executando o Arch Linux em um Raspberry Pi.

De repente:

  1. Não consigo pingar em um site.
  2. Não consigo acessar um site pelo navegador.

Eu tenho mais dois computadores (todos rodando Arch Linux) conectados à Internet, onde posso pingar e usar a Internet. Além disso, /etc/resolv.confé idêntico nos outros computadores:

nameserver 10.230.252.252
nameserver 203.147.88.2
nameserver 8.8.8.8
search domain.name

Eu posso usar VNC. Eu também posso pingar para 8.8.8.8. Ao tentar acessar o DuckDuckGo no Chromium, recebo:

This site can’t be reached
duckduckgo.com’s server IP address could not be found.
DNS_PROBE_FINISHED_NXDOMAIN

Tenho uma conexão ativa com a Internet. O que há de errado?

arch-linux dns

5 respostas

  1. Best Answer

    Embora eu nunca tenha tido problemas com meu outro PC x86_64 rodando o Arch Linux, isso frequentemente acontece até a data com o Arch Linux ARM ao executar o NetworkManager.

    O problema é que você está conectado ao wifi, mas não pode pingar ou usar a internet, mas pode acessar todos os computadores da rede local e até usar o software de compartilhamento remoto da área de trabalho.

    Há uma grande chance de que algo dê errado enquanto seu ping ou seu navegador tenta resolver o host. Posso pensar em 3 soluções:

    Solução 1

    Acredito que isso seja um problema nos milhares de sistemas Raspberry Pi executando o Archlinux ARM e usando o NetworkManger.

    No meu caso /etc/resolv.conf era um link simbólico quebrado para ../run/systemd/resolve/stub-resolv.conf.

    O NetworkManager não pode preencher o link simbólico e o /etc/resolv.conf está vazio. Temos que:

    1. Remova o link simbólico quebrado:
    # rm /etc/resolv.conf
    1. Crie um /etc/NetworkManager/conf.d/dns.confarquivo com o conteúdo:
    [main]
dns=none
main.systemd-resolved=false
    1. Reinicie o NetworkManager:
    sudo systemctl restart NetworkManager

    Isso deve corrigir o problema, caso contrário, siga a Solução 2.

    Solução 2

    Caso o acima não tenha corrigido o problema para você, você pode preencher temporariamente /etc/resolv.conf por:

    sudo systemctl restart systemd-resolved && sudo systemctl stop systemd-resolved

    A razão pela qual isso funciona é porque provavelmente algo está atrapalhando o /etc/resolv.confarquivo. O comando acima deve substituir o conteúdo, mas, novamente, você deve verificar o que está causando o problema.

    Solução 3

    Caso não consiga /etc/resolv.confrecuperar, basta criar um novo /etc/resolv.conf(excluir se existir um antigo vazio ou link simbólico) e colar o código:

    search domain.name
nameserver 8.8.8.8
nameserver 1.1.1.1
nameserver 1.0.0.1

    Observe que, na primeira linha, você também pode usar o endereço IP do seu roteador, por exemplo ( nameserver 192.168.43.1no meu caso), o que tornará outros sistemas pingáveis ​​na mesma rede. Não é uma boa ideia gerar resolv assim, mas eu me dei mal com o resolv gerado automaticamente pelo NetworkManager. Systemd-resolvd também gera erros, mesmo no meu PC.

    Um pouco estranho, aqui estou usando o dns primário do google e o dns primário do cloudflare, você pode usar 8.8.8.8 com 8.8.4.4 ou 1.1.1.1 com 1.0.0.1.

    Embora essa etapa funcione, mas você pode querer impedir que o NetworkManager sobrescreva o arquivo sempre que for reiniciado:

    Adicione esta entrada a/etc/NetworkManager/NetworkManager.conf

    [main]
dns=none
systemd-resolved=false

    Eles funcionaram para minhas instalações no Raspberry Pi 3 modelo B. Espero que isso funcione para você também.

    • 32

  2. Acabei de ter problema com os mesmos efeitos. Verifique se o horário está definido corretamente. O DNSSEC parece estar ativado por padrão e bloqueando solicitações devido a certificados "expirados".

    Alguns outros problemas relacionados a isso podem ser diagnosticados journalctl -u systemd-resolved -b -0.

    • 6

  3. Eu tive esse problema no Raspberry Pi 4 executando o Arch Linux.

    Os sintomas eram que não havia DNS, produzindo a pingmensagem de erro.

    Eu observei ligando dateque o tempo estava severamente desligado, cerca de dois dias atrás.

    Certifiquei-me de que a sincronização de tempo estava ativada, systemctl status systemd-timesyncdmas notei na saída timedatectl timesync-statusque o serviço não tinha um endereço IP para o servidor NTP (dizia Server: Null).

    Usando a dica de verificação do jaku255journalctl -u systemd-resolved -b -0 , vi que a sincronização de tempo não funcionou porque o DNS estava falhando:

    Falha na validação do DNSSEC para a pergunta ntp.org IN DS: assinatura expirada

    É um pouco de impasse: o DNS não funciona porque a hora está errada e a hora está errada porque o DNS não funciona.

    Tentando definir a hora manualmente, emiti

    timedatectl set-time "2020-02-29 10:51:55"

    mas isso produziu um erro:

    Falha ao definir a hora: a sincronização automática de hora está ativada

    Para corrigir isso, desativei temporariamente (hehe^^) a sincronização de tempo com

    timedatectl set-ntp 0

    e ligou timedatectl set-timenovamente, desta vez com sucesso.

    Depois, reativei a sincronização de horário timedatectl set-ntp 1e certifiquei-me de timedatectl timesync-statusque essa sincronização funcionasse agora:

    Servidor: 212.69.166.153 (0.arch.pool.ntp.org)

    Além disso, pinge curlfunciona bem agora com o sucesso do DNS.

    • 5

  4. Queria adicionar mais uma à lista de soluções de Goswami.

    Eu enfrento o mesmo problema de galinha e ovo entre DNSSEC e NTP em meus minúsculos servidores portáteis rodando Debian 10. Às vezes eles ficam sem energia por algum tempo e literalmente perdem a noção do tempo, enquanto o mundo muda ao seu redor, então eu não poderia simplesmente crie uma(s) configuração(ões) de hot-fix estática(s). Ao mesmo tempo, eles precisam ficar on-line sozinhos quando alimentados, pois não tenho acesso físico a eles. Eu decidi sair do loop corrigindo o tempo primeiro e até agora esse método parece ser confiável o suficiente.

    Solução 4

    Obtenha uma lista de endereços IP confiáveis ​​de servidores NTP confiáveis ​​e confiáveis . Vamos usar este, por exemplo: https://tf.nist.gov/tf-cgi/servers.cgi . Aqui estão alguns exemplos de lá:

    time-a-g.nist.gov       129.6.15.28
time-b-g.nist.gov       129.6.15.29
time-c-g.nist.gov       129.6.15.30
...
time-a-wwv.nist.gov     132.163.97.1
time-b-wwv.nist.gov     132.163.97.2
time-c-wwv.nist.gov     132.163.97.3
time-d-wwv.nist.gov     132.163.97.4
...

    Como uso chronydpara sincronização de tempo, simplesmente adicionei esses endereços IP à sua configuração: (NOTA: isso também funciona para ntpdconfiguração, geralmente encontrada em /etc/ntp.conf)

    nano /etc/chrony/chrony.conf

    linhas adicionadas:

    ...
pool time.nist.gov
server 132.163.97.1
server 132.163.97.2
server 132.163.97.3
server 132.163.97.4
...

    Agora, o chrony passa por todos os endereços especificados até conseguir se conectar e obter tempo. E a partir desse ponto todo o resto começa a funcionar corretamente.

    Tenho um script no meu mainframe que verifica periodicamente se todos os IPs da lista estão ativos e avisa se algum deles ficar offline, para que eu possa atualizar as configurações remotas quando necessário, enquanto os servidores estão online e nem todos os servidores NTP expiraram.

    Provavelmente, a melhor prática seria ter configurações de fallback para ambas as extremidades, DNS e NTP.

    • 1

  5. Esse problema ainda continua a acontecer no Arch Linux Arm e Raspberry Pi 4. Eu uso systemd-networkd em vez de NetworkManager, então uma das soluções acima não se aplica. A hora do meu sistema NTP também estava sincronizando corretamente. DNSSEC foi desabilitado por padrão.

    No meu caso, os nomes de host WAN estavam resolvendo, mas os nomes de host LAN não estavam e eu estava recebendo os mesmos Name or service not knownerros.

    Minha solução foi usar o DNS clássico em vez do LLMNR editando /etc/systemd/resolved.conf:

    [Resolve]
...
LLMNR=no
...
ResolveUnicastSingleLabel=yes

    Reinicie os serviços para aplicar as alterações:

    sudo systemctl restart systemd-networkd
sudo systemctl restart systemd-resolved
    • 1

relate perguntas