# Подменяю 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
# Ничего не работает и в логах пусто. Где я неправ?
Найдите шпаргалку по "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
> # Ничего не работает и в логах пусто. Где я неправ?Поделитесь, чего вы, собственно, пытаетесь достичь?
(Если всё равно, куда попадать, то и неважно, в какую сторону идти.)
На локальном интерфейсе висит серверный софт.
Пытаюсь перенаправить запросы клиентского приложения по определенному порту на локальный сервер, с подменой ip.
> На локальном интерфейсе висит серверный софт.
> Пытаюсь перенаправить запросы клиентского приложения по определенному порту на локальный
> сервер, с подменой 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.