A VPN diz conectado mas nada passa: dois lugares para olhar

Um túnel pode informar que está conectado enquanto nada o alcança, e os dois fatos moram em lugares diferentes. Um é a tabela de rotas, que pode ainda enviar pacotes para um dispositivo que ninguém possui. O outro é o resolvedor, que pode ainda listar um servidor em um enlace que já sumiu. A mudança de rede não danificou o perfil, ela deixou órfão o estado da conexão anterior, e o conserto depende de qual dos dois você está realmente olhando.

Primeiro, pergunte ao kernel qual dispositivo ele usaria

Uma listagem de rotas mostra o que existe; uma consulta de rota mostra o que aconteceria. Pergunte por um endereço público e leia o nome do dispositivo na resposta, porque esse único campo decide se o pacote chega a algum lugar útil. Quando a resposta nomeia um dispositivo de túnel, o kernel entrega os pacotes a ele mesmo que nenhum processo cliente ainda esteja rodando atrás dessa interface. Quando a resposta nomeia o adaptador físico enquanto o cliente afirma estar conectado, o túnel está no ar e apenas não é o caminho escolhido.

O segundo caso é o habitual depois que um cabo substitui o Wi-Fi, e ele se apresenta como uma VPN quebrada.

ip route show default
ip route get 203.0.113.9

Leia em seguida as entradas padrão, pois uma rota adicionada pela conexão base anterior pode sobreviver a uma troca de enlace e ficar na frente da nova. Uma rota padrão por um dispositivo que está fora do ar é pior do que nenhuma rota padrão, porque o kernel ainda a prefere. Observe a métrica ao lado de cada entrada, porque essa ordenação explica a preferência mais rápido do que os nomes das interfaces.

Depois, leia o resolvedor por enlace, não por arquivo

A resolução de nomes carrega o próprio estado e a própria obsolescência. Um resolvedor que lista servidores DNS por enlace mantém os servidores de um enlace de túnel que está fora do ar mas continua registrado, e cada consulta passa então a esperar por um servidor que não vai responder. O sintoma é uma rede que parece morta enquanto a tabela de rotas está impecável.

Inspecione o estado por enlace em vez do arquivo, porque em muitas distribuições esse arquivo é um link simbólico para o resolvedor e editá-lo ou não faz nada ou é sobrescrito em pouco tempo. Veja qual enlace possui quais servidores e qual domínio de busca, depois pergunte se o enlace de túnel ainda deveria estar registrado. Se não deveria, desative a conexão que o possui em vez de editar à mão um estado gerado. Um nome que resolve enquanto a consulta de rota envia pacotes para outro lugar é uma terceira falha, separada.

resolvectl status
resolvectl query app.internal.example

Se os endereços resolvem e as conexões falham, o resolvedor está bem e a rota não. Se os endereços não resolvem de jeito nenhum, este é o lugar certo para começar.

Como uma rota obsoleta sobrevive à mudança

O cliente não é dono da rede sozinho. Em um host com NetworkManager um perfil de VPN é ativado sobre uma conexão base, e as configurações de conexão permitem que essa base nomeie a VPN que deve segui-la. Quando a base muda porque outro perfil passa a ser preferido, o túnel segue para a nova base ou fica sem nenhuma.

Um perfil de VPN não se levanta sozinho, então o pareamento importa muito mais do que a preferência de conexão automática do próprio perfil.

Leia a lista ativa e anote qual base está no ar antes de mexer no túnel. Se a base aparece e o túnel não, a rota está faltando e não obsoleta, e o conserto é a ativação. Se ativar o túnel reclamar que não existe conexão de origem, a base com a qual ele estava pareado sumiu, então levante-a primeiro ou conserte o pareamento em vez de tentar o túnel de novo. Repetir um perfil cujo pai está ausente produz o mesmo erro toda vez, o que é um sinal útil e não um incômodo.

nmcli device status
nmcli connection show --active
nmcli connection up office-vpn

Separar estado obsoleto de um pai ausente

Três estados explicam quase todo relato, e cada um precisa de um conserto diferente. Uma rota padrão por um dispositivo que ainda existe mas não carrega mais o túnel é estado obsoleto, limpo apagando a entrada ou reiniciando o perfil responsável. Um dispositivo de túnel cujo processo cliente sumiu é uma falha de limpeza, então o caminho de desconexão merece a atenção e não a tabela de rotas. Nenhum dispositivo de túnel significa que falta o pai ou o pareamento e que a tabela de rotas nunca entrou na história.

Reiniciar esconde qual dos três você tinha, e é exatamente por isso que parece um conserto.

Depois do conserto, peça ao kernel um endereço público e um interno, depois consulte um nome interno. Quando o endereço funciona e o nome não, você achou um problema de escopo de domínio no resolvedor e não de roteamento. Anote qual estado você encontrou, porque a próxima mudança de rede vai reproduzir aquele que você deixou quieto.