ebtable ルールでは、1 つのルールに vlanid および ipv4 プロトコルを指定することはできません。私もこれを試しましたが、2番目のルールはVLANパケットと一致しませんでした。
ebtables -t nat -A PREROUTING --vlan-id 100 -j mark --set-mark 100 --mark-target CONTINUE
ebtables -t nat -A PREROUTING -i <iface> --mark 100 --ip-dst <ip> -j dnat --to-dst <mac> --dnat-target ACCEPT
2 番目のルールは、パケットに VLAN ヘッダーがある場合は一致しないことです。一致する宛先IPアドレスとVLAN IDに基づいてDNAT macの方法はありますか？
答え1
これは、ブリッジフィルタリングに ebtables を使用する際の現在の制限です。 ebtables マッチングは一般的ではなく具体的であり、vlan-plus-ip マッチングを追加しないと、VLAN タグ付き IP を次のものと一致させることはできません。ebtables。
この制限を解決するには2つの方法があります。最初のアプローチは、他の場合には多くのタスクを実行しますが、特定のOPの問題を処理しません。
ブリッジネットワークフィルタ(この場合は適用されません)
多くの場合（実際にはこの場合ではない、以下を参照）何が関連する可能性がありますか？ebtables'スタッキングプロトコルが正しく処理されない場合は、ブリッジコードに次のタスクを実行するように指示します。アップリンク通話到着iptables渡すbr_netfilter モジュールの使用。まあ、そうです。iptablesルート/IPレベルではなくブリッジレベルで機能します。これは現在のシステム全体の変更であり、他のブリッジやその他の名前空間（これはネームスペースごとに行う必要があります。「まもなく」、おそらくカーネル5.3以降）。いくつかの意図しない効果とそれを防ぐ方法については、で説明されています。7.フレーム/パケットがiptables PREROUTING、FORWARD、およびPOSTROUTINGチェーンを通過する2つの可能な方法。
modprobe br_netfilter
sysctl -w net.bridge.bridge-nf-call-iptables=1 #actually default
あります。VLAN セクションに必要なアクションはありません。:
{ip,ip6,arp} テーブルがタグ付けされていないブリッジで VLAN タグ付き IPv4/IPv6/ARP トラフィックを表示できますか？
はい。カーネルバージョン2.6.0-test7以降にこの機能があります。この機能を無効にするには、上記の質問をご覧ください。
今ebtables/iptables 相互作用そうかもしれません。5. ブリッジされた IP パケットのチェーンパス。フレーム/パケットに少なくとも次のことを指示します。
-> ebtables nat/PREROUTING -> iptables nat/PREROUTING, then
-> ebtables filter/FORWARD -> iptables filter/FORWARD ....
他の場合もありますが、必須項目は存在しません。同じ呼び出し部分に戻ります。たとえば、次のようになります。
-> ebtables nat/PREROUTING -> iptables some/THING -> ebtables nat/PREROUTING
したがって、OPの特定のレイアウト（2番目のルールのインターフェイスの役割とMACアドレスの意味、ローカルなのかローカルなのかなど）によって異なりますが、いくつかのオプションが残っている可能性があります（必要）。パケット転送として表示されます）メッセージebtables到着iptables）、方法はありません。
これがまさにebtables / iptablesの代替案が最初からこれらのすべての混乱を避けるように設計された理由です。nftables。
nftables
代替nftables一般的な使い方を念頭に置いて設計すると、ブリッジパスまたはルーティングパスでIPを処理するときに同じことを行うために、わずかに異なるカーネルモジュールに頼る必要はありません。
nftablesは移動先なので、ほとんどの機能を得るにはnftables> = 0.8.3とカーネル> = 4.10を使用するのが最善です。これはnftables 0.9.0とカーネル5.1.xを使ってテストされました。古いnftables /カーネル（RHEL7 / CentOS7など）には必要なすべての機能がない可能性があるため、再テストする必要があります。
この特定のケースにはまだいくつかの制限がありますが、ユーザースペースにあるようです。nftablesカーネル側ではなく側で発生するので、これを克服するための2つの方法を提供しました。
パイプを追加してみましょう（例：aの後ろnft flush ruleset）。
nft add table bridge nat
nft add chain bridge nat prerouting '{ type filter hook prerouting priority -300; policy accept; }'
一致するIPが192.0.2.1でターゲットMACがある場合、通常はこの行で02:00:00:00:00:01操作を実行するのに十分です（nftablesのバージョンによっては多少冗長でなければなりませんが、とにかく冗長を選択しました。とにかくまったく同じバイトを生成します）バージョンとして表示されます）しかし失敗します。
# nft add rule bridge nat prerouting ether type vlan vlan id 100 vlan type ip ip daddr 192.0.2.1 ether daddr set 02:00:00:00:00:01
Error: conflicting protocols specified: vlan vs. ether
add rule bridge nat prerouting ether type vlan vlan id 100 vlan type ip ip daddr 192.0.2.1 ether daddr set 02:00:00:00:00:01
^^^^^^^^^^^
これnftablesユーザーレベルのツールは、次の手順に従って下位レベルのプロトコルの解析に戻ることを望まない。イーサネット-> VLAN-> IP。
この問題は、ユーザーチェーンからルールを分離し、そこに変更を適用することで解決できます。
nft add chain bridge nat mydnat
nft add rule bridge nat prerouting ether type vlan vlan id 100 vlan type ip ip daddr 192.0.2.1 jump mydnat
nft add rule bridge nat mydnat ether daddr set 02:00:00:00:00:01
または話すことによってnftables「これをやってください。理解しないでください」とは、元のペイロードを使用してリンク層の最初の48ビットを変更することを意味します（例：イーサネットターゲットMAC）。したがって、この行は上記の3行ではなく同じことを行います。
nft add rule bridge nat prerouting ether type vlan vlan id 100 vlan type ip ip daddr 192.0.2.1 @ll,0,48 set 0x020000000001
後者のメソッドは、実際には後者の3行目ではなく同じバイトコードを使用することに注意してください。
nft add rule bridge nat mydnat @ll,0,48 set 0x020000000001
ether daddr set 02:00:00:00:00:01チェーンにルールを表示すると、まったく同じように再デコードされます。ミッドナッツ。将来のバージョンを想像することができます。nftablesシングルライニングボックスとして受け付けます。
作成されたとおりに動作することを示すために（たとえば、ARPの追加ルールやOPなどのコンテキストなしでは期待どおりに動作しない可能性があります）、以下は192.0.2.1でpingを受信したときの受信側のtcpdumpです。
14:03:06.542085 9e:72:8c:20:15:2a > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 100, p 0, ethertype ARP, Request who-has 192.0.2.1 tell 192.0.2.2, length 28
14:03:06.542135 ae:3a:24:06:a7:da > 9e:72:8c:20:15:2a, ethertype 802.1Q (0x8100), length 46: vlan 100, p 0, ethertype ARP, Reply 192.0.2.1 is-at ae:3a:24:06:a7:da, length 28
14:03:06.542184 9e:72:8c:20:15:2a > 02:00:00:00:00:01, ethertype 802.1Q (0x8100), length 102: vlan 100, p 0, ethertype IPv4, 192.0.2.2 > 192.0.2.1: ICMP echo request, id 21702, seq 1, length 64
他のIP 192.0.2.11は影響を受けません。
14:11:04.026480 9e:72:8c:20:15:2a > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 100, p 0, ethertype ARP, Request who-has 192.0.2.11 tell 192.0.2.2, length 28
14:11:04.026491 ae:3a:24:06:a7:da > 9e:72:8c:20:15:2a, ethertype 802.1Q (0x8100), length 46: vlan 100, p 0, ethertype ARP, Reply 192.0.2.11 is-at ae:3a:24:06:a7:da, length 28
14:11:04.026505 9e:72:8c:20:15:2a > ae:3a:24:06:a7:da, ethertype 802.1Q (0x8100), length 102: vlan 100, p 0, ethertype IPv4, 192.0.2.2 > 192.0.2.11: ICMP echo request, id 21895, seq 1, length 64
14:11:04.026515 ae:3a:24:06:a7:da > 9e:72:8c:20:15:2a, ethertype 802.1Q (0x8100), length 102: vlan 100, p 0, ethertype IPv4, 192.0.2.11 > 192.0.2.2: ICMP echo reply, id 21895, seq 1, length 64