Início / unix / Perguntas / 748767
Accepted
mYnDstrEAm
Asked: 2023-06-13 22:55:39 +0800 CST

Não é possível resolver nomes de domínio após atualizar para o Debian 12

  • 772

Depois de atualizar Debian11/KDE para Debian12, reiniciá-lo e executá sudo apt-get upgrade-lo mostra erros como Could not resolve ftp.XX.debian.org. Eles também são exibidos durante a execução sudo apt-get update. Em seguida, tentei abrir sites no navegador Firefox-esr e não consigo abrir nenhum (ele mostra o erro "Hmm. Estamos tendo problemas para encontrar esse site."). Também não consigo pingar nenhum site, mostra " Nome ou serviço desconhecido ". Por isso, tem problemas para resolver nomes de domínio com DNS.

Detalhes e o que tentei:

Eu tentei sudo mv /etc/resolv.conf /etc/backup.resolv.conf. O DNS ainda funciona em uma máquina Debian11 e funcionou antes de atualizar para Debian12. As regras do firewall nftables são as mesmas de antes. O tempo estava atrasado em minutos novamente, mas eu o corrigi para que não devesse estar atrasado em mais de segundos. No final da atualização em 99%, tentei abrir o navegador quando ele me pediu para substituir um determinado arquivo de configuração, isso causou uma tela preta (uma vez durante a atualização, a tela não pôde ser acordada também) e me desconectou, então eu tinha para terminar a atualização com sudo dpkg --configure -ao qual parecia ter funcionado. Talvez eu precise verificar se a atualização funcionou.

No momento, não consigo usar a Internet nessa máquina enquanto o NetworkManager exibe que está conectado corretamente e minha página do roteador também mostra o dispositivo como conectado.

  • grep ^hosts /etc/nsswitch.confshowshosts: files mdns4_minimal [NOTFOUND=return] dns mymachines

  • /etc/resolv.confcontém #Generated by NetworkManager nameserver: 1.1.1.1(já tentei adicionar o servidor de nomes 1.0.0.1 abaixo dele, o que não ajudou)

  • nmcli c show <connection name> | grep -i dnsmostra abaixo para a conexão com a Internet (não a conexão VPN). Na máquina Debian11 onde o DNS ainda funciona esses valores são diferentes: não tem connection.dns-over-tls. Acho que dns-over-tls provavelmente tem a ver com o problema. Também está configurado no roteador que é usado por várias máquinas das quais apenas a máquina Debian12 não pode acessar sites. Eu uso apenas IPv4 por bons motivos e uma VPN.

connection.mdns:                        -1 (default)
connection.dns-over-tls:                -1 (default)
ipv4.dns:                               1.1.1.1
ipv4.dns-search:                        --
ipv4.dns-options:                       --
ipv4.dns-priority:                      0
ipv4.ignore-auto-dns:                   yes
ipv6.dns:                               --
ipv6.dns-search:                        --
ipv6.dns-options:                       --
ipv6.dns-priority:                      0
ipv6.ignore-auto-dns:                   no
IP4.DNS[1]:                             1.1.1.1

Por que isso acontece e como resolver esse problema?

debian

2 respostas

  1. A connection.dns-over-tlsconfiguração é nova no Debian 12. Pelo que entendi, o valor "padrão" (-1) tem um significado que depende de qual biblioteca de resolução você está usando. Não acho que o resolvedor libc clássico ( hosts:palavra-chave dns) tenha nenhuma funcionalidade DNS sobre TLS; portanto, com suas configurações atuais, a configuração "padrão" (ou mesmo qualquer configuração!) Significaria "não". Mas você pode alterá-lo com:

    nmcli c modify <connection name> connection.dns-over-tls <new setting>

    As configurações possíveis seriam "padrão", "não", "oportunista" e "sim". Eu acho que eles só teriam efeito ao usar systemd-resolvedou alguma outra biblioteca de resolução com suporte DoT.

    Portanto, você codificou o servidor DNS 1.1.1.1 nas configurações do NetworkManager e tentou adicionar 1.0.0.1 editando diretamente /etc/resolv.conf. Mas você já testou se consegue acessar esses servidores DNS?

    Se você ainda não tem nslookupou diginstalou, o teste mais básico usando apenas libc-binferramentas (que realmente deveriam estar presentes já que o pacote está marcado essential) seria:

    getent hosts 1.1.1.1             # reverse lookup
getent hosts one.one.one.one     # one.one.one.one is the DNS name of 1.1.1.1

    Se você tracerouteinstalou, um bom teste para DNS sobre TLS que pode até localizar o problema para você seria:

    traceroute -T -p 853 -n 1.1.1.1

    Para consultas regulares de DNS não TLS, você pode testar:

    traceroute -T -p 53 -n 1.1.1.1

    Eu sei que você disse que o NetworkManager diz que está conectado corretamente, mas isso é realmente verdade?

    Se você executar ip addr show, verá o estado real de baixo nível de cada interface de rede. Ele deve mostrar <BROADCAST,MULTICAST,UP,LOWER_UP>e ... state UP ...para a interface de rede que você está usando no momento.

    Se houver apenas UP, mas nenhum LOWER_UP entre os colchetes, significa que a interface está configurada (quer funcionar), mas não tem link ou tem algum outro problema que a impede de realmente funcionar (não pode). Nesse caso, verifique a dmesgsaída, pois pode haver uma mensagem de erro indicando que está faltando um arquivo de firmware da NIC ou algo parecido.

    • 1
  2. Best Answer

    Com journalctl | tail -n 100encontrei este erro (que não apareceu no início):
    nm-openvpn: write to TUN/TAP : Invalid argument (fd=-1,code=22)

    Para resolver este problema (no KDE), clique com o botão direito do mouse no ícone da bandeja do NetworkManager (se você importou sua configuração de VPN para ele ou configurou a VPN lá) ->Configurar
    conexões de rede...->Sua VPN->VPN (openvpn )->Avançado->Geral-> marque "Usar compactação" e selecione LZO na caixa à direita (não tentei outros métodos de compactação)->Ok e Aplicar->Desconectar, reconectar e testar.

    Ainda não sei por que esse problema ocorreu e parece que o DNS sobre TLS ainda não funciona. Por favor, comente se você sabe sobre qualquer um.

    • 0

relate perguntas