OpenStackセキュリティグループの実装原理の簡単な説明

[[283112]]

1. iptables の紹介

1.1 iptables の概要

OpenStack セキュリティ グループを紹介する前に、iptables について簡単に紹介しましょう。実際、iptables は単なるユーザー空間プログラムです。実際の作業は Linux カーネルの netfilter です。 iptables を通じて新しいルールを作成すると、実際には、データ パケットを変更し、データ パケットのフローを制御するためのフックが netfilter に挿入されます。 iptablesの使用に慣れていない人は、iptablesの図解説明[1]を参照してください。

簡単に言えば、iptables は一連のルール条件の一致を通じて指定されたアクションを実行するため、ルールは条件 + アクションで構成されます。条件には、送信元 IP アドレス、レイヤー 4 プロトコル、ポートなどが含まれ、アクションにはパケットの拒否、通過、破棄、変更などが含まれます。アクションは通常、-j パラメータによって指定されます。

たとえば、ターゲット ポート 22 への 192.168.1.2 のアクセスを拒否するには、次の iptables ルールを追加するだけです。

上記の通り:

• -t はテーブルを指定します。すべてのルールが混在すると、非常に混乱が生じます。したがって、iptables は機能に応じてさまざまなテーブルに分割されます。パケットフィルタリングはfilterテーブルに配置され、NATはnatテーブルに配置されます。また、rawテーブル、mangleテーブル、securityテーブル、合計5つのテーブルがあります。このパラメータが指定されていない場合は、デフォルトでフィルタ テーブルが選択されます。
• -I は挿入操作を意味し、このルールを先頭に挿入します。対応するパラメータは -A で、これは末尾からルールを追加することを意味します。 -I と -A では、後ろのインデックス位置を指定して、指定した位置にルールを挿入することもできます。
• INPUT はチェーン名を表します。チェーンはリンク リストと見なすことができ、リンク リストの要素はルールです。 Iptables は、PREROUTING、INPUT、FORWARD、OUTPUT、POSTROUTING の合計 5 つのチェーンを操作できます。すべてのテーブルがこれら 5 つのチェーンを共有することに注意してください。もちろん、すべてのテーブルで同時にこれら 5 つのチェーンが必要になるわけではありません。たとえば、フィルター テーブルには PREROUTING と POSTROUTING がありません。上記のチェーンに挿入されたルールが複数のテーブルにある場合、それらは raw -> mangle -> nat -> filter の順序で実行されます。
• -s、-p、および --dport はすべて条件です。複数の条件は AND 関係にあります。つまり、指定されたすべての条件が満たされた場合にのみルールが一致します。たとえば、-s は送信元 IP アドレスを 192.168.1.2 に指定し、-p はプロトコルを TCP に指定し、--dport はポート 22 を指定します。つまり、送信元アドレスがターゲットの TCP ポート 22 にアクセスする場合にのみ、このルールが一致します。
• -j は動作を指定します。もちろん正式名称はターゲットです。ここで DROP はパケットを破棄することを意味します。

1.2 iptables の一致条件

一致条件として前述の -s、-p、--dport などのパラメータに加えて、iptables はターゲット IP アドレスを一致させる -d、どのネットワーク カードを入力するか、どのネットワーク カードを残すかを指定する -i および -o もサポートしています。もちろん、これらの一致条件だけでは不十分であり、MAC アドレスの一致もサポートされていません。さまざまなニーズを満たすために、iptables は拡張モジュールを通じてより多くの一致条件をサポートします。拡張モジュールは主に次の 2 つのカテゴリに分けられます。

• 拡張機能: たとえば、以前の --dport パラメータは、単一のポートまたは連続したポートにのみ一致できます。連続していない複数のポートを一致させる必要がある場合は、複数のルールを追加する必要があります。 mulport 拡張モジュールを使用すると、カンマで区切って複数のポートを同時に指定できます。もう 1 つの例は、IP アドレス セグメントの指定をサポートする ip-range モジュールです。
• 新しい機能: たとえば、mac モジュールは、一致する送信元 MAC アドレスをサポートします。時間モジュールは、たとえば毎日 0:00 から 8:00 まで外部 SSH を禁止するなど、一致条件として時間帯を使用することをサポートしています。

