LINUX.ORG.RU
Форум — Admin  

iptables: redirect трафика на другой порт

 ,


0

3

Добрый день. Суть вопроса: нужно перенаправить трафик от одного конкретного хоста с одного порта на другой (форвардить трафик куда-то дальше не нужно, нужно только принять его именно от этого хоста на нестандартном порту). Я прописал правило: 

iptables -t nat -A PREROUTING -p udp --src 172.21.10.2 --dport 162 -j REDIRECT --to-ports 10150
но когда я встаю tcpdump-ом посмотреть, что приходит на порт 10150, то ничего не вижу: 
tcpdump -i any port 10150
Список правил таблицы nat: 
iptables -t nat -L -v -n --line-numbers
Chain PREROUTING (policy ACCEPT 35073 packets, 5126K bytes)
num   pkts bytes target     prot opt in     out     source               destination
1       56  7112 REDIRECT   udp  --  eth2.2 *       172.21.10.2          0.0.0.0/0           udp dpt:162 redir ports 10150

Chain POSTROUTING (policy ACCEPT 289K packets, 53M bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 289K packets, 53M bytes)
num   pkts bytes target     prot opt in     out     source               destination

Причем видно, что через правило редиректа какие-то пакеты проходят...

Список правил таблицы filter: 

iptables -L -v -n --line-numbers
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1      10G 4374G ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
2    81806   10M ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0
3    1945K  200M ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
4        0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:514
5        0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:49
6    1163K   56M ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:49
7    17610  778K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:249
8        0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:249
9      491 28508 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22
10    482K   27M ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpts:10099:10200
11   1382K  107M ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:162
12       0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:514
13   14437 5626K ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:10113
14       0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:514
15       0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:10150
16    3187  250K REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT 2565K packets, 825M bytes)
num   pkts bytes target     prot opt in     out     source               destination

Таблица raw:

iptables -t raw -L -n
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

В /proc/net/nf_conntrack я вообще не вижу пакетов с udp:162 (то бишь snmp-trap'ов).

uname -a
Linux smarts-Nizhniy_Novgorod 2.6.32-642.11.1.el6.x86_64 #1 SMP Wed Oct 26 10:25:23 EDT 2016 x86_64 x86_64 x86_64 GNU/Linux

cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.8 (Santiago)

iptables --version
iptables v1.4.7

Вопрос: ЧЯДНТ???

В tcpdump пакеты попадают до netfilter'а, поэтому там ты увидишь только трафик на порт 162.

Попробуй поднять простой udp-сервер: 

nc -l -u 10150
И отправить туда что-нибудь снаружи: 
echo test > /dev/udp/$dst_ip/162

Deleted
()

А этот порт 10150 как и кем слушается ? «netstat -lun»

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

vel ★★★★★
()
Ответ на: комментарий от Deleted

вместо простого udp-сервера есть небольшое приложение на Java, которое слушает указанный адрес:порт. И после редиректа до приложения ничего не доходит. Если руками сгенерить трап на нужный порт, то приложение его обработает 

snmptrap -v 2c -c nfrnjrfr my.ip.add.ress:10150 "" 1.3.6.1.4.1.890.1.15.3.3.2.2.2 1.3.6.1.6.3.1.1.4.1.0 oid "1.3.6.1.4.1.890.1.15.3.3.2.2.2" 1.3.6.1.6.3.18.1.3.0 IpAddress "172.21.10.2" 1.3.6.1.6.3.18.1.6.0 s "ac150a02" 1.3.6.1.4.1.890.1.15.3.3.2.2.2 s "4C 9E FF 83 87 89 "

Пробовал заставлять приложение слушать 0.0.0.0:10150, результат - по нулям

galaktoid
() автор топика
Ответ на: комментарий от vel

То есть если пакет пришел на интерфейс 1.2.3.4, то после редиректа адрес назначения остается так же 1.2.3.4, только порт другой? я это учитывал, пробовал слушать и 1.2.3.4:10150, и 0.0.0.0:10150

galaktoid
() автор топика
Ответ на: комментарий от vel

Попробовал переписать правило через DNAT: 

iptables -t nat -A PREROUTING -p udp -i eth2.2 --src 172.21.10.2 --dport 162 -j DNAT --to-destination my.ip.add.ress:10150

По прежнему пакеты до приложения не доходят, счетчик увеличивается, приложение слушает 195.122.226.31:10150 udp

galaktoid
() автор топика
Ответ на: комментарий от gserg

Для DNAT надо и SNAT в обратную сторону, иначе не работает

Нет, не надо. connection tracking для этого есть.

Может, само приложение не может обработать приходящий трафик? В /proc/net/nf_conntrack точно ничего нет? Записи про udp хранятся 30 секунд по дефолту.

Deleted
()
Ответ на: комментарий от gserg

а зачем в обратную сторону? пакеты представляют собой SNMP-трапы и идут только в одну сторону

galaktoid
() автор топика
Ответ на: комментарий от vel

проблему решил. все свелось к тому, что пакеты (трапы) отправлялись не на тот интерфейс. непонятен остался только один момент: почему tcpdump пакеты с «не того» интерфейса видел, а приложение, iptables и все-все-все - не видели

galaktoid
() автор топика
Ответ на: комментарий от galaktoid

iptables видит все, а мимо "-j TRACE" вообще никакой ipv4/ipv6 пакет не проскочит, жаль только, что в логи пишется дофига и на нагруженных системах пользоваться им нужно очень аккуратно.

«ip ro get 172.21.10.2» у тебя какой интерфейс показывает ?

ты же сам "-i eth2.2" указал ? А зачем ?

Эх! Вот если бы «tcpdump -i any» умел показывать интерфейс через которых он получил пакет.

vel ★★★★★
()
Ответ на: комментарий от vel

увы, да, tcpdump -i any интерфейсы не кажет

-i eth2.2 указал, потому что трапы изначально на него слали. слать трапы на другой интерфейс додумался после того, как взглянул на таблицу маршрутизации :)

ip ro get 172.21.10.2 - впервые слышу про такого зверя, догадываюсь, что он мне завтра на работе покажет :)

«iptables видит все» - так то оно так, но почему он пакеты не редиректил?

galaktoid
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Admin