nftables：セグメント間の冗長ブロードキャストパケット

nftablesはまだ利用可能です。Web開発者家族（代わりにアイピー家族）この場合のみ入り口必須（nftablesにはまだ出口書くことができる）。dup調和fwdのとれた行動入り口とつながるTCミラー'mirror砂redirect。

また、小さな詳細についても議論しました。これは、イーサネットソースアドレスを新しいイーサネット送信インターフェイスのMACアドレスに書き換えることです。実際にルーティングされたパケットを使用しているかのように、パケットなしで動作します。したがって、インターフェイスのMACアドレスを事前に知っておく必要があります。必要な２つを入れました（イーサネット0'砂イーサネット1's)の変数/マクロで定義を正しい値に編集する必要があります。

define eth0mac = 02:0a:00:00:00:01
define eth1mac = 02:0b:00:00:00:01

table netdev statelessnat
delete table netdev statelessnat

table netdev statelessnat {
    chain b { type filter hook ingress device eth1 priority 0;
        pkttype broadcast ether type ip ip daddr 192.168.1.255 udp dport 21027 jump b-to-a
        
    }

    chain c { type filter hook ingress device eth2 priority 0;
        pkttype broadcast ether type ip ip daddr 192.168.2.255 udp dport 21027 counter jump c-to-b-a
    }

    chain b-to-a {
        ether saddr set $eth0mac ip daddr set 192.168.0.255 fwd to eth0
    }

    chain c-to-b-a {
        ether saddr set $eth1mac ip daddr set 192.168.1.255 dup to eth1 goto b-to-a
    }
}

編集：後でこの質問を探している人にABが許可する答えは、純粋なnftソリューションを提供します。

ABの提案のおかげで、これは純粋なnftablesルールの代わりにtcを使用して機能します。

tc qdisc add dev eth2 ingress
tc filter add dev eth2 ingress \
    protocol ip u32 \
    match ip dst 192.168.2.255 \
    match ip protocol 17 0xff \
    match ip dport 21027 0xffff \
    action nat ingress 192.168.2.255/32 192.168.0.255 \
    pipe action mirred egress mirror dev eth0 \
    pipe action nat ingress 192.168.0.255/32 192.168.1.255 \
    pipe action mirred egress redirect dev eth1

tc qdisc add dev eth1 ingress
tc filter add dev eth1 ingress \
    protocol ip u32 \
    match ip dst 192.168.1.255 \
    match ip protocol 17 0xff \
    match ip dport 21027 0xffff \
    action nat ingress 192.168.1.255/32 192.168.0.255 \
    pipe action mirred egress redirect dev eth0

これらのフィルタについて私が理解したのは、UDPポート21027の着信ブロードキャストパケットと一致し、それを予想される他のすべてのサブネットのブロードキャストアドレスにNATしてから（変更される送信元IPではなくingress宛先IPの変更nat egress）、コピー/リダイレクトNATed転送を送信することです。パケットを別のインターフェイスの出力キューに送信します。

tcを初めて使用する場合、これが問題を解決するための最良の方法ではないかもしれませんが、通知ブロードキャストがセグメント全体に伝播する可能性があります（Syncthingは新しいノードを見つけてうれしく思います）。