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

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

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

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

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

на порт 8000 --> AF_PACKET (tcpdump) --> conntrack --> nat/PREROUTING (iptables REDIRECT): на порт 30000
--> решение о маршрутизации --> ... --> получение локального процесса на порту 30000

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

на порт 8000 --> AF_PACKET (tcpdump) --> conntrack: на порт 30000
--> решение о маршрутизации --> ... --> получение локального процесса на порту 30000

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

локальный клиентский процесс curl --> решение о маршрутизации --> conntrack --> nat/OUTPUT (здесь нет правил)
--> проверка перенаправления --> AF_PACKET (tcpdump) --> на порт 8000

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

на порт 8000 --> AF_PACKET (tcpdump) --> conntrack
--> решение о маршрутизации --> ... -->нетполучение локального процесса на порту8000

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

Чтобы это работало в локальной системе, ПЕРЕНАПРАВЛЕНИЕ правило также должно быть помещено в нат/выход цепь:

iptables -t nat -I ВЫВОД -d 192.168.1.100 -p tcp --dport 8000 -j ПЕРЕНАПРАВЛЕНИЕ --на порт 30000

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

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

  Просто используйте сетевое пространство имен для создания карманной удаленной системы на тот случай, если никакая другая система недоступна. Пример, который должен работать с системой, имеющей только OP физ/PREOUTING правило и делать завиток http://192.168.1.100/ (который не требует DNS):

  ip netns добавить удаленную систему
  ip link add name vethremote up type veth peer netns имя удаленной системы eth0
  IP-адрес добавить 192.0.2.1/24 dev vethremote
  ip -n адрес удаленной системы добавить 192.0.2.2/24 dev eth0
  ip -n ссылка на удаленную систему установила eth0 вверх
  ip -n маршрут удаленной системы добавить 192.168.1.100 через 192.0.2.1
  ip netns exec remotesystem curl http://192.168.1.100:8000/
  

• tcpdump и NAT

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

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