Por que net.ipv4.conf.default.forwarding deixa tun0 em paz

Você definiu net.ipv4.conf.default.forwarding=1, reiniciou a VPN, e o túnel continua descartando pacotes que o gateway deveria rotear. A configuração parece correta no arquivo, e a interface ainda informa que o encaminhamento está desativado. Nada está quebrado: você alterou o valor que as interfaces futuras herdam, não o que o túnel ativo usa.

Percorra isso no host que possui o túnel, no namespace de rede onde o túnel realmente existe. Um contêiner ou um namespace de rede pode deter a interface enquanto o host mostra números diferentes.

Leia os três valores juntos

Comece comparando o interruptor de todo o gateway, o modelo para as novas interfaces e a interface que lhe importa. Substitua tun0 pela interface de entrada real, e leia também a interface de retorno, porque o encaminhamento é avaliado no ponto em que o pacote chega.

sysctl net.ipv4.ip_forward
sysctl net.ipv4.conf.default.forwarding
sysctl net.ipv4.conf.tun0.forwarding

Um resultado comum é ip_forward = 0, default.forwarding = 1 e tun0.forwarding = 0. Os dois primeiros discordam sobre o papel do host, e o terceiro mostra o que a interface realmente faz. Essa combinação é consistente com um host que nunca foi configurado como roteador, apenas recebeu um valor de modelo. Os três números não se contradizem; eles respondem a três perguntas diferentes. Escrever o valor do modelo também não decide o papel do host.

Por que é o interruptor global que se move

net.ipv4.ip_forward é o controle de todo o gateway. Alterá-lo atualiza as configurações de encaminhamento por interface como parte da mesma operação, por isso uma única escrita pode fazer um túnel existente começar a encaminhar. default.forwarding só semeia as interfaces inicializadas depois, então um túnel que já existia mantém o valor com que nasceu.

A documentação do kernel marca ip_forward como especial por um motivo relacionado: alterá-lo redefine um conjunto de outros parâmetros IPv4 para os padrões de host ou roteador. Isso o torna uma ferramenta grosseira. Defini-lo uma vez como parte do estabelecimento do papel de gateway é aceitável; alterná-lo repetidamente como truque de depuração pode reescrever silenciosamente uma configuração que você levou tempo para acertar.

Os valores por interface também existem por um motivo. Um gateway gerenciado de propósito pode manter o encaminhamento desligado numa interface que nunca deveria rotear, mesmo enquanto o host encaminha noutro lugar. Por isso é importante ler a interface ativa e por isso o valor global sozinho não é a resposta completa. Leia essa exceção como uma decisão deliberada e anote por que aquela interface é diferente. Caso contrário, o próximo engenheiro vai "consertá-la" com toda a boa vontade.

Torne a configuração permanente no lugar certo

Um sysctl -w pontual bem-sucedido prova que o kernel aceita o valor. Ele não sobrevive a um reinício, e não sobrevive a um gerenciador de rede que reaplica a sua própria ideia da configuração da interface ao reconectar. Coloque o papel de gateway no arquivo de configuração do sysctl ou no gerenciador de rede que possui o host, e depois reinicie o serviço que o aplica.

A ordem importa com túneis. Se o gerenciador cria a interface na inicialização e aplica o encaminhamento depois, a interface pode herdar o padrão antigo. Reiniciar um serviço que recria o túnel também é um evento de criação, e é fácil não perceber quando a unidade parece saudável. Verifique a sequência, não apenas o conteúdo final do arquivo.

Leia novamente os mesmos três valores depois que a VPN se reconectar e mais uma vez depois de um reinício. Um túnel recém-criado é uma interface nova, e uma interface nova assume o padrão em vigor no momento da criação. Se os números mudarem entre esses eventos, a configuração está sendo aplicada por algo que você ainda não identificou.

Não conserte isso com a ferramenta errada

Quando o encaminhamento parecia quebrado, a tentação é limpar o firewall ou adicionar masquerading. Nenhum dos dois trata do interruptor de encaminhamento. O estado de encaminhamento, a permissão para encaminhar, uma rota para o destino e um caminho de retorno são quatro requisitos separados, e só o primeiro é o sysctl.

Teste também com o fluxo correto. Um pedido feito no próprio gateway não exercita o encaminhamento de forma alguma; é tráfego gerado localmente. A questão é se um pacote que chega de um cliente VPN ou de um host da LAN é aceito e roteado adiante, então o teste tem de se originar atrás do gateway.

Mantenha o caso IPv6 separado

Aqui tudo é IPv4. O encaminhamento IPv6, os anúncios de router e o comportamento do accept_ra têm os seus próprios controles, e copiar um caminho ipv4 para uma configuração ipv6 produz um arquivo que parece plausível e não faz nada de útil. Um gateway de pilha dupla precisa dos dois conjuntos configurados de propósito.

Uma última verificação: depois que os valores coincidirem, confirme que a rota do túnel é selecionada para o destino e que o caminho de resposta existe. O encaminhamento ativado numa interface sem rota continua a ser um buraco negro, e essa falha parece igual do lado do cliente.