Faça o encaminhamento IPv4 persistir após reiniciar um gateway VPN

Fazer ping ao gateway funciona e chegar a qualquer coisa atrás dele não, e essa é a forma de um problema de encaminhamento e não de um problema de túnel. A entrega local ao gateway prova que o túnel subiu e que a atribuição de endereços funcionou; não diz nada sobre se o kernel deixará passar um pacote de uma interface para outra. Antes de tocar em qualquer sysctl, confirme que a máquina se destina a encaminhar este tráfego e localize o contexto de rede que contém a interface virada para o cliente. Depois leia o valor ali, e não onde o último guia que leu olhou por acaso.

Chegar ao gateway não é o mesmo que encaminhar

Dentro do kernel ocorrem duas decisões separadas. A entrega a um endereço local termina a viagem do pacote; o encaminhamento volta a enviá-lo através de outra interface, e essa segunda decisão é regida por espaço de nomes de rede. Um gateway pode estar perfeitamente acessível enquanto o encaminhamento está desligado, e a partir de um prompt ping as duas falhas parecem idênticas.

Anote por que interface chega o pacote do cliente e por que interface sai o caminho seguinte. Ambas pertencem a um só espaço de nomes, e é esse espaço de nomes que contém a configuração que importa.

Leia o valor onde os pacotes estão realmente

Num gateway que encaminha no espaço de nomes do anfitrião, um só comando responde à pergunta: sysctl net.ipv4.ip_forward. Quando o caminho de entrada e o seguinte vivem num espaço de nomes com nome, pergunte a esse espaço de nomes: ip netns exec vpn-gw sysctl net.ipv4.ip_forward. O valor do anfitrião não substitui o valor do espaço de nomes, e um um no anfitrião não é prova de nada.

Nem todos os contextos de encaminhamento têm um rótulo que possa passar a ip netns. Os ambientes de execução de contentores e os serviços criam espaços de nomes que nunca são registados com um nome amigável, e para esses usa as ferramentas de inspeção do ambiente. Substitua vpn-gw pelo nome real, ou pelo mecanismo do ambiente que alcança o mesmo contexto, e deixe de adivinhar ao nível do anfitrião.

Dê um único proprietário à configuração

Num gateway anfitrião convencional com systemd, a forma duradoura é um ficheiro drop-in com um nome escolhido pelo administrador, como /etc/sysctl.d/60-vpn-forwarding.conf, que contenha net.ipv4.ip_forward = 1. Escreva o ficheiro e depois carregue esse ficheiro concreto para que o estado ativo também mude: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, seguido de uma leitura de retorno. O nome do ficheiro é um exemplo e não um caminho VPN reservado, e o número inicial importa porque os ficheiros ordenados mais tarde ganham.

A precedência é onde a persistência se quebra em silêncio. Verifique tanto o carregador da distribuição como o seu próprio drop-in, porque procps sysctl --system também lê /etc/sysctl.conf no fim, enquanto a ordem sysctl.d do systemd é uma sequência completamente diferente. Uma atribuição posterior pode repor a mesma chave de imediato, deixando o seu ficheiro correto e o valor efetivo errado. Não substitua um ficheiro de administrador existente para ganhar essa discussão; encontre o proprietário e altere ali.

Um espaço de nomes criado após o arranque não é de todo regido por um drop-in do anfitrião. A sua configuração pertence a quem o cria, seja o ambiente de execução de contentores ou a unidade de aprovisionamento do espaço de nomes. Dar a um contentor amplos privilégios de anfitrião para contornar a pergunta é uma troca pior do que passar dez minutos a identificar o proprietário certo.

Saiba quanto custa o interruptor antes de o acionar

ip_forward não é um booleano inofensivo. A documentação do kernel observa que alterá-lo reinicia vários outros parâmetros IPv4 para os valores predefinidos do anfitrião ou do router, pelo que uma troca de diagnóstico pode deitar fora afinações feitas noutro lugar e nunca o mencionar. Trate-o como uma alteração de configuração com efeitos secundários e não como uma sonda que se possa executar de ânimo leve.

Isso também exclui ligá-lo e desligá-lo sempre que um cliente não alcança um anfitrião. Se o valor já é um, a falha está noutro ponto do caminho, e reescrever a mesma chave pela terceira vez não o moverá.

Prove a persistência e depois teste o resto do caminho

Leia o valor de volta em quatro momentos: logo após a alteração, depois de aparecer a interface VPN, após uma reconexão e após um reinício planeado. Um valor que reverte em qualquer desses pontos tem um segundo proprietário, e mais uma escrita pontual só o esconde até ao próximo reinício.

O encaminhamento ativado ainda deixa três coisas por verificar. O cliente precisa de uma rota até ao destino, o gateway precisa de uma rota seguinte mais permissão para a usar, e o destino precisa de um caminho de retorno até ao endereço do túnel do cliente. Uma LAN privada encaminhada não precisa de NAT automaticamente, por isso não acrescente masquerading antes de saber qual das três falta, e teste a partir do cliente previsto e não do próprio gateway, porque um pedido originado no gateway nunca toca no caminho de encaminhamento que acabou de ativar. O IPv6 tem a sua própria política de encaminhamento e de rotas, por isso um teste IPv4 que funcione não diz nada sobre ele.

Mantenha juntos no runbook o caminho do drop-in, o proprietário do espaço de nomes e o comando de leitura de retorno. Quem pegar nisto a seguir deve poder ler o valor, ver quem o possui e decidir num minuto se o problema é a persistência ou o resto do caminho.