Вариант для распечатки		Пред. тема | След. тема
Форум Информационная безопасность (Linux iptables, ipchains / Linux)
Изначальное сообщение		[ Отслеживать ]

"Непонимание с iptables"	+/–
Сообщение от yo100s (?), 19-Мрт-20, 22:22
# Подменяю ip отправителя при обращении к порту 666 протокол udp /sbin/iptables -t nat -A POSTROUTING -j SNAT --to-source 8.8.8.8 -p udp --dport 666 # Перенапрявляю все обращения к порту 666 на локальный интерфейс. /sbin/iptables -t nat -A PREROUTING -p udp --dport 666 -j REDIRECT --destination 127.0.0.1 # Пытаюсь логировать все это /sbin/iptables -A INPUT -p udp --dport 666 -j LOG --log-prefix "iptabless: " /sbin/iptables -A OUTPUT -p udp --dport 666 -j LOG --log-prefix "iptabless: " /sbin/iptables -A FORWARD -p udp --dport 666 -j LOG --log-prefix "iptabless: " cat messages | grep iptables # Ничего не работает и в логах пусто. Где я неправ?
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "Непонимание с iptables"	+/–
Сообщение от Licha Morada (ok), 20-Мрт-20, 01:06
Найдите шпаргалку по "netfilter packet flow" ( типа http://clip2net.com/clip/m17268/1259352160-clip-92kb.png ). Исходя из того, что вы написали, трудно сказать в чём дело, но, может, со шпаргалкой, вам самому станет понятнее. Не пытайтесь создать сразу сложную схему, особенно оесли она не получается с диагнозом "странно". Сделайте что-то совсем простое, и, потом, постепенно усложняйте. > # Подменяю ip отправителя при обращении к порту 666 протокол udp > /sbin/iptables -t nat -A POSTROUTING -j SNAT --to-source 8.8.8.8 -p udp --dport 666 Предположу, что это правило просто не применяется. Если вы в PREROUTING перенаправили пакет на 127.0.0.1, что пойдёт по цепочке INPUT, то никакого POSTROUTING ему уже не светит. > # Перенапрявляю все обращения к порту 666 на локальный интерфейс. > /sbin/iptables -t nat -A PREROUTING -p udp --dport 666 -j REDIRECT --destination 127.0.0.1 Вы точно REDIRECT хотели, а не DNAT? > # Пытаюсь логировать все это > /sbin/iptables -A INPUT -p udp --dport 666 -j LOG --log-prefix "iptabless: " Если до этого правила в INPUT уже был применён какой-то "-j <action>", например ACCEPT, то это уже применятся не будет. > /sbin/iptables -A OUTPUT -p udp --dport 666 -j LOG --log-prefix "iptabless: " Если до этого правила в OUTPUT уже был применён какой-то "-j <action>", например ACCEPT, то это уже применятся не будет. > /sbin/iptables -A FORWARD -p udp --dport 666 -j LOG --log-prefix "iptabless: " Если до правила в FORWARD уже был применён какой-то "-j <action>", например ACCEPT, то это уже применятся не будет. > cat messages | grep iptables > # Ничего не работает и в логах пусто. Где я неправ? Поделитесь, чего вы, собственно, пытаетесь достичь? (Если всё равно, куда попадать, то и неважно, в какую сторону идти.)
Ответить | Правка | Наверх | Cообщить модератору

	2. "Непонимание с iptables"	+/–
	Сообщение от yo100s (?), 20-Мрт-20, 19:47
	На локальном интерфейсе висит серверный софт. Пытаюсь перенаправить запросы клиентского приложения по определенному порту на локальный сервер, с подменой ip.
	Ответить | Правка | Наверх | Cообщить модератору

	3. "Непонимание с iptables"	+/–
	Сообщение от Licha Morada (ok), 20-Мрт-20, 21:48
	> На локальном интерфейсе висит серверный софт. > Пытаюсь перенаправить запросы клиентского приложения по определенному порту на локальный > сервер, с подменой ip. Что вам не позволяет повесить серверный софт на UDP/0.0.0.0:666 и предложить клиентскому приложению запрашивать адрес-сервера:666 ? Чтобы не ходил кто попало, можно фильтровать правилами INPUT. Если вам критично, чтобы серверный софт думал что клиент пришёл с 8.8.8.8, то, подозреваю, одним netfilter-ом на локальной машине не обойтись. Смотрите шпаргалку, на предмет того как пакеты предназначенные локальному процессу не попадают в цепочку POSTROUTING, где можно делать DNAT. Хотя, думаю, с привлечением других инструментов, можно что-то придумать. Это будет грязно и громоздко. Если вам критично, чтобы серверный софт думал что слушает только UDP/127.0.0.1:666, то я бы рекомендовал DNAT, вместо исправления ошибок синтакса в REDIRECT. Тут хорошо описанно: https://gsoc-blog.ecklm.com/iptables-redirect-vs.-dnat-vs.-t.../ "This iptables target cannot be associated with a well-known networking solution. It is like a special DNAT rule where..." Не стоит отклонятся от well-known без особой на то надобности. Если вам критично это дело логировать, то смотрите сниффером что, собственно, происходит, и следите за порядком применения правил netfilter. Скорее всего, пакет выкидывают из цепочки то того как он дойдёт то LOG.
	Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема