Por que um cliente VPN na LAN do escritório perde todas as respostas

Um portátil está na /24 do escritório por Ethernet e também entra num servidor OpenVPN que vive nessa mesma /24. Um colega faz ping ao endereço do túnel; o pedido chega com clareza e não volta nada. O log do túnel está limpo e a navegação continua a funcionar, portanto o túnel é o suspeito errado. A validação de origem IPv4 na máquina que recebe descarta o pacote antes de algo o ler.

O descarte acontece antes de algo ler o pacote

A validação de origem faz uma pergunta sobre cada pacote recebido: se este host respondesse àquela origem, a resposta sairia pela interface por onde o pacote acabou de chegar? Quando a resposta é não, o núcleo descarta o pacote ao chegar. Nem um socket nem um caminho de encaminhamento o vê alguma vez, e é por isso que uma captura no túnel ainda regista um pedido que a aplicação nunca recebe.

O cliente aqui tem 10.66.0.9 no seu túnel, e o servidor OpenVPN responde em 192.168.80.10 dentro do prefixo do escritório. Um colega em 192.168.80.25 faz ping ao endereço do túnel, por isso o pedido atravessa a LAN, o servidor encaminha-o para o túnel, e ele chega à interface do túnel do cliente com um endereço de origem do escritório. Na tabela de rotas dessa máquina o prefixo do escritório pertence ao dispositivo Ethernet, não ao túnel. A validação compara a interface de chegada com a rota, encontra uma divergência e descarta o pacote, por isso o colega vê perda total enquanto os dois extremos relatam um túnel saudável.

A direção espelhada tem a mesma forma: quando o cliente inicia para o escritório, as respostas podem ser descartadas do lado do escritório pelo mesmo motivo. Uma correção verificada apenas numa direção costuma regressar como um segundo ticket.

Prove o modo em vigor antes de tocar em qualquer sysctl

Leia os valores efetivos em vez de confiar num padrão da distribuição, porque a definição por interface é só metade da decisão. O modo em vigor é o maior entre o valor da interface e o valor de all, por isso um zero na interface do túnel não significa nada enquanto all for um. A decisão do modo estrito é uma decisão de encaminhamento, por isso execute a pesquisa que o núcleo executa e compare a resposta com a interface por onde o pacote chegou de facto.

tcpdump -ni tun0 icmp and host 192.168.80.25
ip route get 192.168.80.25
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.tun0.rp_filter

Depois repita o ping enquanto observa o contador de erros. Um contador a subir ao lado de um pedido que a captura já mostra é a assinatura deste descarte, não de uma rota em falta. Ative o registo de pacotes marcianos enquanto está lá, para que o núcleo nomeie a origem e a interface que rejeitou. Juntos excluem a cifra, a firewall e um iroute em falta como explicações.

Anote a linha de base antes de mudar o que quer que seja: os dois valores, o dispositivo que a pesquisa escolheu e o contador que observou. É esse registo que lhe dirá depois se a mudança fez o que pensa.

O que cada modo de rp_filter aceita de facto

O núcleo expõe três valores por interface, e não são três matizes de uma mesma regra. Zero desativa a verificação. Um é estrito e exige que a origem seja encaminhada de volta pela interface de chegada. Dois é frouxo e exige apenas que exista alguma rota para a origem na tabela, para onde quer que aponte.

A linha que importa aqui é a frouxa, e o que continua a rejeitar. Uma origem falsificada que seja encaminhável em qualquer parte da sua tabela passa, enquanto uma origem sem qualquer rota continua a ser recusada. Num portátil é uma concessão estreita; num router que encaminha tráfego de outras pessoas é ampla. O modo pertence ao host, por isso o mesmo número tem peso diferente nos dois locais.

Que linha esta topologia precisa decorre da tabela e não do hábito. O pacote é legítimo e a sua origem é encaminhável, por isso o frouxo aceita-o e o estrito não. Nada no caso exige zero, e escolher zero removeria uma verificação que aqui não custa nada.

Escolha a mudança mais pequena que elimina a ambiguidade

O modo frouxo é a mudança mais pequena que serve, e é uma redução real do rigor, não um interruptor inofensivo. Existe uma opção melhor sempre que a topologia o permite: elimine a sobreposição e a ambiguidade desaparece.

Onde o prefixo do escritório só é necessário por Ethernet, retire-o das rotas que o perfil puxa e o endereço passa a ser alcançável por um único caminho. Quando os dois caminhos têm mesmo de coexistir, fixe a origem e o dispositivo com uma regra de política em vez de afrouxar a validação em cada interface. Isso mantém a filtragem estrita para todo o resto na máquina e documenta a exceção onde o próximo engenheiro a procurará.

Seja qual for o caminho que escolher, registe-o num drop-in de sysctl e não num comando vivo. Defina as chaves all e default em conjunto, para que uma reconexão não possa restaurar o modo estrito em silêncio.

# /etc/sysctl.d/99-rp-filter.conf
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.all.rp_filter = 2
sysctl --system

O que o modo frouxo abdica, e onde

O modo frouxo continua a rejeitar uma origem que nenhuma rota alcançaria, e deixa de rejeitar uma origem falsificada que por acaso é encaminhável. Num portátil é uma concessão estreita. Num dispositivo que encaminha tráfego que não possui, a mesma escolha é muito mais ampla. Por isso a mesma definição tem dois significados muito diferentes consoante o local onde corre.

Desligar a verificação por completo, num host que encaminha tráfego por outras pessoas, é a única reparação a evitar. Zero deita fora a validação que o modo frouxo preserva com cuidado. Se o host encaminha por outros, defenda antes a opção da regra de política da secção anterior.

Deixe uma nota que nomeie as duas interfaces, o prefixo sobreposto e o teste exato que agora tem sucesso. Isso é mais útil ao próximo engenheiro do que uma linha a dizer que a filtragem foi ajustada.