目次


クラウドでのネットワーク構築

IBM SmarterCloud Enterprise でネットワーク構築をするためのツールおよび概念を探る

Comments

クラウドでのネットワーク構築は、2 つの対極的な側面を示します。つまり、クラウドでのネットワーク構築は、クラウド・コンピューティングを実現する基本要素の 1 つであるとともに、クラウド・コンピューティグのユーザーを危険にさらす要因の 1 つでもあります。

ネットワークのパフォーマンスが低下したり不安定になったりすると、クラウド・リソースの利用に大きな影響を及ぼす可能性があります。したがって、クラウドで実行するアプリケーションとしては、ネットワークから比較的分離されているアプリケーションや、ネットワーク障害に対処するように特別に設計されたアプリケーションが適しています。

別の視点から考えると、クラウド・コンピューティングではネットワーク・リソースを仮想化して、他のリソースとまったく同じように使用することができます。

ネットワーク・システムを構成する各層の管理責任は、クラウド・プロバイダーまたはクラウド・コンシューマーのいずれかに置かれ、その責任範囲はクラウドのタイプによって異なります。以下の表に、典型的なシナリオを要約します。

表 1. ネットワーク層の管理
OSI 参照モデルの階層プロトコルIaaSPaaSSaaS
第 7 層: アプリケーションHTTP, FTP, NFS, SMTPコンシューマーコンシューマープロバイダー
第 6 層: プレゼンテーションSSL, TLSコンシューマープロバイダープロバイダー
第 5 層: セッションTCPコンシューマープロバイダープロバイダー
第 4 層: トランスポートTCPコンシューマープロバイダープロバイダー
第 3 層: ネットワークIP, IPSecコンシューマープロバイダープロバイダー
第 2 層: データ・リンクイーサネット、ファイバー・チャネルプロバイダープロバイダープロバイダー
第 1 層: 物理銅線、光ファイバープロバイダープロバイダープロバイダー

上記の表は、実存する多くのモデルを単純化したものです。単純化されていると言っても、この表からは、IaaS がネットワーク・トポロジーとサービスにおいてクラウド・コンシューマーに与える柔軟性は、PaaS および SaaS クラウドを大幅に上回ることが明らかに見て取れます。ただし IaaS には、おそらくその柔軟性を提供するツールを管理しなければならないという犠牲が伴います。

早速、いくつかのネットワーク・ツールについて、それぞれに異なる要件を持つビジネス・シナリオの視点から、その利点と欠点を検討していきます。

ネットワーク・ツールが各種のシナリオで管理を容易にする方法

図 1 に、複合 Web アプリケーションの場合の典型的なネットワーク・トポロジーを示します。この図には、ファイアウォール構成、VLAN セットアップ、ロード・バランシング用のパブリック/プライベート IP 構成、そしてビジネス・パートナーのイントラネットへのアクセスが示されています。

図 1. 複合 Web アプリケーションのネットワーク・トポロジー
複合 Web アプリケーションのネットワーク・トポロジー
複合 Web アプリケーションのネットワーク・トポロジー

ビジネスにクラウドを導入した組織のさまざまなシナリオで、どのようにネットワーク・ツールを使用できるかを見てみましょう。

本番システム (ファイアウォールを使用):

  • プロキシーを使用することもできます。ただし、それはセキュリティーのためではなく、通常はロード・バランシングのためです。
  • 管理者は、SSH トンネルまたは SOCKS プロキシーを介してバックエンド・サーバーにアクセスすることができます。
  • ファイアウォール内のサーバーがセキュリティーの更新や、ライセンスのアクティベーション、その他のタスクを行うためにインターネットにアクセスする際に、サーバーの内部がインターネットに可視にならないようにするためには、ファイアウォール・ルールが必要です。

開発シナリオ (VPN を使用):

  • 企業へのリバース・アクセスが必要になる場合があります。
  • ネットワーク・エキスパートによる支援を得られない場合があるため、軽量のセットアップにしなければなりません。
  • DHCP を使用したラップトップ上の VPN サーバーによって、クラウドからのアクセスを許可することができます。

企業レベル:

  • 企業への一般アクセスに対し、サイト間 VPN が必要になる場合があります。

編集者からの注記:参考文献」セクションでは、企業レベルのクラウド・ネットワーク構築とそのツールについて取り上げた資料 (「クラウド・ネットワークの制御をユーザーに渡す: 仮想ネットワークを使用すると、クラウド・ネットワークの構築に関する制御を顧客ができるようになる仕組みを学ぶ」など) を紹介しています。

ツールおよびツールが解決する課題

以下に記載するようにツールを使用すると、ネットワークを介して提供されるクラウド・サービスを提供する上で役に立ちます。

IP アドレスを使用して VM へ接続する

クラウド・コンピューティングで真っ先に解決しなければならない問題の 1 つは、仮想マシンへの接続方法に関するものです。仮想マシンを作成する際に使用するアドレスには、いくつかの選択肢があります。具体的には、システムが生成するアドレス、予約 IP アドレス、仮想ローカル・エリア・ネットワーク (VLAN) が挙げられます。

システムが生成するアドレスは、DHCP (Dynamic Host Control Protocol) が割り当てるアドレスと似ています。これらのアドレスは実際には静的 IP アドレスですが、それを割り当てるのは IaaS クラウドの役割です。ログインして使用できる仮想マシンさえあれば必要を満たせるという場合には、これが最も簡単な方法となります。

予約 IP アドレスは、仮想マシンとは独立してプロビジョニングし、管理できるアドレスです。仮想マシンに複数の IP アドレスを割り当てる必要がある場合には、予約 IP アドレスが役立ちます。

VLAN については、後述します。

仮想ネットワークを管理する

仮想マシンからなるシステムを扱っている場合、ネットワーク・セキュリティーを検討する際に考えなければならないのは、ネットワークの管理です。ネットワーク・リソースは、他のクラウド・リソースと同じく仮想化することができます。ネットワーク・リソースを仮想化する場合、クラウドは仮想スイッチを使用して、物理ネットワークを論理パーティションに分割します。図 2 に、この概念を図解します。

図 2. クラウドでの物理ネットワークと仮想ネットワーク
クラウドでの物理ネットワークと仮想ネットワーク
クラウドでの物理ネットワークと仮想ネットワーク