拡張モジュールによってサポートされるパラメータが異なります。たとえば、mac モジュールは --mac-source パラメータをサポートしています。

拡張モジュールを使用するには、-m パラメータを使用してロードする必要があります。 -m は --module の略語だとばかり思っていました。 iptables のマニュアルを読んだ後、これは実際には --match の省略形であることがわかりました。ただし、拡張モジュールをロードする機能であることを知っておくだけで十分です。

たとえば、MAC アドレス FA:16:3E:A0:59:BA の通過を許可せず、次のルールを設定します。

iptables には多くの拡張モジュールがあり、man iptables-extensions コマンドで確認できますが、OpenStack セキュリティ グループではそれらの多くを使用しません。

• comment: ルールにコメントを追加します。
• tcp/udp/icmp: はい、これらも拡張モジュールです。 iptables 基本モジュールにはポートを指定する機能すらありません。
• set: ipset と一致します。 IP が ipset セット内にある場合に条件が満たされます。
• mac: 前述のとおり、MAC アドレスの一致をサポートします。
• state: このモジュールは非常に便利です。たとえば、サーバー A (192.168.0.1) に設定されている iptables ルールでは、すべての着信トラフィックがブロックされ (つまり、INPUT チェーンが DROP)、すべての発信トラフィックが許可され (つまり、OUTPUT チェーンが ACCEPT) ているとします。別のサーバー B (192.168.0.2) と A は同じレイヤー 2 ネットワーク内にあります。明らかに、B は A に ping できません。問題は、A は B に ping できるかどうかです。 A はすべての送信接続にアクセスできるので、B に ping できるはずだと言う人がいるでしょう。実際、A のパケットは送信することはできても戻ってくることはできないため、A は B に ping をまったく実行できません。つまり、A の ICMP パケットは確かに B に到達できますが、B の応答パケットは A の INPUT によってドロップされるため、A は応答パケットをまったく受信できません。それで、どうやって解決するのでしょうか? B を A のホワイトリストに追加すると、当初の意図が明らかに損なわれます。この問題は状態モジュールを通じて完全に解決できます。状態を ESTABLISHED として指定すると、接続が確立されているパケットと一致できます。ここで確立された接続は TCP 接続ではなく、udp や icmp などのより広い意味の接続を指すことに注意してください。簡単に言えば、返信パケットを一致させることを意味します。したがって、上記の問題を解決するには、-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT ルールを追加するだけです。
• physdev: このモジュールは、組み込みの -i および -o パラメータよりも強力です。 Linux ブリッジ br0 を作成し、多数の仮想ネットワーク カード タップ デバイスが br0 にマウントされているとします。 -i を通じて br0 を指定すると、どの仮想ネットワーク カードからのトラフィックかに関係なくすべてのトラフィックが一致しますが、どの仮想ネットワーク カードからのトラフィックかを正確に一致させることはできません。 physdev モジュールは非常に強力です。 physdev-in パラメータはデータの送信元となるインターフェースを指定し、--physdev-out パラメータはデータの送信元となるインターフェースを指定します。

1.3 iptables実行アクション

前述したように、iptables は -j を使用して実行するアクション (ターゲット) を指定します。 iptables の一般的なターゲットは次のとおりです。

• ACCEPT: パケットを受信し、チェーン上の他のルールに一致せずに直接解放します。これはこのチェーンのみであることに注意してください。他のチェーンはまだ一致する必要があります。つまり、1 つのレベルしか通過せず、次のいくつかのレベルを通過できるかどうかはわかりません。
• DROP: パケットを直接破棄します。パケットは失われ、他のルールに一致する必要はありません。
• REJECT: パケットを拒否します。これとDROPの違いは何ですか？ DROP は応答せずにパケットを直接破棄します。クライアントはタイムアウトになるまで愚かにも待機することになります。 REJECT は拒否メッセージに応答します。クライアントは拒否パケットを受信し、盲目的に待つことなく応答できます。
• LOG: ログを記録するだけです。

もちろん、NAT を実装するための SNAT、MASQUERADE、DNAT もあります。これらはセキュリティ グループの実装には関係しないため、詳細には紹介しません。さらに、RETURN と別のチェーンを指すアクションがありますが、これについてはサブチェーンが導入されたときに後で説明します。

