Tcpdump показывает другой порт перенаправления после добавления правила REDIRECT в iptables

Question

Для ясности: тест OP выполняется из системы 192.168.1.100 к себе, а не из удаленной системы, и это причина проблемы. В этом случае порт не был изменен, поскольку не совпало ни одно правило NAT, хотя он бы совпал, если бы был выполнен из удаленной системы.

На схеме ниже показан порядок выполнения операций над пакетом:

Причина в том, как работает NAT в Linux:iptablesвидит пакет в natтаблице только для первого пакета нового потока conntrack (который, таким образом, находится в состоянии NEW).

Это правило отлично работает с удаленной системы. В этом случае первый увиденный пакет будет входящим пакетом:

to port 8000 --> AF_PACKET (tcpdump) --> conntrack --> nat/PREROUTING (iptables REDIRECT): to port 30000
--> routing decision --> ... --> local process receiving on port 30000

Все последующие пакеты в том же потоке будут иметь conntrack, обрабатывающий непосредственно смену порта (или возврат порта для ответов), и будут пропускать любые правила iptables в таблице nat(как написано в схеме: natтаблица просматривается только для NEWсоединений). Таким образом, (пропуская часть пакета ответа), следующий входящий пакет будет подвергаться этому вместо этого:

to port 8000 --> AF_PACKET (tcpdump) --> conntrack: to port 30000
--> routing decision --> ... --> local process receiving on port 30000

Для теста на самой системе первый пакет не входящий, а исходящий. Это происходит вместо этого, используя исходящий loинтерфейс:

local process client curl --> routing decision --> conntrack --> nat/OUTPUT (no rule here)
--> reroute check --> AF_PACKET (tcpdump) --> to port 8000

И теперь этот пакет возвращается обратно на loинтерфейс, он снова появляется как пакет, который больше не является первым пакетом в соединении, поэтому следует второму случаю, как указано выше: conntrack самостоятельно заботится о NAT и не вызывает nat/PREROUTING. За исключением того, что на предыдущем шаге ему не было указано выполнять какой-либо NAT:

to port 8000 --> AF_PACKET (tcpdump) --> conntrack
--> routing decision --> ... -->nolocal process receiving on port8000

Поскольку порт 8000 никто не прослушивает, ОС отправляет обратно TCP RST.

Чтобы это работало в локальной системе, REDIRECTв цепочку также необходимо добавить правило nat/OUTPUT:

iptables -t nat -I OUTPUT -d 192.168.1.100 -p tcp --dport 8000 -j REDIRECT --to-port 30000

Дополнительные замечания

если случай предназначен для удаленного использования, не тестируйте из локальной системы: правила, пройденные тестом, не совпадают. Это делает тест не отражающим реальность.

Просто используйте сетевое пространство имен для создания карманной удаленной системы в случае, если нет другой доступной системы. Пример, который должен работать с системой, имеющей только nat/PREROUTINGправило OP и выполняющей curl http://192.168.1.100/(что не требует DNS):
```
ip netns add remotesystem
ip link add name vethremote up type veth peer netns remotesystem name eth0
ip address add 192.0.2.1/24 dev vethremote
ip -n remotesystem address add 192.0.2.2/24 dev eth0
ip -n remotesystem link set eth0 up
ip -n remotesystem route add 192.168.1.100 via 192.0.2.1
ip netns exec remotesystem curl http://192.168.1.100:8000/
```
tcpdumpи НАТ

tcpdumpпроисходит на AF_PACKETэтапах в схеме выше: очень рано для входа и очень поздно для выхода. Это означает, что в случае удаленной системы он никогда не захватит порт 30000, даже если он работает. В случае локальной системы, как только правило nat/OUTPUTдобавлено, он захватит порт 30000.

Только не доверяйте слепо адресу/порту, отображаемому при tcpdumpвыполнении NAT: это зависит от случая и того, где происходит перехват.

Answer 1