この記事では、OpenStack が iptables のチェーンとルールを使用してどのようにネットワーキングを行うかを説明しますが、その方法は他のシステムの場合とほとんど同じです。しかしまずは、この記事で使用する技術の復習として、iptables の構造について見て行きましょう。

iptables の構造

iptables はユーザー空間のアプリケーション・プログラムであり、システム管理者は iptables を利用して Linux カーネルのファイアウォールが提供するテーブルを構成することができます。iptables は IPv4 専用です。

Linux ファイアウォールの設定にはルールが使用され、各ルールにより、パケット内の何と突き合わせるのか、またパケットの処理方法を規定します。チェーンはルールのリストです。

iptables の前身である ipchains では、ルールのチェーンという概念が追加されました。iptables では、この概念をさらにテーブルへと拡張しています。つまり iptables の構造は [iptables > テーブル > チェーン > ルール] となっています。

iptables には以下の 4 つのテーブルが組み込まれています。

• filter テーブル: 以下のチェーンを含むデフォルトのテーブルです。
  • INPUT チェーン: ローカル・サーバーで受信するパケットのためのチェーン
  • OUTPUT チェーン: ローカルで生成され、ローカル・サーバーから送信されるパケットのためのチェーン
  • FORWARD チェーン: ローカル・サーバー経由でルーティングされるパケットのためのチェーン
• nat テーブル: NAT (Network Address Translation) に使用されます。
  • PREROUTING チェーン: 送信先 NAT に使用され、パケットをルーティングする前にパケットの IP アドレスを変換します。
  • POSTROUTING チェーン: 送信元 NAT に使用され、パケットをルーティングした後でパケットの IP アドレスを変換します。
  • OUTPUT チェーン: ファイアウォール上でローカルに生成されるパケットに対する NAT です。
• mangle テーブル: 特殊なパケット変換に使用されます。
  • PREROUTING チェーン
  • OUTPUT チェーン
  • FORWARD チェーン
  • INPUT チェーン
  • POSTROUTING チェーン
• raw テーブル: パケットの追跡を除外するための構成に使用されます。
  • PREROUTING チェーン
  • OUTPUT チェーン

上に戻る

OpenStack 内部の iptables

OpenStack 内部では、Compute (Nova) モジュールには iptables のチェーンとルールが非常に数多くあります (Nova モジュールはクラウド・コンピューティングのファブリック・コントローラー (IaaS システムの主要部分) であり、多くの外部ライブラリーを使用して Python で作成されています)。この記事では、ネットワーキング・タスクに必要な、nova-network の FlatDHCPManager コンポーネントと他の OpenStack コンポーネントの詳細について説明します。

OpenStack が起動されると、OpenStack チェーンがいくつか定義されます。これらのチェーンは Linux に組み込みのチェーンと共にチェーンのファブリックを構成します。起動時にはさらに、固定ネットワーク範囲とメタデータ・サービスのためのルールをいくつか定義します。ネットワークが作成されて使用されると、nova-network がいくつかのルールを設定します。また、インスタンス (つまり、サーバーや VM) が作成されると、nova-compute はそのインスタンスの接続性を確実にするために、インスタンス専用に 1 つのチェーンを作成し、このチェーンの下でルールを設定します。フローティング IP の場合にも、OpenStack はいくつかのルールを使用してそのインスタンスを動作させます。また、OpenStack のセキュリティー・グループとそのルールは iptables のルールによって実現されます。

上に戻る

OpenStack 入門

OpenStack とは、パブリック・クラウドおよびプライベート・クラウド用のクラウド・オペレーティング・システムのオープン・スタンダードを作成するための開発者およびクラウド・コンピューティング技術者によるグローバルなコラボレーション・プロジェクトであり、このプロジェクトが Apache ライセンスの条項の下でリリースしている無料のクラウド・オペレーティング・システムのオープンソース・ソフトウェアのことでもあります。クラウドのサービス・プロバイダーや、クラウドを利用する企業、政府機関などは、この Apache ライセンスの下で提供される無料のソフトウェアを利用して、極めて高いスケーラビリティーを持つクラウド環境を構築することができます。

OpenStack には、この記事を執筆している時点では、以下の 6 つのコアとなるソフトウェア・プロジェクト (括弧の中はコードネーム) があります。

• Compute (Nova): クラウドでのコンピューティング基盤を提供します
• Storage (Swift): クラウドでのストレージ・サービスを提供します
• Image Service (Glance): イメージの提供や登録などのサービスを提供します
• Identity (Keystone): ID サービスを提供します
• Dashboard (Horizon): ダッシュボードを提供します
• Networking (Quantum): ネットワーク・サービスを提供します

