私が遭遇した情報のほとんどは、ブリッジ接続を使用してKVMファイアウォールを設定する傾向があります。
私の理解では、ネットワークトラフィックが最初にファイアウォールを通過せずにホストに到達できる場合、セキュリティ上のリスクがあります。
メインのNIC(eg _eth0
_)が仮想マシンとして設定されているのを見てきましたNICただし、これにより、ホストは_eth0
_?
頭に浮かぶ他のオプションは、NICのPCIパススルーですが、メソッドで問題が発生しました。
ホストトラフィックが最初にファイアウォールを通過することを要求する他のアプローチはありますか?どの方法を使用することをお勧めしますか?
最初のアイデアは、VMへのネットワークアクセスを追加するために使用されるインターフェイスと、ホストの制御に使用されるインターフェイスを分離することです。多くの場合、3番目のインターフェイスセットは、ある種のネットワーク共有ストレージ上のVMイメージにアクセスするために使用されます。したがって、理想的には6つのインターフェイスがあります。4つはギガビットイーサネット、2つは10ギガビットイーサネットです。
2番目のアイデアは、ホストと仮想マシンに異なる802.1qVLANを使用できるということです。私は3つの異なるVLANにVMがあるネットワークを構築しましたが、1つのVMが複数のVLANに参加する可能性があります(複数の仮想NICを作成し、ホスト上のいくつかの異なるVLANでブリッジすることにより)
サーバーのハードウェアには、ホストの帯域外制御に使用されるBMCがあることに注意してください。基本的に、これはホストコンピューターのセンサーにアクセスできる小さなコンピューターであり、値(温度、ファンrpm)、電源のオン/オフ/リセットをボタンを押すように表示でき、IP KVM =機能など、独自のネットワークアドレスを持ちます。通常はIPMIプロトコルも実装します。LAN1と共有されるものとして公開されることがよくあります(つまり、小さなスイッチのように、スイッチではありません。ホストとBMCは通信できませんでしたが、両方そのうちの1つは外部デバイスと通信します)またはBMCに排他的にルーティングされる独立したイーサネットジャック。ブレードシステムは、各ブレードサーバーではなく、ケージごとに1つまたは2つの(冗長)BMCを持つことができます。
安全なセットアップは次のようになります。
bond0はLACPによって結合された(eth0、eth1)であり、ホストにIPアドレスがあり、ホストを制御するために使用されます。
bond1は(eth2、eth3)LACPによって結合されます。これはVLANで分割されます。つまり、ホストにはbond1.10、bond1.552仮想サブインターフェイスなどがあります。作成されたブリッジがあります:br10ブリッジbond1.10およびすべてのVM参加するVMのホスト側インターフェイスvlan 10では、br552はbond1.552とすべてのVM vlan 522のホスト側など)をブリッジします。これらのインターフェイスはどちらもIPアドレスを持たないため、VMはホストと通信できませんでした。
bond2は(eth4、eth5)結合され、VM iSCSI、CEPH経由でディスクイメージにアクセスし、DRBDなどを同期するために使用されます。ホストにIPがありますが、完全に分離されたストレージに接続されています特別な要件を持つネットワーク。
vMがホストと通信できるだけでなく、ホストの制御ネットワークを飽和させるためにも、bond0とbond1は物理的に分離することをお勧めします。そのネットワークは、たとえば、他のホストへのライブマイグレーションの場合に仮想マシンのメモリコンテンツを転送するために使用され、VMはこのプロセスのパフォーマンスを飽和させる可能性はありません。
5つの仮想マシンをホストする1つの物理インターフェイスを備えた小さなシステムを構築していて、bond0とbond1の機能を組み合わせる必要がある場合でも、IPアドレスは物理インターフェイス(デフォルト/ネイティブVLANとしてアクセス可能)とブリッジに参加しているサブインターフェイスにのみ持つことができます。 VMホスト側アダプター、すべてタグ付き。それでもVMはホストに直接アクセスできず、インテリジェントL2スイッチと個別のファイアウォールデバイスまたはL3スイッチのみでVLAN間ルーティングとトラフィックフィルタリングを実行できます。 。
Linuxブリッジは、ホスト上に対応するネットワークインターフェイス(例:br0
)を作成するため、ホストOSからブリッジに完全にアクセスできないようにする方法はないと思います。ファイアウォールVMが実行されている場合、brctl show
は、インターフェイスeth0
とvnet0
がファイアウォールに接続されていることを通知しますが、実際にはthree-ポートスイッチ:1つのポートはeth0
に行き、1つはvnet0
(VM)に行き、もう1つはホストのbr0
インターフェースに行きます。
おそらく、ホストのbr0
インターフェイスとの間で送受信されるすべてのフレームをブロックするために、いくつかの ebtables ルールを設定できます。それが最善のアプローチかもしれませんが、それを行う方法の詳細を提供するためのebtablesについては十分に知りません。
もう1つのオプションは、ブリッジインターフェイスにIPアドレスを設定しないことです。これにより、通常のアプリケーションがブリッジインターフェイスを介して通信できなくなります。 root権限を持つWiresharkなどのアプリケーションからは引き続きアクセスできます(これは便利な場合があります)。
Debianベースのシステム(Ubuntuなど)では、/etc/network/interfaces
に次のように入力できます。
auto br0
iface br0 inet manual
bridge_ports eth0
bridge_stp off
「手動」とは、「インターフェイスを起動するときにアドレスを割り当てない」ことを意味します。これは、他の何かが後でアドレスを割り当てるセットアップを対象としていますが、アドレスがまったく必要ない場合にも機能します。
唯一の例外はIPv6リンクローカルアドレスです。これは、ディストリビューションのネットワーク設定スクリプトではなくカーネルによって自動的に割り当てられるため、「手動」設定でも取得できます。インターフェイスでIPv6を完全に無効にすることで、これを回避できます。 /etc/sysctl.d
にファイルを作成し、次のように配置します。
net.ipv6.conf.br0.disable_ipv6=1
(インターフェイスでもIPv4を完全に無効にできると便利ですが、それに対応するオプションはありません。)