BIG-IP GTM

BIG-IP GTM
インテリジェント DNS
セットアップガイド（V11.6.0 対応）
F5 Networks Japan
V1.0
目次
1. はじめに ................................................................................................................................................................. 4
2. Global Server Load-Balancing (GSLB) ................................................................................................................. 5
2.1. GSLB の動作概要 ........................................................................................................................................... 5
通常時 ..................................................................................................................................................... 5
Web サーバ障害発生時 ........................................................................................................................... 6
メインサイト全障害時 ................................................................................................................................ 7
2.2. GSLB のオブジェクト ........................................................................................................................................ 8
2.3. 階層ロードバランシング .................................................................................................................................. 11
Wide-IP レベルロードバランシング ..........................................................................................................12
Pool レベルロードバランシング ...............................................................................................................12
Pool レベルロードバランシングが階層化になっている理由 ......................................................................13
2.4. Synchronization Group .................................................................................................................................14
2.5. サンプルネットワーク構成 ...............................................................................................................................15
2.6. GSLB の設定ポリシー ...................................................................................................................................16
HTTPS (443) のポリシー .......................................................................................................................16
HTTP (80) のポリシー ...........................................................................................................................16
FTP のポリシー ......................................................................................................................................17
SSH のポリシー .....................................................................................................................................17
2.7. DC-A の LTMs (Active-Active) の設定 .........................................................................................................18
Virtual Servers .......................................................................................................................................18
External Self IP の Port Lockdown ........................................................................................................18
2 つの Traffic-Group ..............................................................................................................................19
2.8. DC-A GTM の基本設定 .................................................................................................................................22
初期セットアップウィザード ......................................................................................................................22
ネットワークの設定 .................................................................................................................................24
NTP 設定 ...............................................................................................................................................26
GTM の Listener 設定 ............................................................................................................................27
2.9. DC-B の GTM+LTM の基本設定 ...................................................................................................................28
初期セットアップウィザード ......................................................................................................................28
ネットワークの設定 .................................................................................................................................30
NTP 設定 ...............................................................................................................................................33
LTM の設定............................................................................................................................................34
GTM の Listener 設定 ............................................................................................................................38
2.10.
GSLB の設定.............................................................................................................................................39
データセンター ....................................................................................................................................39
Servers への追加 (GTM)...................................................................................................................40
GTM 間で同期するための設定 (Sync-Group) ....................................................................................43
Servers への追加 (LTM / 汎用サーバ) ..............................................................................................46
汎用サーバ (Linux)の追加 .................................................................................................................50
Pool の作成 ........................................................................................................................................54
Wide-IP の作成 ..................................................................................................................................60
2.11.
GSLB の動作確認 .....................................................................................................................................64
secure.pub.f5jp.local の動作確認 ......................................................................................................64
web.pub.f5jp.local の動作確認 ...........................................................................................................68
ftp.pub.f5jp.local の動作確認 .............................................................................................................70
ssh.pub.f5jp.local の動作確認 ............................................................................................................72
2.12.
Topology の設定 ........................................................................................................................................74
例：送信元 IP アドレスのサブネットで DNS 返答を変える .....................................................................74
3. Link ......................................................................................................................................................................76
3.1. Link の概要 ...................................................................................................................................................76
3.2. Inbound 制御の概要 .....................................................................................................................................77
3.3. Outbond 制御の概要 .....................................................................................................................................78
3.4. サンプルネットワーク構成 ...............................................................................................................................79
3.5. Link の設定 ...................................................................................................................................................80
VLAN の追加 .........................................................................................................................................80
Ⅹ
Self-IP の追加 ........................................................................................................................................80
Servers の DC-B-GTM02_LTM へアドレスを追加 ..................................................................................81
Gateway-Pool の設定 ............................................................................................................................82
Link の作成 ............................................................................................................................................83
3.6. Inbound 制御の設定 .....................................................................................................................................85
Virtual Servers の作成 ...........................................................................................................................85
GTM の Pool の作成 ..............................................................................................................................88
Wide-IP の作成 ......................................................................................................................................89
動作確認 ................................................................................................................................................90
3.7. Outbound 制御の設定 ...................................................................................................................................93
Gateway Pool の 設定変更 ...................................................................................................................93
Forwarding Virtual Server の設定..........................................................................................................94
動作確認 ................................................................................................................................................95
4. DNSSEC ..............................................................................................................................................................97
4.1. DNSSEC の概要 ...........................................................................................................................................97
DNS が持つ脆弱性 ................................................................................................................................97
DNSSEC による攻撃の防御...................................................................................................................98
4.2. DNSSEC の設定 ...........................................................................................................................................99
4.3. Key Creation Server の指定 .........................................................................................................................99
4.4. KSK の生成.................................................................................................................................................100
4.5. ZSK の作成 .................................................................................................................................................101
4.6. GTM02 側への DNSSEC 鍵同期の不具合 (BugID：506282） .....................................................................102
4.7. DNSSEC Zone の設定 ...............................................................................................................................103
4.8. 動作確認 .....................................................................................................................................................104
5. DNS Express .....................................................................................................................................................105
5.1. ZoneRunner による内部 BIND の設定 ........................................................................................................106
MX レコード用の A レコードの設定 ........................................................................................................106
MX レコードの設定 ...............................................................................................................................107
5.2. Nameserver の設定 ....................................................................................................................................108
5.3. Zone の設定................................................................................................................................................109
5.4. 動作確認 ..................................................................................................................................................... 110
5.5. IXFR への変更 ............................................................................................................................................ 111
5.6. 動作確認 ..................................................................................................................................................... 113
6. DNS キャッシュ (DNSSEC Validation あり) ........................................................................................................ 115
6.1. Cache サーバの設定 ................................................................................................................................... 115
6.2. DNS profile の設定 ..................................................................................................................................... 116
6.3. Listener の設定変更 .................................................................................................................................... 117
6.4. DLV アンカーの設定 .................................................................................................................................... 118
設定 ..................................................................................................................................................... 118
動作確認 .............................................................................................................................................. 119
6.5. Trust アンカーの設定 ...................................................................................................................................120
設定 .....................................................................................................................................................120
動作確認 ..............................................................................................................................................121
7. おわりに ..............................................................................................................................................................122
8. Appendix ............................................................................................................................................................123
8.1. GTM の全ロードバランシング方式一覧 ........................................................................................................123
8.2. GSLB 動作ログ出力の設定方法 ..................................................................................................................125
8.3. 「f5jp.local」の BIND 設定 ............................................................................................................................129
8.4. General host の SNMP 設定 .......................................................................................................................131
8.5. DNSSEC フロー詳細 ...................................................................................................................................132
Ⅹ
1. はじめに
本セットアップガイドにて BIG-IP Global Traffic Manager (以下、GTM)の設定方法についてご案内します。
BIG-IP GTM は、高度な機能を備えた Domain Name System (DNS) です。
一般的な DNS サーバのように、静的に設定された IP アドレスをただ返答するだけではなく、その IP アドレスがサービス
提供可能な状態かどうかを判断してから返答する、というダイナミックな動作が可能です。
これを、Global Server Load Balancing (GSLB) と呼びます。
この GSLB よって、以下のようなメリットが得られます。
災害対策用として、1 つの DC がダウンした場合に、もう一方の DC へ自動的に誘導
複数のデータセンターで提供するサービスを全 Active 化することによるサービスパフォーマンスの向上
また、GTM は以下のような機能も実装しています。
DNSSEC 機能
DNS 応答のパフォーマンス向上 (DNS Express)
DNS キャッシュサーバとしての利用 (DNSSEC Validation 機能付)
GTM と Local Traffic Manager (以下、LTM) を一つの筐体内に実装することができるので、高度なサーバロードバラン
シングを行いつつ、ダイナミック DNS としても利用する、ということが一つのプラットフォーム上で実現できます。
本ガイドでは、GTM の設定をスムーズに進められるように、必要となる典型的なセットアップ手法を、豊富なスクリーンシ
ョットを交えて解説します。
尚、本ガイドは、LTM の基本設定に関しては習得済みであることを前提とします。
また、DNS の概念についても理解済みであることを前提とします。
4
2. Global Server Load-Balancing (GSLB)
2.1. GSLB の動作概要
GTM の機能のうち、GSLB について、災害対策時の動作イメージを用いて解説します。
通常時
通常状態においては、メインサイトのみで Web サービスを提供する、という運用ポリシーであると仮定。
① GTM-A および GTM-B は、メインサイトの Web サービス (VS-IP1) に対して、ヘルスモニターを行っている。
② GTM-A および GTM-B は、バックアップサイトのサービス (VS-IP2) に対しても、ヘルスモニターを行っている。
③ クライアントは、web.f5.com へアクセスしたい、とする。Web ブラウザにその FQDN を入力すると、Web ブラウザは
その FQDN の IP アドレス解決を、自身が契約しているプロバイダ：ISP-1 の DNS (図中の Local DNS) へ要求する
(DNS Query)。
④ Local DNS は、Root サーバへ、com.の DNS サーバの IP アドレスを問い合わせ、返答を得る。
⑤ Local DNS は、com.を管理する DNS サーバへ f5.com.の DNS サーバの IP アドレスを問い合わせ、その返答を得
る。
f5.com を管理する DNS はメインサイトとバックアップサイトの 2 箇所に存在するので、com.の DNS サーバはその 2
つの IP アドレス(IP-A と IP-B)を返答する。
⑥ Local DNS は、f5.com.を管理する DNS サーバ＝GTM-A または GTM-B へ、Web.f5.com の IP アドレスを問合せ
る。 (※GTM-A か GTM-B のどちらへ問い合わせを行うかは、Local DNS の実装に依存する)
このとき、GTM-A または GTM-B は、メインサイトの Web サーバへのヘルスモニターが成功しているので、メインサイ
トの IP アドレス：VS-IP1 を返答する。
⑦ Local DNS は、得られた IP アドレス：VS-IP1 をクライアントへ返答。
⑧ クライアントの Web ブラウザは、VS-IP1 へ HTTP リクエストを送る。
5
Web サーバ障害発生時
① メインサイトの Web サーバがダウン。
GTM-A および GTM-B では、そのサーバ(VS-IP1)のダウンをヘルスモニターにて検知。
② GTM-A および GTM-B によるバックアップサイトのサービス (VS-IP2)へのヘルスモニターは今まで通り正常。
③ 通常時と同じ。
④ 〃
⑤ 〃
⑥ Local DNS は、f5.com.を管理する DNS サーバ＝GTM-A または GTM-B へ、Web.f5.com の IP アドレスを問合せ
る。
GTM-A または GTM-B は、メインサイト Web サービスの IP(VS-VP1)ではなく、バックアップサイトの Web サービスの
IP アドレス：VS-IP2 を返答。
⑦ Local DNS は、クライアントへ VS-IP2 を返答。
⑧ クライアントは、VS-IP2 へ HTTP リクエストを送る。
6
メインサイト全障害時
① メインサイトがダウン。(GTM-A もダウン)。
GTM-B では、そのサーバ(VS-IP1)のダウンをヘルスモニターにて検知。
② GTM-B によるバックアップサイトのサービス (VS-IP2)へのヘルスモニターは今まで通り正常。
③ 通常時と同じ。
④ 〃
⑤ 〃
⑥ Local DNS は、f5.com.を管理する DNS サーバ＝GTM-A または GTM-B へ、Web.f5.com の IP アドレスを問合せ
る。
もし、Local DNS が GTM-A に問合せた場合、GTM-A は応答しないので、ある一定のタイムアウトを待って GTM-B
へ問合せを行う。(タイムアウト時間は Local DNS の実装に依存)
GTM-B は、メインサイト Web サービスの IP(VS-VP1)ではなく、バックアップサイトの Web サービスの IP アドレス：
VS-IP2 を返答。
⑦ Local DNS は、クライアントへ VS-IP2 を返答。
⑧ クライアントは、VS-IP2 へ HTTP リクエストを送る。
7
2.2. GSLB のオブジェクト
GSLB で使われるオブジェクトを説明します。
(1)
Listener
GTM が DNS サービスを提供する IP アドレスです。
上位の権威 DNS (例：「.com」を管理するサーバ) には、f5.com ゾーンの NS レコードとして、この IP アドレスを登録し
てもらいます。
Local DNS からの web.f5.com や ftp.f5.com の IP アドレスの問合せは、この Listener IP アドレス宛に行われることに
なります。
(2)
Data Center
地理的にサーバ群をグルーピングするための名称です。
名称は任意ですので、本図では DC-A、DC-B としていますが、例えば地域名：Tokyo、Osaka などにすると分かりやすい
かもしれません。
8
(3)
Servers
GTM が連携するネットワークデバイスであり、IP アドレスで指定します。
具体的には、BIG-IP LTM であれば、Self IP が該当します。
汎用サーバであれば、NIC に設定された IP アドレスが該当します。
これらの IP アドレスを、GTM の「Servers」として登録することで、GTM と連携できるようになります。
この「Servers」設定で、注意すべきポイントが 4 つあります。
① GTM 内には「gtmd」というプロセスがあり、GTM としての動作はこのプロセスが行います。
② GTM や LTM などが動作する BIG-IP 上には全て、「big3d」というプロセスが存在します。
この「big3d」プロセスが、BIG-IP 自身のステータス情報や汎用サーバから取得したステータス情報を、GTM に渡しま
す。
BIG-IP を Servers として登録し、「bigip」というモニターを適用することで、GTM がその「big3d」と連携する、という設
定をしていることになります。
よって、「Servers」としての登録は、LTM だけでなく GTM 自身も登録する必要があります。
③ 「gtmd」と「bid3d」間で使われるプロトコルを、「iQuery」と呼びます。 「iQuery」は f5 独自プロトコルです。
Servers に登録した BIG-IP に対して「bigip」モニターを適用することで、このプロトコルが使われるようになります。
データ形式は XML で、gzip 圧縮と SSL 暗号化を使ってやり取りされます。
④ 汎用サーバ (Generic host) に対しては、データセンター内のいずれかの big3d が SNMP を使って情報収集を行い
ます。
(4)
Virtual Server
GTM が FQDN (例：web.f5.com)の DNS 問い合わせを受けた際に返答する IP アドレスです。
BIG-IP LTM を GTM に Servers として登録した際に、Virtual Server は自動的に発見されます。
汎用サーバの場合、Virtual Server は手動で設定する必要があります。
9
(5)
Pool
同一のサービスを提供する複数の Virtual Server をグループ化したものです。
本図では、Web-VS1 も Web-VS2 も Web-VS3 も同一の Web サービスを提供する Virtual Server をイメージしていま
すが、DC-A web-pool と DC-B web-pool の 2 つにグループを分けています。
この 2 つのグループに分ける意味については、階層ロードバランシングの項で解説します。
(6)
Pool Member
Pool から見ると、Virtual Server は Pool の Member として扱われます。
言い換えますと、Virtual Server と Pool Member は同じです。
(7)
Wide-IP
Pool と紐付けられる FQDN です。
本図では、「web.f5.com」と「ftp.f5.com」が該当します。
「web.f5.com」は、DC-A Web-pool と DC-B web-pool に紐付けされ、この 2 つの Pool に対して、いくつか存在するロ
ードバランシング方式を割り当てます。
「ftp.f5.com」は、ftp-pool だけが紐付けされます。
10
2.3. 階層ロードバランシング
GTM は、高い柔軟性を提供することを目的として、階層的なロードバランシング方式を採用しています。
大きくは 2 階層となっています。
a) Wide-IP レベルロードバランシング
b) Pool レベルロードバランシング
それぞれについて、以下の図を用いて説明します。
①
②
クライアントが Local DNS に、web.f5.com の IP アドレスを問合せる。
Local DNS が、(Root DNS などへの再起問い合わせ後に) F5.COM の DNS＝GTM に、Web.f5.com の IP アドレ
スを問合せる。
③
GTM 内部では、web.f5.com が設定されている。この FQDN のことを、GTM では Wide-IP と呼ぶ。
④
この Wide-IP: web.f5.com には、2 つの Pool が紐付いている。
・Main Web-pool
・Backup Web-pool
まずは、この 2 つの Pool のどちらを選択するか、というロードバランシングを行う。
これが Wide-IP レベルロードバランシング。
⑤
Main web-pool が選ばれたら、今度はこの Pool の中でのロードバランシングが行われる。
これが Pool レベルロードバランシング。
11
Wide-IP レベルロードバランシング
設定された Pool のどれを選択するか、というロードバランシング方式です。
このレベルでのロードバランシング方式はスタティック方式のみとなっています。
Wide-IP レベルで利用可能な LB 方式。
Pool レベルロードバランシング
Pool 内のどの Member を選択するか、というロードバランシング方式です。
Pool レベルロードバランシングには、更に 3 階層の設定が存在します。
① Preffered
② Alternate
③ Fallback
：ここに設定された方式が最も優先されます。
：①の方式が使えない場合、ここで設定された方式が利用されます。
：①および②の方式が使えない場合、ここで設定された方式が利用されます。
3 階層
例)Preffered で利用可能な LB 方式
各方式の解説は、Appendix に記載しています。
12
Pool レベルロードバランシングが階層化になっている理由
Pool レベルロードバランシングがなぜさらに階層化になっているのかについて、説明します。
Pool レベルでは、ダイナミック LB 方式を採用することができます。
ダイナミック LB 方式の中には、最初から情報を持つことができない方式がいくつか存在します。
例えば Round Trip Time 方式がそれに該当します。
Round Trip Time は、複数のデータセンターそれぞれの BIG-IP から、Local DNS (クライアント PC が最初に問い合わ
せる DNS) にパケットを送って、それが戻ってくるまでの時間を測定し、それを比較してどちらのデータセンターが近いかを
判断する方式です。
よって、その Local DNS の IP アドレスを知り、その IP アドレスへの Round Trip Time を測定するまでは、この方式は使
えません。
以下にそのイメージを示します。
3 つの LB 方式には以下のように設定されていると仮定します。
Preferred：
Alternate:
Fallback:
Round Trip Time
Round Robin
None
① あるクライアントが Local DNS へ web.f5.com の IP アドレスを問い合わせる。
② Local DNS が GTM へ、web.f5.com の IP アドレスを問い合わせる。
GTM はこのタイミングで、Local DNS の IP アドレスを知ることができる。しかしこのタイミングでは、各データセンター
(DC-A および DC-B)～Local-DNS 間の Round Trip Time 値は、まだ測定されていない。
③ よって、Alternate に設定された LB 方式：Round Robin に従って、IP アドレスを返答する。
④ ②のタイミングで Local DNS の IP アドレスを知ったので、GTM は、各データセンターの big3d プロセスに対して、そ
の IP アドレスへの Round Trip Time を測定するように指示する。
⑤ 各 DC の bid3d は、Local DNS への Round Trip Time を測定する。
⑥ その測定結果を GTM へ伝える。
⑦ しばらくして、ほかのクライアントが、Local DNS へ web.f5.com の IP アドレスを問い合わせる。
⑧ Local DNS が GTM へ、web.f5.com の IP アドレスを問い合わせる。
⑨ GTM はこの Local DNS の IP アドレスへの Round Trip Time データを持っているので、値の小さいほうの IP アドレス
を返答する(この例では DC-a の IP アドレス)。
⑩ クライアントは、DC-a へアクセス。
このように、一度目の DNS リクエストを受けた際に Preferred で指定された LB 方式が情報を持たない場合は
Alternate の LB 方式を利用し、Preferred に指定された LB 方式が情報を持っている状態であれば、Preferred の LB 方
式を使う、という形をとっています。
3 つ目の Fallback は、Preferred も Alternate も利用できないような状態になった場合に利用する LB 方式です。例えば
Virtual Server が全てダウンした場合に、他のサイトや Sorry サーバに誘導したい、という場合に利用します。
13
2.4. Synchronization Group
更に理解しておくべき機能が、この synchronization group (以降、Sync-Group) です。
Sync-Group 設定によって、コンフィグレーションの同期を行う、ということに加え、2 つの GTM それぞれが持つ状態情
報をお互いにリアルタイムで同期します。
例えば、GTM を 2 つのデータセンターにそれぞれ 1 台ずつ設置した場合を想定します。
この場合、上位の権威 DNS (例：.com を管理する DNS) には、この 2 つの GTM(DNS)が、f5.com の DNS として(NS
レコードとして)登録されており、それら 2 つが DNS 応答として返されます(図中の⑤)。
一般的に、これらの 2 つの DNS のどちらが優先的に利用されるかの指定はなく、どちらも平等に扱われます。
よって、Local DNS からこの 2 つの GTM(DNS)に対しての問合せ(図中の⑥)は、ランダムに発生します。
そのため、どちらに問合せを受けても同じ返答ができるよう、この 2 つの GTM(DNS)の状態は、リアルタイムで同期して
いる必要があります。
これを実現するための設定が、Sync-Group 設定です。
以降、具体的なネットワーク構成例を元に、GTM の設定を行っていきます。
14
2.5. サンプルネットワーク構成
本ガイドで利用するネットワークサンプルです。
2 つのデータセンター：DC-A と DC-B にそれぞれ GTM を設置し、これら 2 つのデータセンター間のロードバランシング
を提供することを想定します。
それぞれのデータセンターに設置される 2 つの GTM の形態は以下とし、Sync-Group による同期を行います。
DC-A には、GTM をスタンドアローンとして設置(GTM01)。
DC-B には、LTM へ GTM ソフトウェアモジュールをアドオンして設置(GTM02/LTM)。
この 2 つのデータセンターから提供されるサービスの FQDN は、f5jp.local のサブドメイン：pub.f5jp.local とし、以下 4
つのサービスを提供するものとします。
①
②
③
④
secure.pub.f5jp.local
web.pub.f5jp.local
ftp.pub.f5jp.local
ssh.pub.f5jp.local
HTTPS(443)の Web サービス。BIG-IP から提供。
HTTP(80)の Web サービス。BIG-IP から提供。
FTP(22)サービス。汎用サーバ(Generic host)から提供。
SSH(22)アクセス。汎用サーバ(Generic host)から提供。
DC-A の 2 つの LTM：big189.f5jp.local と big190.f5jp.local は、冗長化構成 (Device Service Cluster) とし、有効利用
を前提として、Active-Active として利用することとします。
15
2.6. GSLB の設定ポリシー
サンプルネットワーク構成上に 4 つ存在するそれぞれのサービスに対して、どのようなポリシーで GSLB を実施するか
を記載します。
HTTPS (443) のポリシー
secure.pub.f5jp.local で提供されるサービスは、極力 DC-A を利用し、万が一 DC-A が被災した場合には DC-B を利用
する、というニーズを想定します。
よって、この FQDN には、Wide-IP レベルと Pool レベルの 2 階層ロードバランシングとし、以下のポリシーとします。
① DC-A-sec-pool を優先的に利用 (Wide-IP レベル：Global Availability)
② DC-A-sec-pool 内の 2 つの Member は同レベルとして扱う (Pool レベル：Round Robin)
③ DC-A-sec-pool 内の 2 つの Member が両方ダウンした場合に、DC-B-sec-pool を利用。
HTTP (80) のポリシー
web.pub.f5jp.local で提供されるサービスは、Pool レベルのみの 1 階層ロードバランシングとします。
2 つのデータセンターをまたいで、最も能力が高い Virtual Server＝Pool Member の数が最も多い Virtual Server を優
先的に利用する、というニーズを想定します。(Pool レベル：VS Capacity)
16
FTP のポリシー
ftp.pub.f5jp.local で提供されるサービスは、Pool レベルのみの 1 階層ロードバランシングとします。
現在のパケット数が少ないほうの IP アドレスを返答する、というニーズを想定します。(Pool レベル： Packet Rate)
SSH のポリシー
ssh.pub.f5jp.local で提供されるサービスは、Pool レベルのみの 1 階層ロードバランシングとします。
DC-A を優先し、DC-A のサービスがダウンしたら DC-B を利用する、というニーズを想定します。
(Pool レベル： Global Availability)
以降、DC-A に設置された 2 つの LTM (big189.f5jp.local と big190.f5jp.local)は設定済みとし、GTM と連携するための
ポイントのみ記載します。
DC-A の GTM および DC-B の GTM&LTM は初期設定から行うこととします。
17
2.7. DC-A の LTMs (Active-Active) の設定
DC-A の LTM (冗長化) は、設定済みの前提で進めます。
ここでは、GTM との連携の際に関係のある設定ポイントに絞って説明します。
Virtual Servers
以下 4 つの Virtual Server が設定されています。
「Local Traffic」→「Virtual Servers」→「Virtual Servers List」で確認できます。
External Self IP の Port Lockdown
本ガイドでは、External の Self IP の Port Lockdown は、簡易的に「Allow Default」設定にしています。
GTM との連携に必要な TCP/UDP ポートを Open にしておく必要があるためです。
※実環境では、セキュリティ的観点から、例えば「Network」→「Packet Filters」設定を利用して必要最低限の IP アドレスか
らの通信のみを許可するなど、フィルタリング対応を行ってください。
「Network」→「Self IPs」で表示された「external-ip」をクリックして確認します。
［参考］sol13250: Overview of port lockdown behavior (10.x - 11.x)
http://support.f5.com/kb/en-us/solutions/public/13000/200/sol13250.html
18
2 つの Traffic-Group
DC-A の 2 つの LTM を Active-Acitve で動作させるため、以下 2 つの Traffic-Group を設定しています。
Traffic-Group-1 はデフォルトで設定されていますが、2 つ目の Traffic-Group-2 は追加設定する必要があります。
2.7.3.1. Traffic-group-1 の Failover オブジェクト
Traffic-group-1 は以下 2 つのオブジェクト：Virtual Address と Self IP を含んでいます。
(1)
Virtual Address
Virtual Address をどの Traffic-Group に属させるかの指定は、「Local Traffic」→「Virtual Servers」→「Virtual Address
List」で表示された IP アドレスをクリックして表示された画面で、「Traffic Group」のプルダウンメニューから選択します。
Traffic-Group-1 を選択。
19
(2)
Floating Self IP
Self IP をどの Traffic-Group に属させるかの指定は、「Network」→「Self IPs」で表示された該当 Self IP をクリックて
表示された画面で、「Traffic Group」のプルダウンメニューから選択します。
Traffic-Group-1 を選択。
2.7.3.2. Traffic-group-2 の Failover オブジェクト
Traffic-group-2 は以下 2 つのオブジェクト：Virtual Address と Self IP を含んでいます。
(1)
Virtual Address
設定方法は、Traffic-Group-1 と同じです。
Traffic-Group-2 を選択。
20
(2)
Floating Self IP
設定方法は、Traffic-Group-1 と同じです。
Traffic-Group-2 を選択。
21
2.8. DC-A GTM の基本設定
初期セットアップウィザード
初期セットアップウィザードの画面遷移は一部省略し、設定ポイントのみ記載します。
(1)
プロビジョニング
DC-A に設置の GTM は「GTM スタンドアローン」とすることにしますので、LTM のチェックを外し、GTM だけ選択しま
す。
チェックを外す。
GTM のみチェック。
(2)
BIG-IP の証明書
そのまま「Next」ボタンを押します。
22
(3)
ホスト名／Time Zone／Root および Admin パスワード
以下のように設定します。
FQDN 形式で設定。
地域を選択。
Root/Admin それぞれの
パスワードを設定。
(4)
初期設定ウィザードをこのまま進めれば、冗長化設定も実施できますが、本ガイドではデータセンター内での冗長化
は行わないので、ここでは「Finished」ボタンを押します。
23
ネットワークの設定
ネットワーク構成に合わせて、VLAN、インタフェース IP アドレス(Self IP)およびルーティング設定を行います。
2.8.2.1. External VLAN の設定
まず、VLAN を作成します。
「Network」→「VLAN」で表示された画面の右上にある「Create」ボタンを押し、現れた画面で以下のように設定します。
名前(任意)を指定。
ポートを選択して「Add」ボタンを押す。
24
2.8.2.2. External の Self IP の設定
設定した VLAN に対して、IP アドレスを設定します。
「Network」→「Self IPs」で表示された画面の右上にある「Create」ボタンを押し、現れた画面で以下のように設定します。
この Self IP アドレスを使って、各データセンターの BIG-IP や汎用サーバとの通信を行うので、「Port Lockdown」設定
は、本ガイドでは簡易的に「Allow Default」を選択します。
※実環境では、セキュリティ的観点から、例えば「Network」→「Packet Filters」設定を利用して必要最低限の IP アドレスか
らの通信のみを許可するなど、フィルタリング対応を行ってください。
名前(任意)、IP アドレス、
サブネットマスク、VLAN を設定。
このアドレス上でのサービス(SSH/GUI アクセス等)を許可。
2.8.2.3. デフォルトゲートウェイのルーティング設定
「Network」→「Routes」で表示された画面の右上にある「Add」ボタンを押し、現れた画面で以下のように設定します。
任意の名称を入力。
左記の通りに入力。
ゲートウェイのアドレスを入力。
25
NTP 設定
時刻同期設定を行います。
データセンター間の GTM 間でリアルタイム同期を行うためには、この設定は非常に重要な意味を持ちます。
「System」→「Configuration」→「Device」→「NTP」で表示された画面で、以下のように設定します。
①NTP のアドレスを入力し、
「Add」ボタンを押す。
②Update ボタンを押す
26
GTM の Listener 設定
DNS サービスを提供する IP アドレス：Listener を設定します。
本ガイドでは、アドレス節約の意味で、Listener IP アドレスと Self IP を共用しています。
しかし、Self IP とは異なる、新たな Listener IP アドレスを設定しても構いません。
「DNS」→「Delivery」→「Listeners」で表示された画面の右上にある「Create」ボタンを押し、現れた画面で以下のように
設定します。
名前(任意)を指定。
Listener の IP アドレスを指定。
本ガイドでは、Self IP と共用。
DNS サービスを提供する
VLAN を指定(オプション)。
一旦、DC-A の GTM 設定はここまでで止めておき、DC-B の GTM+LTM の設定に移ります。
27
2.9. DC-B の GTM+LTM の基本設定
初期セットアップウィザード
初期セットアップウィザードの画面遷移は一部省略し、設定ポイントのみ記載します。
(1)
プロビジョニング
DC-B に設置の GTM は「GTM と LTM がひとつの筐体上で動作する」という形態にしますので、LTM と GTM 両方を
選択します。
チェックしたまま。
GTM をチェック。
(2)
BIG-IP 証明書
そのまま「Next」ボタンを押します。
28
(3)
ホスト名／Time Zone／Root および Admin パスワード
以下のように設定します。
FQDN 形式で設定。
地域を選択。
Root/Admin それぞれの
パスワードを設定。
(4)
初期設定ウィザードをこのまま進めれば、冗長化設定も実施できますが、データセンター内での冗長化は行わない
ので、ここでは「Finished」ボタンを押します。
29
ネットワークの設定
ネットワーク構成に合わせて、VLAN、インタフェース IP アドレス(Self IP)およびルーティング設定を行います。
2.9.2.1. VLAN 設定
「Network」→「VLAN」で表示された画面の右上にある「Create」ボタンを押し、現れた画面で以下のように設定します。
(1)
External VLAN の設定
名前(任意)を指定。
ポートを選択して「Add」ボタンを押す。
(2)
Internal VLAN の設定
名前(任意)を指定。
ポートを選択して「Add」ボタンを押す。
30
2.9.2.2. Self IP の設定
設定した VLAN それぞれに対して、IP アドレス(Self IP)を設定していきます。
「Network」→「Self IPs」で表示された画面の右上にある「Create」ボタンを押し、現れた画面で以下のように設定します。
(1)
External の Self IP 設定
この Self IP アドレスを使って、各データセンターの BIG-IP や汎用サーバとの通信を行うので、「Port Lockdown」設定
は、本ガイドでは簡易的に「Allow Default」を選択します。
※実環境では、セキュリティ的観点から、例えば「Network」→「Packet Filters」設定を利用して必要最低限の IP アドレス
からの通信のみを許可するなど、フィルタリング対応を行ってください。
名前(任意)、IP アドレス、
サブネットマスク、VLAN を設定。
このアドレス上でのサービス(SSH/GUI アクセス等)を許可。
(2)
Internal の Self IP 設定
こちらの Port Lockdown 設定は、「管理者による管理のためのアクセス」という意味合いで、Allow Default を選択してい
ます。
名前(任意)、IP アドレス、
サブネットマスク、VLAN を設定。
このアドレス上でのサービス(SSH/GUI アクセス等)を許可。
31
2.9.2.3. ルーティングの設定
ルーティング設定を行います。
「Network」→「Routes」で表示された画面の右上にある「Add」ボタンを押し、現れた画面で以下のように設定します。
(1)
デフォルトゲートウェイのルーティング設定
任意の名称を入力。
左記の通りに入力。
ゲートウェイのアドレスを入力。
(2)
サーバ向けルーティングの設定
任意の名称を入力。
左記の通りに入力。
ゲートウェイのアドレスを入力。
32
NTP 設定
時刻同期設定を行います。
データセンター間の GTM 間でリアルタイム同期を行うためには、この設定は非常に重要な意味を持ちます。
「System」→「Configuration」→「Device」→「NTP」で表示された画面で、以下のように設定します。
①NTP のアドレスを入力し、
「Add」ボタンを押す。
②Update ボタンを押す。
33
LTM の設定
LTM としての設定を行います。
2.9.4.1. Pool の設定
まず、Pool から作成します。Pool は、ロードバランス対象の複数サーバの集合を指します。
「Local Traffic」 → 「Pools」で表示された画面の右上にある「Create」ボタンを押し、現れた画面で以下のように設定し
ます。
名前(任意)を指定。
プールメンバーへの
ヘルスモニターを選択。
ロードバランシング方式を選択。
Address:と Service Port を入力し、
「add」ボタンを押すと、メンバーに追加される。
34
2.9.4.2. HTTPS(Port:443)の Virtual Server 設定
本ガイドでは簡易的に、Client SSL Profile はデフォルトで用意されているものを使います。
「Local Traffic」→「Virutual Servers」で表示された画面の右上にある「Create」ボタンを押し、現れた画面で以下のように
設定します。
名前(任意)を指定。
仮想 IP アドレスとサービスポート:443 を指定。
(任意) HTTP Profile を選択。
デフォルトで用意されている
SSL Profile を選択。
SNAT Automap を選択(オプション。環境依存)。
～略～
先ほど設定した Pool を選択。
35
2.9.4.3. HTTP の Virtual Server 設定
HTTPS の場合とほぼ同様の方法で、HTTP(Port:80)の Virtual Server を設定します。
HTTP では、Client SSL Profile を割当てない、というのが HTTPS との大きな違いです。
名前(任意)を指定。
仮想 IP アドレスとサービスポート:80 を指定。
(任意) HTTP Profile を選択。
SNAT Automap を選択(オプション。環境依存)。
～略～
先ほど設定した Pool を選択。
36
2.9.4.4. 設定された 2 つの Virtual Servers
以下のように、2 つの Virutal Serers が設定された状態になります。
37
GTM の Listener 設定
DNS サービスを提供する IP アドレス：Listener を設定します。
本ガイドでは、アドレス節約の意味で、Listener IP アドレスと Self IP を共用しています。
しかし、Self IP とは異なる、新たな Listener IP アドレスを設定しても構いません。
「DNS」→「Delivery」→「Listeners」で表示された画面の右上にある「Create」ボタンを押し、現れた画面で以下のように
設定します。
名前(任意)を指定。
Listener の IP アドレスを指定。
本ガイドでは、Self IP と共用。
DNS サービスを提供する
VLAN を指定(オプション)。
DC-B GTM+LTM の設定は一旦ここで止めて、DC-A GTM の設定に戻ります。
38
2.10. GSLB の設定
ここから、Global Server Load Balancing の設定を行います。
設定は、DC-A の GTM (big171.f5jp.local) から行ます。
そのあとで、DC-B の GTM (big199.f5jp.local)への設定同期を行います。
データセンター
まず、データセンターを作ります。
「DNS」→「GSLB」→「Data Centers」→で表示された画面の右上にある「Create」ボタンを押し、現れた画面で以下のよ
うに設定します。
(1)
DC-A
名前(任意)を指定。
(2)
DC-B
名前(任意)を指定。
39
Servers への追加 (GTM)
まずは、Sync-Group 設定を行う、2 つの GTM を Servers へ追加します。
2.10.2.1. DC-A GTM(自分自身)の追加
(1)
「DNS」→「GSLB」→「Servers」で表示された画面の右上にある「Create」ボタンを押し、現れた画面で以下のように
設定します。
名前(任意)を指定。
BIG-IP System (Single)を選択。
Servers に登録する装置の
IP アドレスを入力し、
「Add」ボタンを押す。
データセンターを選択。
「BIG-IP」を選択肢し、「<<」を押す。
(2)
以下のように Status がグリーンになれば登録完了です。
40
2.10.2.2. DC-B の GTM+LTM の追加
(1)
同様に、DC-B の GTM+LTM も登録します。
名前(任意)を指定。
BIG-IP System (Single)を選択。
Servers に登録する装置の
IP アドレスを入力し、
「Add」ボタンを押す。
データセンターを選択。
「BIG-IP」を選択肢し、「<<」を押す。
Enabled を選択(LTM 上の Virtual Server を自動取得)
(2)
GTM から他の BIG-IP を初めて Servers に追加した際には、正常に登録されません。
(Status がグリーンになりません。)
GTM01(big171.f5jp.local)の/var/log/gtm には、以下のような証明書関連のエラーメッセージが出力されます。
Oct 9 16:38:16 big171 notice gtmd[12149]: 011ae020:5: Connection in progress to 10.99.1.199
Oct 9 16:38:16 big171 notice gtmd[12149]: 011ae01c:5: Connection complete to 10.99.1.199. Starting SSL handshake
Oct 9 16:38:16 big171 iqmgmt_ssl_connect: SSL error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Oct 9 16:38:16 big171 err gtmd[12149]: 011ae0fa:3: iqmgmt_ssl_connect: SSL error: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (336134278)
この事象は、次のステップで実施する「gtm_add」コマンドによって解消されますので、一旦、このままにしま
す。
41
2.10.2.3. ［参考］GTM の Servers へ他の BIG-IP を初めて追加した際のエラーメッセージについて
GTM の Servers へ他の BIG-IP を初めて追加した際、/var/log/gtm には、既述のような SSL 証明書関連のエラーメッセ
ージが出力されます。
このメッセージは、iQuery で利用する GTM の SSL 証明書と他の BIG-IP の SSL 証明書がお互いに交換されていない
ことが原因です。
「GTM のオブジェクト」でも説明しましたが、iQuery プロトコルは、SSL を使います。
よって、お互いに SSL 証明書を交換しておく必要があります。
しかし、初めて BIG-IP を Servers に登録した際に「bigip」モニターを選択することによって、iQuery プロトコルによる情
報交換を行う準備はできているのですが、それだけでは、まだ SSL 証明書の交換が行われていない状態になります。
後に CLI で実施する、「gtm_add」 または 「bigip_add」によって、お互いに SSL 証明書を交換することができます。
具体的には、以下のように、big3d/gtmd 用の証明書リストにお互いの証明書が追加されます。
GTM は、他の BIG-IP の SSL 証明書を、「/config/gtm/server.crt」ファイルに付加していきます。
他の BIG-IP は、GTM の SSL 証明書を、「/config/big3d/client.crt」ファイルに追加していきます。
42
GTM 間で同期するための設定 (Sync-Group)
Sync-Group の設定方法を以下に記載します。
2.10.3.1. DC-A の GTM
「DNS」→「Settings」→「GSLB」→「General」で表示された画面で、以下のように設定します。
チェックを入れる。
2 つの GTM で同じ名前(任意)にする。
チェックを入れる。
～略～
2.10.3.2. DC-B の GTM+LTM
DC-B の GTM+LTM でも同様の設定を行います。
チェックを入れる。
2 つの GTM で同じ名前(任意)にする。
チェックを入れる。
～略～
43
2.10.3.3. gtm_add コマンド
2 つの GTM 間で Sync-Group を構成するには、上記の GUI 設定だけでなく、CLI で「gtm_add」を実施する必要があり
ます。
gtm_add は「コンフィグ同期を受け付ける側」から実施する必要があるので、本ガイドの構成では、DC-B の
GTM+LTM(big199.f5jp.local)で行います。
① SSH で DC-B の GTM＋LTM (big199.f5jp.local) へログイン。
② [root@big199:Active:Standalone] config # tmsh
③ root@(big199)(cfg-sync Standalone)(Active)(/Common)(tmos)# run gtm gtm_add
WARNING: Running this script will wipe out the current configuration files (bigip_gtm.conf,
named.conf and named zone files) on the BIG-IP GTM Controller on which this script is run. The
configuration will be replaced with the configuration of the remote BIG-IP GTM Controller in the
specified sync group
The local BIG-IP GTM MUST already be added in the configuration of the other GTM.
④ Are you absolutely sure you want to do this? [y/n] y
⑤ Enter the IP address of a remote GTM BIG-IP from which you want to copy the configuration:
10.99.111.171
==> Running 'bigstart shutdown gtmd' on the local system
==> Running 'bigstart shutdown zrd' on the local system
==> Running 'bigstart shutdown named' on the local system
Retrieving remote and installing local BIG-IP's SSL certs ... (←SSL 証明書の交換)
Enter root password if prompted
Password: 「Root のパスワード」
Rekeying Master Key...
Verifying iQuery connection to 10.99.111.171. This may take up to 30 seconds
Retrieving remote GTM configuration...
Retrieving remote DNS/named configuration...
Restarting gtmd
Restarting named
Restarting zrd
==> Done <==
これで、2 つの GTM 間での Sync-Group 設定は完了です。
2 つの GTM で、ここまでに設定した GSLB の内容(Data Centers, Servers)が同期されていることを確認してください。
44
2.10.3.4. 状態確認
DC-B の GTM+LTM (big199.f5jp.local)の状態を確認します。
(1)
以下のように、DC-B の GTM+LTM の Status がグリーンになります。
(2)
DC-B-GTM02_LTM をクリックし、「Virtual Servers」タブをクリックすると、LTM 上に設定された 2 つの Virtual
Servers が自動的に発見されていることが分かります。
45
Servers への追加 (LTM / 汎用サーバ)
DC-A の GTM (big171.f5jp.local)から、GTM 以外の装置(BIG-IP 及び汎用サーバ)を Servers に追加します。
2.10.4.1. DC-A の LTM(冗長化)の追加
「DNS」→「GSLB」→「Servers」で表示された画面の右上にある「Create」ボタンを押し、現れた画面で以下のように設定
します。
名前(任意)を指定。
BIG-IP System (Redundant)を選択。
1 台目の BIG-IP の
External Self IP アドレスを入力し、
「Add」ボタンを押す。
2 台目の BIG-IP の
External Self IP アドレスを入力し、
「Add」ボタンを押す。
データセンターを選択。
「BIG-IP」を選択肢し、「<<」を押す。
Enabled を選択(Virtual Server を自動取得)
46
2.10.4.2. bigip_add コマンド
GTM から他の BIG-IP を初めて Servers に追加した際には、正常に登録されません。
(Status がグリーンになりません。)
DC-A の GTM (big171.f5jp.local)の/var/log/gtm には、以下のような証明書関連のエラーメッセージが出力されます。
Oct 1 16:34:34 big171 notice gtmd[11154]: 011ae020:5: Connection in progress to 10.99.111.190
Oct 1 16:34:34 big171 notice gtmd[11154]: 011ae020:5: Connection in progress to 10.99.111.189
Oct 1 16:34:34 big171 notice gtmd[11154]: 011ae01c:5: Connection complete to 10.99.111.190. Starting SSL
handshake
Oct 1 16:34:34 big171 notice gtmd[11154]: 011ae01c:5: Connection complete to 10.99.111.189. Starting SSL
handshake
Oct 1 16:34:34 big171 iqmgmt_ssl_connect: SSL error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Oct 1 16:34:34 big171 iqmgmt_ssl_connect: SSL error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Oct 1 16:34:34 big171 err gtmd[11154]: 011ae0fa:3: iqmgmt_ssl_connect: SSL error: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (336134278)
Oct 1 16:34:34 big171 err gtmd[11154]: 011ae0fa:3: iqmgmt_ssl_connect: SSL error: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (336134278)
これは GTM と LTM の間で、SSL 証明書の交換がなされていないことが原因です。
(既述：「［参考］GTM の Servers へ他の BIG-IP を初めて追加した際のエラーメッセージについて」参照)
DC-A の GTM (big171.f5jp.local)から「bigip_add」コマンドを使って、SSL 証明書の交換を行います。
[root@big171:Active:Standalone] config # tmsh
root@(big171)(cfg-sync Standalone)(Active)(/Common)(tmos)# run gtm bigip_add 10.99.111.189
Retrieving remote and installing local BIG-IP's SSL certs ...
(←SSL 証明書の交換)
Enter root password for 10.99.111.189 if prompted
Password: 「Root のパスワード」
==> Done <==
root@(big171)(cfg-sync Standalone)(Active)(/Common)(tmos)#
root@(big171)(cfg-sync Standalone)(Active)(/Common)(tmos)# run gtm bigip_add 10.99.111.190
Retrieving remote and installing local BIG-IP's SSL certs ...
(←SSL 証明書の交換)
Enter root password for 10.99.111.190 if prompted
Password: 「Root のパスワード」
==> Done <==
root@(big171)(cfg-sync Standalone)(Active)(/Common)(tmos)#
これで Servers への BIG-IP の登録は完了です。
47
2.10.4.3. 状態確認
(1)
以下のように、DC-A の LTMs(冗長化)の Status がグリーンになります。
(2)
DC-A-LTMs をクリックし、「Virtual Servers」タブをクリックすると、LTM 上に設定された 4 つの Virtual Servers が自
動的に発見されていることが分かります。
48
2.10.4.4. ［参考］ big3d_install について
もし、GTM の Servers に追加する他の BIG-IP の OS Version が古い場合、その big3d も古いバージョンである可能性
が高いです。
その場合、「big3d_install」を実行することによって、GTM から他の BIG-IP に対して、新しい Version の big3d をインス
トールすることができます。 このコマンドを使って、全 BIG-IP で、同じバージョンの big3d にしておくことを推奨します。
以下が、big3d_install の実行例です。
root@(big171)(cfg-sync Standalone)(Active)(/Common)(tmos)# run gtm big3d_install 10.99.111.189
Making sure all BIG-IP systems can be reached, and
checking kernel and big3d versions on each BIG-IP.
Gathering big3d info from 10.99.111.189
Attempting via iqsh ... Successful
Local big3d version is 11.6.0.0.0.401
big3d version at 10.99.111.189 is 11.6.0.3.14.412
The most up-to-date version is already installed at 10.99.111.189 - skipping
(本ガイドの環境では、GTM も他の BIG-IP も V11.6 を利用しているので、インストールは Skip されています。)
49
汎用サーバ (Linux)の追加
2 つ存在する汎用サーバ (Generic-Host-1, Generic-Host-2)を Servers に追加します。
本ガイドでは、汎用サーバに対しては、SNMP によるモニターを実施することにします。
2.10.5.1. SNMP Monitor の作成
SNMP モニターを作ります。
「DNS」→「GSLB」→「Monitors」で表示された画面の右上にある「Create」ボタンを押し、現れた画面で以下のように設
定します。
本ガイドでは、検証用に、Interval と Timeout 値を短め(Interval:15 秒、Timeout:45 秒)に設定して変化を早めに検知で
きるようにしています。
※あまり短くしすぎると、汎用サーバ側の MIB が更新されていない場合があります。
BIG-IP 側では前回取得 MIB との差分を見ている(引き算している)ため、更新されていない＝同じ値が来ると、引き算の
結果、値が「0」となってしまい、トラフィックが流れていても、流れていない扱いになってしまうので、タイマー設定には注意
が必要です。
名前(任意)を指定。
SNMP を選択。
検証用に短めに設定。
50
2.10.5.2. DC-A の汎用サーバ (Generic Host-1) の追加
DC-A の汎用サーバ (Generic Host-1) を Servers に追加します。
「DNS」→「GSLB」→「Servers」で表示された画面の右上にある「Create」ボタンを押し、現れた画面で以下のように設定
します。
名前(任意)を指定。
Generic Host を選択。
汎用サーバの
IP アドレスを入力し、
「Add」ボタンを押す。
データセンターを選択。
作成した SNMP モニターを
選択肢し、「<<」を押す。
FTP と SSH の
それぞれの Virtual Server を作成。
Name(任意)
Address
Service Port
を入力し、「Add」ボタンを押す。
51
2.10.5.3. DC-B の汎用サーバ (Generic Host-2) の追加
DC-B の汎用サーバ (Generic Host-2) を Servers に追加します。
「DNS」→「GSLB」→「Servers」で表示された画面の右上にある「Create」ボタンを押し、現れた画面で以下のように設定
します。
名前(任意)を指定。
Generic Host を選択。
汎用サーバの
IP アドレスを入力し、
「Add」ボタンを押す。
データセンターを選択。
作成した SNMP モニターを
選択肢し、「<<」を押す。
FTP と SSH の
それぞれの Virtual Server を作成。
Name(任意)
Address
Service Port
を入力し、「Add」ボタンを押す。
52
2.10.5.4. 状態確認
(1)
以下のように、追加された 2 つの汎用サーバの Status がグリーンになります。
(2)
DC-A-GenHost-01 をクリックし、「Virtual Servers」タブをクリックすると、設定した 2 つの Virtual Servers が表示さ
れます。
(3)
DC-A-GenHost-02 をクリックし、「Virtual Servers」タブをクリックすると、設定した 2 つの Virtual Servers が表示さ
れます。
53
Pool の作成
必要な Pool を作り、Servers に追加した各オブジェクト(LTM 及び汎用サーバ)が持つ Virtual Servers を、その Pool の
Members として追加します。
尚、Local DNS がキャッシュする時間=TTL はデフォルト：30 秒ですが、本ガイドでは検証用として、変化を早く確認する
ために、短めに設定します。
2.10.6.1. DC-A-sec-pool
HTTPS(Port:443)用の、DC-A の Pool を作成します。
「DNS」→「GSLB」→「Pools」で表示された画面の右上にある「Create」ボタンを押し、現れた画面で以下のように設定し
ます。
名前(任意)を指定。
Advanced を選択。
検証用に短めに設定。
Perferred に Round Robin
Alternate,Fallback に None を設定。
対象の Virtual Server を選択し、
「Add」ボタンを押す。
54
2.10.6.2. DC-B-sec-pool
HTTPS(Port:443)用の、DC-B の Pool も DC-A 同様に作成します。
名前(任意)を指定。
Advanced を選択。
検証用に短めに設定。
Perferred に Round Robin
Alternate,Fallback に None を設定。
対象の Virtual Server を選択し、
「Add」ボタンを押す。
作成した、HTTPS(Port:443)用の 2 つの Pools の状態は以下のようになります。
55
2.10.6.3. Web-pool
HTTP(Port:80)用の Pool も同様の方法で作成します。
名前(任意)を指定。
Advanced を選択。
検証用に短めに設定。
Perferred に VS Capacity
Alternate に Round Robin
Fallback に None を設定。
対象の Virtual Server を選択し、
「Add」ボタンを押す。
56
2.10.6.4. ftp-pool
FTP(Port:21)用の Pool も同様の方法で作成します。
名前(任意)を指定。
Advanced を選択。
検証用に短めに設定。
Perferred に Packet Rate
Alternate に Round Robin
Fallback に None を設定。
対象の Virtual Server を選択し、
「Add」ボタンを押す。
57
2.10.6.5. SSH-pool
SSH(Port:22)用の Pool も同様の方法で作成します。
名前(任意)を指定。
Advanced を選択。
検証用に短めに設定。
Perferred に Global Availability
Alternate に None
Fallback に None を設定。
対象の Virtual Server を選択し、
「Add」ボタンを押す。
58
2.10.6.6. 設定した Pool の一覧
作成した Pools の一覧です。
59
Wide-IP の作成
必要な Wide-IP を作り、作成した Pool を追加します。
2.10.7.1. Secure.pub.f5jp.local
HTTPS(Port:443)用の FQDN (=Wide-IP) には、DC-A と DC-B の 2 つの Pool を追加します。
「DNS」→「GSLB」→「Wide IPs」で表示された画面の右上にある「Create」ボタンを押し、現れた画面で以下のように設
定します。
FQDN を指定。
Global Availability を選択。
Pool を選択し、
「Add」ボタンを押す。
60
2.10.7.2. Web.pub.f5jp.local
HTTP(Port:80)用の FQDN (=Wide-IP) には、作成したひとつの Pool を追加します。
本 Wide-IP では Pool はひとつなので、以下の「Pools」の Load Balancing Method 設定は意味を持たないのですが、設
定が必須となっているので、デフォルトの Round Robin を選んでおきます。
FQDN を指定。
デフォルトのまま、Round Robin。
Pool を選択し、
「Add」ボタンを押す。
61
2.10.7.3. ftp.pub.f5jp.local
FTP(Port:21)用の FQDN (=Wide-IP) には、作成したひとつの Pool を追加します。
本 Wide-IP も Pool はひとつなので、以下の「Pools」の Load Balancing Method 設定は意味を持たないのですが、設定
が必須となっているので、デフォルトの Round Robin を選んでおきます。
FQDN を指定。
デフォルトのまま、Round Robin。
Pool を選択し、
「Add」ボタンを押す。
62
2.10.7.4. ssh.pub.f5jp.local
SSH(Port:22)用の FQDN (=Wide-IP) には、作成したひとつの Pool を追加します。
本 Wide-IP も Pool はひとつなので、以下の「Pools」の Load Balancing Method 設定は意味を持たないのですが、設定
が必須となっているので、デフォルトの Round Robin を選んでおきます。
FQDN を指定。
デフォルトのまま、Round Robin。
Pool を選択し、
「Add」ボタンを押す。
2.10.7.5. 設定した Wide-IP の一覧
以下のように 4 つの Wide-IP が設定された状態になります。
これで、GSLB の設定は完了です。
63
2.11. GSLB の動作確認
設定した GSLB の動作確認を行います。
secure.pub.f5jp.local の動作確認
secure.pub.f5jp.local のロードバランシングメソッドは以下の設定としています。
Wide IP レベル：
Pool レベル：
Global Availability
Round Robin
この設定通りの動作になるかどうかを確認します。
2.11.1.1. 正常時の動作確認
(1)
「Order」の確認
secure.pub.f5jp.local の Pools の Order(順番)を確認します。
「DNS」→「GSLB」→「Wide IPs」→「Wide IP List」で表示された secure.pub.f5jp.local をクリックし、「Pools」タブをクリッ
クすると、以下の画面が表示されます。
「Order」の値に注目してください。
Load Balancing Method が Global Availability の場合は、この「Order」に従って動作します。
DC-A-sec-pool の方が小さい値になっているので、DC-A-sec-pool の Status がグリーンである限り、その Pool が優先
的に利用されます。
64
(2)
クライアント PC から dig を使って、DNS クエリを発行します。
(※Windows 標準では dig は使えません。インストールが必要です。)
正常時においては、数回 dig を実行すると、DC-A-sec-pool が優先的に選択され、その Pool 内のメンバー：
10.99.111.89 と 10.99.111.90 が交互に表示される、というのが期待する動作です。
(TTL を 5 秒に設定しているので、概ね 5 秒ごとに交互に選択されます。)
# dig secure.pub.f5jp.local
または
# dig @10.99.111.171 secure.pub.f5jp.local
(←DNS(図中の 10.99.4.229)経由)
(←GTM へ直接)
Dig を数回実行すると、DC-A の Pool Member の
IP アドレスが交互に表示されることを確認。
Dig を数回実行すると、DC-A の Pool Member の
IP アドレスが交互に表示されることを確認。
65
2.11.1.2. 障害発生時の動作確認
DC-A-sec-pool のメンバーが全て停止した、という障害を想定します。
このことによって、DC-B-sec-pool 内のメンバーのみが返答される、というのが期待される動作です。
(1)
DC-A の LTMs のどちらか一方(例：big189.f5jp.local)で、HTTPS(Port:443)用の Virtual Server×2 個を Disabled
にします。
(2)
以下のように、Status がブラックになります。
66
(3)
再度、クライアントから dig を使って、secure.pub.f5jp.local への DNS クエリを行います。
以下のように、複数回の DNS 応答が全て DC-B の Pool Member のみになれば、GSLB 設定は正常に行われていると
判断できます。
DC-B の Pool Member の IP アドレスになる。
DC-B の Pool Member の IP アドレスになる。
(4)
Disabled した Virtual Servers を Enabled に戻しておきます。
67
web.pub.f5jp.local の動作確認
web.pub.f5jp.local のロードバランシングメソッドは以下の設定としています。
Wide IP レベル：
Pool レベル：
Round Robin (Pool が１つなので、この設定は実質、意味を持ちません。)
VS Capacity
この設定通りの動作になるかどうかを確認します。
2.11.2.1. 正常時の動作確認
VS Capacity は、LTM 上の全ての Virtual Server の Pool Member 数が同じであれば、ラウンドロビンで動作する仕様
になっています。
よって正常時は、数回 dig を実行すると、web-pool 内の Member が交互に表示される、というのが期待する動作です。
クライアント PC から dig を使って、DNS クエリを複数回発行します。
# dig web.pub.f5jp.local
(←DNS(図中の 10.99.4.229)経由)
または
# dig @10.99.111.171 web.pub.f5jp.local (←GTM へ直接)
GTM によって、以下の 3 つの IP アドレスが交互に返答されます。
(TTL が 5 秒なので、概ね 5 秒おきに変化します。)
;; ANSWER SECTION:
web.pub.f5jp.local.
または
または
5
IN
A
10.99.111.89
10.99.111.90
10.99.1.99
68
2.11.2.2. 障害発生時の動作確認
DC-A LTM の Pool Member が 1 台停止した、という状況を想定します。
このとき、DC-B LTM の Pool Member 数のほうが多くなるので、GTM は DC-B の Virtual Server の IP アドレスを返答
する、というのが期待する動作です。
(1)
DC-A の LTMs のどちらか一方(例：big189.f5jp.local)で、HTTP(Port:80)用の Virtual Server に紐付いている Pool
メンバーのうち、一つを Disabled にします。
「DC-A LTM (big189.f5jp.local)」→「Local Traffic」→「Pools」→「Pool List」で該当する Pool をクリックして現れた画面
で、Pool Members の 1 つを Disabled にします。
(2)
再度、クライアントから dig を使って、web.pub.f5jp.local への DNS クエリを、複数回行います。
dig @10.99.111.171 web.pub.f5jp.local
以下のように、複数回の DNS 応答が全て DC-B の Virtual Server (10.99.1.99)のみになれば、GSLB 設定は正常に行
われていると判断できます。
;; ANSWER SECTION:
web.pub.f5jp.local.
(3)
5
IN
A
10.99.1.99
Disabled した LTM 上の Pool Member を Enabled に戻しておきます。
69
ftp.pub.f5jp.local の動作確認
ftp.pub.f5jp.local のロードバランシングメソッドは以下の設定としています。
Wide IP レベル：
Pool レベル：
Round Robin (Pool が１つなので、この設定は実質、意味を持ちません。)
Packet Rate
この設定通りの動作になるかどうかを確認します。
2.11.3.1. 正常時の動作確認
本ガイドでは、SNMP モニターで、汎用サーバのインタフェーストラフィック量を定期的に取得する設定にしています。
Packet Rate は、その SNMP で取得したトラフィック量を常に確認し、トラフィック量が少ないほうの IP アドレスを返答す
る、というのが期待する動作です。
よって、汎用サーバに対してトラフィックがあまり流れていない状態においては、ftp-pool 内のメンバーが概ね交互に返答
されます。
クライアント PC から dig を使って、DNS クエリを発行します。
# dig ftp.pub.f5jp.local
(←DNS(図中の 10.99.4.229)経由)
または
# dig @10.99.111.171 ftp.pub.f5jp.local (←GTM へ直接)
GTM によって、以下 2 つの IP アドレスが概ね交互に返答されます。
;; ANSWER SECTION:
ftp.pub.f5jp.local.
または
5
IN
A
10.99.111.161
10.99.1.162
2.11.3.2. DC-A の FTP サーバにトラフィックを発生させた場合の動作確認
一方の FTP サーバにトラフィック(Packet rate)が発生すると、もう一方の負荷の軽い FTP サーバの IP アドレスが返答
される、というのが期待する動作です。
(1)
クライアントから 10.99.111.161 に ftp アクセスして、大きめのファイルをダウンロードします。
C:\Users\test1009>ftp 10.99.111.161
～略～
ftp> dir
200 PORT command successful. Consider using PASV.
150 Here comes the directory listing.
-rw-r--r-1 0
0
4289386496 Aug 17
～略～
ftp> get CentOS-6.3-x86_64-bin-DVD1.iso
2012 CentOS-6.3-x86_64-bin-DVD1.iso
70
(2)
Bash で以下のコマンドを実行し、汎用サーバのトラフィック状態を 1 秒ごとに確認します。
# watch -n 1 tmsh show gtm server DC-A-GenHost-01 DC-B-GenHost-02 raw
DC-A の汎用サーバ (10.99.111.161)のトラフィック量(Bits/sec，Packets/sec)が上がっていることを確認します。
Every 1.0s: tmsh show gtm server DC-A-GenHost-01 DC-B-GenHost-02 raw
Wed Jan 14 10:38:07 2015
(raw)
---------------------------------------Gtm::Server: DC-A-GenHost-01 (Unit: 0)
---------------------------------------Status
Availability : available
State
: enabled
Reason
:
Global
Virtual Server Picks
Connections
Throughput
Bits/sec
Packets/sec
117
5
In
Out
189850 34271931
351
217
(raw)
-------------------------------------Gtm::Server: DC-B-GenHost-02 (Unit: 0)
-------------------------------------Status
Availability : available
State
: enabled
Reason
:
Global
Virtual Server Picks
Connections
Throughput
Bits/sec
Packets/sec
(3)
90
0
In
773
1
Out
748
1
再度、クライアントから dig を使って、ftp.pub.f5jp.local への DNS クエリを複数回実行します。
dig @10.99.111.171 ftp.pub.f5jp.local
DC-A の汎用サーバ(10.99.111.161)のトラフィックが多い間は、DC-B の汎用サーバ(10.99.1.162)の IP アドレス返答
のみになれば、GSLB 設定は正しく動作していると判断できます。
;; ANSWER SECTION:
ftp.pub.f5jp.local.
5
IN
A
10.99.1.162
71
ssh.pub.f5jp.local の動作確認
ssh.pub.f5jp.local のロードバランシングメソッドは以下の設定としています。
Wide IP レベル：
Pool レベル：
Round Robin (Pool が１つなので、この設定は実質、意味を持ちません。)
Global Availability
この設定通りの動作になるかどうかを確認します。
2.11.4.1. 正常時の動作確認
(1)
「Order」の確認
Global Availability は、「Order」(順番)にしたがって返答する、という動作であることは、secure.pub.f5jp.local で述べた
通りです。Pool の選択時のみでなく、Pool 内のメンバー選択時においても同様です。
ssh.pub.f5jp.local の Pool Member の Order(順番)を確認します。
「DNS」→「GSLB」→「Pools」→「Pool List」で表示された ssh-pool をクリックし、「Members」タブをクリックすると、以下
の画面が表示されます。
「Order」の値を見ると、DC-A の汎用サーバ(10.99.111.161)の方が小さい値になっています。
よって正常時は、DC-A の汎用サーバの IP アドレスが常に返答される、というのが期待する動作です。
(2)
クライアント PC から dig を使って、DNS クエリを複数回発行します。
# dig ssh.pub.f5jp.local
(←DNS(図中の 10.99.4.229)経由)
または
# dig @10.99.111.171 ssh.pub.f5jp.local (←GTM へ直接)
GTM によって、以下の IP アドレスのみが返答されます。
;; ANSWER SECTION:
ssh.pub.f5jp.local.
5
IN
A
10.99.111.161
72
2.11.4.2. 「Order」番号を入れ替えて動作確認
ここでは、Pool Member の停止ではなく、Order 番号を入れ替えてみます。
Order 番号を入れ替えると、今度は DC-B の汎用サーバの IP アドレス (10.99.1.162) のみが返答される、というのが
期待される動作です。
(1)
Order 番号の小さいほう：DC-A-GenHost-01 をクリックして表示された以下の画面で、「Order」値に、2 つ目のメン
バーの Order 番号より大きい値 (＝2 以上) を入力します。
2 つ目の Member より大きい値を入れる
(2)
以下のように、Order が入れ替わります。
DC-B の汎用サーバ (10.99.1.162) の Order 値が小さくなっています。
(3)
再度、クライアントから dig を使って、ssh.pub.f5jp.local への DNS クエリを複数回実行します。
dig @10.99.111.171 ssh.pub.f5jp.local
DC-B の汎用サーバの IP アドレス返答 (10.99.1.162) のみになれば、GSLB 設定は正しく動作していると判断できま
す。
;; ANSWER SECTION:
ssh.pub.f5jp.local.
(4)
5
IN
A
10.99.1.162
Order 設定を戻しておきます。
73
2.12. Topology の設定
ある条件を Topology レコードに指定することで、その条件に合致した場合のアクション(DNS 返答)を変えることが可能に
なります。
例えば送信元 IP アドレス(サブネット)や、送信元 IP アドレスの地域に応じて、DNS で返答する IP アドレスを変える、とい
うアクションが取れます。
例：送信元 IP アドレスのサブネットで DNS 返答を変える
例として、送信元 IP アドレスのサブネットに応じて、DNS の返答を変える設定を行ってみます。
10.99.4.0/24 (サンプルネットワーク図中のクライアント PC が接続されているサブネット) からの secure.pub.f5jp.local
への DNS クエリは、DC-B-sec-pool 内のメンバーIP アドレスを返答する、という Toplogy 設定を行ってみます。
(1)
「DNS」→「GSLB」→「Topology」→「Records」で表示された画面の右上にある「Create」ボタンを押すことで表示さ
れた画面で、以下のように設定します。
サブネットを指定。
Pool を指定。
(2)
「DNS」→「GSLB」→「Wide IPs」→「Wide IP List」で表示された secure.pub.f5jp.local をクリックし、「Pools」タブを
クリックして表示された画面で、以下のように設定します。
Topology を選択。
74
(3)
クライアント PC から secure.pub.f5jp.local への DNS 応答は常に、DC-B-sec-pool のメンバーになることを確認し
ます。
75
3. Link
3.1. Link の概要
Link とは、「BIG-IP から Default Gateway への論理パス」のことを指し、複数設定されたその Link オブジェクトを、効率
よく利用することを目的とした機能です。
例えば、サンプルネットワーク構成の DC-B にて、新しい Web サービス：link.pub.f5jp.local を提供する、とします。
このサービスを提供するにあたり、より高速な処理と ISP 冗長化(一つの ISP がダウンした場合の備え)の意味から、2
つ目の ISP (ISP-4) と契約し、この 2 つの ISP 回線を効率よく利用したい、という要件があるとします。
このような要件を満たすのが Link 機能です。
Link には Inbound 方向/Outbound 方向の 2 つの側面があり、それぞれ別々に解説します。
尚、Link の Dynamic Ratio ロードバランシングを利用するにあたっては、以下 SOL にある内容にご注意ください。
sol15834: End of Life announcement for inbound and outbound cost-based link load balancing and inbound link
path-based load balancing
http://support.f5.com/kb/en-us/solutions/public/15000/800/sol15834.html
76
3.2. Inbound 制御の概要
クライアントから BIG-IP へ入力されるトラフィックを、DNS 応答を使ってコントロールします。
① GTM から見たインターネット方向の Gateway：10.99.1.254 を Link として設定する。
② もう一つの Gateway：10.99.112.254 も同様に、Link として設定する。
③ 10.99.1.254 への Link には、10.99.1.49:80 の Virtual Server を関連付ける。
④ 10.99.112.254 への Link には、10.99.112.49:80 の Virtual Server を関連付ける。
⑤ クライアントが Local DNS へ、「link.pub.f5jp.local」の IP アドレスを問い合わせる。
⑥ Local DNS が、pub.f5jp.local を管理する Listener:10.99.1.199 へ「link.pub.f5jp.local」の IP アドレスを問い合わせ
る。
⑦ その問い合わせを受けた BIG-IP は、2 つの Link の状態を確認し、どちらの負荷 (例えばトラフィック量) が小さいかを
確認する。
例えば、10.99.1.254 の Link は既に他のクライアントによって多数のトラフィックが流れていて、10.99.11.254 側 Link
の負荷の方が小さい、とする。
⑧ 10.99.112.254 の負荷が小さいので、GTM はその Link に紐付いた VS:10.99.112.49:80 の IP アドレスを返答。
⑨ その結果、クライアントのトラフィックを、10.99.112.254 の Link に誘導 ＝ 2 つの Link を効率的に利用。
⑩ クライアントへの戻りトラフィックは、Auto-Lasthop 機能により、ISP-4 のルータ(10.99.112.254)方向に送られる。
77
3.3. Outbond 制御の概要
BIG-IP から出力されるトラフィックのコントロールです。
Outbound 方向(サーバ群からインターネット方向)に対しては、Inbound 方向のような DNS 機能を使った IP アドレス解
決によるコントロールは行いません。
単純に Link の負荷 (例：トラフィック量) を見て、どちらの Link から IP パケットを出力するかを決定します。
例えば、LTM の Pool Members となる実サーバが、不定期にサーバ自身の Update を目的としたインターネット方向へ
のトラフィックが発生する、と仮定します。
① Wildcard (0.0.0.0:0) の Virtual Server を設定する。
② 2 つの Link (10.99.1.254 と 10.99.112.254) を Gateway とする、Gateway Pool を設定する。
③ 実サーバ群からインターネット方向へのトラフィックが発生。
④ GTM は、Gateway-Pool の各 Link の負荷 (例：トラフィック量) を確認し、バランスよくトラフィックを出力する。
78
3.4. サンプルネットワーク構成
Link 設定で利用するサンプルネットワーク構成です。
新たに DC-B の GTM へ 10.99.112.0/24 のネットワークを追加します。
「link.pub.f5jp.local」という新しい Web サービス(Port:80)を、DC-B で提供する、ということを想定します。
この FQDN に関連付ける以下 2 つの Virtual Server を追加で設定します。
10.99.1.49:80
10.99.112.49:80
Inbound 方向は、「link.pub.f5jp.local」への DNS リクエストに対して、2 つの Virtual Server のうち、Link 負荷の軽い側
の Virutal Server IP アドレスを DNS 応答として返答する、という動作になることを確認します。
Outbound 方向は、図中の 10.99.100.210 から 10.99.1.230 の Web サーバ宛にトラフィックを発生させ、2 つの Link を
効率よく使うことを確認します。
GTM01 と GTM02/LTM は Sync-Group を構成しているので、Link の Status も共有されます。
よって、GTM01 へ問い合わせが発生しても、Link 状態を考慮した返答ができるようになっています。
79
3.5. Link の設定
VLAN の追加
DC-B の GTM の外部接続側に、2 つ目のインタフェースを作ります。
「Network」→「VLAN」で表示された画面の右上にある「Create」ボタンを押し、現れた画面で以下のように設定します。
名前(任意)を指定。
ポートを選択して「Add」ボタンを押す。
Self-IP の追加
設定した VLAN に対して、IP アドレスを設定します。
「Network」→「Self IPs」で表示された画面の右上にある「Create」ボタンを押し、現れた画面で以下のように設定します。
名前(任意)、IP アドレス、
サブネットマスク、VLAN を設定。
このアドレス上でのサービス(SSH/GUI アクセス等)を許可。
80
Servers の DC-B-GTM02_LTM へアドレスを追加
追加した Self IP アドレスを、Servers に設定済みの DC-B-GTM02_LTM へ追加します。
「DNS」→「GSLB」→「Servers」で表示された画面で DC-B-GTM02_LTM をクリックし、現れた画面で以下のように設定
します。
新しく追加した Self-IP を Address 欄に入力し、
Add ボタンを押す。
81
Gateway-Pool の設定
2 つ目の Default-Gateway を指定するために、Gateway-Pool を作ります。
(「Network」→「Routes」には、同じネットワーク宛のルーティングを複数設定することができないので、この GatewayPool という方式を使います。)
(1)
「Local Traffic」 → 「Pools」で表示された画面の右上にある「Create」ボタンを押して表示された画面で、以下のよう
に設定します。
名前(任意)を指定。
Gateway_icmp を選択。
Gateway となるアドレス、
Service Port には＊
を入力し、「Add」ボタンを押す。
(2)
「Network」→「Routes」で設定済みの Default Gateway ルーティングをクリックし、以下のように設定変更します。
「Use Pool」を選択。
設定した Gateway-pool を選択。
82
Link の作成
2 つの Link を設定します。
ヘルスモニターに bigip_Link を選択することによって、Link の統計情報 (トラフィック量等) を収集します。
3.5.5.1. 10.99.1.254 の Link
「DNS」→「GSLB」→「Links」→「Link List」表示された画面の右上にある「Create」ボタンを押し、現れた画面で以下のよ
うに設定します。
名前(任意)を指定。
Gateway となるアドレスを入力し、
「Add」ボタンを押す。
Data Center を選択。
Bigip_link を選択。
83
3.5.5.2. 10.99.112.254 の Link
こちらも同様の方法で設定します。
名前(任意)を指定。
Gateway となるアドレスを入力し、
「Add」ボタンを押す。
Data Center を選択。
Bigip_link を選択。
84
3.6. Inbound 制御の設定
BIG-IP へ入力されるトラフィックの制御に関わる設定を行います。
Virtual Servers の作成
「link.pub.f5jp.local」用の Virtual Server を 2 つ作成します。
これらの Virtual Servers は、作成した 2 つのそれぞれの Link に自動的に関連付けられます。
3.6.1.1. 10.99.1.49 の Virtual Server
「Local Traffic」 → 「Virutual Servers」で表示された画面の右上にある「Create」ボタンを押して表示された画面で、以
下のように設定します。
名前(任意)を指定。
仮想 IP アドレスとサービスポート:80 を指定。
(任意) HTTP Profile を選択。
(環境依存)Auto Map を選択。
～略～
Pool を選択。
85
3.6.1.2. 10.99.112.49 の Virtual Server
同様の方法で、もうひとつ Virtual Server を作ります。
名前(任意)を指定。
仮想 IP アドレスとサービスポート:80 を指定。
(任意) HTTP Profile を選択。
(環境依存)Auto Map を選択。
～略～
Pool を選択。
86
3.6.1.3. Virtual Server と Link の関連付け状態確認
作成した Virtual Servers をクリックして画面を開き、それぞれ Link が自動的に関連付けされていることを確認します。
(1)
10.99.1.49 の Virtual Server の確認
関連付けされた Link。
(2)
10.99.112.49 の Virtual Server の確認
関連付けされた Link。
(3)
［参考］ Link に関連付けされる VS の変更について
例えば、link-49-vs1 を 10.99.1.254 の Link から 10.99.112.254 の Link に変更したい場合には、CLI(tmsh)から以下の
コマンドで変更できます。
root@(big199)(cfg-sync Standalone)(Active)(/Common)(tmos)# modify gtm server DC-B-GTM02_LTM virtualservers modify { /Common/link-49-vs1 { explicit-link-name 10.99.112.254 }}
87
GTM の Pool の作成
Wide-IP:「link.pub.f5jp.local」用の Pool を作ります。
本ガイドでは、2 つの Link に流れている「トラフィック量＝Bits / Second」を確認し、トラフィック量の少ないほうの IP アド
レスを返答する、という設定を行うこととします。
「DNS」→「GSLB」→「Pools」→「Pool List」で表示された画面の右上にある「Create」ボタンを押し、現れた画面で以下
のように設定します。
名前(任意)を指定。
「Advanced」を選択。
検証用に短めに設定。
Perferred に Quality of Service
Alternate に Round Robin
Fallback に None を設定。
Bits / Second の値だけを残し、
それ以外は全て「0」にする。
対象の Virtual Server を選択し、
「Add」ボタンを押す。
88
Wide-IP の作成
作成した Pool と関連付ける、「link.pub.f5jp.local」用の Wide-IP を作ります。
「DNS」→「GSLB」→「Wide IPs」で表示された画面の右上にある「Create」ボタンを押し、現れた画面で以下のように設
定します。
FQDN となる名前を指定。
Pool を選択し、
「Add」ボタンを押す。
これで Link の Inbound 方向の制御に必要な設定は完了です。
89
動作確認
Link の inbound 方向の制御が期待とおり動作するかを確認します。
3.6.4.1. 正常時の動作確認
Link の bigip_link モニターによって、Link の統計情報を取得し、Pool の Load Blancing Method の Quality of Service
で Bits / Second をチェックする設定にしています。
この設定によって、取得したトラフィック量を常に確認し、トラフィック量が少ないほうの IP アドレスを返答する、というのが
期待する動作です。
よって、2 つの Virtual Servers に対してトラフィックがあまり流れていない状態においては、LC-pool 内のメンバーIP アド
レスが概ね交互に返答されます。
クライアント PC から dig を使って、DNS クエリを発行します。
# dig link.pub.f5jp.local
(←DNS(図中の 10.99.4.229)経由)
または
# dig @10.99.111.199 link.pub.f5jp.local
(←GTM へ直接)
GTM によって、以下 2 つの IP アドレスが概ね交互に返答されます。
;; ANSWER SECTION:
link.pub.f5jp.local.
または
5
IN
A
10.99.1.49
10.99.112.49
90
3.6.4.2. 10.99.112.49 の VS にトラフィックを発生させた場合の動作確認
一方の Virtual Server にトラフィックが発生すると、もう一方のトラフィック量の少ない Virtual Server の IP アドレスが返
答される、というのが期待する動作です。
(1)
図中の 10.99.4.229 のサーバ(Linux)から、ab (apache bench) で、多数の HTTP リクエストを発生させます。
# ab -n 999999 -c 10 http://10.99.112.49/
(2)
Link のトラフィック状態を確認します。
BIG-IP の bash で以下のコマンドを実行し、Link のトラフィック状態を 1 秒ごとに確認します。
(Link 状態は big171 にもリアルタイムで同期されますので、big199 だけでなく、big171 でも確認することができます。)
# watch -n 1 tmsh show gtm link all raw
----------Every 1.0s: tmsh show gtm link all raw
Tue Feb 24 12:06:44 2015
(raw)
---------------------------------------Gtm::Link: 10.99.1.254
---------------------------------------Status
Availability : available
State
: enabled
Reason
: Monitor /Common/bigip_link from 10.99.1.199 : UP
Throughput (bits/sec)
Link
In
2173
Miscellaneous
Over Prepaid
2173
Out
1690
Total
3863
(raw)
--------------------------------------------------Gtm::Link: 10.99.112.254
--------------------------------------------------Status
Availability : available
State
: enabled
Reason
: Monitor /Common/bigip_link from 10.99.112.199 : UP
Throughput (bits/sec)
Link
Miscellaneous
Over Prepaid
In
Out
Total
2136739 10693462 12830201
10693462
91
(3)
再度、クライアントから dig を使って、link.pub.f5jp.local への DNS クエリを複数回実行します。
# dig link.pub.f5jp.local
または
# dig @10.99.111.199 link.pub.f5jp.local
(←DNS(図中の 10.99.4.229)経由)
(←GTM へ直接)
10.99.112.49 の VS トラフィックが多い間は、DNS 応答が 10.99.1.49 の IP アドレスのみになれば、Link の Inbound
設定は正しく動作していると判断できます。
92
3.7. Outbound 制御の設定
BIG-IP から Default Gateway 方向へ出力されるトラフィックのコントロールを行う設定です。
Gateway Pool の 設定変更
設定済みの Gteway Pool の Load Blancing Method を、「Dynamic Ratio (Node)」に変更します。
「Local Traffic」→「Pools」→「Pool List」で表示された設定済みの Gateway-pool をクリックして表示された画面で、以下
のように設定変更します。
Dynamic Ratio (Node)に変更。
93
Forwarding Virtual Server の設定
BIG-IP の Internal VLAN へ入力される、宛先が不特定(インターネット宛)のトラフィックを受付ける Virtual Server を設
定します。
「Local Traffic」 → 「Virutual Servers」で表示された画面の右上にある「Create」ボタンを押して表示された画面で、以
下のように設定します。
名前(任意)を指定。
Performance (Layer 4)を選択。
Destination Address0.0.0.0/0
Service Port に＊を指定。
All Protocols を選択。
VLAN and Tunnel Traffic で「Enable on;」を選択し、
VLANs and Tunnels で「Internal」を選択。
(環境依存) Auto Map を選択。
Address Translation を無効化。
～略～
設定済みの Gateway-pool を選択。
94
動作確認
Link の Outbound 方向の制御が期待とおり動作するかを確認します。
3.7.3.1. 正常時の動作確認
Internal VLAN に Forwarding 用 VS を設定しました。
その VS から入力されたトラフィックが、2 つの Link から比較的均等に出力される、というのが期待される動作です。
Internal VLAN 側に存在する 10.99.100.211 のサーバから ab (Apache Bench) コマンドで大量の HTTP リクエストを、
10.99.1.230 の HTTP サーバへ宛に発生させます。
10.99.100.211 → 10.99.1.230
宛先となる Web サーバ：10.99.1.230 が存在するネットワーク：10.99.1.0/24 は BIG-IP にとっては Direct Connected
ネットワークです。
よって、BIG-IP がただ単にルーティングを行う場合は、10.99.1.199 のアドレスを持つインタフェースのみからトラフィック
が出力されます。
しかし、この Outbound 方向の Link 設定よって、2 つの Link へ比較的均等にトラフィックが出力されることで、Link 動作
が正常に働いていると判断できます。
(1)
図中の 10.99.100.211 のサーバ(Linux)から、ab (apache bench) で、多数の HTTP リクエストを発生させます。
# ab -n 99999999 -c 10 http://10.99.1.230/
(2)
Gateway-pool に設定した Dynamic-Ratio 値がどのように変化するかを確認します。
BIG-IP の bash で以下のコマンドを実行し、Dynamic-Ratio 値を 1 秒ごとに確認します。
# watch -n 1 tmsh list ltm node 10.99.1.254 10.99.112.254 dynamic-ratio
----------Every 1.0s: tmsh list ltm node 10.99.1.254 10.99.112.254 dynamic-ratio
ltm node 10.99.1.254 {
dynamic-ratio 30497
}
ltm node 10.99.112.254 {
dynamic-ratio 35037
}
-----------
95
Fri Feb 27 15:41:12 2015
(3)
Link のトラフィック状態を確認します。
BIG-IP の bash で以下のコマンドを実行し、Link のトラフィック状態を 1 秒ごとに確認します。
# watch -n 1 tmsh show gtm link raw
----------Every 1.0s: tmsh show gtm link raw
Fri Feb 27 15:41:33 2015
(raw)
-------------------------------------------------Gtm::Link: 10.99.1.254
-------------------------------------------------Status
Availability : available
State
: enabled
Reason
: Monitor /Common/bigip_link from 10.99.1.199 : UP
Throughput (bits/sec)
Link
In
Out
Total
32959901 2975482 35935385
Miscellaneous
Over Prepaid
32929901
(raw)
-------------------------------------------------Gtm::Link: 10.99.112.254
-------------------------------------------------Status
Availability : available
State
: enabled
Reason
: Monitor /Common/bigip_link from 10.99.112.199 : UP
Throughput (bits/sec)
Link
In
Out
Total
38555017 3478228 42033245
Miscellaneous
Over Prepaid
38525017
-----------
Dynamic-Ratio 値の比率に近い形でトラフィックが出力されていれば、Outbound 方向の Link 動作は正常に動作してい
ると判断できます。
96
4. DNSSEC
4.1. DNSSEC の概要
DNS が持つ脆弱性
一般的な DNS は、その仕組み上、以下のような攻撃が成立する可能性を持っています。
以下は、「カミンスキー攻撃」と呼ばれている DNS の脆弱性をついた代表的な攻撃例です。
「f5jp.com」ドメインは存在するが、FQDN：「01.f5jp.com」「02.f5jp.com」･･･「0n.f5jp.com」は存在しない、と仮定します。
① 攻撃者は、存在しない FQDN：「01.f5jp.com」などの DNS リクエストを大量に送信。
② Local DNS(キャッシュ DNS)は、DNS レスポンスの偽装を防止するために、16 ビットのランダムなトランザクション ID
を付与して、権威 DNS に問合せる。
③ 「f5jp.com」の権威 DNS は、存在しない FQDN の問合せに対して、「NXDOMAIN」応答を返す。
そして、Local DNS は以下 2 つを照合することで、正しいレスポンスである、と判断する。
a) 送信した DNS クエリのトランザクション ID と DNS レスポンスのトランザクション ID が一致すること
b) 送信した DNS クエリの送信元 IP アドレス＆ポート宛への応答であること
④ 攻撃者はこの穴をつく。権威 DNS の IP アドレスを詐称し、想定できる DNS クエリのポート番号とトランザクション ID を
ランダムに生成。それらの値で、総当たり(ブルートフォース)で虚偽の DNS レスポンスを仕掛ける。
⑤ Local DNS のクライアントは、そのキャッシュから偽装された IP アドレス返答を受け取ることで、悪意あるサイトへ誘導
されてしまう。
図中①で行う DNS クエリに、”存在しない FQDN”を使うことで、総当たり攻撃試行チャンスをほぼ無限に増やし、成功
確率を圧倒的に高くできます。
さらに、「ADDITIONAL SECTION」を含ませることで、任意のドメイン/FQDN の組合せをキャッシュさせることができま
す。
「ADDITIONAL SECTION」は自由に設定することが可能であるため、さらに広範なドメイン/FQDN の詐称が可能となり
ます。
97
DNSSEC による攻撃の防御
上記の通り、DNS の脆弱性は「キャッシュを書き換えられる」＝「改ざんされる」ことにあります。
よって、この脆弱性をつく攻撃を防ぐには、
「確実に権威 DNS からのレスポンスであると判断できればよい ＝ 改ざんされていないことが証明できればよい」
ということになります。
DNSSEC は、権威 DNS で DNS 応答に署名を行い、Local DNS がその DNS 応答を検証することによって、改ざんが
行われていないと判断するための機能です。
① 攻撃者は、存在しない FQDN：「01.f5jp.com」などの DNS リクエストを大量に送信。
② Local DNS(キャッシュ DNS)は、DNS レスポンスの偽装を防止するために、16 ビットのランダムなトランザクション ID
を付与して、権威 DNS に問合せる。さらに、DNSSEC 対応であることも合わせて通知する。
③ DNS レスポンスのハッシュ計算を行う。
④ そのハッシュ値を、f5jp.com 権威 DNS の秘密鍵で暗号化＝署名する。
⑤ DNS レスポンスと署名をつけて、Local DNS に返答。
⑥ そのレスポンスに対してハッシュ計算を行う。
⑦ f5jp.com 権威 DNS の公開鍵を使って、署名を複合化する。
⑧ この⑥と⑦の値を比較。
⑨ 値が一致したので、正当なレスポンスであると判断し、キャッシュ。
⑩ 攻撃者から送られてくる DNS レスポンスは署名を持たない(もしくは署名が正しくない)ので、キャッシュしない。
(DNSSEC フローの Root DNS を含んだ全体的な流れについては、Appendix を参照ください。)
本章では、図でいうところの「権威 DNS」側の③～⑤の動作が可能となる設定を行います。
一方、図中の⑥～⑧の Local DNS (キャッシュ DNS)の動作を「DNSSEC Validation」といいます。
GTM を、この DNSSEC Validation が可能な Local DNS (キャッシュ DNS) として利用することも可能です。
GTM を Local DNS として利用する方法は、「DNS キャッシュ (DNSSEC Validation あり)」の章で説明します。
98
4.2. DNSSEC の設定
本ガイドでは、GSLB 設定で利用した「pub.f5jp.local」を DNSSEC 化することとします。
ただし、本ガイドの環境はラボ環境であるため、上位 DNS へ対しての DNSSEC 申請は実施できないので、その手前ま
での手順となります。
※ GTM は NTP 同期の設定が完了している必要があります。
4.3. Key Creation Server の指定
Syc-Group を構成した 2 台の GTM のうち、どちらが DNSSEC の Key を生成するかを指定します。
本ガイドでは、DC-A の GTM(DC-A-GTM01)で Key を生成することとします。
「DNS」→「Settings」→「Delivery」→「Keys」で表示された画面で、以下のように設定します。
/Common/DC-A-GTM01
99
4.4. KSK の生成
Key Signing key を生成します。
(1)
「DNS」→「Delivery」→「Keys」→「DNSSEC Key List」で表示された画面右上にある「Create」を押して表示された
画面で、以下のように設定します。
名前(任意)を指定。
Key Signing Key を選択。
期限などの値(任意)を入力。
(2)
以下のように、「Generations」に 1 が表示されれば、Key が生成できています。
(3)
Generations 列に表示されている数字をクリックして表示された画面で ID をクリックすると、公開鍵(Public Key) を
確認することができます。
100
4.5. ZSK の作成
Zone Signing Key を生成します。
(1)
「DNS」→「Delivery」→「Keys」→「DNSSEC Key List」で表示された画面右上にある「Create」を押して表示された
画面で、以下のように設定します。
名前(任意)を指定。
Zone Signing Key を選択。
2048 に変更。
期限などの値(任意)を入力。
(2)
以下のように、「Generations」に 1 が表示されれば、Key が生成できています。
(3)
Generations 列に表示されている数字をクリックして表示された画面で ID をクリックすると、公開鍵(Public Key) を
確認することができます。
101
4.6. GTM02 側への DNSSEC 鍵同期の不具合 (BugID：506282）
新しく生成した KSK/ZSK の鍵が、生成した直後には、Sync-Group 内の機器(big199)へ伝わりません。
以下のように、Generatios の値が 0 のままになります(v11.6.0 で発覚)。
以下に Workaround を示します。
(1)
big171 側で何らかの更新を実施することで、Sync-Group 内の機器(big199)へ伝わります。
ここでは、Rollver Period の Days を少し変更(1 日減)して Update してみます。
一日減らしてみる。
(2)
すると、big199 側に DNSSEC 鍵がコピーされます。
102
4.7. DNSSEC Zone の設定
生成した KSK、ZSK を使って、DNSSEC 用のゾーンを作ります。
本ガイドでは、GSLB 設定で使った pub.f5jp.local を DNSSEC ゾーンとします。
(1)
「DNS」→「Zones」→「DNSSEC Zones」→「DNSSEC Zone List」で表示された画面右上にある「Create」を押し、
現れた画面で、以下のように設定します。
DNSSEC を行うゾーン名を指定。
生成した DNSSEC 鍵を選択。
(2)
「DNS」→「Zones」→「DNSSEC Zones」→「DNSSEC Zone List」で表示された pub.f5jp.local をクリックして表示さ
れた画面で、「SEP Records」タブをクリックすることで、DNSKEY および DS レコードを確認できます。
DS Record 値が DNSKEY のハッシュ値です。これを親ゾーンに登録することで、信頼の連鎖を形成できます。
尚、DNSSEC 設定は 2 号機(big199)側には自動的に伝播されます。
103
4.8. 動作確認
クライアント PC から、dig を使って、DNSSEC レスポンスを確認します。
RRSIG (Resource Record Signature)が確認できれば、DNSSEC 動作確認は成功です。
例：
dig @10.99.111.171 secure.pub.f5jp.local +dnssec
RRSIG レコード。
104
5. DNS Express
DNS Express 機能によって、あらゆる DNS レコードの返答を高速化することができます。
DNS Express 機能が登場した背景として、まずお伝えしておくべきことがあります。
GSLB 設定で返答可能なレコードは、A レコードのみである、ということです。
よって V10.x までは、MX や NS などのレコード等を GTM から返答したい場合は、BIG-IP 内部の BIND または GTM
配下に設置した DNS サーバに DNS クエリを転送し、それらに返答してもらう、という形態のみをサポートしておりました。
この形態は、A レコード以外の DNS 応答処理は、内部 BIND または外部 DNS の能力に依存するため、高速化するに
は、外部 DNS を多数設置してロードバランシングする形態をとる必要があります。
そこで、V11.x からは、以下の動作が可能となりました。
GTM が DNS のスレーブとして動作する。
このことで、事前に内部 BIND または GTM 配下の DNS サーバからゾーン転送を受けることができる。
その結果、GTM が MX や NS レコードを高速に転送することができる。
この機能が「DNS Express」です。
このことによって、MX や NS などを管理する内部 BIND または外部 DNS の処理能力に依存することなく、高速な DNS
応答が可能になりました。
本セクションでは、例として以下の設定を行ってみます。
① BIG-IP の内部 BIND に MX レコードを設定
② GTM が内部 BIND からゾーン転送で MX レコードを受け取る
③ GTM が内部 BIND から受けた MX レコードを(高速に)返答する
BIG-IP の内部 BIND の設定用に「Zone Runner」という GUI が提供されていますので、それを利用して設定します。
105
5.1. ZoneRunner による内部 BIND の設定
MX レコード用の A レコードの設定
まず、BIG-IP 内部 BIND 内に、MX レコードとともに返答する A レコードを作ります。
本ガイドでは、10.99.111.111 の A レコードをダミーとして設定してみます。
(本ガイドのネットワーク図中に、そのアドレスを持つ実体は存在していません。)
(1)
(2)
「DNS」→「Zones」→「ZoneRunner」→「Resource Record List」で表示された画面にある「Create」ボタンを押しま
す。
表示された画面で、以下のように設定します。
Name で指定する FQDN は、末尾に”.”が必要です。
ゾーンを選択。
MX 用 A レコードの FQDN を指定。
TTL を指定。
レコードタイプ(A)を選択。
IP アドレスを指定。
106
MX レコードの設定
次に上記の A レコードと同様の方法で、MX レコードを設定します。
(1)
以下のように設定します。
※Name および Mail Server で指定する FQDN には、末尾に”.”が必要です。
ゾーンを選択。
MX 用 A レコードの FQDN を指定。
TTL を指定。
レコードタイプ(MX)を選択。
Preference を指定。
設定済み A レコードを指定。
(2)
内部 BIND に設定されたレコードの確認方法を示します。
Resource Record List で、MX レコードを確認してみます。
以下のように条件を指定して、「Search」ボタンを押します。
ゾーンを指定。
レコードタイプ(MX)を指定。
107
5.2. Nameserver の設定
BIG-IP 内部の BIND から GTM にゾーン転送するための設定を示します。
(ここからの手順は Sync Group 間で同期されないので、big199 でも設定が必要です。)
「DNS」→「Delivery」→「Nameservers」→「Nameserver List」で表示された画面にある「Create」ボタンを押して表示さ
れた画面で、以下のように設定します。
名前(任意)を指定。
108
5.3. Zone の設定
内部 BIND からゾーン転送を受け取るための設定を行います。
(1)
「DNS」→「Zones」→「Zones」→「Zone List」表示された画面右上にある「Create」ボタンを押して表れた画面で、以
下のように設定します。
DNS Epress 化するゾーン名を指定。
設定した Nameserver を選択。
(2)
もう一度同じ開いて、以下のように Availability がグリーンであれば、ゾーン転送が正しく行われています。
また現在は、「AXFR (Asynchronous xfer)」であることも覚えておいてください。
109
5.4. 動作確認
DNS Express が正しく動作しているかを確認します。
(1)
クライアント PC から、MX レコードの DNS クエリを数回発行します。
dig @10.99.111.171 mail.pub.f5jp.local MX
以下のような DNS 応答が返ってきます。
MX レコードおよび
その A レコードの DNS 応答。
(2)
CLI の tmsh から、以下コマンドにて、DNS Express による応答であることを確認します。
root@(big171)(cfg-sync Standalone)(Active)(/Common)(tmos)# show ltm dns zone pub.f5jp.local
------------------------------------------Ltm::DNS Zone: pub.f5jp.local
------------------------------------------DNS-Express
Status
Availability : available
State
: enabled
Reason
: Successful AXFR.
Queries
Responses
Notifies Received
XFR Messages To Client
SOA Attributes
Serial
:
Refresh
:
Retry
:
Expire
:
5
5
0
0
2014112513
10800
3600
604800
～省略～
110
5.5. IXFR への変更
AXFR によるゾーン転送では、ゾーンデータの内容が 1 レコードだけ変更された場合でも、ゾーンデータ全体を転送する
ようになっています。よって、ゾーンデータが大きくなると、更新が発生する度にネットワークに負荷がかかります。
よって、変更があった箇所の差分だけの転送を行う、IXFR(Incrememtal xfer)に変更する方法を示します。
(1)
「DNS」→「Zones」→「ZoneRunner」→「Zone List」で表示された該当ゾーン(pub.f5jp.local.)をクリックして表示さ
れた画面で、以下のように変更します。
以下を先頭に追加。
also-notify {
::1 port 5353;
};
［参考］ CLI からも同様の変更ができます。CLI の場合は Named.conf を編集します。
# vi /var/named/config/named.conf
～略～
view "external" {
match-clients {
"zrd-acl-000-000";
any;
};
zone "pub.f5jp.local." {
type master;
file "db.external.pub.f5jp.local.";
also-notify {
::1 port 5353;
};
allow-update {
localhost;
};
};
zone "111.99.10.in-addr.arpa." {
type master;
111
file "db.external.111.99.10.in-addr.arpa.";
allow-update {
localhost;
};
};
};
～略～
(2)
IXFR に変更されたことを確認します。
「DNS」→「Zones」→「Zone List」で表示された該当ゾーン(pub.f5jp.local)をクリックします。
以下のように、「Successful IXFR」になっていれば、OK です。
112
5.6. 動作確認
ZoneRunner の変更が反映されるかを確認します。
(1)
ZoneRunner で A レコードを書換え
「DNS」→「Zones」→「ZoneRunner」→「Resource Record List」で表示された画面で、該当ゾーン(pub.f5jplocal.)を
「Search」ボタンを押してサーチします。
「dummy111.pub.f5jp.local」をクリックします。
External を選択。
Pub.f5jp.local を選択。
例えば、IP アドレスの 3 オクテット目を 111→0 に変えて、10.99.0.111 にします。
(2)
クライアント PC で、管理者権限でコマンドプロンプトを起動します。
(3)
クライアント PC で、以下のコマンドで DNS キャッシュをフラッシュします。
ipconfig
/flushdns
113
(4)
クライアント PC から、MX レコードの DNS クエリを数回発行します。
dig @10.99.111.171 mail.pub.f5jp.local MX
以下のように、変更後の IP アドレスが返答されます。
変更後の IP アドレスの返答。
114
6. DNS キャッシュ (DNSSEC Validation あり)
GTM を、DNS キャッシュサーバ (Local DNS) として動作させることも可能です。
本ガイドでは、DNSSEC Validation(DNSSEC の評価)が出来る機能を有効にした DNS キャッシュ設定とします。
(この設定は、2 号機(big199)へはコピーされないので、個別に設定が必要です。)
6.1. Cache サーバの設定
(1)
「DNS」→「Caches」→「Cache List」で表示された画面右上にある「Create」ボタンを押すことで表示された画面で、
以下のように設定します。
名前(任意)を指定。
Validating Resolver を選択。
115
6.2. DNS profile の設定
DNS Cache を有効にするためには、DNS Profile 設定の変更が必要です。
本ガイドでは、デフォルトの DNS Profile 設定を変更するのではなく、新しく DNS Profile を生成する手順としています。
「DNS」→「Delivery」→「Profiles」→「DNS」で表示された画面の右上にある「Create」ボタンを押して現れた画面で、以
下のように設定します。
名前(任意)を指定。
右にチェックを入れ、Enabled を選択。
116
6.3. Listener の設定変更
追加した DNS Profile を Listener に割当てます。
「DNS」→「Delivery」→「Listeners」→「Listener List」で表示された画面で、設定済みの Listener(Listener-171)をクリッ
クし、現れた画面で、以下のように設定変更します。
設定した DNS Profile を選択。
117
6.4. DLV アンカーの設定
DNSSEC は信頼の連鎖で形成されているので、ルートゾーンの鍵を保持していれば、DNSSEC Validation は可能、と
いう仕組みになっています。(Appendix：DNSSEC フロー詳細を参照)
しかし、DNSEC の普及が進んでいない状況において、DNSSEC 対応ゾーンを増やすための暫定的な仕組みとして、
ISC(Internet Systems Consortium)が、DNSSEC Lookaside Validation(DLV) という技術を提唱しています。
詳細は、「https://dlv.isc.org/」を参照ください。
この方式に対応できるよう、Cache に DLV アンカーを設定します。
設定
(1)
以下 URL から、DLV アンカーを取得します。
http://ftp.isc.org/www/dlv/dlv.isc.org.key
(2)
取得した DLV アンカーを、BIG-IP に入力します。
「DNS」→「Caches」→「Cache List」で表示された、作成済みの Cache 名をクリックして表示された画面で、「DLV
Anchors」タブをクリックします。
その画面右上の「Add」ボタンを押して、取得した DLV アンカーを入力します。
DLV アンカーを入力。
(3)
以下のような状態になります。
118
動作確認
(1)
クライアント PC から、「www.isc.org」の DNSEC Validation が出来ることを確認します。
dig @10.99.111.171 www.isc.org +dnssec
以下のように、flags に「ad」が存在すれば、Validation できている、と判断できます。
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> @10.99.111.71 www.isc.org +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41651
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 13
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.isc.org.
IN
A
;; ANSWER SECTION:
www.isc.org.
60
IN
A
149.20.64.69
www.isc.org.
60
IN
RRSIG
A 5 3 60 20141127002325 20141028002325 4521 isc.org.
hyluCkUkt0501ctXoUhnw0cdXk/oem6du38bwxBA3ud33l3BKWpeiPQq Aq8f2tr2DshDKGmio32ZuPbl/8VCI6UNrrs5QEtLsW3VK8bmbYBtw1DT
AUbROtA0+zpIpEBLITusNjxAqsBr+lpMAy4RqMjtnWVi79KvH5UwhxlB pHM=
～省略～
(2)
同様に DLV アンカーしか設定していない状態で、「www.jprs.jp」を確認してみます。
「www.jprs.jp」は DLV に対応していないドメインなので、「ad」フラグが存在しません。
dig @10.99.111.171 www.jprs.jp +dnssec
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> @10.99.111.71 www.jprs.jp +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64445
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 5, ADDITIONAL: 16
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.jprs.jp.
IN
A
;; ANSWER SECTION:
www.jprs.jp.
86400
IN
A
202.11.16.167
www.jprs.jp.
86400
IN
RRSIG
A 8 3 86400 20141124023020 20141025023020 606 jprs.jp.
G7PiGjwtriIh/xrTIiQ19LSYAibx9rcc7WxHMC79ZeTciWNdoAD8ohER yNuf+KEFuSK252blxno7zc202NSOjxfegqxI6YJO7lvv9FVME0RebvVd
Z94yJ9gQwHSg5BUkBbuP+EGs050XXk0QdTmhZOxHglhGH4c5UyIFpdjs GNs=
www.jprs.jp.
86400
IN
RRSIG
A 8 3 86400 20141124023020 20141025023020 18099 jprs.jp.
raO/aM2e+2Jo98pUC9JFy52edjSb65ZquIakH71IE8e42QoxAEL1MNV2 D3pBINamolvGKT4K6MZP+iVcyTx6KZAZxYXTl1czfYxxkJeA7zinDIYk
ciybyGQLTobw2I3K3Y9SPdWw8RQvEcyQmqxV1RuylJBxNJqsCmjyCPRG l2g=
～省略～
119
6.5. Trust アンカーの設定
Root DNS から取得した、Trust アンカーを取得する方法を示します。
設定
(1)
以下の dig コマンドを実行して、Trust アンカーを取得します。
「DNSKEY 257」のレコードが Trust アンカーになります。
# dig . dnskey
～省略～
;; ANSWER SECTION:
.
20438
IN
DNSKEY 257 3 8
AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF…….
～省略～
(2)
実際には、OpenPGP などを用いて、この取得した Trust アンカーが正しいかどうかの評価を実施することが推奨さ
れますが、本ガイドではそのステップは省略します。
(3)
取得した Trust アンカーを BIG-IP に入力します。
「DNS」→「Caches」→「Cache List」で表示された、作成済みの Cache 名をクリックして表示された画面で、「Trust
Anchors」タブをクリックします。
その画面右上の「Add」ボタンを押して、取得した Trust アンカーを入力します。
Trust アンカーを入力。
(4)
以下のような状態になります。
120
動作確認
(1)
DNS キャッシュが残っていると、キャッシュから返答されるので、一時的にキャッシュを削除します。
CLI から以下のコマンドを実行します。
# tmsh
キャッシュの削除
# delete ltm dns cache records rrset cache ValResolver-001
# delete ltm dns cache records key cache ValResolver-001
キャッシュがなくなったことを確認
# show ltm dns cache records key cache ValResolver-001
# show ltm dns cache records rrset cache ValResolver-001
(2)
今度は、「www.jprs.jp」も、flags に「ad」が確認できる＝Validation できていることがわかります。
dig @10.99.111.171 www.jprs.jp +dnssec
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> @10.99.111.71 www.jprs.jp +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4303
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 5, ADDITIONAL: 16
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.jprs.jp.
IN
A
;; ANSWER SECTION:
www.jprs.jp.
86400
IN
A
202.11.16.167
www.jprs.jp.
86400
IN
RRSIG
A 8 3 86400 20141124023020 20141025023020 606 jprs.jp.
G7PiGjwtriIh/xrTIiQ19LSYAibx9rcc7WxHMC79ZeTciWNdoAD8ohER yNuf+KEFuSK252blxno7zc202NSOjxfegqxI6YJO7lvv9FVME0RebvVd
Z94yJ9gQwHSg5BUkBbuP+EGs050XXk0QdTmhZOxHglhGH4c5UyIFpdjs GNs=
www.jprs.jp.
86400
IN
RRSIG
A 8 3 86400 20141124023020 20141025023020 18099 jprs.jp.
raO/aM2e+2Jo98pUC9JFy52edjSb65ZquIakH71IE8e42QoxAEL1MNV2 D3pBINamolvGKT4K6MZP+iVcyTx6KZAZxYXTl1czfYxxkJeA7zinDIYk
ciybyGQLTobw2I3K3Y9SPdWw8RQvEcyQmqxV1RuylJBxNJqsCmjyCPRG l2g=
～省略～
以上で DNS キャッシュ設定は終了です。
121
7. おわりに
基本的な GTM セットアップに関しては以上で終了となります。
BIG-IP シリーズ製品ラインナップにおいては、ソフトウェアモジュールライセンスを追加することで、サーバ負荷分散はも
ちろんのこと、リモートアクセス機能、ネットワークファイアウォール機能、Web アプリケーションファイアウォール機能など、
アプリケーションアクセスを最適化する為の多彩な機能が使用できるようになります。
詳細は各種 WEB サイトにてご確認いただくか、購入元にお問い合わせください。
＜F5 ネットワークス WEB サイトの紹介＞
F5 ネットワークスジャパン総合サイト
http://www.f5networks.co.jp/
F5 Tech Depot：エンジニア向け製品関連情報サイト
http://www.f5networks.co.jp/depot/
AskF5：ナレッジベース総合サイト（英語）
http://support.f5.com/kb/en-us.html
DevCentral：F5 ユーザコミュニティサイト（英語：アカウント登録が必要です）
https://devcentral.f5.com/
以上
122
8. Appendix
8.1. GTM の全ロードバランシング方式一覧
以下に、GTM が持つ全ロードバランシング方式と、その解説を記載します。
W：Wide-IP レベル
Pool レベル
P：Preferred
A：Alternate
F：Fallback
Static
Or
Dynamic
Static
LB 方式
W
P
A
F
解説
1
Round Robin
1
1
1
1
Static
2
Ratio
1
1
1
1
Static
3
Topology
1
1
1
1
Static
4
Global Availability
1
1
1
1
Static
5
Static Persist
1
1
1
Static
6
VS Capacity
1
1
1
Dynamic
7
Packet Rate
1
1
1
Dynamic
8
VS Score
1
1
1
Dynamic
9
Least Connections
1
0
1
Dynamic
10
Round Trip Time
1
0
1
Dynamic
11
Hops
1
0
1
Dynamic
Dynamic
12
13
CPU
Completion Rate
1
1
0
0
1
1
Dynamic
14
Quality of Service
1
0
1
Dynamic
15
Kilobytes/Second
1
0
1
Pool 内の Member (= Virtual Server) の IP アドレスを 1 つ
ずつ順番にローテーションして返答する。
重み付けラウンドロビン。
ユーザーが各リソースに割当てたプライオリティレベルまたは
ウェイトにしたがって、ローテーションして返答。
「Topology」の設定にて、トポロジーデータベースを追加するこ
とによって、IP アドレス返答を制御または限定できる。
この設定を使って、近隣へ誘導するロードバランスを展開でき
る。
例えば、特定地域のクライアントのリクエストは、同じ地域のデ
ータセンターまたはサーバに誘導することができる。
Pool にリストされている Member (＝Virtual Server)の、一番
上の Member の IP アドレスを返答する。
その Virtual Server が Full 状態か、または利用できない時だ
け、リストの中の次の Member を返答する。
Local DNS の送信元 IP アドレスで、Pool Member (＝Virtual
Server) にパーシストする。 その Local DNS は同じ Pool
Member の IP アドレスの返答をもらうことになる。
Virtual Server の中で、最も UP している Pool Member の多
いものを選択する。
例えば、LTM の VS1 では 21 個の Pool Member が Up,
VS2 では 20 個の Pool Member が Up している状態におい
ては、常に VS1 が選択される。
2 つの Virtual Server が同じ結果の場合、GTM は、その 2 つ
の IP をランダムに返答する。
トラフィック量：Packets/Sec の数が最も少ない Virtual Server
を選択する。
ユーザーが定義した、LTM の Virtual Server のランキングに
応じて IP アドレスを返答する。
Virtual Server Score は LTM の場合にだけ利用できる。
VS Score 値は、LTM の Virtual Server で設定する。
LTM 上の Virtual Server で、最もコネクション数の少ない
Virtual Server の IP アドレスを返答する。本機能は、LTM の
場合だけに利用できる。
クライアント LDNS とデータセンター間のラウンドトリップタイム
が最も速い Virtual Server を選択する。
Traceroute を使って、クライアント LDNS とそれぞれのデータ
センター間の中間システム(ルータのホップ)数をトラックする。
ホップ数が最も少ない Virtual Server を選択する。
CPU 処理時間が最も余裕のある Virtual Server を選択する。
データセンターと Local DNS の間のトランザクションで、パケッ
トドロップ数または、タイムアウトしたパケット数が最少である
Virtual Server を選択する。
現在のパフォーマンス値から計算し、各 Virtual Server に割当
てられたスコアをベースに、Virtual Server を選択する。
トラフィック量：KB/sec の数が最も少ない Virtual Server を選
123
Static
16
Drop Packet
1
1
1
Static
17
Fallback IP
1
1
1
Static
Static
18
19
Return to DNS
None
1
0
1
1
1
1
択する。
GTM が、Kilobyte/Second の情報取得が可能な Virtual
Server の場合のみ有効。
何もせず、単に、要求を落とす。
DNS レスポンスを提供したくない場合に利用。
クエリに対する応答として、Fallback IP として指定した IP アド
レスを返す。 指定した IP アドレスはヘルスモニターされない。
Preferred および Alternate で指定したロードバランシングモー
ドが有効な Virtual Serer を返えすことができないときに、DR
サイトの IP を指定することで、DR サイトへ誘導できる。
即座に、Local DNS へ DNS 要求を転送する。
一時的に、GTM Pool からの IP アドレス返答を止めたい場合
に有効。
現在のロードバランシングメソッド(Alternative または
Fallback)をスキップするモード。
124
8.2. GSLB 動作ログ出力の設定方法
GSLB の動作確認の際に、GTM がなぜ、その Pool/Pool Member が選択したのかの詳細ログを出力する方法を示しま
す。
この設定が、トラブルシューティングの助けになることがあります。
ログを外部に出力することもできますが、ここでは BIG-IP 内部へ出力する設定を示します。
(1)
「System」→「Logs」→「Configuration」→「Log Publishers」で表示された画面の右上にある「Create」ボタンを押
し、現れた画面で以下のように設定します。
名前(任意)を指定。
Local-syslog を選択し、「<<」を押す。
(2)
「DNS」→「Delivery」→「Profiles」→「Other」→「DNS Logging」で表示された画面の右上にある「Create」ボタンを
押し、現れた画面で以下のように設定します。
名前(任意)を指定。
設定した Log Publisher を選択。
チェックを入れる。
125
(3)
「DNS」→「Delivery」→「Profiles」→「DNS」で表示された画面の右上にある「Create」ボタンを押して新たに DNS
Profile を作る、または既に割り当て済みの Profile をクリックして現れた画面で以下のように設定します。
Logging にチェックをいれ、→
設定した Logging Profile を選択。
126
(4)
「DNS」→「Delivery」→「Listeners」→「Listener List」で表示された、設定済みの Listener を開き、以下のように設
定変更します。
設定した DNS Profile を選択。
(5)
「DNS」→「GSLB」→「Wide IPs」→「Wide IP List」で表示された、設定済みの Listener を開き、以下のように設定
変更します。
ログ取得したい項目のチェックを入れる。
127
(6)
ログは CLI で確認します。
① SSH で GTM へログイン。
② /var/log/ltm (※gtm ではありません)を、tail で確認。
tail -f /var/log/ltm
③ クライアントから、DNS 問合せを実施。
例)
dig @10.99.111.171 web.pub.f5jp.local
④ 以下のようなログが出ます。
Jan 9 10:38:21 localhost info tmm[10478]: 2015-01-09 10:38:20 big171.f5jp.local from 10.99.4.19#56473: view
none: query: web.pub.f5jp.local IN A +E (10.99.111.171%0)
Jan 9 10:38:21 localhost info tmm[10478]: 2015-01-09 10:38:20 big171.f5jp.local from 10.99.4.19#56473
[web.pub.f5jp.local A] [round robin selected pool (web-pool)] [pool member check succeeded (web-89vs:10.99.111.89) - pool member state is available (green)] [QoS selected pool member (web-89-vs:10.99.111.89) QoS score (0) is higher] [pool member check succeeded (web-90-vs:10.99.111.90) - pool member state is available
(green)] [QoS skipped pool member (web-90-vs:10.99.111.90) from two pool members with equal scores] [pool member
check succeeded (web-99-vs:10.99.1.99) - pool member state is available (green)] [QoS skipped pool member (web99-vs:10.99.1.99) from two pool members with equal scores] [QoS selected pool member (web-89-vs:10.99.111.89)]
Jan 9 10:38:21 localhost info tmm[10478]: 2015-01-09 10:38:20 big171.f5jp.local to 10.99.4.19#56473: [NOERROR
qr,aa,rd,ad] response: web.pub.f5jp.local. 5 IN A 10.99.111.89;
128
8.3. 「f5jp.local」の BIND 設定
「pub.f5jp.local」の親ゾーンを管理する「f5jp.local」の BIND の設定です。
(1)
named.conf
[root@PEOLD-Cent-229 ~]# less /etc/named.conf
//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//
options {
listen-on port 53 { 10.99.4.229; 10.99.88.229; 127.0.0.1; };
//listen-on-v6 port 53 { ::1; };
directory
"/var/named";
dump-file
"/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
allow-query
{ localhost; 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; };
recursion yes;
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside no;
empty-zones-enable no;
/* Path to ISC DLV key */
bindkeys-file "/etc/named.iscdlv.key";
managed-keys-directory "/var/named/dynamic";
};
logging {
channel default_debug {
file "named.run";
severity dynamic;
};
};
zone "." IN {
type hint;
file "named.ca";
};
//include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";
include "/etc/f5jp.local.zone";
trusted-keys {
"."
257 3 8
"AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0=";
};
129
(2)
f5jp.local.zone
[root@PEOLD-Cent-229 etc]# pwd
/var/named/chroot/etc
[root@PEOLD-Cent-229 etc]# ls -l
total 36
-rw-r--r-- 1 named named
88 Jul
-rw-r--r-- 1 root root
331 May
drwxr-x--- 2 root named 4096 Jan
-rw-r----- 1 root named 1523 Oct
-rw-r--r-- 1 root named 2389 Jan
-rw-r----- 1 root named 931 Jun
-rw-r--r-- 1 root named 487 Jul
drwxr-x--- 3 root named 4096 Jul
-rw-r----- 1 root named
77 Jul
[root@PEOLD-Cent-229 etc]#
11
23
21
9
21
21
19
11
11
13:58
2012
2014
13:02
2014
2007
2010
13:33
14:12
f5jp.local.zone
localtime
named
named.conf
named.iscdlv.key
named.rfc1912.zones
named.root.key
pki
rndc.key
[root@PEOLD-Cent-229 etc]# less f5jp.local.zone
zone "f5jp.local" IN {
type master;
file "f5jp.local.db";
allow-update{ none; };
};
(3)
f5jp.local.db
[root@PEOLD-Cent-229 named]# pwd
/var/named/chroot/var/named
[root@PEOLD-Cent-229 named]# ls -l
total 22780
drwxr-xr-x 2 named root
4096 Jul
drwxrwx--- 2 named named
4096 Oct
-rwxr-xr-x 1 named named
599 Oct
-rwxr-xr-x 1 named root
1631 Jul
-rw-r--r-- 1 named named
205008 Oct
-rw-r--r-- 1 root root 22250468 May
-rw-r--r-- 1 root root
840296 Jul
11
3
9
11
9
21
11
14:11
14:32
13:00
13:47
13:02
13:52
15:36
data
dynamic
f5jp.local.db
named.ca
named.run
webmin-1.690-1.noarch.rpm
webmin-1.690-1.noarch.rpm.1
[root@PEOLD-Cent-229 named]# less f5jp.local.db
$TTL
86400
$ORIGIN f5jp.local.
$INCLUDE "/root/dnssec-key/Kf5jp.local.+005+31396.key"
$INCLUDE "/root/dnssec-key/Kf5jp.local.+005+41007.key"
@
IN
SOA
ns1.f5jp.local.
2013042703
28800
14400
3600000
86400 )
ns1
big171
big189
big190
big199
gen161
gen162
pub
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
NS
MX
A
A
A
A
A
A
A
NS
root.f5jp.local.(
; Serial
; Refresh
; Retry
; Expire
; Minimum
ns1.f5jp.local.
10 mail.f5jp.local.
10.99.4.229
10.99.88.171
10.99.88.189
10.99.88.190
10.99.88.199
10.99.111.161
10.99.1.162
GTM01.f5jp.local.
130
pub
GTM01
GTM02
corp
win2k8-001
mail
(4)
IN
IN
IN
IN
IN
IN
NS
A
A
NS
A
A
GTM02.f5jp.local.
10.99.111.171
10.99.1.199
win2k8-001.f5jp.local.
10.99.88.218
10.99.2.221
BIND の Version
[root@PEOLD-Cent-229 named]# rpm -qa | grep bind
bind-9.8.2-0.23.rc1.el6_5.1.x86_64
rpcbind-0.2.0-11.el6.x86_64
samba-winbind-clients-3.6.9-167.el6_5.x86_64
ypbind-1.20.4-30.el6.x86_64
bind-libs-9.8.2-0.23.rc1.el6_5.1.x86_64
PackageKit-device-rebind-0.5.8-21.el6.x86_64
samba-winbind-3.6.9-167.el6_5.x86_64
bind-utils-9.8.2-0.23.rc1.el6_5.1.x86_64
bind-chroot-9.8.2-0.23.rc1.el6_5.1.x86_64
[root@PEOLD-Cent-229 named]#
(5)
DNSSEC 用の設定
以下の設定で、f5jp.local.db に DNSSEC 署名が行われます。
[root@PEOLD-Cent-229 dnssec-key]# pwd
/root/dnssec-key
[root@PEOLD-Cent-229 dnssec-key]# ls
dsset-f5jp.local.
Kf5jp.local.+005+31396.private Kf5jp.local.+005+41007.private
Kf5jp.local.+005+31396.key Kf5jp.local.+005+41007.key
[root@PEOLD-Cent-229 dnssec-key]# dnssec-signzone -o f5jp.local /var/named/chroot/var/named/f5jp.local.db
8.4. General host の SNMP 設定
本ガイドで利用した汎用サーバの SNMP 設定です。
[root@PEOLD-Cent-161 ~]# cat /etc/snmp/snmpd.conf
↓以下の行の設定変更を実施したのみです。
# Make at least snmpwalk -v 1 localhost -c public system fast again.
#
name
incl/excl
subtree
mask(optional)
#view
systemview
included
.1.3.6.1.2.1.1
#view
systemview
included
.1.3.6.1.2.1.25.1.1
view
systemview
included
.1
131
8.5. DNSSEC フロー詳細
DNSSEC 環境において、Local DNS が「web.f5jp.com」の問合せを行い、IP アドレスを得るまでのフローです。
132
上図は、DNSSEC の「信頼の連鎖」により、Local DNS に事前に Trust Anchor を登録しておくだけで、再帰的問い合わ
せのタイミングそれぞれにおいても DNSSEC Validation を行いながら最終的に IP アドレスを得ることができる、という流れ
を示しています。
＜＜各権威 DNS(Root［.］，［.com］, ［f5jp.local］)の事前準備＞＞
(1)
(2)
(3)
(4)
(5)
(6)
KSK 公開鍵と秘密鍵のペアを作る。
ZSK 公開鍵と秘密鍵のペアを作る。
ZSK 公開鍵のハッシュ計算を行う。
(3)のハッシュ値を、自身の KSK 秘密鍵で暗号化する。
リソースレコード(RR)のハッシュ計算を行う。
(5)のハッシュ値を、自身の ZSK 秘密鍵で暗号化する。
＜＜(［.com］, ［f5jp.local］)の権威 DNS の事前準備＞＞
(7)
自身の KSK 公開鍵のハッシュを計算。それを DS(Delegation Signer)値として、親の権威 DNS へ送付。
＜＜(Root［.］, ［.com］)の権威 DNS の事前準備＞＞
(8)
親となる権威 DNS は、自身の ZSK 秘密鍵で、(7)で受け取った DS を暗号化する。
＜＜Local DNS の事前準備＞＞
(9)
Local DNS は、Root[.]の KSK 公開鍵を、「Trust Anchor」として、事前に所有しておく。
＜＜Local DNS による再帰問合せ＞＞
(10)
(11)
(12)
(13)
(14)
(15)
(16)
(17)
(18)
(19)
Root［.］に対して、［.com］の権威 DNS の IP アドレスを問い合わせる。
Root[.]から、［.com］の DNS レスポンスを得る。
(11)の DNSKEY レコードの中から、ZSK 公開鍵を取り出し、ハッシュ計算を行う。
(11)の DNSKEY レコードの電子署名を、Trust Anchor (Root[.]の KSK 公開鍵) で複合化する。
(12)と(13)が一致すれば、Root[.]の ZSK 公開鍵の検証は完了。
(11)のリソースレコードのハッシュ計算を行う。
(11)のリソースレコードの電子署名を、Root［.］の ZSK 公開鍵で複合化する。
(15)と(16)が一致すれば、リソースレコードの検証は完了。
(11)の DS レコードを複合化して、値を取り出す。
［.com］に対して、［f5.com］の権威 DNS の IP アドレスを問い合わせる。
(20) ～ (39) まで、類似の動作が繰り返される。
最終的に(39)で「web.f5jp.com」のリソースレコードを検証することで、正当な権威 DNS から得たレコードであることが確
認でき、「web.f5jp.com」の IP アドレスを取得できます。
F5 ネットワークスジャパン株式会社
〒107-0052 東京都港区赤坂 4-15-1 赤坂ガーデンシティ 19 階
本資料は F5 ネットワークスジャパンのエンジニアが特定のソフトウェアバージョンの動作仕様に基づいて作成した構築・設計を補助するための資料であり、メーカー公式資料とは異なります。資料の記載内
容に誤りがあった際には指摘に基づいて修正を行いますが、内容についての責任は一切負いません。また、修正、変更、改訂は予告無く行われます。
133