仮想ローカル・エリア・ネットワーク (VLAN) は、企業のプライベート・ネットワークの拡張として使用することができます。クラウドでの VLAN は、VLAN に接続された仮想マシンのネットワークでの可視性を制限するために、プライベート IP アドレスを使用します。IANA (Internet Assigned Numbers Authority) では、IP アドレス空間のなかで以下の 3 つのブロックをプライベート・ネットワーク用に確保しています。

  • 10.0.0.0 ~ 10.255.255.255 (10/8 プレフィックス)
  • 172.16.0.0 ~ 172.31.255.255 (172.16/12 プレフィックス)
  • 192.168.0.0 ~ 192.168.255.255 (192.168/16 プレフィックス)

VLAN に接続するには、暗号化された仮想プライベート・ネットワーク (VPN) 接続を使用することも、別のネットワーク (インターネットを含む) に接続されたデュアル・ホーム仮想マシンを介してルーティングすることもできます。

ハイパーバイザーは、1 つの物理ネットワーク・インターフェースを複数の仮想マシンと共有することができます。この場合、各仮想マシンは 1 つ以上の仮想ネットワーク・インターフェースを持ちます。ハイパーバイザーがこの仕組みを可能にする方法には、以下の 3 つがあります。

  • ブリッジング
  • ルーティング
  • ネットワーク・アドレス変換 (NAT)

デフォルト・モードとなるのは、通常はブリッジングです。このモードでは、ハイパーバイザーがデータ・リンク層 (OSI 参照モデルの第 2 層。表 1 を参照) で動作し、イーサネット・レベルで、仮想ネットワーク・インターフェースを外部に対して可視にします。

ルーティング・モードでは、ハイパーバイザーがネットワーク層 (OSI 参照モデルの第 3 層) で動作し、IP レベルで、仮想ネットワーク・インターフェースを外部に対して可視にします。

NAT では、仮想ネットワーク・インターフェースは外部に可視になりません。仮想マシンがインターネットにネットワーク・データを送信することはできても、仮想マシンはインターネット上で可視になりません。

一般に、NAT を使用する目的は、ホストまたはルーターが使用するパブリック IP アドレスの背後に、プライベート IP アドレスを持つ仮想ネットワーク・インターフェースを隠すためです。ネットワーク・パケットに含まれる IP アドレス情報は、NAT ソフトウェアがルーティング・テーブルの情報に従って変更します。パケット内のチェックサム値も同じく変更する必要があります。

NAT は、仮想マシンの数よりも多くのサーバーをネットワークに配置するために使用することができます。これを可能にするのは、ポート変換です。コンピューターの数が IP アドレスの数を上回るとしても、IPv6 が未だに普及していない理由の 1 つは、NAT にあります。IP アドレスを共有するには、いくつかの方法があります。

例えば、1 台のルーターと、HTTP、FTP、メールのそれぞれに対応する 3 台のサーバーがあるとします。表 2 に示すように、ルーターにはパブリック IP アドレスを割り当て、HTTP サーバー、FTP サーバー、メール・サーバーにプライベート IP アドレスを割り当てることで、着信トラフィックを転送することができます。

表 2. ネットワーク・アドレス変換 (NAT) の例
パブリック IPポートプライベート IP
9.0.0.1 (ルーター)9.0.0.1 (ルーター)9.0.0.1 (ルーター)
80、4432125
192.168.0.1 (HTTP サーバー)192.168.0.2 (FTP サーバー)192.168.0.3 (メール・サーバー)

複数の IP アドレスを扱う

IBM SmarterCloud Enterprise では、IP アドレスを個別に管理して、仮想マシンに割り当てることができます。例えば、1 つの仮想マシンに複数の IP アドレスを割り当てることも可能です。

1 つの仮想マシンに複数の IP アドレスを割り当てる必要があるのは、さらに高い可用性が必要な場合や、ファイアウォールや VPN を使用した異なるネットワーク・ゾーンに接続しなければならない場合などです。これらのステップについては、developerWorks の記事「IBM SmartCloud Enterprise についてのヒント: 別々の VLAN にまたがる」で説明しています。

ファイアウォールを使用して複数の仮想マシンを保護する

個々のファイアウォールは、保護対象のリソースと同じサーバーにインストールされます。ファイアウォールは、クラウド・コンピューティングには欠かせないツールです。IBM SmarterCloud Enterprise のすべてのイメージを含め、最近のほとんどのオペレーティング・システムには、個別のファイアウォールが同梱されています。Linux 仮想マシンでそれに相当するのは iptables であり、Windows では Microsoft によるソリューションが同梱されています。

IBM SmarterCloud Enterprise の場合、ハイパーバイザーとその管理対象の仮想マシンの間にもファイアウォールがあります。

ファイアウォール・ルールは、ネットワーク・パケットおよびターゲットに対し、一連の基準を規定します。ネットワーク・パケットが到着すると、それぞれのルールがチェックされます。そのパケットがルールの基準を満たさなければ、次のルールがチェックされるといった具合です。

SUSE マシンでは、YAST 管理ユーティリティーを使用してファイアウォール・ルールを追加することができます。例えば、あらゆる外部アドレスからポート 50030 へのアクセスを許可するには、以下のようにします。

  1. root として、コマンドラインから「yast」と入力して YAST を起動します。Tab キーを使用して「Security and Users (セキュリティとユーザ)」 > 「Firewall (ファイアウォール)」の順にナビゲートし、Enter キーを押します。この操作によって、図 3 のような画面が開きます。
    図 3. YAST ファイアウォール管理ユーティリティー
    YAST ファイアウォール管理ユーティリティー
    YAST ファイアウォール管理ユーティリティー
  2. Custom Rules (カスタムルール)」にナビゲートして、Enter キーを押します。
  3. Add (追加)」にナビゲートして、Enter キーを押します。
  4. ソース・ネットワークとして、任意のソース・コンピューターを意味する「0/0」を入力し、ポートには、この例で対象とするポートである「50030」を入力します (図 4 を参照)。
    図 4. YAST のカスタム・ファイアウォール・ルール
    YAST のカスタム・ファイアウォール・ルール
    YAST のカスタム・ファイアウォール・ルール
  5. Add (追加)」、「Next (次へ)」、「Finish (完了)」の順にクリックします。手動で再起動する必要はありません。その操作は、YAST が自動的に行います。

Red Hat イメージでは、iptables コマンドを使用してファイアウォール・ルールを管理することができます。iptables コマンドの基本フォームは以下のとおりです。

# iptables [-t table] -[AD] chain rule-specification [options]

ファイアウォール・ルールに関連付けるアクションには、ACCEPT、DROP、QUEUE、および RETURN があります。ネットワーク・パケットを許可しない場合には、DROP アクションを指定します。iptables コマンドでは、A を指定するとルールを追加することができ、D を指定するとルールが削除されます。