これらのプロジェクトと、技術プロバイダーや将来のプロジェクトなどによる活発なエコシステムによって、パブリック・クラウドおよびプライベート・クラウド用のプラガブル・フレームワークとオペレーティング・システムが提供されています。

Nova プロジェクトには 10 を超えるバイナリーがあり、そのうち以下の 3 つは VM の接続性に関するものです。

• nova-api は VM 用のメタデータ・サービスを提供します。
• nova-compute は VM 用のネットワーク環境を構築します。
• nova-network はクラウド・エコシステム全体のネットワーク環境を構築します (IP アドレスの割り当てや DHCP の設定などを行います)。

Nova モジュールは主に一連の Python デーモンで構成されますが、データベース機能、メッセージング機能、仮想化機能を実現するためのネイティブのシステム・コンポーネントをいくつも必要とし、それらのコンポーネントと統合されます。Nova モジュールは特殊なメタデータ・サービスを使用して仮想マシン・インスタンスを実現し、インスタンス専用のデータを取得します。インスタンスは http://169.254.169.254 でメタデータ・サービスにアクセスします。

メタデータには SSH 公開鍵 (ユーザーが新しいインスタンスを要求する際に指定する鍵またはその名前で識別されます) とユーザー・データ (API 呼び出しの user_data パラメーターとして渡されるか、Nova のブート・コマンドの --user_data フラグによって渡されます) が含まれています。nova-api バイナリーはメタデータ・サービスを実装します。

OpenStack はさまざまなコンポーネントの複合セットです。OpenStack のシステムや、この記事では取り上げないコンポーネントの動作などについて詳しく学ぶには、OpenStack に関するさまざまなリソースを「参考文献」セクションに挙げましたので、それらを参照してください。

Nova におけるルールとチェーンの説明に移る前に、IP アドレスの設定モードについて見て行きましょう。

上に戻る

Nova における IP アドレス設定

すべての VM には、利用可能な各 nova-network から自動的にプライベート IP アドレスが割り当てられます。これらの IP アドレスは「固定 IP」と呼ばれます。インスタンスには、パブリック IP アドレスを割り当てることもできます。OpenStack では、実行中の仮想インスタンスに動的に追加される IP アドレス (通常はパブリック IP アドレス) のことを「フローティング IP」と表現します。

固定 IP を実装するには以下のモードを使用することができます。

• フラット・モード
• フラット DHCP モード
• VLAN DHCP モード
• Quantum を用いた nova-network モード

フラット・モード

フラット・モードは最も単純なネットワーキング・モードです。各インスタンスはアドレス・プールから固定 IP を取得します。デフォルトで、すべてのインスタンスは同じブリッジ (br100) に追加されます。ブリッジは手作業で構成する必要があります。インスタンスを起動する前には、インスタンスにネットワーク構成が注入されます。また、このモードにはフローティング IP 機能はありません。

フラット DHCP モード

すべてのインスタンスが同じブリッジに追加されるという点で、このモードはフラット・モードと似ています。このモードの場合、Nova は追加の構成を行い、イーサネット・デバイス (デフォルトで eth0) へのブリッジ接続を試みます。また、このブリッジをリッスンする dhcpserver として dnsmasq を実行します。インスタンスは dhcpdiscover を実行することにより、固定 IP を受け取ります。また、このモードにはフローティング IP 機能があります。

VLAN DHCP モード

これはデフォルトのネットワーキング・モードであり、最も多くの機能をサポートしています。複数のマシンにインストールする場合には、ホストが管理する VLAN タギングをサポートするスイッチが必要です。このモードの場合、Nova は各プロジェクトに対して (テナントの場合と同じように) VLAN とブリッジを作成します。プロジェクトには、その VLAN 内からのみアクセス可能な一定範囲のプライベート IP アドレスが割り当てられます。ユーザーが自分のプロジェクトのインスタンスにアクセスするためには、(「cloudpipe」というコードネームの) 特殊な VPN インスタンスを作成する必要があります。Nova はユーザーが VPN にアクセスするための証明書と鍵を生成し、自動的に VPN を起動します。

Quantum を用いた nova-network モード

このモードでは DHCP サーバーも自動的に起動されますが、フローティング IP はサポートされません。計算処理を行う各ホスト上では、仮想インスタンスを Quantum ネットワークに接続するための Quantum エージェントが実行されています。ネットワーク・トポロジーは非常に高度なものになる場合があります。

