それマグで!

知識はカップより、マグでゆっくり頂きます。 takuya_1stのブログ

習慣に早くから配慮した者は、 おそらく人生の実りも大きい。

nftablesでaccept後のdropにマッチを回避できない。

nftablesでacceptとdropにマッチするとdropになる問題

nftablesを使ってると、accept しても他のテーブルでreject(drop)されてしまうことがある。

複数テーブルでaccept と dropが混合しちゃう

例えば、tableAとtableBにforwardの許可設定を書くわけよ。tableAでAcceptしてるのに、tableBで reject されるから、結果として reject になっちゃう。

table ip tableA {
    chain forward {
        type filter hook forward priority filter; policy drop;
        iifname br0 oifname eth1 ip6 daddr 1.1.1.1 accept comment "# cf"
        jump handle_reject
    }
}
table inet tableB {
    chain forward {
        type filter hook forward priority filter; policy drop;
        $RULE_A accept 
        jump handle_reject
    }
}

8.8.8.8へのforwardを許可する例と拒否する例を同時に入れる。

例えば、8.8.8.8 との通信を許可(Accept)と拒否(Reject)を同時に入れるとどうなるかを見てみよう。

先に結果を述べておくと accept & rejectつまり、true & false となり結果はfalse(拒否・REJECT)になる

8.8.8.8 をforward accept する

nft create table ip allow8888
nft create chain ip allow8888 forward { type filter hook forward priority filter\; policy drop\; }
nft add rule  ip allow8888 forward iifname br0 oifname wan0 ip daddr 8.8.8.8 counter accept
nft list table ip allow8888

8.8.8.8 をforward reject する

nft create table ip deny8888
nft create chain ip deny8888 forward { type filter hook forward priority filter\; policy accept\; }
nft add rule  ip deny8888 forward iifname br0 oifname wan0 ip daddr 8.8.8.8 counter reject
nft list table ip deny8888

パケット送るとreject(unreachable)になる

PS C:\Users\takuya> ping 8.8.8.8

Pinging 8.8.8.8 with 32 bytes of data:
Reply from 192.168.1.1: Destination port unreachable.
Reply from 192.168.1.1: Destination port unreachable.
Reply from 192.168.1.1: Destination port unreachable.
Reply from 192.168.1.1: Destination port unreachable.

カウンタ結果は次のようになる。

table ip deny8888 {
  chain forward {
    type filter hook forward priority filter; policy drop;
    iifname "br0" oifname "wan0" ip daddr 8.8.8.8 counter packets 8 bytes 520 reject
  }
}
table ip allow8888 {
  chain forward {
    type filter hook forward priority filter; policy drop;
    iifname "br0" oifname "wan0" ip daddr 8.8.8.8 counter packets 8 bytes 520 accept
  }
}

カウンタ結果を見ると一目瞭然だが、両方のカウンタが回っている。すなわち、パケットは正しく処理されている。AcceptされたあとにRejectが評価されるのだ。

これはPriorityだろうと思うかもしれ無いが、優先度を変えても結果は同じである。accept が先に処理されてもあとからRejectされるし、Rejectを先にするとAcceptまで到達しない。

ということなので、ブロックされるルールの直前にルールを差し込む必要がある。

どうしたらいいんだ。nftables。accept箇所の先もあるんだ。Acceptでは移行をスキップできないんだ止まらいんだ。どうすれば良いのか。

ちゃんと、insert して指定場所に突っ込むしか無い。

めんどくさいことこの上ないが、ちゃんとルールをINSERTして指定場所に差し込む必要がある。

そうすると、こんどはforwardにルールが集中してしまう、そしてjump があるために、追いかけるのが更に面倒になる。

forwardを見てもjump 、jump jump jump の多段Jumpが大量に記載されることになり、iptablesより追いかけるのが面倒になり・・・

困っちゃうよ。nftables

jump 追いかけるのが面倒。

複数テーブルと複数のチェインがあるので、追いかけにくい。どこでDropされてるのかはcounterを入れて調べることができる。jump さきで jump されてしまうと脳内メモリが追いつかない。

しかし、drop されているルールを回避するのはめんどくさい。

nftables test dump みたいなコマンドがほしい。どのjumpを通ってどこにマッチしてdrop/rejectされてるのか追いかけるのが大変だよ。

nft monitor trace

一応、nft monitormeta nftrace set 1 で追いかけることができるのだが。

nft add chain inet fw4 filter  { type filter hook prerouting priority -301\; }
nft add rule  inet fw4 filter trace_chain meta nftrace set 1

nftace がなんか動かないんですよねぇ。

Error: syntax error, unexpected meta
add rule inet fw4 filter trace_chain meta nftrace set 1

もしかしたら、カーネルモジュール??

counterで地道に追いかけてるけど地獄。。。