IBM®
本文へジャンプ
    Japan [変更]    ご利用条件
 
 
検索範囲検索:    
    ホーム    製品    サービス & ソリューション    サポート & ダウンロード    マイアカウント    
skip to main content

developerWorks Japan  >  Web development | Open source | Linux  >

IP エイリアスを使って 1 枚のネットワーク・カードで複数の SSL サイトをホストする

Apache Web サーバーによる予算重視のエンタープライズ・ソリューション

developerWorks
ページオプション

JavaScript を要するドキュメントオプションは表示されません

原文はこちら

原文はこちら


レベル: 中級

John Yao-An Liao, Program Manager, Mindspeed Technologies
Jim Miles, UNIX System Administrator, Capital Group Companies

2006年 12月 19日

SSL と名前ベースの仮想ホストの併用への関心が高まっています。そんなことは不可能だと言う人もいますが、Apache では IP ベースの仮想ホストを使って仮想ホストを実装できます。John Liao と Jim Miles がこの記事でその方法を伝授します。

以前に書いた developerWorks の記事「Secure remote data access for Domino®」では、Apache Web サーバーを利用して予算重視の方法でエンタープライズ問題を解決する方法について話しました (「参考文献」を参照)。今回の記事では引き続きこのテーマを取り上げ、Apache Web サーバーを使用して、1 枚のネットワーク・カードでネットワークに接続する単独のサーバーで、複数の SSL (Secure Sockets Layer) Web サイトを提供する方法について説明します。

どうして誰も、1 台のサーバーに複数の SSL サイトを置こうとしないのでしょう。エンタープライズ内の単一のサーバーで複数の SSL サイトをホストするというビジネス・ニーズは今までになかったのでしょうか。そこで我々は、現実のシナリオを用いてこの問題に取り組んでみたいと思います。革新的なユーザーなら、このアイデアを元に他にも独創的な使い道を必ず見つけ出すはずです。

事例研究: 2 つのアプリケーションと 1 つのサーバー

弊社では以前のプロジェクトで、人事 (HR) 部が Web ベースの給付アプリケーションに対する外部インターネット・アクセスを提供しようと考えていました。この Web アプリケーションは主に企業ネットワーク内からのアクセスを対象としていましたが、ユーザーが外部インターネットからアクセスするケースもありました。セキュリティー要件を満たすため、我々はサーバーを企業ネットワーク内に配置し、Apache の HTTP サーバーを使ってリバース・プロキシー・サーバーを構築することにしました。リバース・プロキシー・サーバーが SSL 接続の終端となり、HR アプリケーションをホストする Web アプリケーションとの別の SSL 接続を再オープンするという考えです。Apache Web サーバーに mod_security モジュールを追加すれば、リバース・プロキシー・サーバーをアプリケーション・ゲートウェイに変更して Web アプリケーションのセキュリティーをさらに強化することができます。HR 部は、わかりやすく覚えやすい完全修飾ドメイン名 (FQDN) を慎重に選びました。我々は順調に SSL 証明書を取得し、それで話は終わったものと思いました。

その一年後、HR アプリケーションと同様の要件を持つ別の企業 Web アプリケーションが出現しました。このアプリケーションにも外部ユーザーがアクセスできるようにする必要がありました。外部ユーザーの数はほんのわずかで、重要な作業のほとんどは企業ネットワーク内で行われることになっていました。そこで即座に思い付いたのが、リバース・プロキシー・サーバーを使って、この新しい Web アプリケーションへの外部アクセスを提供するという方法です。

ところが、この新しいアプリケーションにはいくつかの懸念事項が持ち上がりました。とりわけ懸念されたのはデータ・センターの物理スペースで、サーバーの統合をあらゆるアプリケーションのデプロイメントで真剣に検討しました。第 2 に、リバース・プロキシー・サーバーを追加購入する費用も正当化しなければなりません。この 2 つの懸念事項を考え合わせた上で検討しはじめたのが、既存のリバース・プロキシー・サーバーを使って新しい Web アプリケーションのニーズをどうにか満たせないかということです。唯一問題となったのは、このアプリケーションには既存の HR アプリケーションに確立したものとは異なる FQDN が必要だという点でした。

既存のリバース・プロキシー・サーバーを 2 つ目のアプリケーションに利用する案をいくつか検討してみました。最初の案は、新規アプリケーションと既存のアプリケーション両方のドメイン名を何かしら一般的な名前、例えば rp.company.com などに変更し、それぞれのコンテキスト・パスで 2 つのアプリケーションを区別するというものです。ただしドメイン名の変更には、リバース・プロキシー・サーバーの元々のユーザーが猛反対しました。名前の変更を会社全体に伝え、更新された URL を反映するように印刷物すべてを変更しなければならないためです。また、ヘルプ・デスクにはサイトにアクセスできないユーザーからの電話が殺到することが必至ですが、そんなヘルプ・デスクへの考えられる影響を無視したとしても、このような変更にかかる費用は莫大なものになります。さらに、独自の FQDN を維持したいという両方のアプリケーション・グループの希望もありました。採択されている FQDN の方が提案された汎用 URL より覚えやすく、それぞれの Web アプリケーションの商標を確立するためも使用されているというのが彼らの主張です。