Nova におけるセキュリティー・グループはネットワーク・アクセス・ルールの名前付き集合であり、ファイアウォールのポリシーのようなものです。これらのアクセス・ルールは、受信したネットワーク・トラフィックのどれをグループ内のすべての VM インスタンスに送信する必要があるかを規定し、それ以外の受信トラフィックはすべて破棄されます。ユーザーはグループに対するルールを随時変更することができます。新しいルールは、実行中のすべてのインスタンスと、ルールの変更後に起動されるすべてのインスタンスに対して、自動的に施行されます。セキュリティー・グループは、webappserver のようなセキュリティー・プロファイル、またはセキュリティー・ロールと考えることができます。

上に戻る

iptables のルールとチェーン

先ほど説明したように、iptables はユーザー空間のアプリケーション・プログラムであり、システム管理者は iptables を使用することで Linux カーネルのファイアウォールが提供するテーブルを構成することや、iptables に格納されるチェーンとルールを構成することができます。

同じく先ほど説明したように、iptables ではいくつかの異なるテーブルを定義することができます。その中で OpenStack に使用されるのは filter テーブルと nat テーブルです。各テーブルには組み込みのチェーンがいくつも含まれており、ユーザーが定義したチェーンを含めることもできます。各チェーンは一連のパケットと突き合わせるためのルールのリストです。各ルールには、そのルールにマッチするパケットに対する処理 (「ターゲット」と呼ばれます) を規定します。この処理は、同じテーブル内でユーザーが定義したチェーンにジャンプするという処理の場合もあります。

ここから先では、重要な各種のチェーンとルールについて説明します。

nova-network が起動されると作成されるチェーン

図 1 に示すように、NetworkManager は他の多くのクラスやモジュールと接続する大規模なクラスです。これらのクラスやモジュールのうちの 1 つが linux_net です。linux_net には IptablesManager オブジェクトが含まれ、このオブジェクトの __init__() メソッドは OpenStack システムで定義されるチェーンを初期化します。

先ほど触れたように、Linux カーネルの IPv4 パケット・フィルター・ルールのテーブルには、PREROUTING、INPUT、FORWARD、OUTPUT、POSTROUTING というチェーンが最初から組み込まれています。一般に、Linux ホストで受信されるパケットは PREROUTING チェーンに渡されます。カーネルは受信パケットを PREROUTING チェーンに渡した後、ルーティングについての決定をします。パケットの宛先が Linux ホスト・マシンである場合には、そのパケットは INPUT チェーンに渡され、受け付けられた場合にはターゲット・プロセスに渡されます。パケットの宛先が Linux ホスト・マシンではない場合には、そのパケットは FORWARD チェーンに渡されてから POSTROUTING チェーンに渡され、ホスト・マシンの外部へ送信されます。ローカル・プロセスで作成されたパケットは最初に OUTPUT チェーンに渡され、そこで受け付けられると POSTROUTING チェーンに渡されます。

これらの組み込みチェーンの他に、OpenStack システムはチェーン・システムにフックされる他のチェーンを作成します。OpenStack のチェーンはアンラップ・チェーンとラップ・チェーンという 2 つのタイプで構成されます。

アンラップ・チェーンの例には nova-filter-top や nova-postrouting-bottom などがあります。nova-filter-top は FORWARD チェーンと OUTPUT チェーンの先頭に追加されます。nova-filter-top チェーンの名前はラップされないため、さまざまな Nova ワーカーの間でチェーンを共有することができます。nova-filter-top は FORWARD チェーンと OUTPUT チェーンの先頭で機能する必要のあるルールに使用されます。nova-filter-top チェーンは IPv4 と IPv6 両方のテーブルにあります。

ラップ・チェーンの例にはグリーン・カラー・チェーンなどがあります。これらのチェーンの名前には、プロセス名が接尾辞として含まれます。例えば、nova-network は nova-network-PREROUTING チェーンを作成します。

IPv4 と IPv6 のテーブルに組み込みの INPUT、OUTPUT、FORWARD フィルター・チェーンはラップ・チェーンです。つまり実際の INPUT チェーンには、ラップされた INPUT チェーンにジャンプするルールが含まれている、といった具合です。また、nova-filter-top からのジャンプ先には、local と呼ばれるラップ・チェーンもあります。