ファイアウォール・テーブルは 3 つあります。デフォルトのテーブルは、filter という名前のテーブルです。このテーブルには、inputforwardoutput の 3 つのチェーンが含まれています。input チェーンは、ローカル・ソケットへの着信パケットに適用され、forward チェーンはルーティングされるパケット、output チェーンはローカルで生成されるパケットに適用されます。

一例として、ポート 80 (デフォルトの HTTP ポート) で任意のソースからのネットワーク・パケットを許可するとします。その場合には、コマンド # /sbin/iptables -A INPUT -p tcp --dport 80 -j ACCEPT を使用します。

このコマンドは、filter テーブルの input チェーンに、ポート 80 での TCP パケットに対するアクションを ACCEPT に設定したルールを追加します。-p パラメーターは、プロトコルを指定します (この例では tcp を指定)。--dport 80 オプションは、宛先ポートです (この例ではポート 80 を指定)。-j (jump) オプションは、ターゲット・アクションです (この例では ACCEPT を指定)。

ファイアウォール・ルールは必要な期間に限って設定することが賢明なプラクティスとなるはずなので、それを考えるとコマンドライン形式は理想的です。その一方、次にインスタンスを再起動したときにも設定したルールが引き続き有効になるように、ルールを永続的に維持しなければならないこともよくあります。その場合には、/etc/sysconfig/iptables ファイルを編集してください。典型的な iptables ファイルは、以下のような内容になっています。

*filter
:INPUT DROP [67:14849]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [346:34696]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
COMMIT

上記の内容は、filter テーブルのルールを指定しています。着信パケットのドロップは、ポート 67 から 14849 のパケットに対して適用されます。転送は一切許可されません。ポート 346 から 34696 に対しては、すべての発信パケットが許可されます。また、ポート 22 (SSH) での着信パケットは許可されます。このファイルを編集して保存した後、コマンド # /sbin/service iptables restart を使用して、iptables サービスを起動または再起動します。

iptables コマンドで変更を行った場合は、コマンド # /sbin/service iptables save で、変更内容を保存します。

ファイアウォールの状況を確認するには、以下のコマンドを使用します。

# /sbin/service iptables status

ハイパーバイザーのファイアウォール・ルールを使用すると、パフォーマンスに関して優位な点があります。けれども、これらのルールをローカル・ファイアウォールのルールのように動的に管理することはできません。また、ルールを管理できるのは、個人レベルまたはコミュニティー・レベルの可視性イメージに対してのみです。

ハイパーバイザーのファイアウォール・ルールは、インスタンスの作成時に、IBM SmarterCloud Enterprise の parameters.xml ファイルを使用して設定することができます。この XML ファイルは、使用しているイメージに対応するアセット・カタログ・エントリーで調べてください。

さらに Linux ファイアウォールを使用して、ファイアウォールが置かれているサーバー以外のサーバーを保護することもできます。実際、これは推奨される構成です。Linux ファイアウォールを追加すると、それが追加の分離レベルとなるためです。

サーバーを保護するには、まず、保護対象のサーバーをVLAN に配置してインターネットから隔離する必要があります。次に、ファイアウォール仮想マシンに 2 つの IP アドレスを追加します。最後に、インターネットと VLAN との間での転送用のルールを iptables に構成します。図 5 を参照してください。

図 5. VLAN を保護するファイアウォールの概略図
VLAN を保護するファイアウォールの概略図
VLAN を保護するファイアウォールの概略図

図 5 では、仮想マシン VM1 がインターネットに直接接続されています。ファイアウォール VM2 には、2 つの IP アドレスがあります。

  • 一方のアドレスにはインターネットからアクセスすることができます。
  • もう一方のアドレスは、プライベート VLAN 上でのアドレスです。

仮想マシン VM3 には 1 つの IP アドレスしかありません。この IP アドレスには、VLAN 上でのみアクセスすることができます。ファイアウォール・ルールは、インターネットからのインバウンド・アクセスを許可し、ファイアウォールの IP アドレスを VM3 の IP アドレスの特定のポートにマッピングするというものです。このルールにより、そのポートでのみ、インターネットからのインバウンド・アクセスが許可されることになります。

例えば、これが Web サーバーだとすると、ユーザーがファイアウォールの IP アドレスのポート 80 にアクセスしようとすると、その要求は VM3 の Web サーバーに転送されることになります。それ以外の VM3 上のすべてのポートは開放されません。

もう 1 つのファイアウォール・ルールでは、VM4 に対してアウトバウンド・アクセスを許可します。これを可能にする方法は、個々の TCP 接続に応じて動的にポートを使用するというものです。例えば、VM4 がインターネットへの TCP 接続をオープンしようとして TCP パケットを送信すると、ファイアウォールは使用可能なポートを見つけ、そのポート番号とファイアウォールの IP アドレスを VM4 からの TCP パケットに対して設定しなおしてから、そのパケットを送信します。VM4 からのリクエストへの応答としてインターネットから返されたパケットを受信すると、ファイアウォールはリバース・マッピングを行います。このようにして、仮想マシン VM4 がインターネットに可視になることなく、インターネットとの接続をオープンできるようにします。

SSH または PuTTY を使用してユーザーおよびサーバーを認証する

これまでのセクションでおわかりのように、SSH はクラウド・コンピューティングでの基本ツールです。したがって、クラウド・コンピューティングでの実際の問題の数々を解決するためには、SSH を学んでおく価値があります。SSH は Telnet に代わるセキュアな手段として設計されましたが、今では一般的にさまざまなアプリケーションでプログラムによって使用されています。

SSH の主なバージョンには SSH-1 と SSH-2 の 2 つがあります。最初のバージョンである SSH-1 を置き換えたのが SSH-2 です。SSH-2 は、Internet Engineering Task Force が標準として開発し、2006年にリリースされました。最もよく使われている SSH の実装は、OpenSSH オープンソース・プロジェクトです。一方、Windows で最もよく使用されているクライアントは、PuTTY です。PuTTY の基本的な使用方法についての情報は、「参考文献」セクションを参照してください。

SSH は、必要に応じて公開鍵暗号によるリモート・コンピューターおよびユーザーの認証を行います。リモート・ログインの他、トンネリング、フォワーディング、X11 接続、およびファイル転送にも SSH を使用することができます。また、ファイルをコピーするには SCP (Secure Copy) プロトコルおよび SFTP を使用することができますが、この 2 つはともに SSH を使用します。

一般的なシナリオとして、クラウドに 2 つのインスタンス (server1 と server2) を作成し、server1 から server2 に対して SSH セッションをオープンするとします。ローカル PC には既存の秘密鍵があるはずなので、その秘密鍵を server1 にコピーしなければなりません。鍵をコピーするには、WinSCP を使用することができます。server2 は承認済みの鍵のリストに含まれる公開鍵を使用して作成されているため、あらかじめこの鍵を受け入れるように構成されることになります。以下のコマンドを使用してください。

