Um peer VPN faz ping em outras interfaces porque elas são locais

Um cliente WireGuard conecta e faz ping em um endereço em uma interface completamente diferente, e a resposta chega. As capturas mostram a requisição apenas no túnel. Nada está quebrado, e a configuração de encaminhamento cuidadosamente desativada não tem nada a ver com isso. Esta é uma comparação entre dois caminhos que parecem iguais em um diagrama e são completamente diferentes no kernel.

Um caminho encaminha pacotes por outra pessoa; o outro os entrega ao próprio host.

Um pacote endereçado ao host fica no host

O cliente remoto envia um pacote IP para um endereço que o host possui. O roteamento faz uma pergunta sobre esse pacote: este destino é local? Todo endereço que o host mantém aparece na tabela de roteamento local, e essa tabela é consultada antes da principal, então o pacote vai para a pilha do próprio host em vez de sair por outra interface. A resposta é gerada localmente, e ela volta pelo túnel porque foi de lá que veio a consulta.

Esse é todo o mecanismo. Nenhum encaminhamento ocorre, nenhuma mudança de estado da interface está envolvida, e o endereço em questão não precisa ser alcançável de nenhum outro lugar.

Por que ip_forward não se aplica

O encaminhamento governa pacotes que precisam sair por uma interface diferente daquela pela qual chegaram. Um ping para o próprio host nunca segue esse caminho: o pacote é consumido localmente e a resposta é gerada localmente. Por isso, definir net.ipv4.ip_forward=0 não muda nada aqui, e uma regra na cadeia de encaminhamento nunca vê esse tráfego. O controle correto fica no caminho de entrada, limitado pela interface de entrada ou pela origem.

Por isso, desativar o encaminhamento e presumir que o host está isolado produz uma falsa sensação de segurança.

Leia a tabela local que decidiu

ip rule show normalmente informa uma regra com prioridade zero que envia todas as consultas primeiro para a tabela local, e ip route show table local lista os endereços do próprio host com escopo local. Essa tabela inclui endereços em interfaces administrativamente desligadas mas ainda configuradas. Endereços IPv4 atribuídos estaticamente costumam sobreviver a uma queda de link, e é assim que um ping para uma bridge desligada ainda pode funcionar e surpreender o operador.

O IPv6 discorda exatamente neste ponto. Seus endereços normalmente são retirados quando o link cai, a menos que keep_addr_on_down esteja definido. Compare as famílias em vez de presumir que uma regra cobre as duas.

A que um peer realmente chega

Uma resposta do próprio endereço do roteador em um segmento não diz nada sobre as máquinas atrás desse segmento. O peer não consegue alcançar um host atrás da outra interface por este caminho; ele só alcança endereços que o próprio roteador possui. Testar um serviço em um host de LAN separado, em vez de fazer ping no endereço do roteador, é o que estabelece se o encaminhamento é permitido.

Restringir um peer aos serviços vinculados ao endereço do túnel é uma questão de política de entrada. Permita o serviço desejado na interface do túnel e restrinja as origens que podem usá-lo, porque o pacote realmente chega ali.

Verifique também os endereços que você pretendia retirar. Remover um endereço de uma interface é mais confiável do que empilhar regras de firewall sobre um endereço obsoleto.