3 Module 3 – ソース IP アドレスとネットワーク透過 3.1 透過、それとも非透過モードレッスン目標：このレッスンを通して、ロードマスターがどのようにクライアントのソース IP アドレスを処理するか理解します。そして、クライアント IP アドレスをリアルサーバに透過的に渡す方法について学びます。 3.1.1 ネットワーク構成ロードバランサーを実際のオペレーション環境に展開する場合、千差万別のネットワーク構成の問題が絡んできますが、一番厄介なのがリアルサーバそのものに影響するものです。このモジュールでは、最も共通した問題の解決の糸口を見つけるとともに、ロードマスターを展開する管理方法の手助けとなるオプションについて学びます。これらの問題の中で、一番共通して、尚且つ把握することが難しいのがレイヤ７の透過に絡んだ問題です。このモジュールでは、ネットワークの透過に焦点を当てて、どのように設定を行うかを学ぶと共に、関係するコンセプトについて学びます. ネットワーク透過の実装ネットワーク透過の全ての問題は、単一の質問に集約できるといっても過言ではありません。それは；サーバのアクセスログにクライアントの IP アドレスが必要ですか？もしその答えが“はい”ならば、ネットワーク透過の設定が必要で、ネットワーク構成をそれに合ったものにしなければなりません。もしその答えが“いいえ”なら、ネットワークの設定がより柔軟に行えます。下のテーブルは、ネットワーク透過、非透過モードの長所、短所を述べたものです。長所短所透過モード  ソース IP アドレスをそのまま保てる  レイヤ４と７の両方で使用できる  リアルサーバのあるサブネットからサービスへのアクセスが出来ない  デフォルトゲートウェイはロードマスターでなければならない非透過モード  リアルサーバのあるサブネットよりサービスへのアクセスが可能  デフォルトゲートウェイの変更が不必要  ソース IP アドレスをそのままで保てない  レイヤ７でのみ有効ロードマスターが、どのようにリアルサーバからのトラフィックをクライアントに正しく戻すかは、透過、非透過モードで異なります。ロードマスターに入ってきたトラフィックを、同じルートを通って如何にクライアントに戻すかは、ロードバランサーに本来必要とされる機能です（モジュール８で学習するダイレクトサーバリターンは、唯一の例外です）。レイヤ４とレイヤ７ロードマスターが行う、レイヤ４とレイヤ７の処理は異なります。レイヤ４とレイヤ７を OSI モデルで見てみましょう。レイヤ４は、 TCP/UDP、ポート番号が絡むだけですが、レイヤ７は、HTTP プロトコルで使用されるクッキー、SSL アクセラレーション、コンテントスイッチなどのロードマスターの高いレベルの要素が絡みます。レイヤ４として作成された全てのバーチャルサービスは、透過モードのネットワークとしてのみ動作します。レイヤ４の意味は何でしょうか？それは、セッションの維持にクッキーを使ったり、コンテントスイッチ、もしくはコンテントスイッチのルール、及び SSL アクセラレーションなどが絡まない負荷分散のトラフィックです。レイヤ４では、ソース IP アドレスを使ったセッション維持のみが行えます。バーチャルサービスが、レイヤ４なのかレイヤ７かは“Virtual Services”サブメニュー下の“View/Modify Services”を選択してバーチャルサービスリストを表示させると、下記のように“Layer”で識別可能です。もし、この現在のモードを変更したければ、下記のように各バーチャルサービスの属性画面の“Basic Properties” にある“Force L7”を使用します。もし、このパラメータが表示されていると、そのバーチャルサービスは現在レイヤ４として稼動していることになります。そして、ネットワークは透過モードです。もし、バーチャルサービスが何らかのクッキーを使用したセッション維持、SSL アクセラレーション、もしくはコンテントスイッチを使用していると、自動的にレイヤ７となり、この“Force L7”のパラメータは表示されません。 3.1.2 透過モードの要求ネットワークを透過モードにするためには、バーチャルサービスに属するリアルサーバのゲートウェイの設定をロードマスターとしなければなりません。これは、ネットワーク形態が１アームであろうが２アームであろうが変わりません。ロードマスターがデフォルトゲートウェイでなければ、サーバがクライアントへのレスポンスを返すときにロードマスターへのパスが保障されずに、ロードバランサーとしての働きが出来ません。ネットワークを透過モードとして働かせるためには、更にクライアントがリアルサーバの接続されているサブネット以外からアクセスする必要があります。これは、上記で述べたようにトラフィックの出と入りがロードマスターを通過する必要があるからです。もし、クライアントがリアルサーバと同じサブネット上に存在し、ネットワークが透過モードとなっていると、リアルサーバからの帰りのパケットは、ロードマスターを介さずクライアントに直に戻ってしまいます。クライアントは、バーチャルサービスからのレスポンスを待っていたにもかかわらず、リアルサーバからのパケットが帰ってきたために、結果としてそのパケットを無視することになります。 3.1.3 ネットワーク透過、S-NAT、１アームネットワークもし、バーチャルサービスとリアルサーバが同じサブネット上に存在する１アームでネットワークを構成し、そして透過モードを採用した場合は、S-NAT(Source NAT)を無効にする必要があります。 S-NAT は、ネットワークを２アームで構成した場合、リアルサーバから外部への接続を許可するメカニズムです。オフィスで使用している NAT を使ったファイアウォールと同じような働きをし、あたかもパブリック IP アドレスからアクセスしたかのように見せかけます。 Internet External Clients Internal Clients SRC: 192.168.1.50:8033 eth0 192.168.1.5 192.168.1.1 DEST: 70.119.66.60:80 Virtual Service 192.168.1.50 eth1 10.0.0.1 SRC: 10.0.0.13:8088 Internal Clients DEST: 70.119.66.60:80 10.0.0.12 10.0.0.13 10.0.0.14 １アームのネットワーク構成では、S-NAT は必要ありませんし、通常のオペレーションでは S-NAT が絡んでくるような状態にはなりません。しかしながら例外として、ネットワークが透過モードになっていて、リアルサーバのデフォルト G/W がロードマスターに設定されている場合に、もしリアルサーバに直接アクセスしたいとします。しかしながら、もし S-NAT がオンになっているとこの接続は失敗してしまいます。理由として、ロードマスターがリアルサーバからの帰りのパケットのソース IP アドレスを、バーチャルサービスのアドレスに変えてしまうからです。よって、S-NAT は１アーム·ネットワークでは無効にしておかなければなりません。 3.1.4 非透過モード非透過モードは、下記の二つの利益を与えてくれます。  リアルサーバと同じサブネットのサービス（バーチャルサービス）へのアクセスが可能。  １アームでのネットワーク構成の場合、リアルサーバのデフォルト G/W をロードマスターにしなくても良い。これは、トラフィックがもしロードマスターから来た場合は、必ずロードマスターへ帰るようになるからです。不利益としては、ロードマスターが IP ヘッダーを書き換えるために、クライアントからのソース IP アドレスが隠れてしまうことです。非透過モードは、レイヤ７でのみしか動作しません。もし、バーチャルサービスがクッキーを使ったパーシステンスや、コンテントスイッチの使用、もしくは、SSL アクセラレーションを使用しない場合、レイヤ４で作成され透過モードになりますので、非透過モードに変更したい場合は“Force L7”で強制的にレイヤ７にしなければなりません。もし、反対にクッキーを使ったパーシステンス、コンテントスイッチ、もしくは SSL アクセラレーションを使った場合は、自動的にレイヤ７になり、“Force L7”のパラメータは表示されません。 HTTP ヘッダーによる X-Client/ X-Forwaded 透過モードでは、クライアントの IP アドレスはソース IP アドレスとして保てないことは既に説明しました。しかし、クライアント IP アドレスを HTTP ヘッダーより取り出せることはまだ説明していません。ロードマスターは、デフォルトとして、もしバーチャルサービスがレイヤ７（Force L7 ではなく、パーシステンスオプションを L7 にする）で尚且つ非透過モードの場合、HTTP GET リクエストをリアルサーバに送出するときに、HTTP ヘッダー内に“X-ClientSide” というヘッダを追加します（バージョンによっては追加しない設定もある）。このモードで、クライアントの IP アドレスがログとして必要ならば、この X-ClientSide ヘッダを使ってログに出力するように出来ます。又、X-ClientSide に代わり、一般的な X-Forwarded-For を HTTP ヘッダ内に挿入することも可能です。 3.2 ネットワーク透過設定レッスン目標：このレッスンでは、下記のことを習得します。  どのようにバーチャルサービスをネットワーク透過モード、もしくは非透過モードに設定するのか。  どうして、透過モードではサービスのアクセスが出来ないが、非透過モードでは可能なのか。  どのようにして、１アーム構成下での SNAT の無効化を行うのか。  どのようにして、非透過モード下でクライアントの IP アドレスを HTTP ヘッダー内に挿入できるように設定するのか。 3.2.1 ネットワーク透過ネットワークを透過モードに設定するには、先ず、対応するバーチャルサービスに従属するリアルサーバ全てのデフォルト G/W をロードマスターにしなければなりません。次に、下記のステップに従ってバーチャルサービスを設定します。 SSH/Web 192.168.3.20 Internet Clients Virtual Service 192.168.3.50:80 Default G/W: 192.168.3.1 192.168.3.90 192.168.3.91 192.168.3.92 Real Servers 1. 上記、練習用構成図のシナリオに沿ったバーチャルサービスをモジュール２、及び３に従って作成します。“Virtual Services”サブメニューの“View/Modify Services”より見た結果は下記のようになるはずです。. 2. バーチャルサービスはレイヤ７で作成され、ネットワーク透過モードはオンとなっているはずです。 3. このバーチャルサービスの属性を変更するために、上記のバーチャルサービス一覧画面で対応するバーチャルサービスの“Modify”ボタンをクリックします。 4. 上記の属性画面が表示されますので、透過モードに変更して見ます。透過モードの変更は、 “L7 Transparency”をオフにすることにより可能です。オフにするためにボックスをクリックしチェックマークを外します。 5. もし、L4 モードにするならば“Force L7 ”のチェックマークを外します。 6. １アームでのネットワーク構成で、バーチャルサービスが透過モードになっているとリアルサーバへの直接のアクセスが出来ません。これはロードマスターのシステムが S-NAT をデフォルトでオンにしているためです。S-NAT を無効にすることで、リアルサーバへの直接アクセスが可能になります。無効にするためには、メインメニューの“System Configuration”タブを選択し、その中の “Miscellaneous Options”に行きます。そして、その中の“SNAT Control”を選択します。“Enable SNAT”にチェックマークが付いていますので、無効にするためにクリックして外してください。リアルサーバと同じサブネットよりサービスにアクセスできない理由は何でしょう？上記のバーチャルサービスのように、ネットワークを透過モードに設定すると、サービスへのアクセスがリアルサーバと同じサブネットのクライアントより出来ない理由は、トラフィックフローの問題によります。前にも述べたように、ロードマスターが負荷分散としての役目を果たすのは、トラフィックの入りと出が同じパスを通る必要があります。負荷分散装置は、通常下記のステップを踏みます。 1. クライアントよりロードマスターのバーチャルサービスへ 2. ロードマスターよりリアルサーバへ 3. リアルサーバよりロードマスターへ 4. ロードマスターよりクライアントへ下図の１アームネットワーク構成の例をとってみて見ましょう。クライアントの IP アドレスは‘192.168.1.30’, バーチャルサービスは‘192.168.3.50’, そしてリアルサーバは‘192.168.3.91’です。ソース IP アドレスと宛先 IP アドレスを順を追ってみてください。クライアントが、リアルサーバ以外のネットワークからアクセスすると何の問題もありません。 SSH/Web 192.168.1.200 Internet Clients 1 Virtual Service 192.168.1.50:80 4 2 3 Default G/W: 192.168.1.1 Step Path Source IP Destination 1 Client to Virtual Service 64.254.1.12 192.168.1.50 2 Virtual Service to Real Server 64.254.1.12 192.168.1.32 3 Real Server to Load Master 192.168.1.32 64.254.1.12 4 Load Master to Client 192.168.1.50 64.254.1.12 192.168.1.31 192.168.1.32 192.168.1.33 Real Servers では、同じネットワーク構成を使って、クライアントがリアルサーバと同じサブネット内の IP アドレスである‘192.168.3.200’の場合を下図で見てみましょう。この場合は、３番目のフローは上図とは異なります。これは、クライアントが同じサブネット上に存在するために、リアルサーバはパケットを直接クライアントへ送り返します。クライアントは、レスポンスがロードマスターより帰ってくることを期待していましたので、このパケットを無視してしまいます。よって、リアルサーバより送られてきた情報は破棄されてしまいます。 Step Path Source IP Destination IP 1 Client to Virtual Service 192.168.1.200 192.168.1.50 2 Virtual Service to Real Server 192.168.1.200 192.168.1.32 3 Real Server to Client 192.168.1.32 192.168.1.200 Internet Clients 1 Default G/W: Virtual Service 192.168.1.50:80 192.168.1.1 2 3 SSH/Web 192.168.1.200 192.168.1.31 192.168.1.32 192.168.1.33 Real Servers 3.2.2 非透過モードこのモードに設定する場合は、リアルサーバのデフォルト G/W はそのままとします。多分、ルータ、もしくはプロキシサーバとなっているはずです。そして、下記のステップに沿ってバーチャルサービスを作成します。 1. 上記、練習用構成図のシナリオに沿ったバーチャルサービスをモジュール２、及び３に従って作成します。“Virtual Services”タブの“View/Modify Services” より見た結果は下記のようになるはずです。 2. ロードマスターは、レイヤ７で透過モードとしてバーチャルサービスを作成します。 3. このバーチャルサービスを、非透過モードにするためには、“L7 Transparency”のチェックマークを外します。 4. HTTP ヘッダーにクライアントの IP アドレスを挿入させるために、“System Configuration”タブの“Miscellaneous Options”を選択します。その中にある “L7 Configuration”をクリックすると、下記のような画面が表れます。 5. “L7 Transparency”が“Non Transparency”であることを確認します。そして、 “Additional L7 Header”を“X-ClientSide”もしくは“X-Forwarded-For”に設定してください。 6. リアルサーバのアクセスログから、クライアントの IP アドレスが挿入されていることを確認します。Apache をウェブサーバとして使用している時は、http.conf、もしくは apache2.conf の LogFormat パラメータ内に下記のように、このヘッダ名を追加することにより可能となります。 LogFormat "%{X-ClientSide}i %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i"" combined LogFormat "%{X-Forwarded-For}i %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i"" combined  非透過モードのアクセスログ（ソース IP アドレスはロードマスターのアドレスである‘192.168.3.50’が出力されている）  透過モード（ソース IP アドレスは、クライアントの‘192.168.1.30’が出力されている）  非透過モードで“X-Client”追加ヘッダをアクセスログに含めた場合。VS の IP アドレス‘192.168.3.50’の後に、“192.168.1.30 -> 192.168.3.50:80”という“XClientSide”ヘッダの内容が追加されている。  非透過モードで“X-Forwarded-For”追加ヘッダをアクセスログに含めた場合。 VS の IP アドレス‘192.168.3.50’の後に‘192.168.1.30’という“X-ForwardedFor”ヘッダの内容が追加されている。ネットワーク非透過モードで、同じサブネットワークあるクライアントがサービスにアクセスできる理由は？ネットワーク非透過モードでは、ロードマスターがリアルサーバからのレスポンスを自分に必ず帰ってくるように、ソース IP アドレスを自分のアドレスに変換してリアルサーバに渡します。よって、リアルサーバは、必ずレスポンスをロードマスターに返送します。そして、ロードマスターはそのレスポンスをクライアントへ渡します。透過モード時のソース、もしくは宛先 IP アドレスは、どちらか一方がロードマスターにより書き換えられるのに留意してください。しかしながら、下図の非透過モードでは、両方の IP アドレスがロードマスターにより変換されています。これが、非透過モード時にロードマスターの IP アドレスしかアクセスログに記録されない理由です。 Step Path Source IP Destination IP 1 Client to Virtual Service 192.168.1.200 192.168.1.50 2 Virtual Service to Real Server 192.168.1.50 192.168.1.32 3 Real Server to Load Master 192.168.1.32 192.168.1.50 4 Load Master to Client 192.168.1.50 192.168.1.200 Internet Clients 2 1 4 SSH/Web 192.168.1.200 Virtual Service 192.168.1.50:80 Default G/W: 192.168.1.1 3 192.168.1.31 192.168.1.32 192.168.1.33 Real Servers 3.3 ネットワーク透過実習実習目標：ネットワーク透過モードの設定練習ネットワーク非透過モードの設定練習両方のモードにおいて、実際にサービスにアクセスして TCP パケット内のソース IP アドレスをトレース実習完了予定時間：４０分実習に必要な情報：バーチャルサービス作成のための IP アドレスとポート番号リアルサーバの IP アドレスとポート番号 SSH/Web Internet Clients Virtual Service 192.168.1.50:80 Default G/W: eth0 192.168.1.101 Virtual Service 192.168.1.50:90 192.168.1.1 DNS: 192.168.1.10 192.168.1.11 192.168.1.31:80 192.168.1.32:80 192.168.1.33:80 Real Servers 透過モードでのバーチャルサービス作成と検証  レイヤ４処理 1. モジュール２の実習を参考に、上図の構成に沿ったバーチャルサービスを作成し、リアルサーバを設定します。 2. “Basic Properties”内の “Force L7” パラメータのチェックマークをオフにします。 3. リアルサーバのデフォルト G/W をロードマスターのアドレス‘192.168.1.101’ に変更します。 4. ブラウザを使って、作成したバーチャルサービスへのアクセス ‘http://192.168.1.50’を検証します。  レイヤ７処理 1. 上記で作成、検証したバーチャルサービスの属性画面を開きます。 2. “Basic Properties”内の “Force L7” パラメータにチェックマークを付けます。 3. “L7 Transparency”パラメータのチェックマークがオンになっているのを確認します。 4. ブラウザを使って、作成したバーチャルサービスへのアクセス ‘http://192.168.1.50’を検証します。  アクセスログのソース IP アドレスチェックリアルサーバのアクセスログをオンにしておきます。上記の検証試験後に、アクセスログを出力し、ソース IP アドレスをチェックします。非透過モードでのバーチャルサービス作成と検証    レイヤ７処理 1. 上記のバーチャルサービスの属性画面を開きます。 2. “Basic Properties”内の “L7 transparency” パラメータのチェックマークを外します。 3. ブラウザを使って、作成したバーチャルサービスへのアクセス ‘http://192.168.1.50’を検証します。レイヤ４処理 1. 上記のバーチャルサービスの属性画面を開きます。 2. “Basic Properties”内の “Force L7” パラメータのチェックマークを外します。 3. リアルサーバのデフォルト G/W をルータに戻します。 4. ブラウザを使って、作成したバーチャルサービスへのアクセス ‘http://192.168.1.50’を検証します。アクセスログのソース IP アドレスチェックリアルサーバのアクセスログをオンにしておきます。上記の検証試験後に、アクセスログを出力し、ソース IP アドレスをチェックします。