Пока вы еще не разобрались с NETMAP, я поставил еще эксперимент. Тестировал только iproute2 правила (ниже по тексту видно).
Пингую адрес в антхилле, потому некоторые пакеты теряются, ну вы сами знаете какая у озерков линковка с антхиллом
"ping 10.20.36.183" (настройки по умолчанию):
Code:
[admin@anthy root]$ tcpdump -n -i vlan1 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vlan1, link-type EN10MB (Ethernet), capture size 68 bytes
15:58:03.115315 IP 192.168.30.54 > 10.20.36.183: ICMP echo request, id 1, seq 459, length 40
15:58:03.117777 IP 10.20.36.183 > 192.168.30.54: ICMP echo reply, id 1, seq 459, length 40
15:58:04.117792 IP 192.168.30.54 > 10.20.36.183: ICMP echo request, id 1, seq 460, length 40
15:58:08.729143 IP 192.168.30.54 > 10.20.36.183: ICMP echo request, id 1, seq 461, length 40
15:58:08.745746 IP 10.20.36.183 > 192.168.30.54: ICMP echo reply, id 1, seq 461, length 40
15:58:09.731992 IP 192.168.30.54 > 10.20.36.183: ICMP echo request, id 1, seq 462, length 40
[admin@anthy root]$ tcpdump -n -i br0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 68 bytes
15:58:03.115153 IP 10.0.17.76 > 10.20.36.183: ICMP echo request, id 1, seq 459, length 40
15:58:03.117992 IP 10.20.36.183 > 10.0.17.76: ICMP echo reply, id 1, seq 459, length 40
15:58:04.117633 IP 10.0.17.76 > 10.20.36.183: ICMP echo request, id 1, seq 460, length 40
15:58:08.728976 IP 10.0.17.76 > 10.20.36.183: ICMP echo request, id 1, seq 461, length 40
15:58:08.745886 IP 10.20.36.183 > 10.0.17.76: ICMP echo reply, id 1, seq 461, length 40
15:58:09.731827 IP 10.0.17.76 > 10.20.36.183: ICMP echo request, id 1, seq 462, length 40
Делаем
Code:
ip route add nat 2.0.0.0/8 via 10.0.0.0
ip rule add nat 2.0.0.0 from 10.0.0.0/8
ip route flush cache
Конечно это правило совсем не то что мне нужно, но будем проверять как это простое преобразование работает само по себе. Почти что пример из книжки.
"ping 10.20.36.183":
Code:
[admin@anthy root]$ tcpdump -n -i vlan1 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vlan1, link-type EN10MB (Ethernet), capture size 68 bytes
16:02:27.112499 IP 192.168.30.54 > 10.20.36.183: ICMP echo request, id 1, seq 467, length 40
16:02:27.114954 IP 10.20.36.183 > 192.168.30.54: ICMP echo reply, id 1, seq 467, length 40
16:02:31.691791 IP 192.168.30.54 > 10.20.36.183: ICMP echo request, id 1, seq 468, length 40
16:02:36.691114 IP 192.168.30.54 > 10.20.36.183: ICMP echo request, id 1, seq 469, length 40
16:02:41.690412 IP 192.168.30.54 > 10.20.36.183: ICMP echo request, id 1, seq 470, length 40
16:02:41.691577 IP 10.20.36.183 > 192.168.30.54: ICMP echo reply, id 1, seq 470, length 40
[admin@anthy root]$ tcpdump -n -i br0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 68 bytes
16:02:27.112332 IP 10.0.17.76 > 10.20.36.183: ICMP echo request, id 1, seq 467, length 40
16:02:27.115121 IP 2.20.36.183 > 10.0.17.76: ICMP echo reply, id 1, seq 467, length 40
16:02:31.691623 IP 10.0.17.76 > 10.20.36.183: ICMP echo request, id 1, seq 468, length 40
16:02:36.690946 IP 10.0.17.76 > 10.20.36.183: ICMP echo request, id 1, seq 469, length 40
16:02:41.690244 IP 10.0.17.76 > 10.20.36.183: ICMP echo request, id 1, seq 470, length 40
16:02:41.691717 IP 2.20.36.183 > 10.0.17.76: ICMP echo reply, id 1, seq 470, length 40
Подмена source поля работает. На хосте в окне пинга "Превышен интервал ожидания для запроса". Пока все правильно.
Ждем минуту и делаем "ping 2.20.36.183":
Code:
[admin@anthy root]$ tcpdump -n -i vlan1 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vlan1, link-type EN10MB (Ethernet), capture size 68 bytes
16:05:51.007108 IP 192.168.30.54 > 10.20.36.183: ICMP echo request, id 1, seq 477, length 40
16:05:51.023498 IP 10.20.36.183 > 192.168.30.54: ICMP echo reply, id 1, seq 477, length 40
16:05:55.662083 IP 192.168.30.54 > 10.20.36.183: ICMP echo request, id 1, seq 478, length 40
16:05:55.664256 IP 10.20.36.183 > 192.168.30.54: ICMP echo reply, id 1, seq 478, length 40
16:06:00.661375 IP 192.168.30.54 > 10.20.36.183: ICMP echo request, id 1, seq 479, length 40
16:06:00.666117 IP 10.20.36.183 > 192.168.30.54: ICMP echo reply, id 1, seq 479, length 40
16:06:05.660651 IP 192.168.30.54 > 10.20.36.183: ICMP echo request, id 1, seq 480, length 40
16:06:05.671859 IP 10.20.36.183 > 192.168.30.54: ICMP echo reply, id 1, seq 480, length 40
[admin@anthy root]$ tcpdump -n -i br0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 68 bytes
16:05:51.006936 IP 10.0.17.76 > 2.20.36.183: ICMP echo request, id 1, seq 477, length 40
16:05:55.661919 IP 10.0.17.76 > 2.20.36.183: ICMP echo request, id 1, seq 478, length 40
16:06:00.661200 IP 10.0.17.76 > 2.20.36.183: ICMP echo request, id 1, seq 479, length 40
16:06:05.660478 IP 10.0.17.76 > 2.20.36.183: ICMP echo request, id 1, seq 480, length 40
Ответы застряли где то внутри рутера.
Делаем "ping 10.20.36.183 -w 50" и сразу после этого "ping 2.20.36.183 -w 50":
Code:
[admin@anthy root]$ tcpdump -n -i vlan1 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vlan1, link-type EN10MB (Ethernet), capture size 68 bytes
16:09:19.885091 IP 192.168.30.54 > 10.20.36.183: ICMP echo request, id 1, seq 506, length 40
16:09:19.895111 IP 10.20.36.183 > 192.168.30.54: ICMP echo reply, id 1, seq 506, length 40
16:09:21.134841 IP 192.168.30.54 > 10.20.36.183: ICMP echo request, id 1, seq 507, length 40
16:09:21.138853 IP 10.20.36.183 > 192.168.30.54: ICMP echo reply, id 1, seq 507, length 40
16:09:22.633631 IP 192.168.30.54 > 10.20.36.183: ICMP echo request, id 1, seq 508, length 40
16:09:24.133358 IP 192.168.30.54 > 10.20.36.183: ICMP echo request, id 1, seq 509, length 40
16:09:27.552651 IP 192.168.30.54 > 10.20.36.183: ICMP echo request, id 1, seq 510, length 40
16:09:27.555015 IP 10.20.36.183 > 192.168.30.54: ICMP echo reply, id 1, seq 510, length 40
16:09:28.555700 IP 192.168.30.54 > 10.20.36.183: ICMP echo request, id 1, seq 511, length 40
16:09:29.633477 IP 192.168.30.54 > 10.20.36.183: ICMP echo request, id 1, seq 512, length 40
16:09:29.637206 IP 10.20.36.183 > 192.168.30.54: ICMP echo reply, id 1, seq 512, length 40
16:09:30.639318 IP 192.168.30.54 > 10.20.36.183: ICMP echo request, id 1, seq 513, length 40
16:09:30.649347 IP 10.20.36.183 > 192.168.30.54: ICMP echo reply, id 1, seq 513, length 40
[admin@anthy root]$ tcpdump -n -i br0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 68 bytes
16:09:19.884839 IP 10.0.17.76 > 10.20.36.183: ICMP echo request, id 1, seq 506, length 40
16:09:19.895262 IP 2.20.36.183 > 10.0.17.76: ICMP echo reply, id 1, seq 506, length 40
16:09:21.134610 IP 10.0.17.76 > 10.20.36.183: ICMP echo request, id 1, seq 507, length 40
16:09:21.139002 IP 2.20.36.183 > 10.0.17.76: ICMP echo reply, id 1, seq 507, length 40
16:09:22.633392 IP 10.0.17.76 > 10.20.36.183: ICMP echo request, id 1, seq 508, length 40
16:09:24.133184 IP 10.0.17.76 > 10.20.36.183: ICMP echo request, id 1, seq 509, length 40
16:09:27.552409 IP 10.0.17.76 > 2.20.36.183: ICMP echo request, id 1, seq 510, length 40
16:09:27.555158 IP 2.20.36.183 > 10.0.17.76: ICMP echo reply, id 1, seq 510, length 40
16:09:28.555522 IP 10.0.17.76 > 2.20.36.183: ICMP echo request, id 1, seq 511, length 40
16:09:29.633313 IP 10.0.17.76 > 2.20.36.183: ICMP echo request, id 1, seq 512, length 40
16:09:29.637353 IP 2.20.36.183 > 10.0.17.76: ICMP echo reply, id 1, seq 512, length 40
16:09:30.639144 IP 10.0.17.76 > 2.20.36.183: ICMP echo request, id 1, seq 513, length 40
Работает и подмена source и подмена destination. На хосте в окне ping-а видны ответы
Как я интерпретирую полученный результат: где то все равно используется stateful преобразование, и пока нет запроса на 10.x.x.x, наши ответы с 2.x.x.x игнорируются. Когда проходит один запрос на 10.x.x.x - появляется запись в какой то таблице, и наши ответы на запрос уже на адрес 2.x.x.x приходят обратно по "соединению", оставшемуся от запроса на 10.x.x.x.
Посему вопрос: если мои рассуждения верны, то как называется эта таблица и где про нее можно прочитать?
Так же посмотрел что происходит на других интерфейсах - там все нормально, наши потерявшиеся пакеты на неправильный интерфейс не уходят.