別の案が浮上しました。新しいドメイン名を既存のサーバーに結び付ける DNS エントリーを登録するという方法です。しかしこの提案はすぐに破棄されました。SSL アプリケーションでは、SSL 証明書とユーザーによって要求された URL が一致する必要があり、一致しない場合は、要求 URL が SSL 証明書のドメイン名と一致しないという警告メッセージがポップアップ表示されるためです。ポップアップ広告とマルウェア (破壊工作ソフト) の増加により、社内の全員が、ポップアップ警告ボックスが現れる Web 対話はキャンセルするように訓練されています。そのため、企業アーキテクチャー標準の要件では実動 Web アプリケーションがポップアップ警告メッセージを生成することを禁止していました。

次の案として出されたのは、一方の SSL サイトを実行するサーバー上の別のポートでもう一方の SSL サイトをホストするという方法です。ただし、この方法だとユーザーに大きな混乱を招くことが予想され、そしてサイトの URL だけでなくポート番号も記憶するのはユーザーにとって大変だという感がありました。ユーザーがポート番号宛先を入力せずに URL だけを入力すると、HR アプリケーションにリダイレクトされてしまいます。それでは多くの問題の原因になるだけです。




上に戻る


ソリューション: IP エイリアス

我々が最終的に巡り合ったソリューションは、IP エイリアスです。このソリューションを探求する上で最も難儀だったのは、正しい用語を識別することでした。このコンセプトを初めて紹介されたとき、仮想インターフェースや仮想 IP といった用語を耳にしましたが、この 2 つのコンセプトに関する情報はなかなか見つかりませんでした。苦労の末やっと気付いたのは、我々が探しているものは IP エイリアス機能として知られているコンセプトだったということです。それからは、このトピックに関する資料がいろいろと見つかりました。IP エイリアスは、ネットワーク・インターフェース・エイリアス、または論理インターフェースと呼ばれることがあります。

Linux システムでの IP エイリアス

プロミスキャス・モード: 警告
一部のイーサネット・カードは、複数の IP アドレスで構成するとプロミスキャス・モードとして知られるモードになります。プロミスキャス・モードでは、ネットワーク・カードがローカル・ネットワーク上のすべてのトラフィックを捕捉するため、サーバーは、ネットワーク上の別のホストをターゲットにした攻撃にさらされる恐れがあります。大抵のスニファーやネットワーク監視ソフトウェアは、イーサネット・カードをプロミスキャス・モードにしてすべてのネットワーク・パケットを捕捉します。

IP エイリアスの背後にあるコンセプトは単純です。つまり、単一のネットワーク・インターフェースに複数の IP アドレスを構成することによって、1 台のサーバー上で複数の Web サーバーを実行できるようにします。IP エイリアスの設定は極めて簡単で、システムに追加 IP アドレスをリッスンするネットワーク・インターフェースを構成すればいいだけのことです。Linux™ システムでは、標準ネットワーク構成ツール (ifconfig や route コマンドなど) やグラフィカル・ネットワーク管理ツールを使って IP エイリアスを追加できます。

通常、それぞれのイーサネット・カードは物理ユニット番号で構成されます。構成済みのイーサネット・カードに IP エイリアスを追加するには、同じイーサネット・カードの物理装置番号を論理装置番号で修飾してインターフェースを構成します。例えば、既存の IP アドレスが物理装置番号 eth0 のイーサネット・カードに構成されている場合、リスト 1 に示すように物理装置番号に論理装置番号 :1 を追加して IP エイリアスを作成します。この論理装置番号を増やしていけば、IP アドレスをさらに追加できます。(ルート・ユーザーとしてログインしなければならないことに注意してください。)


リスト 1. 既存のネットワーク・インターフェースへの IP アドレスの追加
                
ifconfig eth0:1 192.168.0.2 netmask 255.255.255.0
    

構成中のシステムで Linux カーネルが IP エイリアスをサポートしていないと、この手法は使用できません。サポートしていない場合、カーネルを再ビルドしなければならない場合があります。カーネルが IP エイリアスをサポートしているかどうかを調べるには、/proc/net/alias* ファイルの有無を確認してください。

新しい IP アドレスを構成したら、リスト 2 に示すように、この新規インターフェースのルートを設定します。


リスト 2. 新規 IP アドレスのルートの追加
                
route add -host 192.168.0.2 dev eth0:1
    

新規 IP アドレスの作成後には、この新規アドレス固有の名前を /etc/hosts ファイルで指定する必要もあります。リスト 3 を参照してください。


リスト 3. 新規 IP アドレスの名前の追加
                
192.168.0.1 primaryserver
192.168.0.2 secondaryserver
    

Solaris システムでの IP エイリアス

