O que realmente acontece quando você inicia uma VPN no Linux
Iniciar uma VPN no Linux cria uma interface, instala rotas e muda o resolvedor. Saber qual serviço possui cada etapa explica a maioria das falhas de configuração.
Pressione conectar e três coisas mudam numa máquina Linux: uma interface aparece, rotas são instaladas e o resolvedor começa a responder de forma diferente. A maioria das falhas de configuração vem de uma dessas três acontecer sem as outras, ou de dois programas discordarem sobre quem as possui. Entender a sequência explica a falha mais rápido do que ler a saída de log de um cliente.
Uma interface aparece antes de qualquer coisa funcionar
Um cliente de túnel abre uma interface virtual e entrega pacotes a ela. Um dispositivo TUN transporta pacotes IP, que é o que uma VPN roteada precisa; um dispositivo TAP transporta quadros Ethernet, que é o que um projeto em ponte precisa. O módulo do kernel fornece o dispositivo, e o cliente o possui enquanto a sessão durar.
A interface subir não é o mesmo que o túnel funcionar. Ela pode existir com um endereço enquanto o par está inalcançável, e por isso a lista de interfaces é a primeira verificação e não a última. Um dispositivo que se declara no ar descreve a visão do kernel sobre um link virtual, não a disposição do par em responder.
Deixe o modo de interface fornecido como está. Mudar um perfil TUN para TAP não transforma um servidor roteado em um em ponte, e normalmente produz uma conexão que se estabelece e não encaminha nada.
As rotas são instaladas por quem possui o túnel
As rotas são a segunda mudança, e sua propriedade importa mais do que seu conteúdo. Um perfil do NetworkManager, uma unidade systemd e um cliente executado à mão podem todos instalar rotas, e dois deles fazendo isso ao mesmo tempo produzem uma tabela que ninguém conseguirá explicar depois.
ip -br addr show ip route show ip -6 route show
Um perfil de túnel completo substitui a rota padrão; um perfil de túnel dividido adiciona rotas mais específicas e deixa a rota padrão como está. As duas são normais, e a segunda é a razão pela qual apagar uma rota padrão é um péssimo primeiro teste numa máquina que você administra remotamente. Removê-la também é a forma mais rápida de perder a sessão que você usa para corrigir o problema.
Leia a tabela em vez de supor. Uma rota mais específica ou uma regra de política pode enviar tráfego para o túnel enquanto a rota padrão ainda aponta para a interface física, o que parece contraditório até você ler a tabela inteira. Essa combinação é normal para túnel dividido e confusa para quem espera que uma linha descreva o projeto. Procure a rota que corresponde ao seu destino real, não a que corresponde ao diagrama.
O resolvedor muda de mãos
O DNS é a terceira mudança e a que mais provavelmente é gerenciada num lugar em que você não olhou. Num desktop, o NetworkManager pode enviar as configurações do resolvedor por conexão. Num sistema que usa systemd-resolved, as configurações são aplicadas por link e /etc/resolv.conf pode ser um stub ou um link simbólico em vez de um arquivo que você deveria editar.
resolvectl status readlink -f /etc/resolv.conf cat /etc/resolv.conf
Se uma edição manual no arquivo do resolvedor desaparece após uma reconexão, esse é o sinal para encontrar o componente que o mantém e mudar o perfil em vez disso. Editar o arquivo gerado é uma mudança que uma reconexão apagará.
Nomes privados geralmente precisam do resolvedor interno e dos domínios de busca fornecidos pelo operador. Substituir por um resolvedor público pode quebrar justamente o recurso para o qual a VPN existe, e o sintoma parece uma falha de roteamento e não de DNS. Teste o nome e o endereço separadamente, porque um funcionar e o outro falhar diz exatamente onde olhar. Essa única comparação economiza uma hora de depuração de rotas.
Um gerenciador por conexão
O formato do perfil decide qual programa pode usá-lo. Um perfil OpenVPN precisa de OpenVPN ou de um plugin compatível, e uma configuração WireGuard tem formato próprio com chaves de par e prefixos permitidos. Uma caixa de importação não traduz um no outro, diga o que disser a extensão do arquivo.
Escolha um gerenciador e deixe que ele seja dono da conexão. Levantar o mesmo túnel com duas ferramentas torna a tabela de rotas e o comportamento de reconexão ambíguos, e o segundo a iniciar costuma vencer de formas difíceis de reproduzir.
Instale os pacotes que a sua distribuição suporta e obtenha o perfil do operador. Trate-o como uma credencial, porque ele normalmente contém uma chave privada ou material equivalente, e guarde-o onde vivem os seus outros segredos. Um perfil deixado numa pasta de downloads é uma chave deixada sobre uma mesa.
O que verificar quando está no ar mas não funciona
Com a interface no ar e o cliente relatando sucesso, trabalhe para fora: a tabela de rotas seleciona o túnel para o destino, o resolvedor responde pelo nome privado e o lado remoto tem um caminho de volta. Cada um tem um comando separado e um dono separado.
nmcli connection show --active nmcli device status wg show
A referência do nmcli documenta os comandos de estado e de conexão se você precisar do conjunto completo. O que importa aqui é a distinção entre um perfil ativo e um dispositivo que transporta tráfego, porque os dois podem discordar.
Reconecte uma vez pelo mesmo gerenciador antes de considerar a configuração concluída, e verifique se o DNS ainda funciona após uma desconexão. Uma configuração que só funciona até a primeira mudança de rede não está concluída, ela está apenas funcionando neste momento.