> chmod 0700 mykey
> ssh -i mykey server2

ここで、mykey はお持ちの秘密鍵の名前です。秘密鍵は、他のユーザーに可視にならないようにしなければなりません。それを行っているのが、chmod コマンドです。このようにモードを変更しなければ、ssh がエラーを発行し、鍵を無視する可能性があります。-i オプションでは、前の説明で SSH セッションでコピーした鍵を指定します。デフォルトは、~/.ssh/id_rsa です。server2 引数は、server2 のホスト名または IP アドレスです。ディレクトリー .ssh に対して適切な権限を持っていることを確実にしてください。ファイルのいくつかを root が所有している場合には、chown 3コマンドでその所有者を idcuser に変更する必要があります。

新しい SSH 鍵を生成するには、ssh-keygen コマンドを使用します。その一例は、> ssh-keygen -t rsa -P 'My Passphrase' -f ~/.ssh/mykey です。

このコマンドにより、パスフレーズが 'My Passphrase' (-P フラグ) に設定された RSA タイプ (-t フラグ) が生成され、秘密鍵はファイル ~/.ssh/mykey (-f フラグ) に、公開鍵はファイル ~/.ssh/mykey.pub に格納されます。-f オプションを使用しない場合、秘密鍵は ~/.ssh/identity に書き込まれます。承認済みの鍵は、ファイル ~/.ssh/authorized_keys に格納されます。新しい公開鍵を承認済みの鍵ファイルに追加するには、以下のコマンドを使用します。

> cat mykey.pub >> ~/.ssh/authorized_keys

IBM SmarterCloud Enterprise は、OpenSSH にも対応したフォーマットで SSH 鍵を生成します。鍵のフォーマットは、PuTTYgen を使用して PuTTY フォーマットに変換することもできます。PuTTYgen では、元の鍵を失くした場合に備え、再び OpenSSH フォーマットに戻せるようにもなっています。フォーマットを戻すには、メニューから「Conversions (変換)」 > 「Export OpenSSH Key (OpenSSH 鍵のエクスポート)」の順に選択し、ファイルを保存します。

PuTTYgen でも鍵を生成することはできます。クラウドによって生成された鍵を使用しないことを選ぶ場合には、生成した公開 SSH 鍵を SmarterCloud Enterprise にアップロードしてください。

IBM SmarterCloud Enterprise 上の Linux システムでは、SSH の構成ファイルは /etc/ssh/ssh_config および /etc/ssh/sshd_config に置かれます。この構成ファイルで変更する必要がある設定は、AllowedUsers だけです。このパラメーターの値は、ユーザー名パターンをスペースで区切ったリストです。例えば、AllowUsers idcuser webadmin のようなリストになります。

SSH サーバー (sshd) を起動するにはコマンド # /etc/init.d/sshd start を使用し、再起動するにはコマンド # /etc/init.d/sshd restart を使用します。

スクリプトから実行する場合をはじめ、SSH コマンドにユーザー名を組み込まなければならないこともあります。その場合には、$ ssh -i .ssh/key-file idcuser@host という形を使用します。

  • @ 記号は、ユーザー名をホスト名または IP アドレスから区別します。
  • -v (verbose) オプションは、追加情報を出力するため、問題をデバッグする際に役立ちます。

IBM SmarterCloud Enterprise のイメージの大半では、デフォルトで、SSH サーバーは /var/log/secure ファイルに情報およびエラー・メッセージを送信します。

パスフレーズを SSH 鍵に追加することは、鍵を保護する上で賢明なプラクティスですが、このプラクティスの問題は、鍵を利用しなければならないスクリプトとプログラムがパスフレーズの情報を持っていないことです。OpenSSH ディストリビューションに含まれている ssh-agent ツールは、この問題を解決するように意図されています。このツールには、stash ファイルによって Web サーバーが X.509 証明書を開けるようにしているのと同じような方法で、パスフレーズの入力を自動化する機能があります。

SSH トンネルを利用するツールはいくつもあります。例えば、NX リモート・デスクトップ技術でも、SSH トンネルを利用します。ファイル転送ツールのなかにも、SSH トンネルを利用するツールがあります。

SCP としても知られる Secure Copy は、ファイルをセキュアに転送するためのプロトコルであり、なおかつそのためのプログラムでもあります。Secure Copy は、SSH でトンネリングされたBSD RCP (Remote Copy) コマンドをベースとします。SSH の場合と同様、デフォルトではポート 22 で動作します。Linux で SCP を使用するには、以下のコマンドを使用します。

# scp -i identity_file host:sourcefile destinationfile

このコマンドは秘密鍵ファイル identity_file を使用して、sourcefile ファイルを host マシンからローカル・マシンの destinationfile ファイルにコピーします。

Windows の WinSCP プログラムは、実際にはデフォルトで SFTP (Secure FTP) で動作しますが、SCP を使用することもできます。

SSH によるポート・フォワーディング

SSH によるポート・フォワーディングは、以下の処理を行うプロセスです。

  1. パケットのアドレスとポートを新しい宛先のアドレスとポートに変換します。
  2. その宛先へのアクセスに利用されている SSH 接続上でパケットを伝送します。

このプロセスにより、ユーザーは SSH 接続上で別のプロトコルをトンネリングすることができます。OpenSSH の場合、このプロセスは sshd によって行われます。トンネリングの対象とするプロトコルがセキュアでない場合や、宛先のアドレスとポートの組み合わせが送信元から見えない場合には、この SSH によるポート・フォワーディングが役に立ちます。

プロトコルをトンネリングして使用するクライアントは、そのプロトコルが機能する標準ポート以外のポートを指定することができなければなりません。この概念では、ユーザーは自分の目的とするサーバーに対して SSH セッションを確立した後、接続の転送元とするクライアント・マシン上のポートを指定します。

SSH は、他のサーバーに対して転送することもできます。ポート・フォワーディングは、クラウド、ワークステーション、そして企業内の IT リソースとの間の接続性の問題を解決する上で重要な手段となる場合があります。特に、ファイルをセキュアな場所に移動するなどの、作業量が少ない管理タスクのために、柔軟でありながらセキュアなアクセスが必要な場合には、ポート・フォワーディングがなおさら重要になります。

ツールを理解することで、これらの管理タスクのカスタム・コードを作成して保守する必要がなくなります。このセクションでは、VNC での例を取り上げます。