Solaris™ で IP エイリアスを設定する場合は、使用するコマンド・セットが多少異なります。リスト 4 に示すようにネットワーク・インターフェースを構成してください。ルート・ユーザーとしてログインする必要があります。


リスト 4. Solaris での仮想 IP の追加
                
ifconfig eth0:1 plumb
ifconfig eth0:1 192.168.0.2 netmask 255.255.255.0
ifconfig eth0:1 up
    

リブートしてからも仮想 IP を持続させるには、/etc/hosts から IP アドレスまたはホスト名を /etc/hostname.eth0:1 ファイルに追加します。

Linux と Solaris ではいずれも 1 枚の物理イーサネット・カードで、異なるサブネット上の IP アドレスとの仮想インターフェースを複数作成できます。ただし、このように構成することは通常は避けてください。この構成は 2 つのサブネット間のボトルネックとなり、この 2 つのサブネット上のすべてのネットワーク・デバイスのパフォーマンスがある程度影響されるためです。

IP エイリアスの別の使用方法

IP エイリアスは、クライアント側で負荷/ストレス・テストを行う場合にも使用されます。詳しくは、記事「Testing and tuning load balancers and networks」を参照してください (「参考文献」にリンクを記載)。

IP アドレスごとに複数の SSL サイトを構成する方法

2 つ目の IP アドレスを構成すると、リスト 5 に示すように、Apache Web サーバーの構成ファイルに IP アドレスごとの SSL サイトを追加できるようになります。

これで、同じサーバーの同じ物理ネットワーク・カードに複数の SSL Web サイトを構築したことになります。


リスト 5. 2 つの SSL Web サイトの構成
                
<IfModule mod_ssl.c>
    Listen 443
    <VirtualHost 192.168.0.1:443>
       DocumentRoot "/Web site1/docs"
       ServerName Web site1.company.com:443
       SSLEngine on
       SSLCertificateFile ssl/site1.crt
       SSLCertificateKeyFile ssl/site1.key
    </VirtualHost>

    <VirtualHost 192.168.0.2:443>
       DocumentRoot "/Web site2/docs"
       ServerName Web site2.company.com:443
       SSLEngine on
       SSLCertificateFile ssl/site2.crt
       SSLCertificateKeyFile ssl/site2.key
    </VirtualHost>

</IfModule>

    




上に戻る


他にも考えられる複数 SSL サイトの使用方法

この記事を共有する

digg Digg へ投稿
del.icio.us del.icio.us へ投稿
Slashdot Slashdot へ投稿

Apache Web サーバー上のトラフィック量は少ないため、このリバース・プロキシー・サーバーは、同じくトラフィック要件が厳しくないバックエンドのサーバーにも利用できるはずです。

より大規模でより強力なサーバーと、より大きな帯域幅に対応するネットワーク・カードが登場すれば、この方法で複数の仮想 SSL サイトをホストすることもできます。帯域幅の制限された複数の SSL サイトをカスタマーに提供する ISP を設定すれば、低トラフィックのサイトで SSL セキュリティーを必要とする少量の販売取引を行うことができます。IP エイリアスでは、一方の IP アドレスで SSL Web サイトをホストし、もう一方の IP アドレスで他のサービス (Web サービスなど) をホストすることも考えられます。その他の可能性としては、主実動システムとフェールオーバー・システムを設定して、QA システムや DR システムとして二重化することも実現可能です。IP エイリアスの基本コンセプトを理解した今、アプリケーションの可能性が広がったはずです。



参考文献

学ぶために

製品や技術を入手するために
  • IBM 製品の評価版: DB2®、Lotus®、Rational®、Tivoli®、および WebSphere® のアプリケーション開発ツールとミドルウェア製品を使ってみてください。


議論するために


著者について

John Liao は現在、主要なグループ会社でシニア・テクニカル・アーキテクトとして、財務会計、法規準拠、HR などのビジネス・エリアをサポートする IT システム向けエンタープライズ・テクニカル・アーキテクチャーを設計しています。


Jim Miles は現在、主要なグループ会社のコントラクターとして、HP-UX、Sun Solaris、そして Linux システムを含め、数百にのぼる UNIX 指向のシステムを支援しています。彼が取り組んでいるのは、これらのシステムの管理サポートを自動化するためのポリシー、標準、操作ツールの開発です。また、ネットワーク・アップグレード、SAN および NAS ストレージのアップグレード、OS パッチ、OS アップグレード、OS カーネル調整、災害回復計画と訓練、そしてハードウェア・アップグレードにも深く関わっています。




記事の評価


サイト改善のため、ご意見をお寄せください。こちらのフォームからお願いいたします。



はいいいえわからない
 


 


54321
大変素晴らしい不充分・不完全である
 


上に戻る


Linux は、Linus Torvalds の米国およびその他の国における商標です。 他の会社名、製品名およびサービス名等はそれぞれ各社の商標です。 他の会社名、製品名およびサービス名等はそれぞれ各社の商標です。

    日本IBMについて プライバシー お問い合わせ