O pacote UDP chega à interface VPN e não é entregue ao processo

Question

Eu tenho um servidor X (45.55.245.182) que está conectado ao servidor Y pela VPN. A interface VPN no X é tap0 com ip 10.200.0.2; A interface VPN em Y é tap0 com ip 10.200.0.1. Eu corro netcat no servidor Y para ouvir UDP 35000:

nc -lu 10.200.0.1 35000

No servidor X, os pacotes da porta 35000 são DNAT com a seguinte regra do iptables:

iptables -t nat -A PREROUTING -p udp --dport 35000 -j DNAT --to-destination 10.200.0.1

A execução do tcpdump no servidor Y em sua interface tap0 mostra os pacotes como esperado:

11:54:44.000610 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.200.0.1 tell 10.200.0.2, length 28
11:54:44.000638 ARP, Ethernet (len 6), IPv4 (len 4), Reply 10.200.0.1 is-at fa:0f:00:1a:57:59 (oui Unknown), length 28
11:54:44.154702 IP (tos 0x8, ttl 47, id 52840, offset 0, flags [DF], proto UDP (17), length 34)
    hotnet-213-57-17-185.hotnet.net.il.24740 > 10.200.0.1.35000: [udp sum ok] UDP, length 6

Veja o diagrama que mostra a configuração:

No entanto, não consigo ver esse netcat de escuta no servidor Y obter os dados (nada ecoa na tela de Y quando eu pressiono entrar no cliente).

O que pode ser um problema?

    

Answer 1

A explicação mais provável para o seu problema é o rp_filter , que é ativado por padrão. O servidor Y recebe o pacote em tap0 , mas de acordo com sua tabela de roteamento, o pacote deveria chegar em uma interface diferente (provavelmente eth0 ).

Se este for realmente o seu problema, a solução é desativar rp_filter para tap0 . Primeiro, tente isso para ver se o problema desaparece:

echo 0 > /proc/sys/net/ipv4/conf/tap0/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter

Depois de obter o Servidor Y para aceitar o pacote. Você pode enfrentar um problema com o cliente que está rejeitando a resposta por ter vindo do endereço IP incorreto. Existem soluções diferentes para esse problema.

Se você escolher usar SNAT no servidor X, isso resolverá os dois problemas. Mas há duas ressalvas.

• O servidor Y não saberá o endereço IP do cliente.
• As respostas para o cliente precisarão percorrer o longo caminho do servidor X para voltar ao cliente, o que pode ser menos eficiente do que direcioná-las diretamente de volta ao cliente.

Answer 2

Definindo o endereço de origem para 10.200.0.2 a partir do qual o pacote chegou resolveu o problema:

iptables -t nat -A POSTROUTING -p udp --dport 35000 -j SNAT --to 10.200.0.2