
netfilter
INPUT
私のチェーンから拒否されたトラフィックが私のチェーンを通過できるようです。問題のパケットに適用されるチェーンOUTPUT
のルールは次のとおりです。INPUT
LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 6 prefix "ICATCH:"
REJECT-PKT all -- * * 0.0.0.0/0 0.0.0.0/0
ユーザー定義REJECT-PKT
チェーンとその関連ルール:
REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp reject-with tcp-reset
記録された結果は次のとおりです。
May 15 06:41:51 li51-144 kernel: ICATCH:IN=eth0 OUT= MAC=f2:3c:91:1f:61:44:84:78:ac:0d:97:c1:08:00 SRC=188.138.135.9 DST=<my IP> LEN=40 TOS=0x00 PREC=0x00 TTL=46 ID=46841 PROTO=TCP SPT=8838 DPT=23 WINDOW=22014 RES=0x00 SYN URGP=0
May 15 06:41:51 li51-144 kernel: OCATCH:IN= OUT=eth0 SRC=<my IP> DST=188.138.135.9 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=23 DPT=8838 WINDOW=0 RES=0x00 ACK RST URGP=0
2 行目は、表の次の (最後から 2 番目の) ルールによって生成されますOUTPUT
。
LOG all -- 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 6 prefix "OCATCH:"
拒否されたパケットはカーネルによって何らかの形でマークされ、ルールRST
の結果として生じたフラグを持つ TCP トラフィックはiptables
ファイアウォールによって処理されないという印象を受けました。
何を誤解しているのでしょうか?
答え1
@Aaron が言ったように、これは正常です。
着信パケットがREJECT
ルールに到達すると、netfilter によって処理され、RST
パケットとメッセージが送信者に返信されます。
ただし、代わりに に設定するとDROP
、ソースはメッセージを受信しません。
このリンクを確認してください: DROPとREJECTの違い
tcpdump
実行するかwireshark
、出力をキャプチャしてハブの下で何が起こっているかを確認する価値があります。