IPv4 のテーブルに組み込みの NAT チェーン (PREROUTING、OUTPUT、POSTROUTING) は、組み込みのフィルター・チェーンと同じ方法でラップされています。NAT チェーンの他には、POSTROUTING チェーンの後に適用される sNAT チェーンと float-sNAT チェーンがあります。

nova-network が起動される際のルール

図 3 は FlatDHCPManager の起動プロセスの一部を示しています。数多くの OpenStack のチェーンを作成するために IptableManager オブジェクトを作成する __init__() メソッドについては先ほど説明しました。そこで今度は init_host() に注目しましょう。init_host() メソッドは LinuxNet3 の initialize() メソッドを呼び出し、initialize() メソッドは linux_net のメソッドを呼び出すことによって nat テーブル内の iptables ルールを設定します。

(図 3 を拡大したものはこちら)

これらのルールについて見て行きましょう。

メタデータ・ホストのルール

linux_net の init_host() によって作成されるルールのうち、1 つのルールは FLAGS.fixed_range という範囲の IP で metadata_host (この場合は192.168.1.90) にアクセスできるようにするためのものです。

-A nova-network-POSTROUTING -s 10.0.0.0/8 -d 192.168.1.90/32 -j ACCEPT

ensure_metadata_ip() は以下のコマンドを使用して lo デバイスに 169.254.169.254/32 を追加します。

# ip addr add 169.254.169.254/32 scope link dev lo

すると、metadata_forward() が 169.254.169.254/32 から metadata_host にルーティングされるパケットに dNAT ルールを追加します。

-A nova-network-PREROUTING -d 169.254.169.254/32 -p tcp -m tcp --dport 80 -j DNAT
--to-destination 192.168.1.90:8775

nova-network と nova-api が同じホスト上で実行されていない場合には、nova-api を実行しているホストを指す metadata_host を、nova-network を実行しているホスト上で定義する必要があります。

dmz にアクセスするためのルール

FLAGS.dmz_cidr は dmz (ペリメーター・ネットワーク) の CIDR (Classless Inter-Domain Routing) のリストを定義します。デフォルトの FLAGS.dmz_cidr は空のリストです。この記事の例では、dmz の CIDR は 10.128.0.0/24 です。そのため、ルールは以下のようになります。

-A nova-network-POSTROUTING -s 10.0.0.0/8 -d 10.128.0.0/24 -j ACCEPT

VM を相互に接続するためのルール

2 つの固定 IP を持つ VM 同士が通信できるようにするためのルールもあります。

-A nova-network-POSTROUTING -s 10.0.0.0/8 -d 10.0.0.0/8 -m conntrack ! --ctstate DNAT 
-j ACCEPT

固定サブネットの外部にアクセスするためのルール

add_snat_rule() メソッドは nat テーブルのラップ・チェーン sNAT に sNAT ルールを追加します。図 3 には ip_range と FLAGS.routing_source_ip があります。ip_range の値は FLAGS.fixed_range によって定義され、この記事の例では、その範囲は 10.0.0.0/8 です。FLAGS.routing_source_ip のデフォルトは FLAGS.my_ip であり、flags._get_my_ip() 関数によってデフォルト値が設定されます。この場合は FLAGS.my_ip は 192.168.1.90 です。その結果、以下のようなルールが作成されます。

-A nova-network-snat -s 10.0.0.0/8 -j SNAT --to-source 192.168.1.90

外部にアクセスするための固定 IP に関しては、FLAGS.fixed_range のサブセットとしてのネットワークを作成する必要があります。そうすることで、nova-network を実行しているマシンのデフォルト・ゲートウェイが br100 ブリッジの 1 つの IP を指した状態で、このサブネットの IP を持つ VM は外部ネットワークにアクセスすることができます。

各ネットワークのルール

nova-network はネットワークを設定するために、いくつかのルールを filter テーブル内に作成します。指定されたネットワークで nova-network を実行するためには、以下のようなコマンドを実行します。

1. 以下のようにしてネットワークを作成し、ホストを設定します。

   # ./bin/nova-manage network create mynet 10.10.10.0/24

   
   
2. 以下のようにしてサーバーをブートします。

   nova boot --image a3fb743d-42df-49ba-b9c4-8042ebbd344e --flavor 1 myserver

   
   

これらのコマンドを実行すると、以下のようなルールが作成されます。

1. 転送されたトラフィックが br100 ブリッジを通過し、その結果 br100 ブリッジ上の IP がゲートウェイとして動作するようにするルール

   -A nova-network-FORWARD -i br100 -j ACCEPT -A nova-network-FORWARD -o br100 -j ACCEPT

   
   
