web-dev-qa-db-ja.com

仮想IPで送信されたパケットがiptablesルールにヒットしない

IPアドレスeth1:3の仮想インターフェイス222.192.124.3があり、インターフェイスのIPを使用してそのインターフェイスに着信するパケットをログに記録するiptablesルールを設定しました（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ルールを削除し、ロギングルールのみを追加しましたが、これ以上成功しませんでした。

サーバーは、VMwareESXで仮想化された2.6.32カーネルを備えたRHEL6.2で実行されています。

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 -n -nn -vvv -i eth1 "Host 203.0.59.135"）を示すtcpdumpの出力のサンプルです。

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

UPDATE：

iptables diagram
（出典： 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テーブルにはヒットしないので、 "Data for theファイアウォール」。そして、決してネットワークやシステムのエキスパートではない（多くてもパワーユーザー）ので、ここで迷子になり、何が起こっているのか理解できません...

最終編集（解決策）

@nodensの回答で示唆されているように、この問題はRPFが「厳密」モードになっていることが原因でした...このような単純な設定では非常に多くの頭痛の種です...

linuxnetworkingiptablesrhel6
5
mdeous

他のテーブル（mangleやnatなど）に一致するルールがないと確信していますか？ RHEL 6で利用可能な場合は、INPUTに入ってくるすべてのパケットをログに記録することもできます。さらに良いのは、生のテーブル（PREROUTINGチェーン）でTRACEターゲットを試すことです。

編集（まだコメントを追加できません）：

OK、パケットはインターフェイスに到達しましたが、ローカルで処理する必要があるパケットとは見なされません。ルーティングテーブルを確認してください。このネットワークへのスコープリンクルートがないか、RPFフィルターが原因でパケットがカーネルによってドロップされます（これはネットワークトポロジによっては発生する可能性があります）：check https：/ /access.redhat.com/site/solutions/53031

3
nodens

仮想インターフェイスはカーネルレベルでは存在しません。これらは、ifconfigによってアドレスに付けられるエイリアスです。前の千年紀の終わり以来、それらは使用されるべきではありません。

Iptablesについて。これはカーネルレベルのインターフェイスではないため、実際のインターフェイス名でフィルタリングする必要があります。あなたの場合、eth1。厳密にしたい場合は、可能であればソースネットワークでフィルタリングして、仮想インターフェイス名を使用して実行しようとしていたことを模倣する必要があります。

0
Eric Leblond