проблема такая: прописал в /etc/sysconfig/iptables*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:MyPostrouting - [0:0]
-A POSTROUTING -j MyPostrouting
-A MyPostrouting -p icmp -j SNAT --to-source X.Y.Z.T -v
COMMIT
==========================================
перезапустил iptables#iptables -L -v -t nat выдает
Chain PREROUTING (policy ACCEPT 232 packets, 39755 bytes)
pkts bytes target prot opt in out source destinationChain POSTROUTING (policy ACCEPT 97 packets, 7552 bytes)
pkts bytes target prot opt in out source destination
97 7552 MyPostrouting all -- any any anywhere anywhereChain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destinationChain MyPostrouting (1 references)
pkts bytes target prot opt in out source destination
0 0 SNAT icmp -- any any anywhere anywhere to:X.Y.Z.T
==========================================
вроде, все круто. когда с этой машинки пингую любой адрес, все натится и счетчик у этого фильтра увеличивается...
Теперь, пингую эту машинку... ответы один фиг приходят с ее реального адреса, а не с X.Y.Z.T и счетчик не увеличивается... что я не так делаю?
похоже, icmp responses считаются частью сессии (входящий пинг) и не проходят через эту таблицу... плохо....
>#iptables -L -v -t nat выдает
>Chain PREROUTING (policy ACCEPT 232 packets, 39755 bytes)
>pkts bytes target prot opt in out source destination
>
>Chain POSTROUTING (policy ACCEPT 97 packets, 7552 bytes)
>pkts bytes target prot opt in out source destination
>97 7552 MyPostrouting all -- any any anywhere anywhere
>
>Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
>pkts bytes target prot opt in out source destination
>
>Chain MyPostrouting (1 references)
>pkts bytes target prot opt in out source destination
>0 0 SNAT icmp -- any any anywhere anywhere to:X.Y.Z.T
>==========================================
>вроде, все круто. когда с этой машинки пингую любой адрес, все натится
>и счетчик у этого фильтра увеличивается...
>Теперь, пингую эту машинку... ответы один фиг приходят с ее реального адреса,
>а не с X.Y.Z.T и счетчик не увеличивается... что я не
>так делаю?Входящие пакеты, в отличие от исходящих и проходящих,
никогда не попадают в цепочку postrouting таблицы nat.
>Входящие пакеты, в отличие от исходящих и проходящих,
>никогда не попадают в цепочку postrouting таблицы nat.Так вот в чем вопрос: ответ на пинг это же исходящий пакет, правильно?
>Так вот в чем вопрос: ответ на пинг это же исходящий пакет,
>правильно?
Да, но это ОТВЕТ на входящий. Пришел входящий echo - состояние NEW, исходящий reply - ESTABLISHED. А если он ответит с другого ip, то ничего работать не будет. Клиент ждет ответ от запрошенного адреса.
А если он ответит с другого ip,
>то ничего работать не будет. Клиент ждет ответ от запрошенного адреса.
>компьютер этот - роутер, он должен сообщать что (например) ttl исходного сообщения = 0. icmp responses - Пакеты выходят в канал с приватными адресами, и через другой роутер уходят в инет. А дальше режутся где-то в пути. Задача была поставить в этих ответных пакетах source один из не-приватных ip адресов
>компьютер этот - роутер, он должен сообщать что (например) ttl исходного сообщения
>= 0. icmp responses - Пакеты выходят в канал с приватными
>адресами, и через другой роутер уходят в инет. А дальше режутся
>где-то в пути. Задача была поставить в этих ответных пакетах source
>один из не-приватных ip адресов
Вот на том "другом" роутере и делайте SNAT этих ответных пакетов. Хотя я не понимаю, зачем все это нужно.
>Вот на том "другом" роутере и делайте SNAT этих ответных пакетов. Хотяа на "другом" та же картина! видимо, contrack отслеживает :(
Попробуйте делать nat с помощью iproute2
http://linux-ip.net/html/nat-stateless.html
Опишите более подробно структуру. Какие Ваши роутеры, какие нет, на каких реальные или приватные адреса. Какая задача.
вот, поставил эксперимент:структура сети
(сеть A.B.C.64/27)-eth0(A.B.C.65)-Роутер1-ppp0(192.168.96.6)--канал
--ppp1(192.168.96.5)-Роутер2-eth1(Инет)на Роутере1 генерирую пакет icmp type 11 src=192.168.96.6 dst=somehost
на Роутере2 iptables -t nat -p ip -s 192.168.96.6 -o eth1 -j SNAT --to-source A.B.C.65смотрю tcpdump-ом на интерфейсе eth1 на Роутере2
18:01:02.084764 IP 192.168.96.6 > ppp85-140-173-102.pppoe.mtu-net.ru: icmp 72: time exceeded in-transitА вто если на роутере1 генерирую пакет абсолютно такой же но type8
то на Роутере2 вижу18:02:08.040008 IP A.B.C.65 > ppp85-140-173-102.pppoe.mtu-net.ru: icmp 64: echo request seq 0
Выходит, одни типы icmp транслируются а другие нет?!
>Выходит, одни типы icmp транслируются а другие нет?!
ИМХО разница в статусе для этих типов. В случае type 8 трассировщик присваивает пакету статус NEW, а в случае type 11 - RELATED. Возможно проблема в этом.
Предлагаю попробовать следующее. На Роутер2:
iptables -t mangle -A PREROUTING -i ppp1 -s 192.168.96.6 -p icmp --icmp-type 11 -j MARK --set-mark 0x10
ip rule add fwmark 10 nat A.B.C.65
>Предлагаю попробовать следующее. На Роутер2:
>iptables -t mangle -A PREROUTING -i ppp1 -s 192.168.96.6 -p icmp --icmp-type
>11 -j MARK --set-mark 0x10
>ip rule add fwmark 10 nat A.B.C.65что-то теперь пакет пропадает внутри роутера2: приходит и нигде не выходит :(
Поменяйте mark на 1 (кажется напутал с dec и hex числами)
iptables -t mangle -A PREROUTING -i ppp1 -s 192.168.96.6 -p icmp --icmp-type 11 -j MARK --set-mark 1
ip rule add fwmark 1 nat A.B.C.65
в общем, не меняются эти пакеты, блин! Какие приходят такие и уходят.. Похоже, где-то в ядре прописано что не SNAT-ить некоторые icmp. Я кстати, попробовал другие типы icmp, 3 тип (ответ не доступен), тоже не меняется
>Попробуйте делать nat с помощью iproute2
>http://linux-ip.net/html/nat-stateless.html
посмотрел: тот нат который в iproute2 - это DNAT
>посмотрел: тот нат который в iproute2 - это DNAT
Вы невнимательно читали. nat в iproute2 работает "тупо" в соответствии с правилами. Указано via - переписывает destination ip, from - source ip.It involves rewriting addresses passing through a routing device: inbound packets will undergo destination address rewriting and outbound packets will undergo source address rewriting.
Вот Вам пример изменения source ip
ip rule add nat 205.254.211.17 from 192.168.100.17This command enters the corresponding rule for the outbound traffic into the RPDB (kernel 2.2 and up). This rule will cause the kernel rewrite any packet from 192.168.100.17 with the specified source address (205.254.211.17). Any packet originating from 192.168.100.17 which passes through this router will trigger this rule. In short, this command rewrites the source address of outbound packets so that they appear to originate from the NAT IP.
>>Так вот в чем вопрос: ответ на пинг это же исходящий пакет,
>>правильно?
>Да, но это ОТВЕТ на входящий. Пришел входящий echo - состояние NEW,То есть, ответ не идет через nat POSTROUTING. Это точно?
>То есть, ответ не идет через nat POSTROUTING. Это точно?
100%
вопрос снят, это фича by design :(https://lists.netfilter.org/pipermail/netfilter/2006-January...
цитата=========================================
<AFAIK>
There's two class of ICMP packets:
. ICMP requests/replies, such as ping
. ICMP errorsICMP requests/replies works on a NEW/ESTABLISHED scheme, meaning the
request have NEW state and reply ESTABLISHED state.ICMP errors, if valid (i.e. corresponding to an existing contrack
entry), have RELATED state.Now for NAT table... NAT table only "sees" packets with state NEW. If
matched and accepted by filtering rules, an according conntrack entry is
created, and following packets are handled transparently by conntrack,
meaning both ESTABLISHED and RELATED packets.
</AFAIK>Now, to partially answer your question, and maybe to refine your
observations:
. you won't see ICMP errors in NAT table, which means you won't
see ICMP packets generated by a tracerouting application
. you should see ICMP echo requests, but won't see ICMP echo
repliesI know it does not totally answer your question, but at least, I hope
this provides some useful information to you.
Спасибо, буду знать.