1 pontos por GN⁺ 1 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • Na rede doméstica, ping google.com funcionava, mas ping6 google.com falhava, e a causa era que as consultas DNS IPv6 estavam desativadas nas configurações do Adguard Home DNS
  • A ACT broadband não oferecia suporte a IPv6 no passado, mas foi confirmado que está fazendo uma implantação gradual para usuários de Chennai, e quando o IPv6 foi ativado no roteador, tudo funcionou normalmente
  • Durante testes de rede recentes, o problema com IPv6 apareceu de novo, mas o portal administrativo do roteador mostrava que a conexão IPv6 do ISP em si estava ativa, e o mesmo problema também foi reproduzido no macOS e em um Raspberry Pi
  • Como dig AAAA google.com não retornava resultado de DNS, o escopo do problema foi reduzido do link do ISP ou da configuração dos clientes para o lado do servidor DNS que processa consultas de registros AAAA
  • Era um problema de configuração surgido depois que o DNS foi migrado no ano passado para o Adguard Home, e ao desativar o bloqueio de consultas DNS IPv6, tanto ping -4 quanto ping -6 passaram a funcionar com 0% de perda de pacotes

Causa e solução

  • Na rede doméstica, ping google.com funcionava, mas ping6 google.com falhava, e a causa final era que todas as consultas DNS IPv6 estavam desativadas nas configurações do Adguard Home DNS
  • A ACT broadband não ofereceu suporte a IPv6 por um bom tempo, mas alguns anos atrás foi confirmado que estava fazendo uma implantação gradual para usuários de Chennai, e após ativar o IPv6 no roteador, na época tudo funcionou sem problemas
  • Recentemente, ao testar a conexão de rede enquanto reorganizava o ambiente da mesa, o problema com IPv6 reapareceu, e o portal administrativo do roteador confirmava a própria conexão IPv6 do ISP
  • Nas configurações de rede do macOS, o IPv6 também estava permitido, e o mesmo problema foi reproduzido em um Raspberry Pi conectado ao roteador via LAN, o que torna difícil atribuí-lo a um dispositivo específico
  • Para testar diretamente um endereço IPv6, foi executado dig AAAA google.com, mas nenhum resultado de DNS apareceu; como o Google suporta IPv6, surgiu a suspeita de problema no lado do servidor DNS
  • Depois de lembrar que no ano passado o DNS havia sido migrado para o Adguard Home, as configurações do servidor DNS foram verificadas, e foi encontrado um pequeno botão de alternância que bloqueava consultas DNS IPv6
  • Após desativar essa opção e salvar, tanto o IPv4 quanto o IPv6 voltaram a funcionar normalmente

Processo de verificação e resultados

  • Verificação dos sintomas

    • A resolução de nomes e a conexão via IPv4 funcionavam normalmente
    • A resolução de nomes ou a conexão via IPv6 falhavam
    • Os testes básicos usados foram os seguintes
      ping google.com
      ping6 google.com
      
  • Verificação do ISP e das configurações dos dispositivos

    • Primeiro surgiu a suspeita de que o ISP pudesse ter desativado o IPv6 novamente, mas a conexão IPv6 foi confirmada no portal administrativo do roteador
    • Nas configurações de rede do macOS, o IPv6 também estava permitido
    • O mesmo problema ocorreu no Raspberry Pi, então é difícil considerá-lo um problema de configuração de um único cliente
    • Como estava sendo usado um servidor DNS próprio, também foram comparados o endereço do servidor DNS IPv6 do roteador e o endereço IP da interface Ethernet do Raspberry Pi
  • Indícios que levaram ao DNS como causa

    • Para descartar um problema no repasse do DNS IPv6 via DHCP, tentou-se verificar diretamente um endereço IPv6, e dig AAAA google.com não retornou resultado
    • Nesse ponto, o problema deixou de parecer ligado à conexão do ISP ou à permissão de IPv6 no cliente, e ficou restrito ao lado do servidor DNS que processa consultas de registros AAAA
  • Validação após a correção

    • Depois de desativar no Adguard Home a opção que bloqueava consultas DNS IPv6, tanto ping -4 quanto ping -6 passaram a funcionar
    • No teste IPv4, foram enviados 5 pacotes para 172.217.24.110, 5 foram recebidos, com perda de pacotes de 0%
    • No teste IPv6, foram enviados 5 pacotes para 2404:6800:4007:817::200e, 5 foram recebidos, com perda de pacotes de 0%
    • Ativar o IPv6 traz vantagens como menor latência, melhor conexão P2P sem necessidade de NAT traversal e recursos como SLAAC

1 comentários

 
GN⁺ 1 시간 전
Opiniões no Lobste.rs
  • Isso é terrível, e o AdGuard Home deveria se envergonhar

    • Não parece que essa configuração venha ativada por padrão
      Eu também uso AdGuard Home, e aqui isso está desativado; além disso, troquei a configuração/roteador há menos de duas semanas, então tenho bastante certeza de que não fui eu que mexi nisso
  • Não faço ideia de por que esse recurso existe

    • Porque a comunidade de bloqueio de anúncios via DNS como um todo, especialmente lugares como AdGuard e Pi-hole, historicamente tem sido bastante hostil a IPv6 e redes dual-stack
      Quando chega um pedido de suporte nesses serviços, seja nos canais oficiais, fóruns, Discord ou subreddits da comunidade do projeto, a primeira recomendação ainda costuma ser algo como “desative o IPv6”
  • O IPv6 tem um design ruim e é fácil errar na configuração, então o conselho mais óbvio acaba sendo desativá-lo

  • Acabei de depurar o problema oposto: o IPv4 não funcionava na rede da minha casa
    Era um serviço somente IPv6 que usa DS-Lite para conectividade IPv4, e no DS-Lite o roteador doméstico encapsula os pacotes IPv4 para o AFTR, o NAT do ISP
    O domínio do AFTR é fornecido via DHCPv6 e, no meu caso, era no formato something.aftr.kabelbw.de, mas neste momento esse domínio não está resolvendo por causa de alguns problemas da denic com sua configuração de DNSSEC
    Felizmente, como eu não desativei o IPv6 em lugar nenhum, tirando o GitHub, todo o resto funciona bem