クラウド・アプリケーションでは、リモート Linux デスクトップに接続しなければならないことがよくあります。リモート・マシンはインターネット上にあるため、セキュアでないネットワーク・トラフィックをリモート・マシンに送信することも、VNC などのセキュアでないサービスをインターネット上に公開することも避けなければなりません。

図 6 に、関連するネットワーク接続の概略を示します。

図 6. VNC トラフィックの SSH フォワーディングの概略図
VNC トラフィックの SSH フォワーディングの概略図
VNC トラフィックの SSH フォワーディングの概略図

VNC サーバーは仮想マシン上のポート 5901 で実行されています。このサーバーが接続する X11 ディスプレイは、Linux デスクトップをサポートします。ラップトップまたはワークステーションは、SSH クライアントを使用して、仮想マシン上で実行される SSH サーバーへのトンネリングによる接続を作成します。仮想マシン上で実行されているファイアウォールは、ポート 22 宛ての SSH トラフィック以外のトラフィックが仮想マシンにアクセスできないようにします。ラップトップ上で実行されている VNC クライアントは、トンネルを利用することで、ファイアウォールのポート 22 を通過して VNC サーバーにアクセスすることができます。

SSH トンネルの作成および使用

  1. ユーザーを root に切り替え、カレント・ディレクトリーを /etc/ssh ディレクトリーに変更し、ファイル sshd_config を以下のように編集します。
    AllowTcpForwarding yes
  2. root として ssh サーバーを再起動します。
    # /etc/init.d/sshd restart
    Stopping sshd:                            [  OK  ]
    Starting sshd:                            [  OK  ]
  3. VNC が実行されていない場合、idcuser として VNC を起動します。
    $ /usr/bin/vncserver
    ...
    New 'vhost0270:1 (idcuser)' desktop is vhost0270:1
    
    Creating default startup script /home/idcuser/.vnc/xstartup
    Starting applications specified in /home/idcuser/.vnc/xstartup
    Log file is /home/idcuser/.vnc/vhost0270:1.log
  4. プロンプトが出されたら、パスワードを入力します。表示専用パスワードを設定するかどうかを尋ねるプロンプトに対しては、「いいえ」を表す「n」を入力します。コマンドが出力する情報には、ログ・ファイルの名前も含まれます。
  5. vncserver を初めて実行するときに、構成ファイル ~idcuser/.vnc/xstartup が作成されます。通常のデスクトップでログインできるようにするには、この構成ファイルで 2 つの設定を変更する必要があります。~idcuser/.vnc/xstartup ファイルで、以下の 2 行のコメントを外してください。
    unset SESSION_MANAGER
    exec /etc/X11/xinit/xinitrc
  6. SUSE を使用している場合には、xstartup ファイルに上記の 2 行がない可能性があります。その場合には、以下のように VNC セッションを停止してから開始してください。
    $ /usr/bin/vncserver -kill :1
    $ /usr/bin/vncserver

    上記の例では、最初のコマンドで指定している「:1」は、前に vncserver を実行して VNC を起動したときに表示された内容と一致している必要があります。

  7. VNC ログを調べて、どのポートで VNC が実行されているのかを確かめます。ログには以下のような内容が見つかるはずです。
    tail -f /home/idcuser/.vnc/vhost0270:1.log
    Copyright (C) 2002-2005 RealVNC Ltd.
    See http://www.realvnc.com for information on VNC.
    Underlying X server release 70101000, The X.Org Foundation
    
    Sun Oct 16 03:54:31 2011
     vncext:      VNC extension running!
     vncext:      Listening for VNC connections on port 5901
     vncext:      Listening for HTTP connections on port 5801
     vncext:      created VNC server for screen 0

    上記の例では、VNC が接続をポート 5901 でリッスンしていることがわかります。

仮想マシンに接続するには、SSH クライアントを使用してください。次のセクションでは、2 つのクライアント、OpenSSH と PuTTY について説明します。

OpenSSH コマンドによるトンネリング

Linux または Windows で OpenSSH を使用するには、Cygwin コマンドラインを使用することができます。Cygwin を使用するには、システムに cygwin openssh パッケージがインストールされていなければならないので、まずこのパッケージをインストールします (cygwin openssh パッケージがインストールされていない場合)。

SSH クライアントから仮想マシンへのトンネリングをポート 5901 で開始するには、以下のコマンドを実行します。

$ ssh -i ~/.ssh/key_name -L 5901:localhost:5901 idcuser@${SCE_VM}

-i オプションは使用する鍵を指定し、-L オプションはトンネルを指定します。使用するポート (5901) は、仮想マシン上で実行される VNC サーバーが使用するポートと一致していなければなりません。

PuTTY によるトンネリング

上記のトンネルに相当するトンネルを PuTTY で作成するには、以下の手順に従います。

  1. 「Connection (接続)」 > 「SSH」 > 「Tunnels (トンネル)」の順にクリックし、「PuTTY Configuration (PuTTY 設定)」ウィンドウを開きます (図 7 を参照)。
    図 7. PuTTY でのトンネルのセットアップ
    PuTTY でのトンネルのセットアップ
    PuTTY でのトンネルのセットアップ
  2. 「Source Port (源ポート)」フィールドにはポート番号として「5901」と入力し、「Destination (送り先)」フィールドには IP アドレス (またはホスト名) と宛先ポート番号 (5901) を ip:port の形で入力します。
  3. Add (追加)」をクリックします。
  4. Open (開く)」をクリックします。
  5. ログイン・プロンプトが出されたら、「idcuser」と入力します。これで、トンネルが作成されて、ユーザーが対話型シェルにログインされます。
  6. VNC クライアントを起動します。接続先のアドレスとして「localhost:5901」と入力します (図 8 を参照)。
    図 8. VNC クライアント
    VNC クライアント
    VNC クライアント
  7. OK」をクリックします。すると、Linux デスクトップが表示されるはずです。

仮想プライベート・ネットワークを使用する

仮想プライベート・ネットワーク (VPN) は暗号化を利用して、インターネット上にプライベート・ネットワークの拡張を作成します。VPN は、企業にとって価値のある数々のネットワーク・シナリオを実現します。

VPN は従来、企業の個々のオフィスのローカル・エリア・ネットワークを広域ネットワークに接続するために使用されてきました。このようなタイプの接続は、サイト間接続と呼ばれます。サイト間接続のために VPN が導入されると、それまで使用していた専用線に代わって VPN が使われるようになり、企業にとって大幅なコスト削減となりました。