アクションは通常、短絡的です。つまり、ルールが一致してアクションが実行されると、チェーン内の他のルールは一致しなくなります。もちろん、これは絶対的なものではありません。たとえば、LOG アクションは例外です。アクションを実行した後、次のルールが一致します。

1.4 iptables チェーン

前述したように、iptables には合計 5 つのチェーンがあり、チェーンは一方向のリンク リストと見なすことができます。問題は、新しいパケットが受信されたときに、ルールがどのように一致するかということです。ここでは、画像とテキストでiptablesを理解する[1]という記事から図をそのまま引用します。

（１）データパケットはまずPREROUTINGチェーンに到達し、次にPREROUTINGで定義されたルールをraw、mangle、natの順に照合して実行します。

（２）次に、ルーティング判断の結果、パケットが自分宛であればINPUTチェーンに流れ、INPUTチェーンはそれをユーザー空間プロセスに送って処理する。パケットが自分自身に送信されない場合、FORWARD テーブルに流れ、raw -> mangle -> nat -> filter テーブルに従って順番に実行チェーン上のルールと一致します。

（３）同様に、ONPUTチェーン、POSTROUTINGチェーン、パケットフロー方向も図を見れば非常に明確なので、ここでは詳細には触れません。

前述のように、各チェーンにルールを挿入できます。これらのルールは順守されていることに注意してください。 iptables が一致するたびに、最初のルールから開始して、次のルールに順番に一致します。いずれかのルールが一致すると、対応するアクションが実行されます。

このチェーンのルールがどれも一致しない場合は、どうすればいいのかと疑問に思う人がいるはずです。答えはチェーンのデフォルトポリシーによって異なります。ポリシーが DROP の場合、一致しないすべてのパケットは破棄されます。つまり、チェーンはホワイトリストです。デフォルトのポリシーが ACCEPT の場合、一致しないすべてのパケットが通過します。つまり、チェーンはブラックリストです。もちろん、DROP として構成するのは危険すぎるため、通常はポリシーは ACCEPT に設定されます。たとえば、ルールをクリアすると、すぐにすべてがブロックされます。 SSH 経由でサーバーに接続すると、接続はすぐに切断され、vnc またはアウトオブバンド コンソール接続経由で接続をリセットする必要があります。したがって、ポリシーを変更することはお勧めしません。

フィルター テーブル内の各チェーンのデフォルト ポリシーを表示するには、次のコマンドを使用します。

チェーンに複雑なルールが多数あると管理が非常に面倒になるため、チェーンを機能ごとにグループ化する必要があります。 iptables はカスタム チェーンを通じて実装されます。ユーザーは、iptables -N name を使用して新しいチェーンを作成し、組み込みチェーンと同様に新しいチェーンにルールを追加できます。ただし、カスタム チェーンは独立して存在することはできず、5 つの組み込みチェーンの下にハングアップする必要がある、つまり組み込みチェーンのサブチェーンである必要があることに注意してください。

前のセクション 1.3 では、-j で新しいチェーンを指定できることを説明しました。ここでの新しいチェーンはサブチェーンです。つまり、iptables は -j を使用してサブチェーンを特定のルールに添付します。たとえば、SSH アクセスを許可するホワイトリストを作成するには、新しいサブチェーンを作成し、すべての SSH 関連ポリシーをこの新しいチェーンに配置します。

上記の 2 番目のコマンドは、ローカル マシンのポート 22 にアクセスするすべてのパケットが処理のために SSH_Access_List サブチェーンに配置され、その後、多くのホワイトリスト ルールがこのサブチェーンに追加されることを意味します。このサブチェーンに入るパケットはターゲット ポート 22 である必要があるため、ルールで --dport パラメータを指定する必要はありません。最後の DROP は、ホワイトリストにないパケットが直接破棄されることを意味します。

ホワイトリスト ルールのアクションは ACCEPT ではなく RETURN であることに注意してください。この2つの違いは何でしょうか? ACCEPT は、パケットが INPUT の他のルールに一致せずに INPUT を直接通過できることを意味します。 RETURN は、サブチェーン配下の後続のルールを照合する必要はないが、照合を続行するにはサブチェーンの親チェーンまたはサブチェーンのルールに戻る必要があることを意味します。 INPUT レベルを通過できるかどうかは、後続のルールによって決まります。

