A VPN diz que está conectada, mas a rota padrão está morta

O cliente informa que está conectado, o ícone da bandeja parece normal e nada carrega. Começou logo depois de você passar de Wi-Fi para cabo, ou logo depois de uma atualização da distribuição terminar. O que quebrou não é o perfil, mas o estado que foi construído para a conexão base anterior. O kernel ainda tem uma rota padrão apontando para um dispositivo de túnel que ninguém possui, ou o resolvedor ainda lista servidores num link que desapareceu. As duas falhas parecem uma rede morta e ambas podem ser reparadas no local.

As peças obsoletas já estavam erradas antes de você notar. Desconectar um cabo apenas as tornou visíveis.

Pergunte ao kernel para onde um pacote iria

As listas de rotas são difíceis de ler porque enumeram tudo o que o sistema conhece, incluindo entradas que já não se aplicam. Uma consulta de rota responde à única pergunta que vale a pena: qual dispositivo carrega este pacote específico agora. Se a resposta nomear um dispositivo de túnel, o kernel vai usá-lo mesmo que não haja nenhum processo cliente vivo por trás, e o pacote cai numa interface que ninguém mantém. Se a resposta nomear o adaptador Ethernet enquanto o cliente insiste que a ligação está ativa, o túnel existe mas perdeu a seleção, que é o resultado habitual da passagem de sem fio para cabo.

Execute a consulta duas vezes, uma para um endereço público e outra para um interno, porque uma política de túnel dividido pode encaminhar um com honestidade e deixar cair o outro.

ip route show default
ip route get 1.1.1.1
ip route get 10.20.30.40

O resolvedor também guarda o link morto

Num host com systemd-resolved, os servidores DNS pertencem aos links e não a uma lista global. Um link VPN que caiu pode ficar registado com os seus servidores durante algum tempo, e então cada consulta espera por um endereço que nunca responderá. Esse atraso parece uma rede morta e leva as pessoas a olhar para as rotas quando a rota está bem.

resolvectl status
resolvectl query intranet.example.com

Leia os blocos por link e identifique qual link possui o domínio em questão. Um túnel que está levantado mas não é o proprietário do domínio interno reencaminha os nomes internos para o resolvedor público, e o sintoma é indistinguível de uma falha de encaminhamento.

Repare o registo em vez de /etc/resolv.conf. Nas instalações atuais de Ubuntu e Fedora esse caminho é um link simbólico para o estado de execução do resolvedor, pelo que uma edição é ignorada ou substituída no evento de rede seguinte.

Uma VPN nunca arranca sozinha

O NetworkManager levanta uma VPN sobre uma conexão base, e aprende qual deve seguir a partir de connection.secondaries nessa base. A referência das definições de ligação diz explicitamente que a ligação automática não está implementada para perfis VPN. Esse é todo o mecanismo por trás desta classe de falha: mude a base e a VPN tem de ser emparelhada de novo ou reativada à mão.

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

Quando a lista ativa mostra a base sem a VPN, o túnel não está ativo de todo e a rota nunca foi instalada, em vez de ter ficado obsoleta. Quando a ativação se queixa de que não existe nenhuma ligação de origem, a base com que estava emparelhada desapareceu, por isso repare primeiro a base ou o emparelhamento e pare de tentar a VPN outra vez.

Uma atualização pode deixar cair definições sem mensagem

Atualizar uma distribuição substitui o cliente e muitas vezes o seu plugin do NetworkManager, enquanto o perfil guardado mantém os nomes de propriedade com que foi escrito. Tudo o que o novo plugin já não reconhece é ignorado em silêncio. O perfil continua a ativar-se e o dispositivo continua a aparecer, mas a rota que antes vinha com ele já não vem.

Os ganchos escritos à mão também se deslocam. Um script que instalava uma rota num momento previsível da sequência antiga pode agora correr antes de a interface existir, ou depois de o cliente já ter esgotado o tempo.

Compare o perfil vivo com o plugin que realmente tem, e não com o comportamento de que se lembra. Se uma chave desapareceu da documentação, mova o trabalho para um script despachante ou para uma substituição suportada em vez de restaurar a propriedade antiga.

Três estados, três reparações diferentes

Decida em que estado está antes de tocar em coisa alguma, porque um reinício destrói as provas e a falha volta na mudança de rede seguinte.

Termine com uma consulta para um endereço público, uma para um endereço interno e uma consulta de nome. Se os endereços funcionam e o nome não, a falha restante é o âmbito do domínio no resolvedor, e a tabela de rotas nunca foi o problema.