Я пытаюсь изменить IP-адрес назначения для пакета ответа ICMP.
Ответ ICMP поступает на маршрутизатор из моего туннеля IPSEC как таковой (я не совсем уверен, почему он отображается в tcpdump дважды):
14:28:09.562030 IP 35.182.188.86 > 54.76.131.136: ICMP echo request, id 28997, seq 1259, length 64
14:28:09.641595 IP 54.76.131.136 > 35.182.188.86: ICMP echo reply, id 28997, seq 1259, length 64
14:28:09.641645 IP 54.76.131.136 > 35.182.188.86: ICMP echo reply, id 28997, seq 1259, length 64
Я пытаюсь изменить IP-адрес назначения на локальный IP-адрес (172.31.20.219) в таблице PREROUTING с помощью:
sudo iptables -t nat -A PREROUTING --source 54.76.131.136 --destination 35.182.188.86 -j DNAT --to-destination 172.31.20.219
Итак, таблицы выглядят так:
ubuntu@ip-172-31-23-13:~$ sudo iptables-save -c
# Generated by iptables-save v1.6.0 on Tue Oct 3 14:58:19 2017
*nat
:PREROUTING ACCEPT [33:2711]
:INPUT ACCEPT [32:2627]
:OUTPUT ACCEPT [8:1080]
:POSTROUTING ACCEPT [9:1164]
[0:0] -A PREROUTING -s 54.76.131.136/32 -d 35.182.188.86/32 -j DNAT --to-destination 172.31.20.219
COMMIT
# Completed on Tue Oct 3 14:58:19 2017
# Generated by iptables-save v1.6.0 on Tue Oct 3 14:58:19 2017
*raw
:PREROUTING ACCEPT [2646:283498]
:OUTPUT ACCEPT [998:168846]
[1954:164136] -A PREROUTING -s 54.76.131.136/32 -d 35.182.188.86/32 -j LOG
[821:68964] -A PREROUTING -s 54.76.131.136/32 -d 35.182.188.86/32 -j TRACE
COMMIT
# Completed on Tue Oct 3 14:58:19 2017
Однако смена ip не происходит.
С помощью
sudo iptables -t raw -A PREROUTING --source 54.76.131.136 --destination 35.182.188.86 -j LOG
Я вижу, что совпадение может быть выполнено на необработанной таблице:
Oct 3 14:25:20 ip-172-31-23-13 kernel: [ 889.588090] IN=eth0 OUT= MAC=02:fc:a0:12:56:64:02:7f:fe:dc:a4:0d:08:00 SRC=54.76.131.135 DST=35.182.188.85 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=64700 PROTO=ICMP TYPE=0 CODE=0 ID=28997 SEQ=1091
Но похоже, что это не подходит для нат-таблицы.
Может ли кто-нибудь дать совет о том, почему IP-адрес назначения не изменяется или как отладить это дальше? Выглядит очень странно.
Я использую Ubuntu 16.04. Входящий трафик поступает через туннель IPSEC, настроенный с помощью StrongSwan.
Спасибо
Пакет ответа ICMP Echo является частью установленного потока. Это означает, что когда ядро в нормальном случае получило такой пакет, оно уже ожидало его (после первоначального запроса ICMP Echo), поэтому conntrack, базовый блок, необходимый для nat, уже создал для него запись ожидания. В таком случае таблица nat будет закорочена и даже не будет выполнена для этого ответного пакета.
ссылка: https://www.netfilter.org/documentation/HOWTO/netfilter-hacking-HOWTO-3.html#ss3.2 (NAT)
Эта таблица немного отличается от таблицы "filter" тем, что только первый пакет нового соединения будет проходить через таблицу: результат этого прохождения затем применяется ко всем будущим пакетам в том же соединении.
Чтобы проверить это поведение, используйте команду conntrack (из пакета conntrack) в режиме монитора событий. Вот пример с одним пингом в Google:
# conntrack -E
[NEW] icmp 1 30 src=192.168.3.2 dst=8.8.8.8 type=8 code=0 id=12837 [UNREPLIED] src=8.8.8.8 dst=198.51.100.5 type=0 code=0 id=12837
[UPDATE] icmp 1 30 src=192.168.3.2 dst=8.8.8.8 type=8 code=0 id=12837 src=8.8.8.8 dst=198.51.100.5 type=0 code=0 id=12837
[DESTROY] icmp 1 src=192.168.3.2 dst=8.8.8.8 type=8 code=0 id=12837 src=8.8.8.8 dst=198.51.100.5 type=0 code=0 id=12837
Первый пакет создаст запись [NEW] и, таким образом, передаст таблицу nat, давая возможность изменить ожидание (в этом примере классический SNAT / MASQUERADE). Другие пакеты этого потока обрабатываются только с ожиданием conntrack до тех пор, пока запись не будет уничтожена (тайм-аут 30 секунд для этого icmp).
Использование правила nat могло бы работать с первоначальным запросом ICMP Ping Echo, потому что это был бы новый поток.
Вы не сказали, что на самом деле хотите со всем этим делать. Если ваша цель - скопировать пакет в 172.31.20.219, вам следует попробовать цель TEE (man iptables-extensions).