また、上記の 5 つの組み込みチェーンはポリシーを使用して構成できることにも注意してください。すべてのルールが一致しない場合は、ポリシーを使用してパケットが処理されます。ただし、カスタム チェーンはポリシーをサポートしません。より正確に言うと、カスタム チェーンのポリシーは RETURN のみであるため、ポリシーの設定はサポートされていません。つまり、子チェーンのルールが一致しない場合は、親チェーンに戻って一致を続行します。

1.5 iptables の概要

このセクションでは、iptables の機能と使用方法について簡単に説明します。概要は次のとおりです。

1. iptables はルールを一致させてパケットの宛先を決定します。ルールは一致する条件 + アクションで構成され、ルールは -I と -A を通じて挿入されます。

2. 5 つのチェーンと 5 つのテーブル。 5 つのチェーンは、PREROUTING、INPUT、FORWARD、OUTPUT、POSTROUTING です。 5 つのテーブルは、raw、mangle、nat、filter、security です。チェーン、リスト、ルールはすべて順序付けられています。

3. チェーン内のすべてのルールが一致しない場合、iptables はチェーンによって設定されたデフォルトのポリシーに従ってパケットを処理します。ポリシーは「ACCEPT」に設定されています。 DROP に設定することはお勧めしません。

4. サブチェーンを作成し、内蔵チェーンに掛けることができます。サブチェーンのポリシーは RETURN であり、構成をサポートしていません。

5. マッチング条件には、基本マッチング条件と拡張モジュールによって提供される拡張マッチング条件が含まれます。拡張一致条件は -m パラメータを通じて読み込まれます。覚えておく必要がある拡張モジュールは、comment、tcp、udp、icmp、mac、state、physdev、set です。

6. 一般的な iptables アクション (ターゲット) は、ACCEPT、DROP、RETURN、LOG、サブチェーンへのジャンプです。

2. OpenStack セキュリティ グループの紹介

2.1 Neutron セキュリティ グループと Nova セキュリティ グループ

OpenStack セキュリティ グループは当初、Nova を通じて管理および構成されていました。 Neutron の導入後、新しい OpenStack セキュリティ グループは Neutron を通じて管理され、関連付けられたオブジェクトは仮想マシンではなくポートになります。ページで仮想マシンをセキュリティ グループに追加すると、実際には仮想マシンのポートがセキュリティ グループに関連付けられます。

歴史的な理由により、Nova の一部のバージョンではセキュリティ グループ ルールを操作するための API がまだ保持されている場合がありますが、使用することはお勧めしません。セキュリティ グループ ルールは Neutron を通じて管理することをお勧めします。

2.2 セキュリティグループとファイアウォール

OpenStack を初めて使用するユーザーの多くは、セキュリティ グループとファイアウォールの違いを区別できません。これは、どちらもネットワーク アクセス制御に使用され、コミュニティが iptables に基づいて実装しているためです。実際、この 2 つの違いはかなり大きいです。

