Linux iptables UDP port redirect

[synclpz]

Добрый день господа.

 

Есть проблема следующего сорта - перенаправить SNMP-трапы с порта 162 на 2500 дабы нерутовый сервис мог их ловить и выполнять некую бизнес-логику.

 

Сейчас это решено простым правилом iptables:

 

iptables -t nat -A PREROUTING -i eth0 -p udp --dport 162 -j REDIRECT --to-port 2500

 

Однако, есть проблема: часть пакетов не попадает на это правило и не редиректится.

Все трапы идут с одного IP, есть подозрение, что шалит conntrack.

 

Если добавить в

-t mangle

правило

-j LOG

- то все пакеты видно. А в

-t nat

- нет.

 

Также пробовал делать -j DNAT на 127.0.0.1:2500 с тем же эффектом.

 

Подскажите, пожалуйста, что я делаю не так?

 

Спасибо!

[[anp/hsw]]

1. Ну если между mangle и NAT пакеты теряются, то видимо у вас там есть правила, под которые эти пакеты попадают, так что покажите весь листинг.

2. Не знаю, как сейчас, а раньше таргет 127.0.0.1 в цели DNAT не благославлялся как раз из-за неявного поведения conntrack, т.е. ваше правило по-идее должно выглядеть так: iptables -t nat -A PREROUTING -d $MY_IP -p udp --dport 162 -j DNAT --to $MY_IP:2500

[synclpz]

Больше никаких правил нет, в том-то и дело :)

 

Я просто прочитал на netfilter.org о таблице nat:

 

