web-dev-qa-db-ja.com

nftablesとVLANを備えた透過ファイアウォール

透過ファイアウォールビルドのベストプラクティスのアドバイスをお願いしたいと思います。

ネットワークの2つのセグメントと2つの10Gインターフェイスを備えたCentOSサービスがあります。セグメント間のトラフィックをフィルタリング/監視/制限/ドロップしたい。トラフィックはタグ付けされています。フィルタリングのためにトラフィックのタグを外してタグを付ける必要がありますか、それともnftableがタグ付きのトラフィックを処理できますか？

スキームは次のようになります。

PCs--|                                         |--PCs
PCs--|--untag--[Switch]--tag--[Switch]--untag--|--PCs
PCs--|                                         |--PCs

が欲しいです：

PCs--|                                                              |--PCs
PCs--|--untag--[Switch]--tag--**[Firewall]**--tag--[Switch]--untag--|--PCs
PCs--|                                                              |--PCs
linuxfirewallvlannftables
4
Severgun

TL; DR：nftablesは、ブリッジレベルで、わずかに異なるルールを使用して、タグ付きパケットとタグなしパケットの両方を適切に処理できます。すべてのタグ付け作業は、VLAN対応ブリッジを使用してLinux側で実行できるため、ファイアウォールでnftablesを選択した場合でも、スイッチの構成を変更する必要はありません。

VLANのテストに関する多くの興味深いドキュメントは、これらのブログシリーズにあります（特に、いくつかの情報が完全に正確でない場合でも、パートIV）。

名前のないLinuxネットワーク名前空間でのveth-devices、Linuxブリッジ、VLANの楽しみ [〜＃〜] i [〜＃〜][〜＃〜] ii [〜＃〜] = [〜＃〜] iii [〜＃〜][〜＃〜] iv [〜＃〜][〜＃〜] v [〜＃ 〜][〜＃〜] vi [〜＃〜][〜＃〜] vii [〜＃〜][〜＃〜] viii [〜＃〜]

ファイアウォールの2つの最小限のモデルを（ネットワーク名前空間に）配置しましょう。 trunk100とtrunk200は、左側のコンピューターからvlan 100タグ付きパケットを送信し、右側のコンピューターからvlan200タグ付きパケットを送信する2つのスイッチにリンクされています。ここで、VLANタグは、反対側にサブインターフェースを作成することにより明示的に反対側に表示することが明示的に許可されていることに注意してくださいVLAN id、反対側のVLAN ID。

  1. タグなしパケットをブリッジに配置するVLANサブインターフェイス

    ip link add fw0 type bridge vlan_filtering 1
ip link set fw0 up
for trunk in 100 200; do
    for vlan in 100 200; do
        ip link add link trunk$trunk name trunk$trunk.$vlan type vlan id $vlan
        ip link set trunk$trunk.$vlan master fw0
        bridge vlan add vid $vlan pvid untagged dev trunk$trunk.$vlan
        bridge vlan del vid 1 dev trunk$trunk.$vlan
        ip link set trunk$trunk.$vlan up
    done
done
bridge vlan del vid 1 dev fw0 self

    この場合、trunk100およびtrunk200を介して到着するタグ付きパケットは、VLANごとのサブインターフェイスに分割され、パケットにはタグが付けられません。ブリッジは、使用中のVLANを内部的に認識しており、送信元と宛先にVLANフィルタリングを適用しています。 nftは独自の制限を追加します。発信パケットは、親トランクインターフェイスに到着すると再タグ付けされます。

  2. タグ付けされたパケットを直接ブリッジに

    ip link add fw0 type bridge vlan_filtering 1
ip link set fw0 up
for trunk in 100 200; do
    ip link set trunk$trunk master fw0
    for vlan in 100 200; do
        bridge vlan add vid $vlan tagged dev trunk$trunk
    done
    bridge vlan del vid 1 dev trunk$trunk
    ip link set trunk$trunk up
done
bridge vlan del vid 1 dev fw0 self

この単純なケースでは、タグ付きパケットはvlanタグを保持したままブリッジを通過します。

