Início / server / Perguntas / 710137
Accepted
rlib
Asked: 2015-08-02 01:24:26 +0800 CST

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

  • 772

Eu tenho um servidor X (45.55.245.182) que está conectado ao servidor Y por 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'ed 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 de tcpdump no servidor Y em sua interface tap0 mostra que os pacotes vêm conforme o 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 mostrando a configuração: insira a descrição da imagem aqui

Porém, não consigo ver aquele netcat escutando no servidor Y obter os dados (nada ecoa na tela de Y quando pressiono enter no cliente).

O que pode ser um problema?

iptables

2 respostas

  1. Best Answer

    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 esse for realmente o seu problema, a solução é desativar rp_filtero 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

    Assim que você conseguir que o Servidor Y aceite o pacote. Você pode enfrentar um problema com o cliente rejeitando a resposta devido ao endereço IP errado. Existem diferentes soluções para esse problema.

    Se você optar por usar SNATno servidor X, resolverá os dois problemas. Mas há duas ressalvas.

    • O servidor Y não saberá o endereço IP do cliente.
    • As respostas ao cliente terão que passar pelo servidor X para voltar ao cliente, o que pode ser menos eficiente do que encaminhá-las diretamente de volta ao cliente.
    • 2

  2. Definir o endereço de origem para 10.200.0.2 de onde realmente o pacote chegou resolveu o problema:

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

relate perguntas