2. DHCP トラフィックと DNS トラフィックをローカルの dnsmasq プロセスで受信できるようにするルール

   -A nova-network-INPUT -i br100 -p udp -m udp --dport 67 -j ACCEPT -A nova-network-INPUT -i br100 -p tcp -m tcp --dport 67 -j ACCEPT -A nova-network-INPUT -i br100 -p udp -m udp --dport 53 -j ACCEPT -A nova-network-INPUT -i br100 -p tcp -m tcp --dport 53 -j ACCEPT

   
   

注: 67 は DHCP のポートであり、53 は DNS のポートです。

nova-compute を実行しているホストのルール

nova-compute モジュールもラップ・チェーンを作成します。これらのチェーン上で、nova-compute モジュールは filter テーブル内にルールを作成します。これらのルールについて調べてみましょう。

転送されたトラフィックがブリッジを通過できるようにするためのルール

nova-compute を実行しているホスト上に以下のルールが作成されることにより、VM は nova-network を実行しているホストや、他の nova-compute を実行しているホスト上の VM と接続できるようになります。

-A nova-compute-FORWARD -i br100 -j ACCEPT 
-A nova-compute-FORWARD -o br100 -j ACCEPT

各インスタンスに対するチェーンとルール

nova-compute モジュールは各インスタンスに対し、以下のように 1 つのチェーンと複数のルールを filter テーブル内に作成します (図 4)。

この図から以下のことがわかります。

1. nova-compute は各インスタンスに対して 1 つのチェーンを作成します。図 4 の場合、このチェーンの名前は「nova-compute-inst-1」です。
2. このインスタンスを送信先とするすべてのトラフィックは、それが転送されたトラフィックであれ、ローカル・プロセスによって生成されたプロセスであれ、このインスタンスの専用チェーンに渡されます。
3. このインスタンスが存在するサブネットの IP からのトラフィックはすべて許可されます。
4. 指定された DHCP サーバーからの DHCP トラフィックはすべて許可されます。
5. それ以外のトラフィックはすべて破棄されます。

nova-api

nova-api は起動されると、他のプロセスが nova-api サービスにアクセスできるようにするためのルールを filter テーブル内に作成します。

-A nova-api-INPUT -d 192.168.1.90/32 -p tcp -m tcp --dport 8775 -j ACCEPT

フローティング IP

フローティング IP がどのように実装されるのかを確認するには、まず 1 つのフローティング IP をインスタンスの固定 IP と関連付けます。先ほど作成したインスタンスの固定 IP は 10.10.10.2 です。

デフォルト・プール内にフローティング IP を作成する

以下のようにしてデフォルト・プール内にフローティング IP を作成します。

# nova-manage floating create --ip_range=192.168.1.232/30

以下のようにしてこのプールからフローティング IP を割り当てます。

# Nova floating-ip-create

すると 192.168.1.233 という IP が得られます。今度はこの IP を、以下のようにして 8f773639-c04f-4885-9349-ac7d6a799843 という ID のインスタンスに割り当てます。

# nova add-floating-ip 8f773639-c04f-4885-9349-ac7d6a799843 192.168.1.233

フローティング IP をパブリック・インターフェースにバインドする

FLAGS.public_interface を使用してフローティング IP をバインドします。nova add-floating-ip コマンドを実行すると、public_interface の下に以下のフローティング IP があることがわかります。

# ip addr list dev wlan0
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 08:11:96:75:91:54 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.90/16 brd 192.168.255.255 scope global wlan0
    inet 192.168.1.233/32 scope global wlan0
    inet6 fe80::a11:96ff:fe75:9154/64 scope link 
       valid_lft forever preferred_lft forever

フローティング IP のための nat テーブルのルール

インスタンスが nova-network を実行しているホスト上でフローティング IP を取得すると、以下のルールが適用されます。

-A nova-network-OUTPUT -d 192.168.1.233/32 -j DNAT --to-destination 10.10.10.2
-A nova-network-PREROUTING -d 192.168.1.233/32 -j DNAT --to-destination 10.10.10.2 
-A nova-network-float-snat -s 10.10.10.2/32 -j SNAT --to-source 192.168.1.233