VPN の従来の用途には、従業員が例えば自宅からリモートにある企業のプライベート・ネットワークにアクセスできるようにするというものもありました。このシナリオでは、企業がインターネットからアクセス可能な VPN ゲートウェイを用意し、従業員が各自のラップトップに VPN クライアントをインストールします。従業員はこの VPN クライアントで、e-メールなどのアプリケーションにアクセスします。このようなネットワークは、エンドポイントの一方 (従業員がいる場所) に固定 IP アドレスがないため、モバイル仮想プライベート・ネットワークと呼ばれます。

クライアントが VPN ゲートウェイ経由でパケットを送信する場合、パケットに認証ヘッダーが追加され、データが暗号化されてから、カプセル化セキュリティー・ペイロード (ESP) に格納されます。受信側 VPN サーバーは、このデータを復号し、ヘッダーの情報に従って、パケットを宛先にルーティングします。

VPN の暗号化は下位レベルで行われるため、企業との通信はすべて暗号化されます。暗号化が行われるのは OSI 参照モデルの第 2 層 (データ・リンク層) または第 3 層 (ネットワーク層) のいずれかで、そこには以下の暗号化手法をどれでも組み込むことができます。

  • IPsec
  • SSL/TLS
  • Datagram Transport Layer Security (Cisco)
  • Microsoft Point-to-Point 暗号化
  • SSH トンネリング

VPN では、ブリッジングを利用して仮想広域イーサネット LAN を作成することができます。この方法には、ルーティングを使用するのに優る利点がいくつかあります。ブリッジングは、イーサネットで有効なあらゆるプロトコルに対応できるためです。非 IP プロトコルや Windows ファイル共有を使用している場合には、ブリッジングが必要になります。ただし、VPN をセットアップするにはルーティングを使用したほうが簡単です。また、ルーティングでは、特定のホストおよびポートへのアクセスをきめ細かく制御することができます。

多くの企業でクラウド・コンピューティングを使用する目的は、企業の IT インフラストラクチャーのキャパシティーの拡大です。このシナリオをサポートするために、企業内のネットワークから内部のゲートウェイ経由で、クラウド内のプライベート VLAN に接続するための VPN が構成されます。これは、サイト間接続と呼ばれます。クラウドのプライベート・ネットワーク上にある仮想マシンは、インターネットからは見えませんが、VPN、または VLAN 上の他の仮想マシンを介した場合に限り、アクセスすることができます。この仕組みを図 9 に示します。

図 9. VPN を使用した企業ネットワークの拡張
VPN を使用した企業ネットワークの拡張
VPN を使用した企業ネットワークの拡張

このシナリオでは、クラウドは企業ネットワークの拡張として機能します。クラウド内での拡張は、インターネットからも、クラウド内の VLAN の外部にある仮想マシンからも隔離されます。IBM SmarterCloud Enterprise は、このシナリオを基本オファリングとしてサポートしています。自宅からアクセスするシナリオとは異なり、このシナリオでは従業員が特別な VPN クライアントをインストールする必要はありません。

また、企業がオンプレミスの VPN ゲートウェイを所有していなくても、クラウドを使用して VPN をサポートするというネットワーク・シナリオにも対応することができます。例えば、IBM SmarterCloud Enterprise カタログに含まれる CohesiveFT VPN-Cubed イメージによって、VPN ゲートウェイを提供することができます。その場合、自宅で業務を行う従業員を、OpenVPN クライアントなどの VPN クライアントでサポートすることが可能です。図 10 を参照してください。

図 10. クラウド内の VPN ゲートウェイを使用した VLAN へのアクセス
クラウド内の VPN ゲートウェイを使用した VLAN へのアクセス

OpenVPN は、ポイント・ツー・ポイント接続およびサイト間接続を管理できる、オープンソースの VPN クライアント・サーバー型ソリューションです。OpenVPN は、OpenSSL 暗号化ライブラリーを使用します。OpenVPN インストール・イメージは、OpenVPN Webサイトからダウンロードすることができます。このインストール・イメージには、クライアント・ソフトウェアとサーバー・ソフトウェアの両方が含まれているため、クライアント・マシンとサーバー・マシンの両方にイメージをインストールする必要があります。RHEL マシンでは RPM パッケージを使ってイメージをインストールすることができ、SUSE または他の Debian ベースのシステムの場合は apt-get コマンドを使用することができます。その他の Linux システムでは、make を使用して tarball からインストールすることができます。Windows 用には自己解凍インストーラーが用意されているだけでなく、クライント専用のインストール・イメージもあるので、エンドユーザーにはこれを使用するように指示することができます。

VPN-Cubed ソリューションは、Cohesive FT による商用ソフトウェア・パッケージです。これも、IBM SmarterCloud Enterprise に用意されています。VPN-Cubed ソリューションは、より複雑な仮想ネットワーク構成をクラウド内に作成する場合や、複数のクラウドにあるコンピューティング・リソースに VPN で接続する場合などに有用な数々のネットワーク構成に対応することが可能です。VPN-Cubed は仮想ルーター、仮想ブリッジ、VPN コンセントレーター、およびファイアウォールとして機能することができます。

OpenVPN をセットアップする

OpenVPN で VPN をセットアップするには、公開鍵インフラストラクチャーをセットアップする必要があります。これには、サーバーとクライアントごとの公開鍵および秘密鍵を格納する証明書、そしてこれらの証明書のそれぞれに署名する認証局 (CA) 証明書のセットアップも含まれます。デフォルトでは、VPN はこれらの証明書を使用して、サーバーとクライアント相互の認証を行いますが、別の認証方法を構成することもできます。さらに、動的 IP アドレスで OpenVPN サーバーをセットアップすることも可能です。

