私のLinuxコンピュータには次の設定があります。
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether bc:e6:7c:51:20:6b txqueuelen 1000 (Ethernet)
br0.1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.103 netmask 255.255.255.0 broadcast 192.168.0.255
ether bc:e6:7c:51:20:6b txqueuelen 1000 (Ethernet)
br0.2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 20.20.20.1 netmask 255.255.255.0 broadcast 20.20.20.255
ether bc:e6:7c:4d:8f:b0 txqueuelen 1000 (Ethernet)
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether bc:e6:7c:51:20:6b txqueuelen 1000 (Ethernet)
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether bc:e6:7c:51:3a:b0 txqueuelen 0 (Ethernet)
/ # brctl show
bridge name bridge id STP enabled interfaces
br0 8000.bce67c51206b no eth0
eth1
2つのレイヤ3インターフェイスがあり、br0.1
ブリッジのbr0.2
上部に作成されます。これはbr0.2
、.NET経由でLAN側クライアントにDHCPサービスが提供される非定型NAT構成ですeth1
。固定IP 20.20.20.1を持ち、br0.1
WANポートを介して接続し、eth0
DHCPを介してDHCPからIPを取得しますeth0
。
リアルーティングチェーンにもマスカレードルールがあります。
table ip haswell-nat {
chain haswell-postrouting {
type nat hook postrouting priority mangle; policy accept;
ip saddr 20.20.20.0/24 masquerade
}
}
- クライアント(20.20.20.2)からデフォルトゲートウェイ192.168.0.10にpingすると、NATが発生します。
- パケットが192.168.0.103から来ていることを確認しました。
このpingパケットがブリッジされたインターフェイスeth0
にあるので、どのようになりすましているのか疑問に思います。eth1
通常、eth0
およびeth1
は別々のインターフェイスであり、ブリッジの下にはありません。
ブリッジの下にある場合はIP層にあるので、iptableルールに触れることなくパケットを別のインターフェイスに転送する必要がありますか?
編集:ブリッジはVLANを認識します。
/ # bridge vlan show
port vlan-id
eth0 1 PVID Egress Untagged
2
15
br0 1
2
15
eth1 1 PVID Egress Untagged
答え1
OPはすべての詳細を提供しているわけではありませんが、
br0.1はeth0を介してwanポートに接続し、eth0を介してDHCPからIPを取得します。
br0.2 は、eth1 を介して接続された LAN 側クライアントに DHCP を提供します。
私は推測することができますイーサネット0そしてイーサネット1VLANタグ付きトラフィックは、そのポートにVLANが設定されているスイッチなどの外部デバイスから受信され、タグ付きトラフィックはbr0(VLAN認識で設定されていないか、OPで説明されているように設定されていません)
このVLANでタグ付けされたトラフィックはスイッチによってフィルタリングされるため、「相手」に漏れません。
このトラフィック返品ブリッジの独自のインターフェースに到着:参加したいインターフェースルーティング。その上に VLAN サブインターフェイスを設定して、複数のインターフェイスが着信トラフィック ルーティングに参加できるようにすることができます。これは2つのインターフェースを持つルーターになります。br0.1そしてbr0.2ルーティングに参加する(br0また、参加するがIPアドレスが設定されていないので参加しません。 ARPとの可能な相互作用は無視できます。
私の仮説が少し間違っても構いません。ルーティング代わりにブリッジング起こります。
イーサネット0そしてイーサネット1ルーティングには関与しません。ただブリッジポートです。同様に、br0アドレスがないため、ルーティングに参加せず、使用するルートが追加されていないと想定できます。
ルーティングに関連する残りのインターフェイスは次のとおりです。
- br0.1:広域ネットワーク
- br0.2: LAN
私はRoute(ip route
)が次のようになると仮定できます:
# ip route
default via 192.168.0.10 dev br0.1
20.20.20.0/24 dev br0.2 proto kernel scope link src 20.20.20.1
192.168.0.0/24 dev br0.1 proto kernel scope link src 192.168.0.103
これから、ブリッジまたはブリッジポートの介入を無視できます。トラフィックが到着するとbr0.1またはbr0.2それではこれになるルーティング済み代わりに、イーサネットに似たインターフェイスを介したIPパケットブリッジ額縁。
Webフィルタつながる(および NAT) IP アドレスとともに使用nftablesインターフェイスを介して動作を選択できます。ここで設定されたルールにはインターフェイス名は含まれず、アドレスのみが含まれます。つまり、IP ソースが 20.20.20.0/24 のパケットが nat/postrouting で偽装されるたびに適用されます。
2つの状況は次のとおりです。
デフォルト以外のソースアドレス 20.20.20.1 を使用してシステムでローカルに開始されたフローは NAT を通過します。
20.20.20.0/24でルーティングされたパケットはNATを通過します。
要求がクライアント 20.20.20.2 から別のクライアント 20.20.20.3 に送信されると、このトラフィックは次のようになります。ブリッジ代わりにルーティング済み:(ARPブロードキャストを除く)決して到着しません。br0、br0.1またはbr0.2そしてルーティングは発生しません。これnftablesIPフックはまったく使用されず、NATは発生しません(カーネルモジュールbr_netfilter
荷物を積んだこれは得るNATはブリッジされたトラフィックで機能できます。また。これは絶対に必要または組み合わせてはいけません。nftables.)