• セキュリティ グループは主にホストの保護に使用されます。つまり、セキュリティ グループは仮想マシンのポートに関連付けられます。セキュリティ グループは各ポートのネットワーク アクセス制御を実行するため、ホスト ファイアウォールに似ています。ファイアウォールは VPC ネットワーク用です。 VPC 全体のネットワークを制御し、通常はルーティングのポリシーを作成します。したがって、セキュリティ グループはコンピューティング ノードのタップ デバイスに実装され、ファイアウォールはネットワーク ノードのルーターに実装されます。
• 従来のネットワーク モデルと比較すると、セキュリティ グループは実際にはオペレーティング システム内に構成されたファイアウォールに似ていますが、ファイアウォールはルーターに取り付けられて LAN ネットワーク トラフィック全体を制御します。
• セキュリティ グループは、通過が許可されるルールのセットを定義します。つまり、ルールのアクションは ACCEPT です。つまり、ホワイトリストルールが定義されます。したがって、仮想マシンが空のルールを持つセキュリティ グループに関連付けられている場合、仮想マシンはセキュリティ グループから出入りできません。また、これらはすべてホワイトリスト ルールであるため、セキュリティ グループ ルールの順序は重要ではなく、仮想マシン ポートを複数のセキュリティ グループに同時に関連付けることができます。これは、ルール セットの結合に相当します。ファイアウォール ルールにはアクション (許可、拒否、拒否) があります。ルールは ACCEPT または DROP のいずれかであるため、順序は非常に重要です。パケットの運命はルールだけでなく、ルールの優先順位にも依存します。
• 前述したように、セキュリティ グループは仮想マシン ポートを対象としています。仮想マシンの IP アドレスは既知の条件であるため、ルールを定義するときに仮想マシンの IP アドレスを指定する必要はありません。たとえば、受信ルールを定義する場合、送信元 IP アドレス、宛先ポート、プロトコルのみを定義する必要があり、宛先 IP アドレスを定義する必要はありません。ファイアウォールはレイヤー 2 ネットワーク全体を対象とします。レイヤー 2 ネットワークには多くの仮想マシンが存在するため、ルールでは送信元 IP、送信元ポート、宛先 IP、宛先ポート、プロトコルを同時に定義する必要があります。以前誰かが私に質問をしました。複数の仮想マシンがセキュリティ グループに関連付けられます。これらの仮想マシンでネットワーク アクセス制御を実行したいと考えています。ソース IP は 192.168.4.5 ですが、2 台の仮想マシンのポート 80 へのアクセスのみを開きたいです。どうすればいいですか？同じセキュリティ グループに関連付けられた仮想マシンのネットワーク アクセス ポリシーは同じである必要があるため、これは実現できないと述べました。ターゲット IP を指定することはできません。仮想マシンのアクセス要件が異なる場合は、異なるセキュリティ グループを関連付けることによってのみ実現できます。
• セキュリティ グループは通常、東西トラフィック制御とマイクロセグメンテーション戦略を実装するために使用されますが、ファイアウォールは通常、南北トラフィック制御を実装するために使用されます。

2.3 セキュリティグループの使用法の概要

前述したように、セキュリティ グループは実際にはコレクションです。セキュリティ グループ ルールをこのコレクションに配置するのは理にかなっています。

Neutron は、security-group-create サブコマンドを通じてセキュリティ グループを作成します。パラメータはセキュリティ グループ名という 1 つの名前のみです。

ただし、Neutron によって作成された新しいセキュリティ グループは空のルール セキュリティ グループではなく、次の 2 つのデフォルト ルールが自動的に追加されます。

つまり、すべてのトラフィックのアクセスが禁止され、すべてのトラフィックの外出が許可されます。

セキュリティ グループを作成したら、セキュリティ グループにルールを追加できます。 Neutron は、security-group-rule-create サブコマンドを通じて作成されます。関係するパラメータは次のとおりです。

• --direction: ルールが出力か入力か。
• --ethertype: イーサネット タイプ、ipv4 または ipv6。
• --protocol: プロトコル タイプ、tcp/udp/icmp など。このパラメータを指定しない場合は、任意のプロトコルが使用されます。
• --port-range-min、--port-range-max ポート範囲。ポートが 1 つしかない場合は、両方のパラメータに同じ値を入力します。ポート範囲は1〜65535です。
• --remote-ip-prefix は着信コールの場合、送信元 IP アドレス セグメントを参照します。発信コールの場合は、宛先 IP セグメントを参照します。 CIDR 形式で定義されます。 IP が 1 つだけ指定されている場合は、xxxx/32 で指定されます。任意のIPの場合は0.0.0.0/0で指定します。
• --remote-group-id: IP セグメントによるルールの指定に加えて、OpenStack では、xyz セキュリティ グループに関連付けられているすべての仮想マシンがポート 22 にアクセスできるようにするなど、一致条件としてセキュリティ グループを使用することもできます。

192.168.4.5 のみが仮想マシンの SSH ポート 22 にアクセスできるようにするセキュリティ グループ ルールを作成します。

セキュリティ グループとセキュリティ グループ ルールの作成は論理操作のみであり、iptables ルールは作成されないことに注意してください。対応する iptables ルールは、セキュリティ グループがポートに関連付けられている場合にのみ作成されます。

