Como verificar o estado do IPv6 de um Mac depois que a VPN desconecta

Chegue a um site por IPv4 depois que o túnel cair e você não terá provado nada sobre IPv6. O macOS configura as duas famílias separadamente, por serviço de rede, e um cliente VPN pode alterar uma sem tocar na outra. Percorra as três camadas em ordem: configuração do endereço, seleção de rota e, depois, qualquer política que o cliente instale enquanto estiver desconectado. Mantenha a rede de acesso inalterada nesse meio-tempo, ou comparará dois problemas diferentes.

Comece pela família que realmente quebrou

Uma página que carrega por IPv4 diz que a rede física está viva. Ela não diz nada sobre se o serviço tem um endereço IPv6 global, se o prefixo ainda é anunciado ou se algo filtra a família. Confirme o que falhou antes de escolher uma ferramenta, porque um nome que resolve para um endereço inalcançável parece idêntico a um nome que não resolve de forma alguma. Pergunte qual camada respondeu errado e escreva a resposta. Sem isso, cada passo seguinte é um palpite vestido de procedimento.

Mantenha a mesma rede Wi-Fi e o mesmo ponto de acesso durante toda a comparação. Uma rede de café que ontem oferecia IPv6 não diz nada sobre aquela em que você está agora.

Leia o endereço antes da rota

Nas Ajustes do Sistema, o painel TCP/IP do serviço ativo mostra se o IPv6 é automático, manual ou apenas local de enlace. Compare isso com o que você espera, lembrando que uma organização pode ter escolhido a configuração manual de propósito. Depois execute ifconfig e leia a interface em questão. Um endereço fe80:: sozinho significa que a interface pode falar com os vizinhos e nada mais, então a presença local de enlace não é prova de um caminho utilizável.

Procure também interfaces utun deixadas pelo cliente. Um dispositivo de túnel obsoleto pode manter um endereço e uma rota muito depois de o cliente parar de usá-lo. Se houver um, é um achado de ciclo de vida para o proprietário do cliente, não algo para apagar na hora.

Leia a tabela de rotas para o destino que falha

Pergunte ao kernel sobre o destino que falhou, não sobre a rota padrão. route -n get 2001:db8::25 imprime a interface e o gateway escolhidos para esse endereço, e netstat -rn -f inet6 mostra a tabela inteira para comparação. Uma rota padrão diz que existe uma padrão; não diz que este destino a usa.

Mantenha o DNS no seu próprio compartimento. Um resolvedor alcançável por IPv4 ainda pode retornar registros AAAA, então uma falha de consulta e uma falha de roteamento produzem o mesmo sintoma no navegador.

Separe a política de bloqueio do cliente de um resíduo

Alguns clientes são projetados para bloquear o tráfego enquanto estão desconectados, incluindo a outra família de endereços, e esse comportamento é um recurso, não um defeito.

Descubra qual comportamento o seu cliente documenta antes de tratar um bloqueio como dano. scutil --dns mostra os resolvedores em vigor por serviço, e é aí que um resolvedor instalado pelo cliente ou um ajuste de DNS com escopo se torna visível. Depois verifique se regras de filtro de pacotes foram instaladas e deixadas para trás. Um bloqueio esperado e uma regra remanescente exigem respostas opostas, e só a documentação do proprietário as separa.

Reúna evidências e depois mude uma coisa

Registre a versão do cliente, a versão do macOS, o serviço de rede, a política desconectada pretendida e a saída de endereços e rotas dos dois lados de um ciclo de conexão e desconexão. É esse registro que transforma uma reclamação em um problema de ciclo de vida que alguém pode investigar. Depois faça uma única mudança e meça de novo.

Resista à reinicialização. Apagar interfaces virtuais, limpar a tabela de rotas e desativar o IPv6 na máquina inteira destroem o estado que você precisava capturar, e podem levar junto configuração não relacionada. Se o cliente tiver um fluxo compatível de pausa, reparo ou desinstalação, use-o, e siga o procedimento do administrador onde a rede é gerenciada. Uma máquina que já foi reinicializada não dá ao proprietário nada com que trabalhar, e costuma reproduzir a falha na conexão seguinte.