フローティング IP からインスタンスの固定 IP への変換に dNAT ルールが使用されていることがわかります。ターゲット IP としてフローティング IP を持つ、nova-network を実行しているホストにパケットが到着すると、そのターゲット IP は変換されます。そして sNAT ルールにより、トラフィックはインスタンスの固定 IP からフローティング IP に変換されます。VM から固定ネットワーク外部へのトラフィックはすべてゲートウェイ宛てに送信され、ゲートウェイは nova-network の dnsmasq プロセスによって設定されているため、この sNAT ルールによって VM からのトラフィックはフローティング IP からのトラフィックとして適切にマスクされます。また OUTPUT チェーンにラップされた dNAT ルールにより、nova-network のローカル・プロセスはフローティング IP を持つ VM にアクセスすることができます。

フローティング IP を持つ VM に ping を実行する

フローティング IP を持つ VM に ping を実行するためには、さらにルールが必要です。nova-compute を実行しているホストには各インスタンス専用のチェーンがあることを思い出してください。そのチェーンのルールは単に固定サブネット内の IP からのトラフィックを許可するにすぎません。フローティング IP に ping を実行すると、ping パケットのソース IP は固定サブネットの範囲内にはないため、これらのルールによってトラフィックは破棄されます。当然ですが、icmp トラフィックを許可するためのルールを追加する必要があります。

ping を許可するルールを追加するには、以下のように OpenStack のセキュリティー・グループ・ルールの概念を使用します。

# nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0

すると、そのインスタンスの専用チェーンの下に、もう 1 つのルールが以下のように作成されたことがわかります。

同じ方法で、フローティング IP を持つ VM に SSH 接続を許可することもできます。

上に戻る

まとめ

OpenStack ネットワークでは、iptables のルールが至るところで使用されています。OpenStack ネットワークのセキュリティー・グループとフローティング IP の概念は iptables のルールを使用するための出発点にすぎません。以下に挙げる参考文献を掘り下げ、OpenStack の IaaS 環境を使用する方法についてさらに学んでください。

参考文献

学ぶために

• 開発者コミュニティーによる以下のリソースを利用して OpenStack システムについて調べてください。
  • Compute (Nova) モジュール
    • OpenStack の資料
    • GitHub にある Nova プロジェクト開発者のサイト
    • 「OpenStack Compute Administration Manual」
  • Networking (Quantum) に関する OpenStack の資料
  • Image Service (Glance)
    • Image Service プロジェクトの資料
    • OpenStack の資料
  • Identity (Keystone)
    • OpenStack の資料
    • OpenStack プロジェクトの資料
  • Storage (Swift) に関する OpenStack の資料
  • Dashboard (Horizon) に関する OpenStack の資料
  • OpenStack のマニュアル
    • 開発者マニュアル
    • API マニュアル
    • 管理ガイド
  • 一般的な質問に対する回答
  
  
• この記事の著者は、Compute ノードのどのホストがイメージ・インスタンスを起動するのかを OpenStack の Nova スケジューラーを使用して判断するための方法を解説しています。OpenStack についての著者の解説は彼のブログを参照してください。
  
  
• developerWorks には OpenStack のウィキがあります。
  
  
• developerWorks のクラウド・コンピューティング・ゾーンを訪れてください。コミュニティーで行われている貴重な議論を見つけることやクラウドに関連する新しい技術リソースについて学ぶこともできます。
  
  
• さまざまな IBM 製品や IT 業界のトピックに焦点を絞った developerWorks の Technical events and webcasts で最新情報を入手してください。
  
  
• 無料の developerWorks Live! ブリーフィングに出席し、IBM の製品やツール、また IT 業界のトレンドに関する最新情報を入手してください
  
  
• Twitter で developerWorks をフォローしてください。
  
  
• developerWorks On demand demos をご覧ください。初心者のための製品インストール方法やセットアップのデモから、上級開発者のための高度な機能に至るまで、多様な話題が解説されています。
  
  

製品や技術を入手するために

• 皆さんに最適な方法で IBM 製品を評価してください。製品の試用版をダウンロードする方法、オンラインで製品を試す方法、クラウド環境で製品を使う方法、あるいは SOA Sandbox で数時間を費やし、サービス指向アーキテクチャーの効率的な実装方法を学ぶ方法などがあります。
  
  

議論するために

• developerWorks コミュニティーに参加してください。ここでは他の developerWorks ユーザーとのつながりを持てる他、開発者によるブログ、フォーラム、グループ、ウィキを調べることができます。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• iptables の構造
• OpenStack 内部の iptables
• OpenStack 入門
• Nova における IP アドレス設定
• iptables のルールとチェーン
• まとめ
• 参考文献
• 著者について
• コメント