Neutron の port-update コマンドを使用してセキュリティ グループを関連付けます。たとえば、仮想マシンの UUID 38147993-08f3-4798-a9ab-380805776a40 をセキュリティ グループに追加するには、次のようにします。

セキュリティ グループ コマンドの操作パラメータは比較的複雑で、図に示すようにダッシュボードのグラフィカル インターフェイスから操作できます。

具体的な操作についてはここでは紹介しません。

3. セキュリティグループの実装原則の分析

3.1 仮想マシンのネットワークフローパス

Linux ネットワーク仮想化は、Linux ブリッジと openvswitch (略して OVS) をサポートします。 OpenStack Neutron ml2 ドライバーは両方をサポートします。現在、ほとんどの人が OVS を使用しています。

ただし、初期の iptables は OVS ブリッジとポートをサポートしていませんでした。そのため、セキュリティ グループを実装するために、仮想マシンのタップ デバイスは OVS ブリッジに直接接続されません。代わりに、中間に Linux ブリッジが追加されます。 Linux ブリッジと OVS ブリッジは、veth ペアを介して接続されます。このようにして、Linux ブリッジに iptables ルールを追加して、セキュリティ グループ機能を実装できます。

現在、ほとんどの OpenStack 環境では上記のルールが引き続き適用されています。簡略化された仮想マシンのトラフィック パスは次のとおりです。

X、Y、Z は、仮想マシン ポート UUID の最初の 11 桁です。

3.2 セキュリティ グループ ルールはどの iptables チェーンに接続する必要がありますか?

これまでの基盤に基づいて、セキュリティ グループの iptables ルールをフィルター テーブルに実装する必要があることは容易に推測できます。フィルター テーブルには、INPUT、FORWARD、OUTPUT の 3 つのチェーンのみが含まれます。 iptables ルールのフロー図は次のように簡略化できます。

ホスト ファイアウォールに取り組んだことがある人なら、セキュリティ グループ ルールが INPUT チェーンと OUTPUT チェーンに適用されるだろうと最初に考えるかもしれません。しかし、上記のフローチャートによれば、パケットが自分自身に送信されなければ、INPUT と OUTPUT にはまったく到達しません。したがって、セキュリティ グループ ルールを INPUT と OUTPUT に実装することはできないことは明らかです。したがって、セキュリティ グループの iptables ルールは FORWARD チェーンに実装する必要があります。つまり、コンピューティング ノードは仮想マシンのパケット (自身に送信されたパケットを除く) を処理せず、パケットの転送のみを担当します。

3.3 セキュリティグループルールの定義

その後のテストを容易にするために、IP アドレスが 192.168.100.10/24、ポート UUID が 3b90700f-1b33-4495-9d64-b41d7dceebd5 の仮想マシン int32bit-server-1 を事前に作成し、以前に作成した int32bit-test-secgroup-1 セキュリティ グループに追加しました。

まず、Neutron ポートに対応するこのコンピューティング ノードのすべてのタップ デバイスをエクスポートします。スクリプトは github int32bit/OpenStack_Scripts からダウンロードできます。

前回の分析によると、仮想マシン セキュリティ グループは、フィルター テーブルの FORWARD チェーンで定義されています。このチェーンのルールを確認してみましょう。

FORWARD チェーンは最初に neutron-filter-top サブチェーンにジャンプし、neutron-filter-top チェーンは neutron-openvswi-local にジャンプします。 neutron-openvswi-local チェーンは空のチェーンなので、親チェーンに FORWARD で戻ります。したがって、ここでの最初のルールは実際には役に立ちません。

FORWARD チェーンに戻った後、2 番目のルールが一致し、チェーンは neutron-openvswi-FORWARD にジャンプします。このチェーンのルールを確認してみましょう。

このチェーンには 4 つのルールがあります。最初のルールと 2 番目のルールに対応するタップ デバイスは dhcp ポートと router_interface ポートであり、これは DHCP とゲートウェイのポートが通過を許可されていることを意味します。

そして、tap3b90700f-1b は明らかに仮想マシン ポートに対応するタップ デバイスです (名前は tap+portUUID の最初の 11 ビットです)。 3 番目と 4 番目のルールは、このタップ デバイスに出入りするすべてのパケットが、処理のためにサブチェーン neutron-openvswi-sg-chain に入ることを示しています。

