☰

ルーティングポリシーデータベースが表示されたパケットを検出できません。

tag-icon • tag-icon iptables routing netfilter
ルーティングポリシーデータベースが表示されたパケットを検出できません。

mangle1宛先アドレスが次の場合、私のラボサーバーには次のテーブルルールがあります6.6.6.6。

$ sudo iptables -t mangle -L PREROUTING 2 -v -n --line-numbers
2       17   884 MARK       udp  --  ge-0.0.0-Iosv6 *       0.0.0.0/0            6.6.6.6              MARK set 0x1
$

6.6.6.6/32loこのサーバーに構成します。上記のルールカウンタは、traceroute実行するたびに6.6.6.6増加します。これは予想される結果です。つまり、パケットが表示されているようです。私のルーティングポリシーデータベースは次のとおりです。

$ ip rule show
0:      from all lookup local
32764:  from all fwmark 0x2 lookup twohundred
32765:  from all fwmark 0x1 lookup threehundred
32766:  from all lookup main
32767:  from all lookup default
$

..テーブルはthreehundred次のとおりです。

$ ip r sh table threehundred
default via 192.168.100.2 dev ge-0.0.0-Iosv6
$

ただし、タグ付きパケットはテーブル内のエントリに基づいてルーティングされませんthreehundred。承認によってサーバーを介してUDPパケットをmain取得できますが、ICMP応答はテーブルに関連付けられているデフォルトパスを介して送信されます。前述のように、この期間中にテーブルルール＃2が増加します。tcpdumpge-0.0.0-Iosv6port unreachableeth0mainmanglePREROUTING

この動作の原因は何ですか？私はUbuntu 16.04.6 LTSを実行しています。

ベストアンサー1

これは一般ネットワークのNetfilterとパケットフロー模式図：

一般ネットワークのNetfilterとパケットフロー

受信パケットはPREROUTINGに示されていますが、ローカルで生成された応答パケットはOUTPUTを通過します。そこに表示するルールがないので表示そして路線も違います。

mangle / OUTPUTでパケットを変更すると（タグの変更などのメタ情報を含む）、パスリダイレクトチェックがトリガーされます。このパスは次のパスを変更する必要があります。イーサネット0到着ge-0.0.0-Iosv6（注：nftables変えるiptables、献身的な路線この効果を得るには接続が必要です。）この規則は次のことを行います。

iptables -t mangle -A OUTPUT -s 6.6.6.6 -j MARK --set-mark 1

2つの方法で、特定のルールで個々のパケットを表示するのではなく、フロー全体を自動的に表示できます。つながる）。これコマック競争とそのコマック対象対応物を使用できます。このブログでは使用例を提供します。ネットフィルターコマック。

この場合、代わりにiptables上記の規則：

  • mangle/PREROUTING の最後の規則でなければなりません。

    iptables -t mangle -A PREROUTING -m mark ! --mark 0 -j CONNMARK --save-mark

  • mangle / OUTPUTの最初のルールである必要があるため、必要に応じて変更を続けることができます。これにより、パスリダイレクト確認が実行されます。

    iptables -t mangle -I OUTPUT -m connmark ! --mark 0 -j CONNMARK --restore-mark

テストがなければ、安定して予測するのが難しく、知っておくべきことがいくつかあります。

  • スイッチfwmark_reflect（例sysctl -w net.ipv4.fwmark_reflect=1：）はこの特定のケースで十分であり、上記の規則の代わりに使用できますが、より一般的な場合には役に立ちません。またありますtcp_fwmark_acceptTCP状況を軽減します。 UDPのような他のプロトコルには同様のプロトコルはありません。

  • 時々パスが失敗する今後ルートリダイレクト確認のため厳格なリバースパスの転送そして、パケットは表示され、再ルーティングされる前に早期に廃棄される。明らかにここではそうではありません（SRPFがアクティブではない可能性があります）。ただし、そのような場合は、関連するインターフェイスのいずれかを緩いモードに変更してチェックを軽減する必要があります（どのインターフェイスであるかを判断するにはテストを実行する必要があります）。rp_filter設定（例sysctl -w net.ipv4.conf.eth0.rp_filter=2）。

  • 場合によっては追加のパスがある場合があります。基本テーブルは置換される前に読み取られるため、追加されたテーブルにコピーする必要があります。基本テーブルが一致しない可能性があります。いつ、特にいつ必要なのかを把握するのは難しいです。噴水すべて関連しています。たとえば、

    ip route add table threehundred 192.168.100.2/32 dev ge-0.0.0-Iosv6

  • ip route get ...適切なコマンドが提供されても、そのコマンドがmark現在起こっていることを常に正確に予測するわけではないようです。噴水そしてiptablesすべて関連しています。

  • マーカー、パス、および予測間の相互作用に関連する動作は、文書化されていないコンテンツを介して変更される可能性ip route getがあります。src_valid_markトグル（経由でも利用可能sysctl）問題が解決しそうな場合にのみ使用してください。

  • ポリシー ルーティングでは、UDP サーバーの動作が TCP サーバーの動作と異なることがわかります。その理由は複雑で説明が困難です。使用噴水複雑さだけが重み付けされます。

おすすめ記事