これは、両方のケースがどのように処理されるかを示す単一のnftablesルールセットです。ここでは、iifnameの代わりにiifが選択されているため、どちらの場合も同じルールセットが機能します（インターフェイスがないためにエラーが発生することはありません）。通常はiifを優先する必要があります。 （nft list ruleset -aを使用して）正確に一致した、または一致しなかったものを確認するための追加のカウンターエントリがあります。

#!/usr/sbin/nft -f

flush ruleset

table bridge filter {
    chain input {
        type filter hook input priority -200; policy drop;
    }

    chain forward {
        type filter hook forward priority -200; policy drop;
        counter
        arp operation request counter
        arp operation reply counter
        vlan type arp arp operation request counter
        vlan type arp arp operation reply counter
        arp operation request counter accept
        arp operation reply counter accept
        vlan type arp arp operation request counter accept
        vlan type arp arp operation reply counter accept
        ip protocol icmp icmp type echo-request counter
        ip protocol icmp icmp type echo-reply counter
        vlan type ip icmp type echo-request counter
        vlan type ip icmp type echo-reply counter
        iifname trunk100.100 ip protocol icmp icmp type echo-request counter accept
        oifname trunk100.200 ip protocol icmp icmp type echo-reply counter accept
        vlan id 100 vlan type ip icmp type echo-request counter accept
        vlan id 200 vlan type ip icmp type echo-reply counter accept
    }

    chain output {
        type filter hook output priority 200; policy drop;
    }
}

これらのルールはさらに詳細に記述されている可能性があることに注意してください。例：

iifname "trunk100.100" ether type ip ip protocol icmp icmp type echo-request

または

ether type vlan vlan id 200 vlan type ip ip protocol icmp icmp type echo-reply

最初のセットアップが使用されている場合（サブインターフェースを介したタグなしパケット）、従来のルールのみが一致します。 2番目のセットアップが使用されている場合、vlanを明示的に使用するルールのみが一致します。したがって、この一連のデュアルルールは、基本的なARP解決を許可し、VLAN 100からping VLAN 200までを許可しますが、その逆はできません。どちらの場合も機能します。 。

このルールセットは、CentOSのnftables v0.6（CentOSのカーネルではテストされていません）または現在のnftables v0.8.3で使用すると機能します。

現在の既知の制限：

V0.8.3以降のNftablesは、ebtables/iptablesの相互作用で可能だった方法でconntrackを使用できません。それについては計画があるようです。このPDFを参照してください： nftablesによるブリッジフィルタリング 。したがって、これによりステートフルルールの実装が非常に困難になります。

Nftablesにはまだ（0.8.3の時点で）表示の問題があることにも注意してください。オプションが使用されていない場合、nft list ruleset -aは「逆コンパイル」ルールからvlanを削除します。例、これらの2つのルール：

nft add rule bridge filter forward ip protocol icmp counter
nft add rule bridge filter forward vlan type ip ip protocol icmp counter

nft list ruleset -a（v0.8.3）で戻って表示された場合：

        ip protocol icmp counter packets 0 bytes 0 # handle 23
        ip protocol icmp counter packets 0 bytes 0 # handle 24

バイトコードをダンプするのはnft --debug=netlink list ruleset -aだけであり、これらが実際に2つの異なるルールであることは明らかです（データはここではリトルエンディアンです）。

bridge filter forward 23 22 
  [ payload load 2b @ link header + 12 => reg 1 ]
  [ cmp eq reg 1 0x00000008 ]
  [ payload load 1b @ network header + 9 => reg 1 ]
  [ cmp eq reg 1 0x00000001 ]
  [ counter pkts 0 bytes 0 ]

bridge filter forward 24 23 
  [ payload load 2b @ link header + 12 => reg 1 ]
  [ cmp eq reg 1 0x00000081 ]
  [ payload load 2b @ link header + 16 => reg 1 ]
  [ cmp eq reg 1 0x00000008 ]
  [ payload load 1b @ network header + 9 => reg 1 ]
  [ cmp eq reg 1 0x00000001 ]
  [ counter pkts 0 bytes 0 ]

CentOSのv0.6（カーネル4.15でテスト済み）にも、独自の異なる「逆コンパイル」表示の問題があります。

ip protocol icmp icmp type echo-request

次のように表示されます：

icmp type echo-request counter

これは、v0.6でそのまま試行すると構文エラーになります（v0.8.3では問題ありません）。

3
A.B