RHEL5 での OpenVPN サーバーのインストールと構成

  1. yum を使用して、OpenVPN サーバーをインストールします。
    1. RHEL5 用の OpenVPN パッケージは、標準リポジトリーには含まれていません。したがって、「yum install openvpn」と入力する前に、root として Fedora EPEL (Extra Packages for Enterprise Linux) リポジトリーのディストリビューションをダウンロードする必要があります。
      # rpm -ivh http://download.fedora.redhat.com/pub/epel/5/x86_64/ 
        epel-release-5-4.noarch.rpm

      上記のコマンドによる出力は、以下のとおりです。

      Retrieving http://download.fedora.redhat.com/pub/epel/5/x86_64/
       epel-release-5-4.noarch.rpm
      warning: /var/tmp/rpm-xfer.wmJlYz: Header V3 DSA signature: 
       NOKEY, key ID 217521  f6
      Preparing...                ########################################### [100%]
         1:epel-release           ########################################### [100%]
      [root@vhost0508 ~]#
    2. コマンド「# yum install openvpn」を実行して、OpenVPN パッケージをインストールします。

      このコマンドによる出力は、以下のとおりです。

      Loaded plugins: security
      Repository rhel-server is listed more than once in the configuration
      Setting up Install Process
      Resolving Dependencies
      --> Running transaction check
      ...

    OpenVPN (バージョン 2.1) の最新の (ただし、公式にはまだ安定版ではない) リリース候補 9 を提供する EPEL リポジトリーが正常にインストールされたことが出力から確認できるはずです。yum は、従属 LZO ライブラリーもインストールします。

  2. OpenVPN サーバーを構成します。以下のコマンドを root として実行してください。
    # mkdir -p /etc/openvpn
    # cp -R /usr/share/openvpn/easy-rsa/ /etc/openvpn/
    # cd /etc/openvpn/easy-rsa/2.0/

    VPN を構成するために利用できるスクリプトのリストが表示されます。以下に、重要なスクリプトをまとめて示します。

    • vars: 環境変数を作成し、必要なスクリプト変数を設定します。
    • build-ca: CA 証明書を作成します (対話式)。
    • build-dh: Diffie-Hellman ファイルを作成します。
    • build-key-server: サーバーの秘密鍵を作成します。
    • build-key: クライアントの秘密鍵を作成します。
  3. マスター CA 証明書/鍵、サーバー証明書/鍵、およびクライアントの証明書/鍵を生成します。
    1. 環境に合わせて vars スクリプトを編集します。以下は、その一例です。
      export KEY_COUNTRY="CN"
      export KEY_PROVINCE="Shanghai"
      export KEY_CITY="Shanghai"
      export KEY_ORG="IBM"
      export KEY_EMAIL="a.user@example.com"
    2. CA 証明書を生成します。
      # ./clean-all
      # source ./vars
      # ./build-ca

      上記のコマンドによる出力は、以下のとおりです。

      Generating a 1024 bit RSA private key
      .........................++++++
      ...................++++++
      writing new private key to 'ca.key'
      -----
      You are about to be asked to enter information that will be incorporated
      into your certificate request.
      What you are about to enter is what is called a Distinguished Name or a DN.
      There are quite a few fields but you can leave some blank
      For some fields there will be a default value,
      If you enter '.', the field will be left blank.
      -----
      Country Name (2 letter code) [CN]:
      State or Province Name (full name) [Shanghai]:
      Locality Name (eg, city) [Shanghai]:
      Organization Name (eg, company) [IBM]:
      Organizational Unit Name (eg, section) []:
      Common Name (eg, your name or your server's hostname) [IBM CA]:
      Name []:
      Email Address [a.user@example.com]:
      #
    3. サーバーの秘密鍵を生成します。
      # ./build-key-server server

      上記のコマンドによる出力は、以下のとおりです。

      Generating a 1024 bit RSA private key
      .................................++++++
      ....++++++
      writing new private key to 'server.key'
      -----
      You are about to be asked to enter information that will be incorporated
      into your certificate request.
      ...
      Certificate is to be certified until Sep 23 13:15:05 2021 GMT (3650 days)
      Sign the certificate? [y/n]:y
      1 out of 1 certificate requests certified, commit? [y/n]y
      Write out database with 1 new entries
      Data Base Updated
    4. クライアントの秘密鍵を生成します。
      # ./build-key client1

      上記のコマンドによる出力は、以下のとおりです。

      Generating a 1024 bit RSA private key
      ....................++++++
      .............++++++
      writing new private key to 'client1.key'
      -----
      ...
      Certificate is to be certified until Sep 23 13:16:57 2021 GMT (3650 days)
      Sign the certificate? [y/n]:y
      
      1 out of 1 certificate requests certified, commit? [y/n]y
      Write out database with 1 new entries
      Data Base Updated
    5. Diffie-Hellman パラメーターを生成します。
      # ./build-dh

      上記のコマンドによる出力は、以下のとおりです。

      Generating DH parameters, 1024 bit long safe prime, generator 2
      This is going to take a long time
      .........+........................................................+.........
    6. サーバー証明書を /etc/openvpn にコピーします。
      # cd keys
      # cp server.crt server.csr server.key ca.crt 
        ca.key dh1024.pem /etc/openvpn/
    7. クライアント証明書 zip で圧縮します。
      tar zcvf client1.vpn.key.tar ca.crt ca.key 
       client1.crt client1.csr client1.key
    8. サーバーを構成します。openvpn の構成ファイルを作成するには、openvpn の sample-config ファイルを参照することをお勧めします。以下に、一例を記載します。
      # cp /usr/share/doc/openvpn-2.1.4/sample-config-files/server.conf
       /etc/openvpn/
      # cd /etc/openvpn/
      # vi server.conf

      上記のコマンドによる出力は、以下のとおりです。

      local 129.35.209.162 # Which local IP address should OpenVPN listen on
      port 1194 #
      proto udp
      
      dev tun
      ca ca.crt
      cert server.crt
      key server.key  # This file should be kept secret
      dh dh1024.pem
      
      server 10.8.0.0 255.255.255.0
      
      client-to-client
      keepalive 10 120
      
      comp-lzo
      
      persist-key
      persist-tun
      status openvpn-status.log
      log         openvpn.log
      log-append  openvpn.log
      
      verb 3
      
      push "dhcp-option DNS 10.8.0.1"
      push "dhcp-option DNS 170.225.111.10"  # see h) to get name server,
      push "dhcp-option DNS 170.225.111.10"  # see h) to get name server
      push "dhcp-option DNS 170.224.55.203"  # see h) to get name server
    9. DNS 名前解決が適切に構成されていることを確認します。
      # vi /etc/resolv.conf

      上記のコマンドによる出力は、以下のとおりです。

      domain site2.compute.ihost.com
      nameserver 170.225.111.10
      nameserver 170.225.111.11
      nameserver 170.224.55.203
    10. ポート 1194 が開放されていることを確認します。それには、ファイアウォールがポート 1194 へのトラフィックを許可していることを確認するか、以下のコマンドを使用してポートを開放します。
      /sbin/iptables -A INPUT -i eth0 -p udp --dport 1194 -j ACCEPT
      /sbin/iptables -A OUTPUT -o eth0 -p udp --dport 1194 -j ACCEPT
      /sbin/service iptables save
      /sbin/service iptables restart
    11. openvpn サービスを起動、停止、再起動します。

      以下のコマンドで openvpn サービスを起動します。

      # service openvpn start

      出力は、以下のとおりです。

      Starting openvpn:                                          [  OK  ]

      以下のコマンドで openvpn サービスを停止します。

      # service openvpn stop

      出力は、以下のとおりです。

      Shutting down openvpn:                                     [  OK  ]

      以下のコマンドで openvpn サービスを再起動します。

      # service openvpn restart

      出力は、以下のとおりです。

      Shutting down openvpn:                                     [  OK  ]
      Starting openvpn:                                          [  OK  ]

これで、OpenVPN サーバーのインストールと構成は完了し、サーバーが稼働中の状態になりました。次は、このサーバーと通信するクライアントを構成する必要があります。

RHEL5 での OpenVPN クライアントのインストールと構成

  1. openvpn パッケージをインストールします。前の手順のステップ 1 とステップ 2 を繰り返してください。
  2. サーバーから client1 マシンに client1.key、client1.crt、および ca.crt をコピーします。
    #cp /usr/share/doc/openvpn-2.1.4/sample-config-files/client.conf
     /etc/openvpn
  3. sample-config-files/client.conf を見つけて編集します。「remote」ディレクティブを編集して、OpenVPN サーバーのホスト名 (または IP アドレス) とポート番号を指すようにしてください。

    出力は、以下のとおりです。

    remote 129.35.209.162  1194
    ca /etc/openvpn/easy-rsa/2.0/keys/ca.crt
    cert /etc/openvpn/easy-rsa/2.0/keys/client1.crt
    key /etc/openvpn/easy-rsa/2.0/keys/client1.key
  4. ソース・ディレクトリーから openvpn を起動します。
    ./openvpn sample-config-files/client.conf

起動プロセスの終わりに近づくと、「Initialization Sequence Completed (初期化シーケンス完了)」というメッセージが出力されます。

Windows での OpenVPN クライアント GUI のインストールと構成

  1. OpenVPN Webサイトから、OpenVPN GUI をダウンロードします。注: OpenVPN GUI と OpenVPN サーバーのバージョンは同じでなければなりません。
  2. OpenVPN GUI をインストールします。指示に従って、ファイルをダウンロードします。
  3. OpenVPN を構成します。
    1. サーバーからクライアント証明書をコピーします。
      ca.crt
      ca.key
      client1.crt
      client1.csr
      client1.key
    2. sample-config-files/client.conf を、インストール・ディレクトリーの下にある config ディレクトリーにコピーし、このファイルを以下のように編集して名前を client.ovpn に変更します (C:\Program Files\OpenVPN\config)。
      129.35.209.162  1194
      ca ca.crt
      cert client1.crt
      key client1.key
  4. GUI から OpenVPN を再起動します。

プロキシー・サーバーをセットアップする

Red Hat にプロキシー・サーバーをセットアップするには、以下の手順に従います。

  1. RTP Data Center で Red Hat 5.6 インスタンスをプロビジョニングします。このインスタンスには、パブリック IP とプライベート IP が設定されています。デフォルトでは、プライベート IP はプロビジョニング後もアクティブになりません。
    図 11. プロキシー・サーバーのセットアップ
    プロキシー・サーバーのセットアップ
    プロキシー・サーバーのセットアップ
  2. 以下のコマンドを実行して、現在のゲートウェイ情報を確認します。現在のゲートウェイは 170.224.160.1 です。
    # /sbin/route -n
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    170.224.160.0   0.0.0.0         255.255.240.0   U     0      0        0 eth0
    169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
    0.0.0.0         170.224.160.1   0.0.0.0         UG    0      0        0 eth0
  3. プライベート IP アドレスをアクティブにします。
    # /sbin/ifup eth1
  4. もう一度以下のコマンドを実行して、ゲートウェイ情報を確認します。現在のゲートウェイは 10.216.1.1 になっています。
    # /sbin/route -n
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    10.216.1.0      0.0.0.0         255.255.255.0   U     0      0        0 eth1
    170.224.160.0   0.0.0.0         255.255.240.0   U     0      0        0 eth0
    169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth1
    0.0.0.0         10.216.1.1      0.0.0.0         UG    0      0        0 eth1
  5. 今度はプライベート IP が「Active (アクティブ)」になっていることを再び確認します。
    図 12. アクティブになったプライベート IP
    アクティブになったプライベート IP
    アクティブになったプライベート IP
  6. プライベート IP を有効にすると、デフォルト・ゲートウェイが変更されて、インターネットにアクセスできなくなります。この問題を修正するには、パブリック IP ゲートウェイをインターネットから到達可能な最優先ゲートウェイとして設定します。
    [root@vhost0513 ~]# /sbin/route del default
    [root@vhost0513 ~]# /sbin/route add default gw 170.224.160.1
    [root@vhost0513 ~]# /sbin/route add default gw 10.216.1.1 metric 1

これで、インターネット上の IP に対して ping を実行すると応答が返ってくるようになります。

以下の手順によって、プライベート IP をプロキシー・サーバーとして設定し、同じサブネット内のプライベート IP を持つインスタンスにアクセスできるようになります。

  1. 以下のように yum を実行して、プロキシー・サーバー squid をインストールします。SUSE の場合は、zypper install squid を実行してください。
    [root@vhost0513 ~]# yum install squid
    Loaded plugins: security
    Setting up Install Process
    Resolving Dependencies
    ...
    Complete!
  2. /etc/squid/squid.conf で squid を構成し、以下の太字で示されている行を追加します。
    http_access allow localhost
    acl lan_users src 10.216.1.0/24
    http_access allow lan_users
    http_access deny all
  3. 以下のコマンドを実行して squid を起動します。
    # /sbin/service squid start

    これで、openssh を使用して、前のインスタンスからプライベート IP を持つ別のインスタンスにアクセスできるようになりました。

  4. 最後のステップとして、以下のコマンドでプロキシーをエクスポートします。
    # export http_proxy=http://10.216.1.144:3128

プロキシーの構成は、これで完了です。

まとめ

この記事では、さまざまなクラウドのシナリオでネットワーク層を管理する方法について概説し、クラウドでのネットワーク管理ツールが数々のビジネス・シナリオでどのようなメリットをもたらすかを紹介しました。さらに、ネットワークを介して提供されるクラウド・サービスを管理する上で役立つ、以下のようなツールの使用方法について詳しく説明しました。

  • IP アドレスを使用して VM へ接続する
  • 仮想ネットワークを管理する
  • 複数の IP アドレスを扱う
  • ファイアウォールを使用して複数の仮想マシンを保護する
  • SSH または PuTTY を使用してユーザーおよびサーバーを認証する
    • ポート・フォワーディング
    • SSH トンネルの作成および使用
    • OpenSSH コマンドによるトンネリング
    • PuTTY によるトンネリング
  • 仮想プライベート・ネットワークを使用する
  • OpenVPN をセットアップする
  • プロキシー・サーバーをセットアップする

ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing, Open source
ArticleID=825812
ArticleTitle=クラウドでのネットワーク構築
publish-date=07192012