neutron-openvswi-sg-chain ビュー チェーンの表示を続けます。

ルールから次のことがわかります。

• --physdev-out は、tap3b90700f-1b から仮想マシンに送信されたパケットがサブチェーン neutron-openvswi-i3b90700f-1、つまり仮想マシン アクセス トラフィックによって処理されることを示します。
• --physdev-in は、仮想マシンから tap3b90700f-1b に入るパケットがサブチェーン neutron-openvswi-o3b90700f-1、つまり仮想マシンの送信トラフィックによって処理されることを示します。

明らかに、neutron-openvswi-i3b90700f-1 と neutron-openvswi-o3b90700f-1 は、それぞれセキュリティ グループの受信ルールと送信ルールに対応します。つまり、仮想マシンの受信ルール チェーンは neutron-openvswi-i + ポート プレフィックスであり、仮想マシンの送信ルール チェーンは neutron-openvswi-i + ポート プレフィックスです。

3.4 セキュリティグループアクセスルール

3.3 からは、セキュリティ グループ アクセス ルール チェーンが neutron-openvswi-i3b90700f-1 であることがわかります。チェーンルールを確認してみましょう:

ルールは全部で6つあります。

• 最初のルールはすでに紹介しましたので、皆さんもよくご存知のはずです。主に返品パッケージのリリースに使用されます。
• 2 番目と 3 番目のルールは、主に DHCP ブロードキャスト パケットを許可するために使用されます。
• 記事 4 は、先ほど追加したセキュリティ グループ ルールです。
• ルール 5 は、役に立たないパケットを破棄します。
• 6 番目のルールは、どのルールにも一致しないパケットを処理し、neutron-openvswi-sg-fallback チェーンにジャンプするために使用されます。このチェーンには、実際には DROP ALL という 1 つのルールのみがあります。したがって、セキュリティ グループのルールに一致しないパケットは直接破棄されます。

セキュリティ グループ アクセスの 1 番目、2 番目、3 番目、5 番目、6 番目のルールが固定されています。新しいセキュリティ グループ ポリシーがある場合は、4 番目のルールの後に追加されます。

3.5 セキュリティグループ訪問ルール

3.3 からは、セキュリティ グループ アクセス ルール チェーンが neutron-openvswi-o3b90700f-1 であることがわかります。チェーンルールを確認してみましょう:

ルールは全部で 8 つあります。

• 最初のルールと 3 番目のルールは、仮想マシンの DHCP クライアント ブロードキャスト パケットを許可するために使用されます。
• 2 番目のルールは第 4 章で紹介されます。
• 4 番目のルールは、DHCP スプーフィングを防ぎ、ユーザーが仮想マシン内で DHCP サーバーを起動して Neutron の DHCP サーバーに影響を与えるのを防ぐために使用されます。
• ルール 5 についてはこれ以上説明しません。
• ルール 6 はセキュリティ グループ ルールです。セキュリティ グループの送信アクセスは ANY であるため、すべてのパケットが許可されます。
• ルール 7 は、役に立たないパケットを破棄します。
• ルール 8 は、どのルールにも一致しないパケットを処理し、neutron-openvswi-sg-fallback チェーンにジャンプするために使用されます。このチェーンには、実際には DROP ALL という 1 つのルールのみがあります。したがって、セキュリティ グループのルールに一致しないパケットは直接破棄されます。

3.6 セキュリティ グループ セキュリティ グループを一致条件として使用する

セクション 2.3 で説明したように、セキュリティ グループは、送信元または宛先として IP アドレス セグメントを使用する一致条件をサポートするだけでなく、別のセキュリティ グループを指定することによる一致条件もサポートします。この状況にどう対処すればいいのでしょうか?

テスト用に、新しいセキュリティ グループ int32bit-test-secgroup-2 と新しい仮想マシン int32bit-server-2 (192.168.100.7) を作成し、int32bit-server-2 をセキュリティ グループ int32bit-test-secgroup-2 に関連付けました。

同時に、int32bit-test-secgroup-1 に受信ルールを追加して、int32bit-test-secgroup-2 に関連付けられた仮想マシンがポート 8080 にアクセスできるようにします。

