Назад | Перейти на главную страницу

UDP-пакет поступает на интерфейс VPN и не доставляется процессу

У меня есть сервер X (45.55.245.182), который подключен к серверу Y через VPN. Интерфейс VPN на X - tap0 с ip 10.200.0.2; Интерфейс VPN на Y - tap0 с ip 10.200.0.1. Я запускаю netcat на сервере Y, чтобы слушать UDP 35000:

nc -lu 10.200.0.1 35000

На сервере X пакеты порта 35000 подвергаются DNAT-обработке по следующему правилу iptables:

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

Запуск tcpdump на сервере Y на его интерфейсе tap0 показывает, что пакеты приходят, как ожидалось:

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

См. Схему, показывающую настройку:

Однако я не могу видеть, что прослушивающий netcat на сервере Y получает данные (на экране Y ничего не отображается, когда я нажимаю клавишу ввода на клиенте).

Что может быть проблемой?

Наиболее вероятным объяснением вашей проблемы является rp_filter, который включен по умолчанию. Сервер Y получает пакет на tap0, но согласно его таблице маршрутизации пакет должен был прибыть на другой интерфейс (вероятно, eth0).

Если это действительно ваша проблема, то решение - отключить rp_filter для tap0. Сначала попробуйте это, чтобы увидеть, исчезнет ли проблема:

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

Как только вы заставите сервер Y принять пакет. Вы можете столкнуться с проблемой, когда клиент отклоняет ответ из-за того, что он пришел с неправильного IP-адреса. Есть разные решения к этой проблеме.

Если вы решите использовать SNAT на сервере X это решит обе проблемы. Но есть два предостережения.

  • Сервер Y не знает IP-адрес клиента.
  • Ответы клиенту должны пройти долгий путь через сервер X, чтобы вернуться к клиенту, что может быть менее эффективным, чем их маршрутизация напрямую обратно клиенту.

Установка адреса источника на 10.200.0.2, с которого фактически пришел пакет, решила проблему:

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