VPN instalada no Windows, Linux inicia sem rede: o que verificar

Instala uma VPN no Windows, reinicia no Linux e a ligação por cabo está morta. A história óbvia escreve-se sozinha: a VPN deixou algo para trás. A história está errada, porque os dois arranques executam núcleos separados com controladores separados, tabelas de encaminhamento separadas e resolvedores separados. Um filtro de rede do Windows não é executado dentro do Linux, pelo que a falha está na pilha do Linux ou em algo que ambos os arranques partilham realmente, como o hardware, o firmware ou o encaminhador.

O sintoma e a conclusão errada

A parte útil da observação é o momento: a falha apareceu depois de uma alteração. A parte inútil é o salto causal para a VPN do Windows, que não pode ser executada no outro sistema operativo. Separar as duas coisas é todo o trabalho. Anote a cronologia antes de tocar num cabo.

O que os dois arranques partilham é o adaptador físico, o cabo, a porta do comutador e tudo o que está a montante. São variáveis partilhadas reais e merecem uma verificação depois de inspecionar a pilha do Linux.

Capture a pilha do Linux com quatro comandos

Comece em modo de apenas leitura e capture o estado antes de alterar qualquer coisa: ip -br link para a presença de interfaces, ip -br address para os endereços, ip route para as rotas IPv4 e ip -6 route onde o IPv6 for importante. A referência da ferramenta ip distingue estes objetos, e uma interface na lista não prova que tenha um endereço funcional ou uma rota utilizável.

Guarde a saída num ficheiro para a comparar mais tarde com um arranque que funcione. Uma captura que não consegue reproduzir é apenas uma memória de um estado.

É ligação, endereço, rota ou nome?

Quatro falhas diferentes parecem iguais no navegador. O dispositivo pode faltar por completo, existir sem portadora, estar ligado mas sem o endereço esperado, ou ter endereço sem rota até ao destino. A falha da resolução de nomes enquanto os endereços em bruto funcionam é um quinto caso, e pertence ao resolvedor e não ao controlador.

Cada caso aponta para um trabalho diferente: controlador ou firmware para um dispositivo ausente, cablagem ou comutador quando não há portadora, DHCP ou configuração estática para um endereço em falta, e encaminhamento ou política para um caminho em falta. Um problema de resolvedor aponta para systemd-resolved, NetworkManager ou uma configuração DNS local.

Verifique se a instalação de Linux tem a sua própria VPN ou uma configuração de firewall persistente. Um túnel local ou um conjunto de regras nftables é um responsável do lado do Linux, e é muito mais provável que explique a falha do que um programa do Windows que não está a correr.

Depois compare a transição de arranque

O Windows Fast Startup é um encerramento híbrido que mantém o estado da sessão do núcleo em vez de realizar um arranque completo. A documentação da Microsoft sobre estados de energia distingue-o de um reinício e de um encerramento completo, e por isso o mesmo hardware pode comportar-se de forma diferente nas duas transições.

Se a falha depender da passagem de um sistema operativo para o outro, compare um reinício documentado ou um encerramento completo com o caminho normal, depois de guardar o trabalho. Um resultado que segue a transição justifica examinar o estado do controlador, do dispositivo ou do firmware, e não prova por si só que o Fast Startup causou uma falha concreta do adaptador.

Anote que sistema operativo usou o adaptador por último, o tipo de transição, o estado da ligação no Linux e a primeira operação que falhou. Uma diferença reproduzível entre arranque a frio e transição a quente vale muito mais do que remover o software VPN das duas instalações sem saber que pilha se quebrou.

O que não alterar

Não reinicie as duas pilhas de rede como primeiro passo. Isso destrói a comparação e muitas vezes não corrige nada, porque o responsável real nunca foi identificado. Não reinstale a VPN do Windows para reparar o Linux, e não altere definições do firmware ao acaso só porque uma transição de arranque se correlacionou com uma falha.

A referência da ferramenta ip documenta os objetos de ligação, endereço e rota usados acima. Leia primeiro o lado do Linux, conserve a captura e só depois decida se a camada de hardware partilhada merece investigação.