仮想マシンのアクセス ルール チェーン neutron-openvswi-i3b90700f-1 を確認します。

4 という番号の新しいルールが挿入されていることがわかります。このルールは、set 拡張モジュールを使用します。前述したように、set は ipset と一致させるために使用されます。次のパラメータ NIPv4fc83d82a-5b5d-4c90-80b0- は ipset 名であり、明らかに NIPv4 + セキュリティ グループ UUID プレフィックスで構成されています。

ipsetを確認しましょう:

192.168.100.7 が ipset セットに含まれていることがわかります。

したがって、OpenStack セキュリティ グループがセキュリティ グループを一致条件として使用する場合は、ipset を通じて実装されます。各セキュリティ グループは ipset セットを作成し、関連付けられた仮想マシンの IP がこのセットに配置されます。 iptables は、ipset マッチングを通じてセキュリティ グループ マッチング機能を実装します。

4. セキュリティグループのアンチスヌープ機能

上記のセクション 3.5 で説明した 2 番目のルールでは、すべてのパケットは最初に neutron-openvswi-s3b90700f-1 サブチェーンに入り、処理されます。このチェーンは何に使われるのですか?

まずルールを見てみましょう:

このチェーンの処理ロジックは非常にシンプルです。 IP アドレス 192.168.100.10 および MAC アドレス FA:16:3E:A0:59:BA のパケットのみを通過させます。これは実際には、Neutron でデフォルトで有効になっているアンチスヌープ機能です。 Neutron ポートによって割り当てられたものと一致する IP アドレスと MAC アドレスのみが通過できます。つまり、IP 192.168.3.1 で仮想マシンをセットアップし、その後ネットワーク カードの IP を手動で 192.168.3.2 に変更すると、確実に通過できなくなります。

ただし、当社のビジネスでは仮想 IP の需要が頻繁にあり、最も一般的なものは haproxy と pacemaker VIP です。 OpenStack はこの要件を考慮し、ポートの許可されたアドレス ペアの構成を通じてユーザーがホワイトリストを追加できるようにサポートします。

たとえば、IP アドレスが 192.168.0.10 と 192.168.0.11 の 2 つの仮想マシンがあるとします。これら 2 つの仮想マシンの VIP としてポート 192.168.0.100 を申請しました。 Neutron を通じてポート情報を更新できます。

追加したら、neutron-openvswi-s3b90700f-1 チェーンルールを確認しましょう。

IP 192.168.0.100 のパケットを通過させるルールが先頭に追加されていることがわかります。このとき、仮想マシン 192.168.0.10 の IP を 192.168.0.100 に変更すると、ping も成功します。

5. 仮想マシン経由でホストマシンにアクセスするにはどうすればよいですか?

セキュリティ グループがフィルター テーブルの FORWARD チェーンに実装されていることはすでにわかっています。ただし、仮想マシンのパケットがホストマシン宛ての場合、カーネルは宛先アドレスが自分自身であると判断するため、FORWARD チェーンには流れず、INPUT チェーンに流れます。これはセキュリティ グループのルールをバイパスするのではないですか?

解決策は非常に簡単です。 neutron-openvswi-o3b90700f-1 を INPUT チェーンに再度接続するだけです。

INPUT チェーンのルールを見てみましょう。

今すぐ：

ホストから仮想マシンに送信されるパケットに何か問題が発生するのだろうかと疑問に思う人もいるかもしれません。 OUTPUT チェーンにルールを追加する必要がありますか?答えは「いいえ」です。OUTPUT から直接出力して、通常のプロセスに従うことができるためです。

6. まとめ

この記事では、まず iptables について簡単に紹介し、次に OpenStack セキュリティ グループを紹介し、最後にセキュリティ グループの実装原則を詳細に分析します。

また、コンピューティング ノードで実行する必要がある仮想マシンの iptables ルールをすばやくエクスポートできるスクリプトも作成しました。

Fu Guangping は銀行のクラウド技術管理センターに勤務し、クラウド コンピューティング関連技術の研究を担当しています。北京郵電大学を卒業し、2013年からOpenStack関連の仕事に従事し、OpenStack Nova、Cinder、Osloなどのプロジェクトのコミュニティ開発に参加しました。