qemu guestを見回している間、非常に奇妙なことがわかりました。ゲートウェイに向かうすべてのトラフィックを拒否するようにシステムファイアウォールを設定すると（10.0.2.2）、ファイアウォールはゲートウェイに直接移動するトラフィックのみを拒否します。宛先ではないように見えるトラフィックは、ルールが10.0.2.2存在しなかったかのようにルーティングされ、ゲートウェイを通って流れます。
顧客の立場から私が理解したところによると10.0.2.15：
Packet{dest==10.0.2.0/24} 10.0.2.15 -x-> 10.0.2.2 (Rejected)
Packet{dest!=10.0.2.0/24} 10.0.2.15 <--> 10.0.2.2 <-> !=10.0.2.0/24 (Okay)
これは私が期待していたものとまったく逆です。何か抜けたようですが、なにかわかりません。
これは私の設定です。
- ファイアウォールルール：
ufw reject out to 10.0.2.0/24 - 出力
ip route：default via 10.0.2.2 dev ens3 proto dhcp metric 100 10.0.2.0/24 dev ens3 proto kernel scope link src 10.0.2.15 metric 100 - 出力の関連部分は
iptables -S次のとおりです。-A ufw-user-output -d 10.0.2.0/24 -j REJECT --reject-with icmp-port-unreachable
ベストアンサー1
これは有効で、ゲートウェイが送信元 IP アドレスと宛先 IP アドレスのパケットをルーティングするため、ブロックされません。いいえゲートウェイのアドレスです。いいえIPv4アドレスが10.0.2.2のパケット（ARPの以下を参照）は、IPアドレスが10.0.2.2/24のゲートウェイを介して正常にルーティングするために使用されます。
したがって、10.0.2.15 が 8.8.8.8 にパケットを送信する場合、パケットの送信元アドレスは 10.0.2.15、宛先アドレスは 8.8.8.8 です。パケットには宛先 10.0.2.2 がないため、10.0.2.0/24 の範囲に宛先はありません。合格。
ゲートウェイを介してルーティングされるペイロードに関連する唯一の間接的な方法は、IPv4アドレスが10.0.2.2のパケットがIPv4パケットではないことです。彼らARPVM システムがゲートウェイ インターフェイスのイーサネット MAC アドレスを取得（およびその ARP テーブルにキャッシュ）するために使用するパケット。 IPv4トラフィック「外部」：ルートはゲートウェイと一致し、リンク層（イーサネット）からこのMACアドレス（IPアドレス10.0.2.2ではなく）に送信されます。
ARPはフィルタリングされません。iptablesこれはUFWバックエンドなので、UFWによってブロックすることはできません。それは関係があるかもしれませんarpテーブルたとえば、有用なユースケースは一般的ではありません。
ノート
動的ホスト構成プロトコル（IPv4）
10.0.2.2が仮想マシンのDHCPサーバーでもある場合、これは使用された特定の技術によって将来の特定の時点でDHCP通信が正しく機能しないようにしたり、仮想マシンにブロードキャストDHCP検索を実行するように強制することも、そうでない場合もあります。 。ユニキャストDHCP要求の代わりに。数時間後にリースが失われる可能性がある場合、IPアドレスも失われてルーティングされるため、ルータを介して間接的に接続されます。
通常、LinuxのDHCPは通常、ソースアドレスをバイパスするRAWソケット（ソースアドレス0.0.0.0を正しく処理する）に依存する必要があるため、通常そうではありません。iptablesルール。
IPv6
IPv6のリンクレイヤ解決プロトコルはARPではなくICMPv6の使用したがって、IPv6の一部であり、フィルタリングされています。IP6テーブル, IPv4 に有効な仮定の一部は IPv6 には無効です。たとえば、ICMPv6 を無差別にブロックすると、IPv6 接続が急激に切断され、次の方法で得られたルーティング可能な IPv6 アドレスが削除されることがよくあります。SLAAC、IPv4を無差別にブロックするICMPは通常うまく機能しますが（可能な場合を除く）PMTUDブラックホールの問題）。