пакеты, отправленные на виртуальный IP, не попадают в правило iptables

У меня есть виртуальный интерфейс eth1:3 с IP-адресом 222.192.124.3, Я установил правило iptables для регистрации пакетов, поступающих на этот интерфейс, с использованием IP-адреса интерфейса (я знаю, что iptables не заботится о метках виртуальных интерфейсов), например:

iptables -A INPUT -d 222.192.124.3 -j LOG --log-level warning --log-prefix "VIP3-IN: "

Когда я запускаю tcpdump и отправляю пакеты на этот IP-адрес с другой машины, я их вижу, поэтому предполагаю, что они принимаются и обрабатываются ядром должным образом, но iptables никогда не регистрирует эти пакеты, и когда я запускаю iptables -nvL, количество пакетов для этого правила не увеличивается, например, если они никогда не попадают в правило (или если iptables даже не видит пакеты, поступающие на этот интерфейс).

Сначала я подумал о другом правиле, подходящем для пакета и, следовательно, о его обработке до того, как он попадет в правило LOG, поэтому я удалил все правила iptables и добавил только правило ведения журнала, но безуспешно.

Сервер работает на RHEL 6.2 с ядром 2.6.32, виртуализированным на VMware ESX.

Вот полный вывод iptables -nvL:

Chain INPUT (policy ACCEPT 40 packets, 2891 bytes)
  pkts bytes target     prot opt in     out     source               destination
  0     0    LOG        all  --  *      *       0.0.0.0/0            222.192.124.3 LOG flags 0 level 4 prefix `VIP3-IN: '

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
  pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 34 packets, 3816 bytes)
  pkts bytes target     prot opt in     out     source               destination

А вот образец вывода tcpdump, показывающий входящие пакеты (tcpdump -n -nn -vvv -i eth1 "host 203.0.59.135"):

10:26:01.259409 IP (tos 0x50, ttl 121, id 26746, offset 0, flags [DF], proto TCP (6), length 52)
    203.0.59.135.62332 > 222.192.124.3.8888: Flags [S], cksum 0x8da8 (correct), seq 3373891789, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0

И наконец, ifconfig eth1:3 вывод:

eth1:3    Link encap:Ethernet  HWaddr 00:50:56:AC:35:35
      inet addr:222.192.124.3  Bcast:222.192.127.255  Mask:255.255.252.0
      UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1

ОБНОВИТЬ:

_{(источник: austintek.com)}

С помощью приведенной выше диаграммы я установил правила iptables в разных таблицах, чтобы увидеть, куда идут пакеты. Я придумал следующий сценарий:

IPT_FILTER="iptables -t filter"
IPT_MANGLE="iptables -t mangle"
IPT_NAT="iptables -t nat"

$IPT_FILTER -F
$IPT_FILTER -X
$IPT_FILTER -A INPUT -d 222.192.124.0/22 -j LOG --log-prefix "DEBUG filter: "
$IPT_FILTER -Z

$IPT_MANGLE -F
$IPT_MANGLE -X
$IPT_MANGLE -A PREROUTING -d 222.192.124.0/22 -j LOG --log-prefix "DEBUG mangle/prerouting: "
$IPT_MANGLE -A INPUT -d 222.192.124.0/22 -j LOG --log-prefix "DEBUG mangle/input: "
$IPT_MANGLE -Z

$IPT_NAT -F
$IPT_NAT -X
$IPT_NAT -A PREROUTING -d 222.192.124.0/22 -j LOG --log-prefix "DEBUG nat/prerouting: "
$IPT_NAT -Z

И похоже, что пакеты проходят через mangle/PREROUTING и nat/PREROUTING столы, но не попадайте в mangle/INPUT таблица, поэтому я предполагаю, что требуется ветка «Нет» в «Данные для брандмауэра». И я ни в коем случае не специалист по сетям или системам (в лучшем случае опытный пользователь), вот где я теряюсь и не понимаю, что происходит ...

ОКОНЧАТЕЛЬНОЕ РЕДАКТИРОВАНИЕ (решение)

Как предположил @nodens в их ответе, проблема была вызвана тем, что RPF находился в "строгом" режиме ... Столько головной боли для такой простой настройки ...