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

Почему эта конфигурация iptables отбрасывает дублированные пакеты UDP 10 из 11 раз?

Я пытаюсь дублировать UDP-пакеты, поступающие на порт 50007 на Интернет-адрес с устройств в локальной сети NAT (192.168.12.0/24), с целью их локальной обработки (на 192.168.12.1:50006).

На 38 из 40 моих устройств следующие таблицы iptables mangle и nat делают свое дело - порт 50006 принимает пакеты со скоростью 12 в минуту - 1 в 5 секунд.

Однако на двух устройствах, конфигурация которых идентична конфигурации другого 38, порт 50006 принимает пакеты со скоростью 1/11 от передаваемой скорости, например 1 пакет каждые 55 секунд - остальные 10 из 11 пакетов предположительно отбрасываются.

Порт 50006 прослушивается сценарием socat:

socat UDP-RECVFROM:50006,fork "EXEC:handler-script"

Сценарий обработчика возвращается в течение 1 секунды, и никаких изменений в скорости получения не наблюдается, когда сценарий изменяется на бездействие.

Одно из двух неисправных устройств самопроизвольно исправилось, и порт 50006 начал принимать пакеты со скоростью передачи.

Оставшееся устройство по-прежнему принимает пакеты только с 1/11 от передаваемой скорости, хотя tcpdump показывает исходные пакеты, прибывающие с полной скоростью.

$ sudo iptables -L -t mangle
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
TEE        udp  --  192.168.12.0/24      anywhere             udp dpt:50007 TEE gw:10.0.0.1

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
$ sudo iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
DNAT       udp  --  192.168.12.0/24      anywhere             udp dpt:50007 to:192.168.12.1:50006

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  all  --  192.168.12.0/24      anywhere            

Одна странность с неисправным узлом заключается в том, что tcpdump показывает дублированный пакет с исходным адресом источника и адресом источника, соответствующим IP-адресу локального узла на восходящей линии связи. На рабочих узлах tcpdump показывает только исходный (предварительно замаскированный) пакет.

$ sudo tcpdump -i eth2 port 50007

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes
03:56:41.851719 IP 192.168.12.66.4097 > example.com.50007: UDP, length 216
03:56:41.851996 IP 10.0.0.8.4097 > example.com.50007: UDP, length 216`

ЦП на неисправном узле выглядит номинальным, и почти наверняка нет различий в конфигурации между функционирующим и неисправным узлами. Однако узлы развернуты в разных локальных сетях.

Возникает вопрос: что могло быть причиной того, что неисправный узел отбрасывает 10 из каждых 11 пакетов? Второй вопрос: почему tcpdump по-другому ведет себя на этом узле и показывает замаскированный пакет, а также исходный пакет.

Любые предложения о том, как я могу отладить эту проблему?

Хорошо, оказывается, объяснение было предоставлено этим вопросом и ответом:

Почему iptables не отбрасывает пакеты?

Оказывается, эта установка имела особенно хорошее соединение Wi-Fi между устройством ниже по потоку и маршрутизатором, и запись ip_conntrack была создана до того, как было установлено правило DNAT, что привело к обстоятельствам, которые применялись в упомянутых вопросах и ответах.

Я смог подтвердить это, отключив точку доступа на маршрутизаторе на 185 секунд (на 5 секунд дольше, чем тайм-аут входа conntrack по умолчанию), а затем снова включил его. Как только я это сделал, пакеты пошли с ожидаемой скоростью.

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