Encaminhe apenas a porta 25 para o túnel, não o host

Quatro coisas precisam de estar alinhadas antes de um host Linux enviar apenas o seu próprio SMTP pelo túnel: uma rota numa tabela dedicada, uma regra de política que seleciona o tráfego, um endereço de origem que o peer aceite e um caminho de retorno que sobreviva à assimetria. Cada uma é uma configuração separada com o seu próprio modo de falha. A ordem abaixo é a que faz uma falha apontar para a peça que está realmente errada. É um trabalho de encaminhamento específico de porta, não um pedido de uma rota predefinida de VPN.

Uma regra de porta não é uma rota predefinida

Uma regra que associa o TCP gerado localmente à porta de destino 25 envia esse tráfego para uma tabela que você nomeia. A regra não cria nada por si só: seleciona, e a tabela tem de conter uma rota capaz de transportar o pacote. Combinar as duas cobre apenas a direção de saída de um protocolo, pelo que o encaminhamento para outros hosts, as ligações de correio de entrada e o IPv6 ficam fora do arranjo. Chamar-lhe política específica de porta em vez de predefinição de VPN mantém essa fronteira honesta.

Duas definições do wg-quick são pré-requisitos, não parte da política. AllowedIPs = 0.0.0.0/0 permite que o peer transporte destinos IPv4 arbitrários, e Table = off impede o wg-quick de instalar a sua própria rota predefinida para esse prefixo. Não misture estas instruções com um gestor que aplica a sua própria política de rotas, porque os dois vão discordar sobre quem é dono da tabela principal.

Escreva a rota, o seletor e a guarda

Escolha um número de tabela e um par de prioridades que nada mais use, e depois aplique a rota, o seletor e a guarda nessa ordem. Os números abaixo são exemplos, não valores reservados:

ip -4 route add default dev wg0 src 10.77.0.2 table 51825
ip -4 rule add priority 10000 iif lo ipproto tcp dport 25 lookup 51825
ip -4 rule add priority 10001 iif lo ipproto tcp dport 25 unreachable

iif lo limita a regra ao tráfego com origem local, e ipproto tcp dport 25 identifica a direção da ligação; a referência do ip-rule documenta ambos os seletores. Existem nos kernels e nas versões de iproute2 atuais, e num sistema mais antigo a regra é rejeitada de imediato, o que é uma falha mais clara do que uma regra que carrega e não corresponde a nada.

A regra unreachable na prioridade seguinte é a guarda. Sem ela, uma rota ausente na tabela 51825 recai na rota predefinida comum, e o correio sai pela ligação física durante uma falha do túnel, que é exatamente o caso que a política queria evitar.

O endereço de origem tem de concordar

A preferência src da rota apenas preenche uma origem para as ligações que não tenham vinculado uma própria. Não é tradução e não anula uma ligação explícita, pelo que um daemon vinculado ao endereço físico continua a enviar a partir desse endereço. Se é isto que encontra, altere a definição do próprio daemon ou conceba uma política de tradução deliberada, porque um masquerade global tardio é outra solução com outras consequências.

No gateway, o peer do cliente tem de autorizar a origem que realmente recebe, ou seja, 10.77.0.2/32 em vez de um prefixo de destino largo. Copiar o 0.0.0.0/0 do cliente para cada peer do gateway confunde qual peer possui qual tráfego. O gateway também precisa de encaminhamento, de uma política de firewall que permita o fluxo e de um caminho de retorno, incluindo tradução de saída quando a parte superior não consegue encaminhar um endereço privado do túnel.

Verifique o caminho de retorno e depois a persistência

Leia as consultas antes de confiar em qualquer coisa, porque mostram que tabela e que origem cada direção recebe. Um destino na porta 25 e o mesmo destino na porta 443 bastam:

ip -4 route get 198.51.100.25 ipproto tcp dport 25
ip -4 route get 198.51.100.25 ipproto tcp dport 443

A primeira consulta deve indicar wg0 e a origem pretendida, e a segunda deve manter a ligação ascendente comum. Quando a aplicação vincula o seu próprio endereço, acrescente from com esse endereço à consulta. Uma direção de resposta que chega a wg0 e depois é descartada localmente aponta para a filtragem de caminho inverso IPv4, porque uma regra apenas para a porta de saída não faz a consulta inversa escolher o túnel.

Onde o encaminhamento assimétrico é autorizado, o modo tolerante limitado à interface através de net.ipv4.conf.wg0.rp_filter=2 pode ser adequado, e vale a pena verificar primeiro o máximo efetivo dos valores all e da interface. Não desative a validação globalmente como atalho. Depois entregue a tabela, as prioridades e a guarda a quem possui a configuração, e abra novas ligações após uma reconexão para confirmar que a seleção ainda se mantém. Tenha em conta que as respostas de um ouvinte SMTP local transportam a porta de origem 25 e não a porta de destino 25, o que é uma questão de política separada.