This table is slightly different from the `filter' table, in that only the first packet of a new connection will traverse the table: the result of this traversal is then applied to all future packets in the same connection.

 

Может ли быть, что он сначала применяет правила для "новых" пакетов (типа трекает UDP-соединение), а потому почему-то не применяет для последующих? Пример: делал `tcpdump port 162`, получил в конце:

 

53595 packets captured

 

потом сделал iptables -vL -t nat получил:

 

Chain PREROUTING (policy ACCEPT 768 packets, 91701 bytes)
pkts bytes target     prot opt in     out     source               destination         
52387 6548K REDIRECT   udp  --  eth0   any     anywhere             anywhere            udp dpt:snmptrap redir ports 2500 

Chain POSTROUTING (policy ACCEPT 81 packets, 5144 bytes)
pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 81 packets, 5144 bytes)
pkts bytes target     prot opt in     out     source               destination

 

Итого 52387 пакетов...

 

Кстати, может кто подскажет как поймать tcpdump-ом редиректенные на новый порт пакеты?

[srg555]

повесьте какой-нибудь IP на лупбэк типа:

ifconfig lo:0 10.1.1.1 netmask 255.255.255.255

после чего делайте DNAT на этот адрес. на 127.0.0.1 в современных linux, к сожаленью, нельзя

[orlik]

Простите за тупой вопрос, а может переписать сервис чтоб она слушала на 16 порту ,но понижала свои привилегии после запуска ? 10 строчек кода, не более

Ну или как вариант переконфигурить того кто шлет эти пакетики, чтоб слал на нужный порт. Тем более , что сами говорите, все пакеты от одного источника

[srg555]

Простите за тупой вопрос, а может переписать сервис чтоб она слушала на 16 порту ,но понижала свои привилегии после запуска ? 10 строчек кода, не более

Ну или как вариант переконфигурить того кто шлет эти пакетики, чтоб слал на нужный порт. Тем более , что сами говорите, все пакеты от одного источника

 

В общем случае и то и то может быть невозможным. Да и всякие понижения привилегий приведут к геморрою с кроссплатформенностью

[st_re]

IP источника в пакетах нужно сохранять ? А то может того, неткатом развернуть куда надо ?

[synclpz]

@srg555, сделал. Буду тестировать на потери. Как посмотреть tcpdump-ом обработанные правилами пакеты так и не понимаю. На eth0 на 162-м порту все вижу, а на своем 2500 - нет.

 

@orlik, не получится, это JBoss и EE приложение на нем. Как вариант переконфигурить - уже сделали. Но причину хочется найти :)

 

PS: Последнее мое сообщение на сегодня, далее форум рубит, ибо только зарегистрировался.

[srg555]

IP источника в пакетах нужно сохранять ? А то может того, неткатом развернуть куда надо ?

 

фишки с лупбэком достаточно будет, проверено, инфа 146%

Edited August 20, 2013 by srg555

[srg555]

Как посмотреть tcpdump-ом обработанные правилами пакеты так и не понимаю.

 

Никак не посмотреть. tcpdump показывает реальный трафик, а не извращённый iptables-ом

Тестировать на потери можно путём снятия tcpdump-а с реального интерфейса на 162 порту и счётчиком snmp-трапов в самом приложении.

 

Если потери есть, то 99.99999999% не по вине iptables, а по вине java(не успевает выгребать из буфера)

 

это JBoss и EE приложение на нем.

 

можно выдать capability CAP_NET_BIND_SERVICE самой java(или сервлет контейнеру или что там реально биндит сокет)

[orlik]

Простите за тупой вопрос, а может переписать сервис чтоб она слушала на 16 порту ,но понижала свои привилегии после запуска ? 10 строчек кода, не более

Ну или как вариант переконфигурить того кто шлет эти пакетики, чтоб слал на нужный порт. Тем более , что сами говорите, все пакеты от одного источника

 

В общем случае и то и то может быть невозможным. Да и всякие понижения привилегий приведут к геморрою с кроссплатформенностью

 

Да конечно , редирект с iptables, это очень кросплатформенно

[srg555]

Да конечно , редирект с iptables, это очень кросплатформенно

 

Это никак не затрагивает исходный код. DNAT умеет все - linux, solaris, windows и даже freebsd, хотя вряд ли найдётся адекватный человек, рискующий запускать JEE на freebsd под коммерческой нагрузкой

[[anp/hsw]]

повесьте какой-нибудь IP на лупбэк типа:

ifconfig lo:0 10.1.1.1 netmask 255.255.255.255

после чего делайте DNAT на этот адрес.

НЕ НАДО так делать.

Понадобится отдельный bind() на этот адрес, т.к. bind(0.0.0.0) по протоколу UDP невозможен - в стеке не содержится информация о локальном ип, на который пришел пакет, вследствии этого неовозможно будет назначить пакету правильный исходящей адрес (если локальных адресов более одного).

 

Если топикстартеру нет необходимости делать редирект на неопределенный круг локальных IP, то лучше все-же будет DNAT на тот же адрес с изменением порта (это отличается от REDIRECT!), тогда никакие игры с лупбэком будут не нужны.

[srg555]

' timestamp='1377018884' post=870807]

НЕ НАДО так делать.

Понадобится отдельный bind() на этот адрес, т.к. bind(0.0.0.0) по протоколу UDP невозможен - в стеке не содержится информация о локальном ип, на который пришел пакет, вследствии этого неовозможно будет назначить пакету правильный исходящей адрес (если локальных адресов более одного).

 

 

udp/162 это snmp trap. на них НЕ нужно отвечать, их надо только принять. лупбэк удобен тем, что это лупбэк, нет привязки к потенциально изменяющимся внешним условиям

[[anp/hsw]]

лупбэк удобен тем, что это лупбэк, нет привязки к потенциально изменяющимся внешним условиям

Теперь только осталось понять, какой именно трафик хочет модифицировать топикстартер: на один адрес, или на неопределенное их количество, т.к. -i вместо -d выглядит по меньшей мере странно.

[^rage^]

можно выдать capability CAP_NET_BIND_SERVICE самой java(или сервлет контейнеру или что там реально биндит сокет)

имхо, самый лучший вариант.

[Ilya Evseev]

Сейчас это решено простым правилом iptables:

iptables -t nat -A PREROUTING -i eth0 -p udp --dport 162 -j REDIRECT --to-port 2500

Однако, есть проблема: часть пакетов не попадает на это правило и не редиректится.

В порядке бреда предлагаю указать это правило дважды и посмотреть, не станут ли у второго правила расти значения в счётчиках.

 

Перед первым ещё можно поставить --dport 161 -j LOG, чтобы понять, доходят ли пакеты вообще до -t nat, или теряются раньше.

[synclpz]

Сейчас занимаюсь устроительством load-test для конфигурации:

 

<хост, который шлет трапы> ----> <162/udp хоста, принимающего, iptables redirect 2500/udp> ----> <java-приложение, считающее трапы на порту 2500 и 162 одновременно>

 

Как сделаю - отпишусь.

[srg555]

synclpz

А с чего Вы вообще решили что будут потери? Или просто проверить перед вводом в эксплуатацию?

[evil-man]

Чтобы всё хорошо работало, надо чтобы для коннтрака был загружен хелпер протокола snmp. Без него будут проблемы с редиректом/натом snmp-пакетов.

[srg555]

helper нужен только для синхронного snmp (udp/161), для трапов не нужен

[^rage^]

helper нужен только для синхронного snmp (udp/161), для трапов не нужен

а в чём синхронность snmp при посылке трапов?

[srg555]

helper нужен только для синхронного snmp (udp/161), для трапов не нужен

а в чём синхронность snmp при посылке трапов?

 

её нет, при отслыке трапов процесс асинхронный.

[^rage^]

helper нужен только для синхронного snmp (udp/161), для трапов не нужен

а в чём синхронность snmp при посылке трапов?

 

её нет, при отслыке трапов процесс асинхронный.

 

а синхронный snmp - это что тогда?