Comments
Description
Transcript
ClusterXL NGX（R60A）
ClusterXL NGX（R60A） 重要 チェック・ポイントでは、常に最新のホット・フィックスやサービス・ パックを適用することをお勧めします。これらのアップデートには、日々進化する 脅威や攻撃手法に対処するための重要な機能拡張が含まれています。 本書に記載されていない技術的な情報については、以下の SecureKnowledge を参照してください。 https://secureknowledge.checkpoint.com 本書の最新版については、以下の Web サイトを参照してください。 http://www.checkpoint.com/support/technical/documents/docs_r60a.html Part No.: 701869 2005 年 9 月 © 2003-2006 Check Point Software Technologies Ltd. All rights reserved. 本製品および関連ドキュメントは著作権法によって保護され ており、その使用、複写、逆コンパイルを制限するライセンス契約に基づいて配 布されています。本製品または関連ドキュメントのいかなる部分も、チェック・ ポイントの書面による事前承諾を得ない限り、いかなる形態や方法によっても複 製することはできません。本マニュアルを製作するにあたっては細心の注意が払 われていますが、チェック・ポイントはいかなる誤りまたは欠落に対しても一切 責任を負いません。本マニュアルおよびその記述内容は、予告なく変更される場 合があります。 権利の制限 米国政府による本製品の使用、複写、または開示は、DFARS（連邦国防調達規定） 252.227 7013 および FAR（連邦調達規定）52.227-19 の技術データおよびコン ピュータ・ソフトウェアに関する権利条項（c）（1）（ii）により制限されます。 商標 © 2003-2005 Check Point Software Technologies Ltd. All rights reserved. Check Point、Application Intelligence、Check Point Express、Check Point の ロゴ、AlertAdvisor、ClusterXL、Cooperative Enforcement、ConnectControl、 Connectra、CoSa、Cooperative Security Alliance、Eventia、Eventia Analyzer、 FireWall-1、FireWall-1 GX、FireWall-1 SecureServer、FloodGate-1、Hacker ID、 IMsecure、INSPECT、INSPECT XL、Integrity、InterSpect、IQ Engine、Open Security Extension、OPSEC、Policy Lifecycle Management、Provider-1、 Safe@Home、Safe@Office、SecureClient、SecureKnowledge、 SecurePlatform、SecuRemote、SecureXL Turbocard、SecureServer、 SecureUpdate、SecureXL、SiteManager-1、SmartCenter、SmartCenter Pro、 Smarter Security、SmartDashboard、SmartDefense、SmartLSM、SmartMap、 SmartUpdate、SmartView、SmartView Monitor、SmartView Reporter、 SmartView Status、SmartViewTracker、SofaWare、SSL Network Extender、 Stateful Clustering、TrueVector、Turbocard、UAM、User-to-Address Mapping、 UserAuthority、VPN-1、VPN-1 Accelerator Card、VPN-1 Edge、VPN-1 Pro、 VPN-1 SecureClient、VPN-1 SecuRemote、VPN-1 SecureServer、VPN-1 VSX、 VPN-1 XL、Web Intelligence、ZoneAlarm、ZoneAlarm Pro、Zone Labs、および Zone Labs のロゴは、チェック・ポイント・ソフトウェア・テクノロジーズまた はその関連会社の商標または登録商標です。本書に記載されているその他の製品 名は、各所有者の商標または商標登録です。本書に記載された製品は、米国の特 許 No. 5,606,668、5,835,726、6,496,935 および 6,850,943 によって保護されてい ます。また、その他の米国における特許およびその他の国における特許で保護さ れているか、出願中の可能性があります。 サード・パーティ Entrust は、米国およびその他の国における Entrust Technologies, Inc. の登録 商標です。Entrust のロゴ、Entrust の製品およびサービスの名称も Entrust Technologies, Inc. の登録商標です。Entrust Technologies Limited は、Entrust Technologies, Inc. の完全所有子会社です。FireWall-1 および SecuRemote には、 Entrust の証明書管理技術が採用されています。 Verisign は Verisign Inc. の商標です。 下記は、ソフトウェアのうちミシガン大学が著作権を所有する部分に関する記述 です。Portions of the software copyright © 1992-1996 Regents of the University of Michigan. All rights reserved. この表記が削除されることなく、かつ Ann Arbor のミシガン大学に正当な帰属承認が与えられる限り、ソース形式およびバイナリ 形式での再配布および使用は認められています。あらかじめミシガン大学から書 面による特定の承諾を得ない限り、本ソフトウェアに基づく製品の保証または販 売促進に大学名を使用することはできません。本ソフトウェアは、明示もしくは 黙示の保証なく、 「そのままの状態」で供給されます。Copyright © Sax Software （端末エミュレーションのみ） 下記は、ソフトウェアのうちカーネギー・メロン大学が著作権を所有する部分に 関する記述です。 Copyright 1997 by Carnegie Mellon University. All Rights Reserved. 本ソフトウェアおよび関連するドキュメントを何らかの目的のために無償で使用、 複製、変更および配布することは認められています。ただし、上記著作権表記が すべての複製物に記載され、その著作権表記およびこの許可表記が全関連ドキュ メントに記載され、かつ書面による特定の事前承諾なく本ソフトウェアの配布に 関する広告または宣伝にカーネギー・メロン大学の名称が使用されることのない 場合に限ります。カーネギー・メロン大学は、市場性および適合性の黙示保証を 含め、本ソフトウェアに関するすべての保証を拒否します。契約行為、過失また は不法行為にかかわらず、本ソフトウェアの使用または性能から、またはそれら に関連して生じる特定の、間接的なもしくは派生的な損害、または使用能力、 データ、利益の損失によるいかなる損害に対しても、カーネギー・メロン大学は 一切責任を負いません。 下記は、ソフトウェアのうち The Open Group が著作権を所有する部分に関する 記述です。 ソフトウェアは、市場性、特定目的への適合性、および非侵害の保証等を含めた 明示または黙示の保証なく、「そのままの状態」で供給されます。The Open Group は、契約行為、不法行為その他にかかわらず、ソフトウェアもしくはソフ トウェアの使用や取り扱いから、またはそれらに関連して生じる補償請求、損害 その他の賠償に対して一切責任を負いません。 下記は、ソフトウェアのうち OpenSSL Project が著作権を所有する部分に関する 記述です。本製品には、OpenSSL Toolkit で使用するために OpenSSL Project が 開発したソフトウェアが含まれています（http://www.openssl.org/） 。 本ソフトウェアは OpenSSL Project により「そのままの状態」で供給されます。 OpenSSL Project は、市場性および特定目的への適合性の黙示保証等を含め、 明示または黙示の保証をすべていたしません。本ソフトウェアを使用した結果と して、直接的損害、間接的損害、付随的損害、特別損害、懲罰的損害、または派 生的損害（代替品もしくは代替サービスの調達、使用能力、データもしくは利益の 損失、または事業の中断を含みますが、それらに限定されません）が発生した場合 は、いかなる原因で生じたとしても、またいかなる責任論上においても、契約行 為、無過失責任または不法行為（怠慢その他を含め）によるものかを問わず、 たとえ当該損害が発生する可能性を事前に通知されていたとしても、OpenSSL Project またはそれに対する寄稿者は、いかなる場合も一切の責任を負いません。 下記は、ソフトウェアのうち Eric Young が著作権を所有する部分に関する記述 です。本ソフトウェアは Eric Young により「そのままの状態」で供給されます。 Eric Young は、市場性および特定目的への適合性の黙示保証等を含め、明示また は黙示の保証をすべていたしません。本ソフトウェアを使用した結果として、直 接的損害、間接的損害、付随的損害、特別損害、懲罰的損害、または派生的損害 （代替品もしくは代替サービスの調達、使用能力、データもしくは利益の損失、 または事業の中断を含みますが、それらに限定されません）が発生した場合は、 いかなる原因で生じたとしても、またいかなる責任論上においても、契約行為、 無過失責任または不法行為（怠慢その他を含め）によるものかを問わず、たとえ 当該損害が発生する可能性を事前に通知されていたとしても、著作者またはそれ に対する寄稿者は、いかなる場合も一切の責任を負いません。Copyright © 1998 The Open Group. 下記は、ソフトウェアのうち Jean-loup Gailly および Mark Adler が著作権を所有 する部分に関する記述です。Copyright (C) 1995-2002 Jean-loup Gailly and Mark Adler. 本ソフトウェアは、明示もしくは黙示の保証なく、「そのままの状態」で供 給されます。本ソフトウェアの使用から生じる損害に対して、著者は一切の責任 を負いません。本ソフトウェアを、商用アプリケーションを含め、何らかの目的 のために使用し、また自由に変更および再配布することは認められています。 ただし、その場合は以下の制限を条件とします。 1. 本ソフトウェアの出自について虚偽の表示をすることはできません。また、 自分がソフトウェアの原著作者であると主張することはできません。本ソフト ウェアを製品の一部として使用する場合、製品のドキュメントに謝辞を入れてい ただければ幸いですが、必須ではありません。 2. ソース・バージョンを変更した場合は、その旨を明示する必要があります。 また、オリジナルのソフトウェアであるという虚偽の表示をすることはできま せん。 3. この表示をソースの配布物から削除したり変更したりすることはできません。 下記は、ソフトウェアのうち Gnu Public License が著作権を所有する部分に関する 記述です。本プログラムはフリーソフトウェアです。Free Software Foundation が公表した GNU General Public License（GNU 一般公衆利用許諾契約書）のバー ジョン 2 または（任意で）それ以降のバージョンの条件に基づき、本ソフトウェア を再配布および / または変更することができます。本プログラムは実用に万全を期 して配布されていますが、市場性または特定目的への適合性の黙示保証を含め、 一切の保証を伴いません。詳細については、GNU General Public License をご参 照ください。本プログラムには、GNU General Public License のコピーが同梱さ れています。同梱されていない場合は、Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. までお問い合わせください。 下記は、ソフトウェアのうち Thai Open Source Software Center Ltd および Clark Cooper が著作権を所有する部分に関する記述です。Copyright (c) 2001, 2002 Expat maintainers. 本使用条件に従い、本ソフトウェアおよび関連するド キュメント・ファイル（以下「ソフトウェア」といいます）のコピーを入手する 人物に対して無償で、ソフトウェアのコピーの使用、複製、変更、統合、公表、 配布、サブライセンス発行、および / または販売などを含め、制限なくソフト ウェアを取り扱い、またソフトウェアを提供された人物にこれらを行うことを許 可することが認められています。ただし、その場合は以下の条件に従うものとし ます。上記著作権表記およびこの許可表記がソフトウェアのすべての複製物また は実質的に同様な部分に記載される必要があります。ソフトウェアは、市場性、 特定目的への適合性、および非侵害の保証等を含めた明示もしくは黙示の保証なく、 「そのままの状態」で供給されます。契約行為、不法行為その他にかかわらず、 ソフトウェアもしくはソフトウェアの使用や取り扱いから、またはそれらに関連 して生じる補償請求、損害その他の賠償に対し、著作者または著作権所有者は 一切責任を負いません。GDChart はお客様のアプリケーションで、またチャート 作成のために自由に使用できます。ただし、コードを自分のものとして再配布 または表明することはできません。コードを再配布する場合は、著者を表記し、 Check Point Software Technologies Ltd. 米国本社： 800 Bridge Parkway, Redwood City, CA 94065、電話： (650) 628-2000 ファックス： (650) 654-4233 [email protected] イスラエル本社： 3A Jabotinsky Street, Ramat Gan, 52520, Israel、電話： 972-3-753 4555 ファックス： 972-3-575 9256 http://www.checkpoint.com すべてのオリジナル・ドキュメントを含める必要があります。Copyright. Bruce Verderaime.1998, 1999, 2000, 2001. 部分的著作権1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002 by Cold Spring Harbor Laboratory. 米国国立衛生研究所に よる許可 P41-RR02188 に基づく資金供給を受けています。部分的著作権 1996, 1997, 1998, 1999, 2000, 2001, 2002 by Boutell.Com, Inc. GD2 フォーマットに関 する部分的著作権 1999, 2000, 2001, 2002 Philip Warner.PNG に関する部分的著 作権 1999, 2000, 2001, 2002 Greg Roelofs.gdttf.c に関する部分的著作権 1999, 2000, 2001, 2002 John Ellson ([email protected]).gdft.c に関する部分的著作権 2001, 2002 John Ellson ([email protected]).JPEG および color quantization に 関する部分的著作権 2000, 2001, 2002, Doug Becker and copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, Thomas G. Lane. 本ソフトウェ アの一部は Independent JPEG Group の著作物に基づいています。詳細について は、README-JPEG.TXT ファイルを参照してください。WBMP に関する部分的 著作権 2000, 2001, 2002 Maurice Szmurlo and Johan Van den Brande.gd を、商 用アプリケーションを含め、何らかの目的のために無償で複製、配布および変更 することは認められています。ただし、この表記がユーザのアクセスできる全関 連ドキュメントに記載されている場合に限ります。これはお客様の派生著作物自 体の所有権に影響を与えるものではありません。その目的はあくまでも gd の著者 の適切なクレジットを確保することであり、お客様による gd の生産的な利用を妨 げるためではありません。詳細についてはお問い合わせください。「派生著作物」 にはライブラリを利用したすべてのプログラムが含まれます。ユーザのアクセス できるドキュメントにはクレジットを表記する必要があります。本ソフトウェア は「そのままの状態」で供給されます。著作権所有者は、市場性および特定目的 への適合性の黙示保証等を含め、このコードおよび付属ドキュメントに関する明 示または黙示の保証をすべて行いません。gd 2.0.4 に記載されているコードはあ りませんが、著作者は David Koblas、David Rowley および Hutchison Avenue Software Corporation のこれまでの貢献に謝意を表します。 Apache License, Version 2.0（「本ライセンス」）に基づいてライセンスが許諾 されます。このファイルを使用するためには、本ライセンスに従う必要があり ます。本ライセンスのコピーは http://www.apache.org/licenses/LICENSE-2.0 から 入手できます。 curl license 著作権および許可表記 Copyright (c) 1996 - 2004, Daniel Stenberg, <[email protected]>. All rights reserved. 本ソフトウェアを、有償、無償にかかわらず、何らかの目的のために使用、複製、 変更および配布することは認められています。ただし、上記著作権表記および この許可表記がすべての複製物に記載される必要があります。 本ソフトウェアは、市場性、特定目的への適合性、およびサード・パーティの 権利の非侵害の保証等を含めた明示もしくは黙示の保証なく、「そのままの状態」 で供給されます。契約行為、不法行為その他にかかわらず、ソフトウェアもしくは ソフトウェアの使用や取り扱いから、またはそれらに関連して生じる補償請求、 損害その他の賠償に対し、著者または著作権所有者は一切責任を負いません。 この表記に含まれるものを除き、著作権所有者の書面による事前承諾なく、 本ソフトウェアの販売、使用、またはその他の取り引きを促進するための広告 その他のものに著作権所有者の名称を使用することはできません。 PHP License, version 3.0 Copyright (c) 1999 - 2004 The PHP Group. All rights reserved. ソース形式およびバイナリ形式での再配布および使用は、その改変の有無にかか わらず、認められています。ただし、その場合は以下の条件に従うものとします。 1. ソース・コードの再配布物には上記著作権表記、本条件一覧、および下記免責 条項を含める必要があります。 2. バイナリ形式で再配布する場合は、上記著作権表記、本条権一覧、および下記 免責条項を配布物と共に供給されるドキュメントおよび / またはその他の資料に 転載する必要があります。 3. 書面による事前許可を得ずに、本ソフトウェアから派生した製品の保証または 販売促進に「PHP」という名称を使用することはできません。書面による承諾に ついては、[email protected]. までお問い合わせください。 4. [email protected] からの書面による事前許可を得ずに、本ソフトウェアから派生 した製品を「PHP」と呼ぶことはできません。またそれらの名称に「PHP」と 記載することはできません。お客様のソフトウェアを「PHP Foo」または 「phpfoo」と呼ぶ代わりに「Foo for PHP」と記載することにより、そのソフト ウェアが PHP と連携して動作する旨を表すことができます。 5. PHP Group は随時、ライセンスの改訂バージョンおよび / または新しいバー ジョンを発行することがあります。各バージョンには、識別のためのバージョン 番号が割り当てられます。対象コードが特定のバージョンのライセンスに基づき 公開された後、お客様は常に当該バージョンの条件に従ってそれを引き続き使用 することができます。また、PHP Group が発行するそれ以降の任意のバージョンの ライセンスの条件に従って、当該対象コードを使用することもできます。本ライ センスに基づいて作成される対象コードに適用される条件を変更する権利は、 PHP Group のみが保持しています。 6. いかなる形式で再配布する場合も、次の文言を表示する必要があります。 「This product includes PHP, freely available from <http://www.php.net/>」 本ソフトウェアは PHP Development Team により「そのままの状態」で供給され ます。PHP Development Team は、市場性および特定目的への適合性の黙示保証 等を含め、明示または黙示の保証をすべて行いません。本ソフトウェアを使用し た結果として、直接的損害、間接的損害、付随的損害、特別損害、懲罰的損害、 または派生的損害（代替品もしくは代替サービスの調達、使用能力、データもし くは利益の損失、または事業の中断を含みますが、それらに限定されません）が 発生した場合は、いかなる原因で生じたとしても、またいかなる責任論上におい ても、契約行為、無過失責任または不法行為（怠慢その他を含め）によるものか を問わず、たとえ当該損害が発生する可能性を事前に通知されていたとしても、 PHP Development Team またはその寄稿者は、いかなる場合も一切の責任を負い ません。 本ソフトウェアは、多くのお客様による PHP Group のための自発的な貢献によっ て成り立っています。PHP Group へは電子メール（[email protected]）でお問い合 わせください。 PHP Group および PHP プロジェクトについての詳細は、http://www.php.net を 参照してください。本製品には Zend Engine が含まれています。Zend Engine は http://www.zend.com から自由に入手できます。 本製品には Tim Hudson（[email protected]）が作成したソフトウェアが含まれて います。 Copyright (c) 2003, Itai Tzur <[email protected]> All rights reserved. ソース形式およびバイナリ形式での再配布および使用は、その改変の有無にかか わらず、認められています。ただし、その場合は以下の条件に従うものとします。 ソース・コードの再配布物には上記著作権表記、本条件一覧、および下記免責条 項を含める必要があります。 書面による特定の事前許可を得ずに、本ソフトウェアから派生した製品の保証また は販売促進に Itai Tzur またはその他の寄稿者の名前を使用することはできません。 本ソフトウェアは著作権所有者および寄稿者により「そのままの状態」で供給さ れます。著作権所有者および寄稿者は、市場性および特定目的への適合性の黙示 保証等を含め、明示または黙示の保証をすべて行いません。本ソフトウェアを使 用した結果として、直接的損害、間接的損害、付随的損害、特別損害、懲罰的損 害、または派生的損害（代替品もしくは代替サービスの調達、使用能力、データ もしくは利益の損失、または事業の 中断を含みますが、それらに限定されません）が発生した場合は、いかなる原因 で生じたとしても、またいかなる責任論上においても、契約行為、無過失責任ま たは不法行為（怠慢その他を含め）によるものかを問わず、たとえ当該損害が発 生する可能性を事前に通知されていたとしても、著作権所有者または寄稿者は、 いかなる場合も一切の責任を負いません。 Copyright (c) 1998, 1999, 2000 Thai Open Source Software Center Ltd 本使用条件に従い、本ソフトウェアおよび関連するドキュメント・ファイル （以下「ソフトウェア」といいます）のコピーを入手する人物に対して無償で、 ソフトウェアのコピーの使用、複製、変更、統合、公表、配布、サブライセンス 発行、および / または販売などを含め、制限なくソフトウェアを取り扱い、また ソフトウェアを提供された人物にこれらを行うことを許可することが認められて います。ただし、その場合は以下の条件に従うものとします。上記著作権表記お よびこの許可表記がソフトウェアのすべての複製物または実質的に同一の部分に 記載される必要があります。 ソフトウェアは、市場性、特定目的への適合性、および非侵害の保証等を含めた 明示もしくは黙示の保証なく、「そのままの状態」で供給されます。契約行為、 不法行為その他にかかわらず、ソフトウェアもしくはソフトウェアの使用や取り 扱いから、またはそれらに関連して生じる補償請求、損害その他の賠償に対し、 著者または著作権所有者は一切責任を負いません。 Copyright © 2003, 2004 NextHop Technologies, Inc. All rights reserved. 機密著作権表記 本文書に記載されている事項を除き、NextHop Technologies, Inc. の書面による 事前許可を得ずに、本ドキュメントの一部として供給される資料を、電子、機械、 写真複写、筆記その他による手段等を含め、いかなる形式または方法によっても、 複写、複製、配布、再発行、ダウンロード、表示、掲示、または送信することは できません。別段の記載がない限り、資料を改変しないこと、および著作権その 他の所有権の表記をすべて資料に含めることを条件として、個人的な非商業目的に 限り、本ドキュメントの資料を表示、複写、配布およびダウンロードすることは認 められています。NextHop の書面による事前許可を得ずに、本ドキュメントに含 まれている資料を別のサーバに「ミラーリングコピー」することはできません。 本ドキュメントに含まれている資料を許可なく使用した場合は、著作権法、商標 法、プライバシーおよびパブリシティーに関する法律、通信に関する規制および 法令に違反する可能性があります。以上の許可は、本条項または条件に違反した 場合には自動的に終了します。本許可が終了した場合、ダウンロードおよび印刷 した資料は直ちに破棄する必要があります。 商標表記 本ドキュメントに使用および記載されている商標、サービスマーク、およびロゴ （以下「商標」といいます）は米国および / またはその他の国における NextHop の 登録商標または商標です。ここに記載した会社および製品の名称は各所有者の商 標である場合があります。本ドキュメントのいかなる記載も、黙示、禁反言その 他によって、ドキュメントに記載されている商標を使用するライセンスまたは権 利を許諾するものとは解釈されないものとします。所有者は法律の認める最大の 範囲内で自己の知的所有権を積極的に行使します。商標は、書面による事前の許 可なく、使用を含め、本ドキュメントの資料の配布または資料へのアクセスに関 する宣伝広告を含むいかなる手段によっても、 使用することはできません。ほかの Web サイトへの「ホット」リンクとして商標 を使用することは、当該リンクの構築が書面により事前に承認されない限り、禁 じられています。これらの商標の使用に関する質問については、米国の NextHop （+1 734 222 1600）までお問い合わせください。 アメリカ合衆国政府の制限された権利 ドキュメントの資料は「制限付き権利」を付して提供されています。ソフトウェア および付随する文書は、制限付き権利を伴う連邦調達規則に準拠する取引に基 づき、米連邦政府（以下「政府」 ）といいます）に提供されています。政府による 使用、変更、複製、公表、実行、表示または開示の権利は、 DFAR 252.227-7014（1995 年 6 月）の非商用コンピュータ・ソフトウェアおよび 非商用コンピュータ・ソフトウェアドキュメンテーションに関する権利条項（b） （3） 、ならびに FAR 52.227-14, Alternative III（1987 年 6 月）の一般データに関す る権利条項（g） （3）（i）および FAR 52.227-19（1987 年 6 月 ) の商用コンピュータ・ソフトウェアに関する制限 付き権利条項（c）（2）におけるその他の限定および条件により制限されます。 政府による本ドキュメントの資料の使用は、当該資料における NextHop または 原著作者の所有権の承認となります。請負業者 / 実施許諾者は、1911 Landings Drive, Mountain View, California 94043 にある NextHop です。政府による使用、 複製、または開示は適用法令に記載されている制限を受けます。 保証の放棄 本ドキュメントの資料は明示もしくは黙示の保証なく、「そのままの状態」で 供給されます。NextHop は、適用法に従って認められる最大の範囲で、市場性、 特定目的への適合性、権利の非侵害その他の黙示保証等を含め、明示または黙示の 保証をすべて行いません。NextHop または本ドキュメントに含まれている資料の 提供者もしくは開発者は、本ドキュメントの資料の使用、有効性、正確性もしくは 信頼性、またはその使用の結果その他の事項に関して、いかなる保証または表明 も行いません。 責任の制限 NextHop はいかなる場合においても、本ドキュメントの資料の使用もしくは使用 不能から生じるデータまたは利益の損失等を含めた直接的損害、間接的損害、 特別損害、付随的損害、または派生的損害に対して、たとえ NextHop または NextHop の正式な代表者が当該損害の発生する可能性を事前に通知していたとし ても、一切責任を負いません。本ドキュメントの資料を使用した結果、機器また はデータの付帯サービス、修理もしくは修正が必要になった場合、その費用はお 客様の負担となります。一部の州は付随的または派生的損害に対する免責または 制限を認めていないため、お客様によっては上記の制限または免責は適用されな い場合があります。 Copyright © ComponentOne, LLC 1991-2002. All Rights Reserved. BIND: ISC Bind (Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")) Copyright 1997-2001, Theo de Raadt: OpenBSD 2.9 リリース 目次 第1章 ClusterXL について 本書の内容 13 ゲートウェイ・クラスタの必要性 14 HA（ハイ・アベイラビリティ）による信頼性 14 負荷共有による信頼性とパフォーマンスの向上 14 チェック・ポイントの ClusterXL ゲートウェイ・クラスタ・ソリューション 14 クラスタ・コントロール・プロトコル 15 インストール、ライセンス、およびサポートされているプラットフォーム 16 ClusterXL でのクロックの同期 16 クラスタの定義と用語 17 第2章 クラスタ間での接続情報の同期 クラスタ情報を同期させる必要性 19 チェック・ポイントのステート同期ソリューション 19 ステート同期について 20 同期ネットワーク 20 ステート同期の動作 21 同期不要なサービス 21 同期の不要なサービスの選択 22 継続時間が制限された同期 23 非対称通信 23 非対称通信の例：TCP 3 ウェイ・ハンドシェーク 24 同期メカニズムによる非対称通信の処理方法 25 WAN を介したクラスタの同期 26 同期クラスタの制限 26 ステート同期の設定 27 ステート同期の設定 27 サービスを非同期に設定する方法 28 同一サービスの同期バージョンと非同期バージョンの作成 28 継続時間が制限された同期の設定 28 目次 7 第3章 対称通信 対称通信について 31 対称判定機能 31 負荷共有構成でサードパーティ製ピアとの VPN トンネルを許可する方法 32 ハブ・アンド・スポーク型トポロジでのサードパーティ製ゲートウェイ 33 対称通信の設定 34 対称判定機能の設定 34 ハブ・アンド・スポーク型トポロジでサードパーティ製ゲートウェイを 確立する方法 35 第4章 ClusterXL における HA と負荷共有 HA（ハイ・アベイラビリティ）と負荷共有について 37 負荷共有 38 HA 38 ClusterXL トポロジの例 39 クラスタ・メンバの IP アドレスの定義 40 クラスタの仮想 IP アドレスの定義 41 同期ネットワーク 41 異なるサブネット上のクラスタ・アドレスの設定 41 ClusterXL のモード 42 ClusterXL のモードについて 42 負荷共有マルチキャスト・モード 43 負荷共有ユニキャスト・モード 44 HA New モード 46 各モードの比較表 48 フェイルオーバー 49 フェイルオーバーとは 49 フェイルオーバーはいつ発生するか 50 ゲートウェイが復帰した場合の処理 50 復帰したクラスタ・メンバがセキュリティ・ポリシーを取得する方法 51 導入計画における注意事項 51 HA または負荷共有 51 負荷共有モードの選択 51 IP アドレスの移行 52 ハードウェア要件、互換性、および設定例 52 ClusterXL のハードウェア要件 52 ClusterXL のハードウェアの互換性 55 Cisco Catalyst ルーティング・スイッチの設定例 55 チェック・ポイントのソフトウェアとの互換性 57 サポートするオペレーティング・システム 57 サポートするチェック・ポイントのソフトウェア（SmartDefense を除く）57 ClusterXL がサポートする SmartDefense 機能 60 転送レイヤ 61 8 ClusterXL の設定 62 クライアント・マシンのルーティングの設定 62 クラスタ・メンバ・マシンの準備 62 クラスタ・メンバでの CCP トランスポート・モードの選択 63 SmartDashboard の設定 64 第5章 OPSEC 認定クラスタ製品の使用 OPSEC 認定クラスタ製品について 69 OPSEC 認定クラスタ製品の設定 70 スイッチの準備とルーティングの設定 70 クラスタ・メンバ・マシンの準備 70 OPSEC クラスタに対する SmartDashboard の設定 71 OPSEC クラスタにおける CPHA コマンド・ラインの働き 74 OPSEC クラスタにおける cphastart コマンドと cphastop コマンド 74 OPSEC クラスタにおける cphaprob コマンド 74 第6章 ゲートウェイ・クラスタの監視とトラブルシューティング クラスタの正常動作を確認する方法（cphaprob）78 cphaprob コマンド 78 クラスタの状態監視（cphaprob state）79 クラスタ・インタフェースの監視（cphaprob [-a] if）81 クリティカル・デバイスの監視（cphaprob list）83 クリティカル・デバイスの登録（cphaprob -d ... register）84 ファイルにリストしたクリティカル・デバイスの登録 （cphaprob -f <file> register）84 クリティカル・デバイスの登録削除（cphaprob -d ... unregister）85 ClusterXL へのクリティカル・デバイス状態報告（cphaprob -d ... report）85 cphaprob スクリプトの例 85 SmartConsole クライアントを使用したクラスタ状態監視 86 SmartView Monitor 86 SmartView Tracker 87 ClusterXL 設定コマンド（cphaconf、cphastart、cphastop）90 cphaconf コマンド 90 cphastart コマンドと cphastop コマンド 91 フェイルオーバーの開始方法 91 クラスタ・メンバの停止 91 クラスタ・メンバの起動 92 同期の監視（fw ctl pstat）92 同期のトラブルシューティング（cphaprob [-reset] syncstat）96 cphaprob [-reset] syncstat の概要 96 cphaprob [-reset] syncstat コマンドの出力 97 同期のトラブルシューティング・オプション 105 目次 9 ClusterXL のエラー・メッセージ 107 ClusterXL の一般的なエラー・メッセージ 108 SmartView Tracker のアクティブ・モード・メッセージ 109 同期関連のエラー・メッセージ 110 TCP Out-of-State エラー・メッセージ 111 プラットフォーム固有のエラー・メッセージ 112 Solaris プラットフォーム固有の問題：VLAN スイッチ・ポートのフラッピング 114 メンバの再起動の失敗 114 第7章 ClusterXL の高度な設定 ClusterXL クラスタのアップグレード 118 VPN とクラスタの使用 118 VPN とクラスタの設定方法 118 別のマネージャ下の VPN ピアにクラスタ・オブジェクトを定義する方法 119 NAT とクラスタの使用 119 クラスタのフォールドとクラスタの隠蔽 119 ゲートウェイ・クラスタ上での NAT 設定 120 クラスタ・メンバ上での NAT 設定 120 VLAN とクラスタの使用 121 ClusterXL の VLAN サポート 121 同一 VLAN への複数クラスタの接続 122 モジュール設定パラメータを使用した高度なクラスタ設定 125 モジュール設定パラメータの設定方法 125 モジュール設定パラメータを起動時に有効にする方法 126 クラスタリング・タイマと同期タイマの制御 127 高負荷状態での新しい接続の阻止 127 SmartView Tracker のアクティブ・モードの使用 128 処理待ちパケット数の削減 129 完全同期詳細オプションの設定 130 Disconnected インタフェースの定義 131 Unix での Disconnected インタフェースの定義 131 Windows での Disconnected インタフェースの定義 131 ポリシー更新タイムアウトの設定 131 TCP 3 ウェイ・ハンドシェーク実施の強化 132 異なるサブネット上のクラスタ・アドレスの設定 133 異なるサブネット上のクラスタ・アドレスについて 133 異なるサブネット上のクラスタ・アドレスの設定 134 異なるサブネット上のクラスタ・アドレスの例 135 異なるサブネット上のクラスタ・アドレスの制限事項 137 HA Legacy モードから HA New モードまたは負荷共有モードへの移行 （簡易的方法）139 モジュールの設定 140 SmartDashboard からの設定 140 10 HA Legacy モードから HA New モードまたは負荷共有モードへの移行 （ダウンタイムを最小限にする方法）141 単一ゲートウェイから ClusterXL クラスタへの移行 143 単一ゲートウェイ・マシンの設定 143 マシン「B」の設定 143 マシン「B」に対する SmartDashboard での設定 143 マシン「A」の設定 143 マシン「A」に対する SmartDashboard での設定 144 既存クラスタへの別メンバの追加 144 クラスタの ISP 冗長性の設定 145 クラスタ構成でのダイナミック・ルーティング・プロトコルの有効化 146 システムのコンポーネント 146 ClusterXL のダイナミック・ルーティング 147 付録 A HA Legacy モード HA Legacy モードについて 149 HA Legacy モードのトポロジ例 150 共有インタフェースの IP アドレスと MAC アドレスの設定 150 同期インタフェース 151 HA Legacy モードの導入計画における注意事項 151 IP アドレスの移行 151 SmartCenter サーバの場所 152 ルーティングの設定 152 スイッチ（レイヤ 2 転送）に関する注意事項 152 HA Legacy モードの設定 153 ルーティングの設定 153 SmartDashboard の設定 154 付録 B cphaprob スクリプトの例 関連情報 157 clusterXL_monitor_process スクリプト 157 付録 C ClusterXL のコマンドライン・インタフェース 索引 目次 11 12 第 1 章 ClusterXL について この章の構成 本書の内容 13 ページ ゲートウェイ・クラスタの必要性 14 ページ チェック・ポイントの ClusterXL ゲートウェイ・クラスタ・ ソリューション 14 ページ クラスタ・コントロール・プロトコル 15 ページ インストール、ライセンス、およびサポートされている プラットフォーム 16 ページ ClusterXL でのクロックの同期 16 ページ クラスタの定義と用語 17 ページ 本書の内容 ■ ■ ■ ■ ■ 第 1 章「ClusterXL について」では、ゲートウェイ・クラスタの必要性、ClusterXL と クラスタ・コントロール・プロトコルの概要、インストールとライセンス要件、お よびクラスタの定義と用語について説明します。 第 2 章「クラスタ間での接続情報の同期」では、ステート同期、同期の必要がない サービス、およびステート同期の設定方法について説明します。 第 3 章「対称通信」では、特定の負荷共有接続で対称判定機能を使用するための要 件について説明します。 第 4 章「ClusterXL における HA と負荷共有」では、ClusterXL の負荷共有モードと HA モード、フェイルオーバー、および各種のチェック・ポイント製ソフトウェア / ハードウェアとの互換性について説明します。 第 5 章「OPSEC 認定クラスタ製品の使用」では、OPSEC クラスタ製品を使用する際 の注意事項について説明します。 13 ゲートウェイ・クラスタの必要性 ■ ■ ■ 第 6 章「ゲートウェイ・クラスタの監視とトラブルシューティング」では、クラス タが正常に機能していることを確認する方法とコンソール・エラー・メッセージへ の対処方法について説明します。 第 7 章「ClusterXL の高度な設定」では、詳細設定の手順について説明します。 第 A 章「HA Legacy モード」では、HA Legacy モードとその設定方法について説明し ます。 ゲートウェイ・クラスタの必要性 HA（ハイ・アベイラビリティ）による信頼性 ファイアウォールと VPN 接続は、組織にとってビジネスに欠かせないネットワーク・デ バイスです。ファイアウォールまたは VPN 接続に障害が発生すると、組織と外部との接 続は直ちに切断されます。金融取引など、これらの接続の多くはミッション・クリティ カルであり、これらが切断されると重要なデータが失われてしまいます。 したがって、ファイアウォールと VPN 接続には高い可用性（ハイ・アベイラビリティ） が求められます。組織と外部との間のゲートウェイは、どのような状況においても常に 動作している必要があります。 負荷共有による信頼性とパフォーマンスの向上 負荷共有ゲートウェイ・クラスタでは、クラスタ内のすべてのコンピュータが常にアク ティブです。これにより、クラスタの信頼性は向上します。これは、1 台のマシンが故障 したり、保守のために停止しても、残りのマシンがアクティブな状態で稼動しているか らです。残りのマシンを「起動」する必要はありません。 負荷共有には、パフォーマンス上の大きな利点もあります。1 つのゲートウェイの代わり に複数のゲートウェイを稼動すると、VPN、セキュリティ・サーバ、ポリシー・サーバ、 SmartDirectory（LDAP）など、CPU 負荷が高いアプリケーションのパフォーマンスが向上 します。 チェック・ポイントの ClusterXL ゲートウェイ・クラスタ・ ソリューション ClusterXL は、ソフトウェアベースの負荷共有および HA ソリューションです。冗長構成の VPN-1 Pro ゲートウェイのクラスタ間にネットワーク・トラフィックを分散し、クラスタ内 のマシン間で透過的にフェイルオーバーを行います。 VPN-1 Pro ゲートウェイ・クラスタは、同じ VPN-1 Pro ゲートウェイのグループで、1 台 が故障すると、もう 1 台がすぐに置き換わるように接続されています（図 1-1 を参照） 。 14 負荷共有による信頼性とパフォーマンスの向上 図 1-1 ファイアウォール・ゲートウェイ・クラスタ ClusterXL は、クラスタ・メンバに対しては固有の物理 IP アドレスと MAC アドレスを使用 し、クラスタ自身を表すには仮想 IP アドレスを使用します。仮想アドレスは（HA Legacy モードを除くすべての構成では）、実際のどのマシン・インタフェースにも属しません。 ClusterXL は、各ゲートウェイ・クラスタが他のメンバを経由する接続を認識できるよう にして、障害が発生してもデータが失われないインフラストラクチャを提供します。 クラスタ・メンバ間で接続と他の VPN-1 Pro の状態に関する情報をやり取りすることを 「ステート同期」と呼びます。 VPN-1 Pro ゲートウェイ・クラスタは、OPSEC 認定の HA および負荷共有製品を使用して 構築することもできます。OPSEC 認定のクラスタ製品は、ClusterXL と同じステート同期 インフラストラクチャを使用します。 クラスタ・コントロール・プロトコル クラスタ・コントロール・プロトコル（CCP）は、チェック・ポイントのゲートウェイ・ クラスタ内のマシンを互いにリンクします。CCP トラフィックは通常のネットワーク・ト ラフィックとは区別され、ネットワーク・スニッファを使用して表示できます。 CCP は UDP ポート 8116 上で動作し、以下の機能があります。 ■ ■ キープアライブ・パケットを送信して、クラスタ・メンバが自分自身の状態を報告し、 他のメンバの状態を把握できるようにする機能（ClusterXL クラスタ利用時のみ） ステート同期 チェック・ポイントのクラスタ・コントロール・プロトコルは、4 つの各 ClusterXL モー ドと OPSEC クラスタで使用されます。ただし、このプロトコルが行うタスクとタスクの 実施方法は、モードによって異なる場合があります。 第1章 ClusterXL について 15 インストール、ライセンス、およびサポートされているプラットフォーム インストール、ライセンス、およびサポートされている プラットフォーム ClusterXL は、SmartCenter サーバとクラスタ・メンバが別のマシン上にある分散構成にの みインストールする必要があります。ClusterXL は、標準 VPN-1 Pro インストールの一部 になっています。 ゲートウェイ・クラスタにポリシーをインストールするには、以下の手順に従います。 1 少なくとも 1 つのクラスタ・メンバにインストールする VPN-1 Pro のライセンス （SKU：CPMP-VPG) が必要です。Check Point Express の場合は、少なくとも 1 つのクラ スタ・メンバにインストールする、一致する Express ライセンス（SKU：CPXP-VPX） が必要です。 2 ほかのメンバには、SKU：CPMP-HVPG の 2 番目のモジュール・ライセンスまたは（Check Point Express の場合には）SKU：CPXP-HVPX のライセンスをインストールできます。 3 以前のバージョンのライセンス（FM-X）を使用している場合は、項目 1 と 2 を無視し て、各クラスタ・メンバが FireWall-1 ライセンス（SKU：FM-U など）を持っているこ とを確認します。 4 ClusterXL 負荷共有クラスタごとに、管理ステーションにインストールする追加の負 荷共有アドオン・ライセンスが必要です。負荷共有ライセンス SKU には、 CPMP-CXLS-U-NGX と CPMP-CXLS-500-NGX の 2 種類があります。 ClusterXLHA クラスタと サード・パーティー製クラスタ（HA と負荷共有の両方）では、追加のライセンス / アドオンは必要ありません。 5 NGX（R60A）にアップグレードすると、ClusterXL の以前のバージョンのライセンス は、自動的に正式な負荷共有ライセンスとしてカウントされるので、項目 4 の要件は なくなります。 6 プラグ・アンド・プレイ・ライセンスと評価版ライセンスの両方には、同じ管理ス テーションで最大 3 つの ClusterXL 負荷共有クラスタを使用するオプションが含まれ ています。 ClusterXL がサポートするプラットフォームは、 『Check Point Enterprise Suite NGX（R60A） Release Notes』のプラットフォーム対応表に示されています。このリリース・ノートは http://www.checkpoint.com/downloads/index.html からダウンロードできます。 ClusterXL でのクロックの同期 ClusterXL を使用する場合は、すべてのクラスタ・メンバのクロックを同期させる必要が あります。 これは、手作業で設定するか、NTP などのプロトコルを使用して行うことができます。 VPN などの機能は、すべてのクラスタ・メンバのクロックが同期している場合にのみ正 常に動作します。 16 負荷共有による信頼性とパフォーマンスの向上 クラスタの定義と用語 ゲートウェイ・クラスタ、HA、および負荷共有に関する用語の意味は、ベンダーによっ て異なる場合があります。チェック・ポイントでは、クラスタについて説明する際には 以下の定義を使用します。 クラスタ 負荷共有または HA を提供するために一緒に動作する複数のマシンで構成されるグループ。 障害 マシンがパケットをフィルタリングできなくなる原因となるハードウェアまたはソフト ウェアの問題。アクティブなマシンに障害が発生すると、フェイルオーバーが発生します。 フェイルオーバー クラスタ内で、障害が発生したマシンに代わって、別のマシンがパケットのフィルタリ ングを引き継ぐこと。 HA 障害が発生した場合に、クラスタ内の別マシンに接続を引き継がせることによって接続を 維持する機能。アクティブ・マシンのみがパケットをフィルタリングし、ほかのマシンは フィルタリングを行いません。クラスタ内の 1 つのマシンがアクティブ・コンピュータと して設定されます。アクティブ・マシンでフェイルオーバーが発生した場合、クラスタ 内のほかのマシンの 1 つがその処理を引き継ぎます。 アクティブ・アップ アクティブであった HA マシンに障害が発生し、そのマシンが再び使用可能になった場 合、アクティブ・マシンとしてではなく、クラスタ内のスタンバイ・マシンの 1 つとして クラスタに復帰します。 プライマリ・アップ アクティブであった HA マシンに障害が発生し、そのマシンが再び使用可能になった場 合、プライマリ・マシンとして処理を再開します。 ホット・スタンバイ アクティブ / スタンバイとも呼ばれます。HA と同じ意味です。 第1章 ClusterXL について 17 クラスタの定義と用語 負荷共有 負荷共有ゲートウェイ・クラスタでは、クラスタ内のすべてマシンがパケットをフィル タリングします。負荷共有は HA を実現し、障害が発生した場合、クラスタ内のほかのマ シンに透過的なフェイルオーバーを行い、信頼性とパフォーマンスを向上させます。負荷 共有はアクティブ / アクティブとも呼ばれます。 マルチキャスト負荷共有 ClusterXL の負荷共有マルチキャスト・モードでは、クラスタのすべてのメンバが、クラ スタ IP アドレスに送信されたすべてのパケットを受信します。ルータまたはレイヤ 3 ス イッチは、マルチキャストを使用してパケットをすべてのクラスタ・メンバに転送します。 すべてのクラスタ・メンバ上にある ClusterXL 決定アルゴリズムによって、パケットに対 してエンフォースメント処理を行うクラスタ・メンバが決定されます。 ユニキャスト負荷共有 ClusterXL の負荷共有ユニキャスト・モードでは、1 つのマシン（「ピボット」）が、ユニ キャスト設定されたルータからすべてのトラフィックを受信して、クラスタ内の他のマ シンにパケットを再配信します。ピボット・マシンは、ClusterXL によって自動的に選択 されます。 クリティカル・デバイス 管理者が、クラスタ・メンバの動作にとって重要と定義したデバイス。クリティカル・デ バイスは問題通知（pnote）とも呼ばれます。クリティカル・デバイスは常時監視されます。 クリティカル・デバイスが動作を停止した場合、障害と見なされます。デバイスは、ハー ドウェアでもプロセスでも構いません。fwd プロセスと cphad プロセスは、デフォルトで クリティカル・デバイスとして事前に定義されています。セキュリティ・ポリシーもク リティカル・デバイスとして事前に定義されています。管理者は、cphaprob コマンドを 使用してクリティカル・デバイスの一覧に追加できます。 ステート同期 フェイルオーバーの発生後も接続を維持するための技術。ステート同期は、ClusterXL ク ラスタ・ソリューションとサード・パーティーのクラスタ・ソリューションの両方で使 用されます。VPN-1 Pro カーネル・テーブルを複製することによって動作します。 安全に保護されたインタフェース 安全なネットワーク上のインタフェース。同期ネットワークは、重要なデータが通過す るため、安全に保護する必要があります。ネットワークを保護する 1 つの方法は、ネット ワークに接続したすべてのインタフェースを、物理的なセキュリティ手段で保護された 安全な部屋に設置することです。クロス・ケーブルで同期インタフェースを接続するこ とも、インタフェースを保護する 1 つの方法です。 18 第 2 章 クラスタ間での接続情報の同期 この章の構成 クラスタ情報を同期させる必要性 19 ページ チェック・ポイントのステート同期ソリューション 19 ページ ステート同期の設定 27 ページ クラスタ情報を同期させる必要性 ファイアウォールに障害が発生すると、組織と外部との接続は直ちに切断されます。金 融取引など、これらの接続の多くはミッション・クリティカルであり、これらが切断さ れると重要なデータが失われてしまいます。ClusterXL は、各ゲートウェイ・クラスタ・ メンバがほかのメンバを経由する接続を認識できるようにして、障害が発生してもデー タが失われないインフラストラクチャを提供します。クラスタ・メンバ間で接続情報と ほかの VPN-1 Pro の状態に関する情報をやり取りすることを「ステート同期」と呼びます。 チェック・ポイントのステート同期ソリューション このセクションの構成 ステート同期について 20 ページ 同期ネットワーク 20 ページ ステート同期の動作 21 ページ 同期不要なサービス 21 ページ 19 チェック・ポイントのステート同期ソリューション 同期の不要なサービスの選択 22 ページ 継続時間が制限された同期 23 ページ 非対称通信 23 ページ 非対称通信の例：TCP 3 ウェイ・ハンドシェーク 24 ページ 同期メカニズムによる非対称通信の処理方法 25 ページ WAN を介したクラスタの同期 26 ページ 同期クラスタの制限 26 ページ ステート同期について ステート同期により、クラスタ内のすべてのマシンは、ほかの各マシンを経由する接続を 認識できます。これにより、あるクラスタ・メンバで障害が発生しても、そのマシンで 処理されていた接続はほかのマシンによって維持されます。 VPN-1 Pro によって認識されるすべての IP ベースのサービス（TCP と UDP を含む）は、同 期されます。 ステート同期は、ClusterXL ソリューションとサード・パーティの OPSEC 認定クラスタ製品 の両方で使用されます。 ClusterXL 負荷共有構成内のマシンは同期させる必要があります。ClusterXL HA（ハイ・ アベイラビリティ）構成内のマシンは同期させる必要はありませんが、同期していない とフェイルオーバー時に接続が失われます。 同期ネットワーク 同期ネットワークは、接続とクラスタ・メンバ間のほかの VPN-1 Pro の状態に関する同期 情報を転送する際に使用します。 同期ネットワークは、組織の最も重要なセキュリティ・ポリシー情報を送信するため、悪 意のある妨害や事故から安全に保護する必要があります。以下の両方を実行して同期イ ンタフェースを保護することをお勧めします。 ■ ■ 専用の同期ネットワークを使用する。 クロスケーブルを使用して、クラスタ・メンバの物理ネットワーク・インタフェー スを直接接続する。3 つ以上のメンバを含むクラスタでは、専用のハブまたはスイッ チを使用してください。 注： WAN を介して同期を実行できます。詳細については、26 ページの「WAN を介したクラスタの同期」 を参照してください。 20 ステート同期の動作 これらの推奨方法に従うことによって、ほかのネットワークが同期情報を送信しないため、 同期ネットワークの安全性が保証されます。 バックアップのための複数の同期ネットワークを定義できます。バックアップも専用 ネットワークにすることをお勧めします。 バージョン NGX（R60）では、同期ネットワークは VLAN インタフェースの最も小さい VLAN タグでサポートされます。たとえば、タグ 10、20、および 30 の 3 つの VLAN がイ ンタフェース eth1 に構成されている場合には、インタフェース eth1.10 を同期に使用でき ます。 ステート同期の動作 同期は以下の 2 つのモードで動作します。 ■ ■ 完全同期では、クラスタ・メンバ間ですべての VPN-1 Pro カーネル・テーブル情報が転 送されます。完全同期は、暗号化された TCP 接続を使用して、fwd デーモンによって 処理されます。 差分同期では、クラスタ・メンバ間でカーネル・テーブルの変更情報が転送されます。 差分同期は、ポート 8116 で UDP マルチキャストを使用して、VPN-1 Pro-1 カーネルに よって処理されます。 完全同期は、何千もの接続について、状態情報の初期転送に使用されます。クラスタ・ メンバがダウン後に起動した場合、完全同期を実行します。すべてのメンバが同期した ら、更新情報のみが差分同期によって転送されます。差分同期は完全同期より遥かに高 速です。 ステート同期トラフィックは通常、すべてのクラスタ・コントロール・プロトコル（CCP） トラフィックの約 90 % を占めます。ステート同期パケットは、UDP データ・ヘッダ内の opcode によって残りの CCP トラフィックと区別されます。 注： 送信元 MAC アドレスは変更できます。122 ページの「同一 VLAN への複数クラスタの接続」を参照 してください。 同期不要なサービス ゲートウェイ・クラスタ内では、通常、すべてのクラスタ・メンバに対するすべての接 続がクラスタ間で同期されます。ただし、必ずしもゲートウェイ・クラスタを通過する すべてのサービスを同期させる必要はありません。 第2章 クラスタ間での接続情報の同期 21 チェック・ポイントのステート同期ソリューション ■ ■ ■ TCP、UDP、その他の種類のサービスを同期しないように指定できます。デフォル トでは、これらのサービスはすべて同期されます。 VRRP と IP クラスタ・コントロール・プロトコル、および IGMP プロトコルは、デ フォルトでは同期されません（これらのプロトコルに対して同期をオンにすること はできます）。クラスタ・メンバ間のみで実行しているプロトコルは、同期させる 必要はありません。同期させることは可能ですが、同期するようにクラスタを設定 しても利点がありません。同期情報はフェイルオーバーの際には役立たないため、 この場合は関係ありません。したがって、IGMP、VRRP、IP クラスタ・コントロー ル・プロトコル、およびその他の OPSEC クラスタ・コントロール・プロトコルは、 デフォルトでは同期されません。 ブロードキャストとマルチキャストは同期されず、また同期することができません。 サービスに対して同期サービス定義と非同期サービス定義の両方を設定し、ルール・ベー スで選択的に定義を使用できます。 同期の不要なサービスの選択 同期を行うには、パフォーマンスに多少の負担がかかります。以下の条件がすべて当て はまる場合には、サービスを同期しないように設定できます。 1 クラスタを通過するトラフィックの大部分が特定のサービスを使用する。サービスを 同期しないようにすると、同期トラフィックの量が減るため、クラスタ・パフォーマ ンスが向上します。 2 通常、サービスは短時間の接続を確立するため、接続が失われたかどうか通知され ない場合があります。DNS（UDP 経由）と HTTP は、通常、ほとんどの接続に関係し ていますが、非常に寿命が短く、アプリケーション・レベルで接続を回復できます。 FTP などの、一般的に長時間の接続を確立するサービスは、必ず同期させる必要があ ります。 3 すべての接続に対して双方向対称性を保証する構成では、 （HA を維持するためだけに） 同期を行う必要はありません。そのような構成には以下が含まれます。 ■ ■ ■ HA モードのクラスタ（たとえば、ClusterXL New HA または Nokia VRRP） 非暗号化接続での負荷共有モードの ClusterXL（VPN またはスタティック NAT を 除く） 完全対称性を保証する OPSEC クラスタ（OPSEC クラスタのマニュアルを参照） 負荷共有モード（マルチキャストまたはユニキャスト）の ClusterXL クラスタを通過 する VPN 接続とスタティック NAT 接続は、 双方向対称性を維持しない場合があります。 したがって、そのような環境ではステート同期を有効にする必要があります。 同期しないようにサービスを構成するには、サービス・オブジェクトを編集します。 28 ページの「サービスを非同期に設定する方法」を参照してください。 22 継続時間が制限された同期 継続時間が制限された同期 一部の TCP サービス（たとえば、HTTP）には、継続時間が非常に短いという特徴があり ます。これらの接続を同期化すると、ゲートウェイ・リソースを消費しフェイルオーバー が発生する時までに接続が終了してしまうため、同期化は意味がありません。 GUI で定義される［Protocol Type］ が［HTTP］ または［None］ のすべての TCP サービスの 場合には、このオプションを使用して VPN-1 Pro への接続情報の通知を遅らせ、接続開始 x 秒後に接続がまだ存在する場合にのみ接続を同期するように設定できます。この機能を 使用するには、「Delayed Notifications」をサポートする SecureXL デバイスと Performance Pack with ClusterXL LS Multicast などの最新のクラスタ構成が必要です。 この機能は、SecureXL 対応デバイスが、接続が通過する VPN-1 Pro ゲートウェイにイン ストールされている場合にのみ使用可能です。 接続テンプレートが ClusterXL 対応デバイスからオフロードされていない場合、この設定 は無視されます。詳細については、SecureXL のマニュアルを参照してください。 非対称通信 通信のすべてのパケットが 1 つのクラスタ・メンバによって処理される場合、通信は「対 称」であると呼ばれます。非対称通信では、返信パケットは元のパケットと別のゲート ウェイを経由して返される場合があります。 同期メカニズムでは、非対称通信を適切に処理できます。非対称通信では、クラスタ・メ ンバ・ゲートウェイは out-of-state パケットを受信できます。ただし、一般的に out-of-state パケットにはセキュリティ・リスクがあるため、VPN1-Pro はこのパケットを廃棄します。 負荷共有構成ではすべてのクラスタ・メンバがアクティブで、スタティック NAT 接続と 暗号化接続では発信元 IP アドレスと宛先 IP アドレスが変更されます。したがって、負荷 共有クラスタを経由するスタティック NAT 接続と暗号化接続は、非対称になることがあ ります。非対称性は Hide NAT でも発生する可能性がありますが、ClusterXL はそれらを正 しく処理するメカニズムを備えています。 HA 構成では、すべてのパケットがアクティブなマシンに到達するため、非対称通信は発生 しません。通信の確立中にフェイルオーバーが発生した場合、通信は失われますが、同期 は後で実行できます。 ほかのメンバが非対称通信について知らない場合には、パケットは out-of-state となり、通信 はセキュリティ上の理由から切断されます。ただし、同期メカニズムにより、ほかのメン バに通信を通知できます。したがって、同期メカニズムは、有効であるが非対称の通信で out-of-state パケットが発生するのを防ぎ、これらの非対称通信が許可されます。 ネットワーク管理者が、返信パケットが元のパケットと別のゲートウェイを経由して返 される非対称ルーティングを設定した場合にも、非対称通信が発生します。 第2章 クラスタ間での接続情報の同期 23 チェック・ポイントのステート同期ソリューション TCP ストリーミング TCP ストリーミング技術は、TCP セグメントを再構成して TCP セグメントがクライアン トやサーバに到達する前にプロトコル・ユニット全体を検査できるようにします。また、 TCP ストリーミングは、TCP ストリームを直ちに変更してストリームにデータを追加した り、データを削除する機能を提供します。 TCP ストリーム技術を使用する特定の Web Intelligence 機能と VoIP Application Intelligence 機能は、同期が過剰にならないようにするために対称にする（つまり、各方向で同じク ラスタ・メンバによって処理される）必要があります。対称性が必要なチェック・ポイ ントのセキュリティ機能の詳細については、『Check Point Enterprise Suite NGX (R60) Release Notes』を参照してください。このリリース・ノートは http://www.checkpoint.com/downloads/index.html からダウンロードできます。 デフォルトでは、フェイルオーバーの際、TCP ストリーミング通信はリセットされます。 非対称通信の例：TCP 3 ウェイ・ハンドシェーク すべての TCP 接続を開始する 3 ウェイ・ハンドシェークは、多くの場合、非対称（非対称 ルーティング）通信になります。以下の状況が発生する可能性があります。 クライアント A は、SYN パケットをサーバ B に送信して接続を開始します（図 2-1 を参 照）。SYN はゲートウェイ C を経由しますが、SYN/ACK 応答はゲートウェイ D を経由し て返されます。これは、返答パケットが元のパケットと異なるゲートウェイを経由して 返されるため、非対称通信です。 ゲートウェイ D には、SYN パケットについて同期ネットワーク経由で通知されます。サー バ B から送信された SYN/ACK パケットがゲートウェイ D に届く前にこのマシンが更新さ れた場合は、通信は正常に処理されます。同期が遅れ、SYN フラグが更新される前に SYN/ACK パケットがゲートウェイ D で受信された場合は、ゲートウェイは SYN/ACK パ ケットを out-of-state として処理し、通信を切断します。 詳細については、132 ページの「TCP 3 ウェイ・ハンドシェーク実施の強化」を参照して ください。 24 同期メカニズムによる非対称通信の処理方法 図 2-1 非対称（非対称ルーティング）通信 同期メカニズムによる非対称通信の処理方法 同期メカニズムは、有効であるが非対称の通信で、out-of-state パケットの発生を防ぎます。 すべての TCP データ通信を開始する 3 ウェイ・ハンドシェークの例を参考にすると、同期 メカニズムの処理方法を理解できます。3 ウェイ・ハンドシェークは以下のように行なわ れます。 1 SYN（クライアントからサーバへ） 2 SYN/ACK（サーバからクライアントへ） 3 ACK（クライアントからサーバへ） 4 データ（クライアントからサーバへ） out-of-state パケットの発生を防ぐために、以下のシーケンス（「Flush and Ack」と呼ばれ ます）が実行されます（手順番号は図 2-1 の番号に対応しています） 。 1 クラスタ・メンバは接続の最初のパケット（SYN）を受信します。 2 通信が非対称でないかを確認します。 3 SYN パケットを保持します。 4 すべてのクラスタ・メンバに（このパケットに関するすべての変更を含む）保持中の 同期アップデートを送信します。 第2章 クラスタ間での接続情報の同期 25 チェック・ポイントのステート同期ソリューション 5 ほかのすべてのクラスタ・メンバが、syn パケット内の情報に対して肯定応答するの を待ちます。 6 保持中の SYN パケットを解放します。 7 すべてのクラスタ・メンバが SYN-ACK に対してレディになります。 WAN を介したクラスタの同期 組織では、物理的に離れた場所にあるクラスタ・メンバを検索する必要がある場合があ ります。典型的な例が、障害回復のために遠隔地に配置された複製用のデータ・センター です。このような構成では、同期ネットワークとしてクロス・ケーブルを使用するのは 不可能です（20 ページの「同期ネットワーク」を参照） 。 同期ネットワークはリモート・サイトに拡大できるため、地理的に分散したクラスタを 簡単に導入できます。この機能には以下の 2 つの制限があります。 1 同期ネットワークは、100 ms 以下の待ち時間と 5 % 以下のパケット・ロスを保証する 必要があります。 2 同期ネットワークにはスイッチとハブのみを含めることができます。ルータはクラ スタ・コントロール・プロトコル・パケットを廃棄するため、同期ネットワークで は使用できません。 地理的に分散したクラスタを監視してトラブシューティングを実行するには、コマンド・ ラインを使用できます。96 ページの「同期のトラブルシューティング（cphaprob [-reset] syncstat）」を参照してください。 同期クラスタの制限 クラスタ・メンバの同期には以下の制限があります。 1 同じプラットフォーム上で実行されているクラスタ・メンバのみを同期させることが できます。 たとえば、Windows 2000 クラスタ・メンバと Solaris 8 クラスタ・メンバを同期させ ることはできません。 2 クラスタ・モジュールは同じソフトウェア・バージョンである必要があります。 たとえば、NG FP3 バージョンのクラスタ・メンバと NGX バージョンのクラスタ・ メンバを同期させることはできません。 26 ステート同期の設定 3 クラスタ・メンバを通過するユーザ認証接続は、クラスタ・メンバがダウンすると 失われます。同期しているほかのクラスタ・メンバは接続を再開できません。 ただし、クライアント認証接続またはセッション認証接続は失われません。 このような制限は、ユーザ認証状態がセキュリティ・サーバで保持され、これがプロ セスであるために、マシン間でデータの同期と同様には同期ができないことによるも のです。ただし、セッション同期とクライアント同期の状態はカーネル・テーブルに 保存されるため、同期させることができます。 4 「リソース」を使用する接続の状態はセキュリティ・サーバで維持されるため、ユーザ 認証接続を同期させることができないのと同じ理由でこれらの接続は同期させること ができません。 5 アカウンティング情報は各クラスタ・メンバに蓄積され、個別に SmartCenter サーバ に送信されて集計されます。フェイルオーバーの場合、障害が発生したメンバに蓄 積されたが、SmartCenter サーバに送信されなかったアカウンティング情報は失われま す。この問題を最小限にするには、アカウンティング情報を「フラッシュする」期間 を短くできます。これを実行するには、クラスタ・オブジェクトの［Logs and Masters］ >［Additional Logging］ ページで［Update Account Log every:］ 属性を設定します。 ステート同期の設定 このセクションの構成 ステート同期の設定 27 ページ サービスを非同期に設定する方法 28 ページ 同一サービスの同期バージョンと非同期バージョンの作成 28 ページ 継続時間が制限された同期の設定 28 ページ ステート同期の設定 ClusterXL と OPSEC 認定クラスタ製品の設定プロセスの一部として、ステート同期を設定 します。ステート同期の設定では以下の操作を実行します。 ゲートウェイ・クラスタの同期ネットワークのセットアップ ■ ■ ■ VPN-1 Pro のインストールと設定段階での同期機能の有効化 SmartDashboard 内での、クラスタ・オブジェクトの ClusterXL ページでステート同期 が選択されていることの確認 詳細については、以下のセクションを参照してください。 ■ 62 ページの「ClusterXL の設定」 ■ 70 ページの「OPSEC 認定クラスタ製品の設定」 第2章 クラスタ間での接続情報の同期 27 ステート同期の設定 サービスを非同期に設定する方法 サービスを非同期に設定する基本的な情報については、21 ページの「同期不要なサービス」 を参照してください。 1 オブジェクト・ツリーの［Services］ ブランチで、同期させたくない TCP、UDP、 またはその他のサービスをダブルクリックします。 2 ［Service Properties］ ウィンドウで、［Advanced］ をクリックして［Advanced Services Properties］ ウィンドウを表示します。 3 ［Synchronize connections on the cluster］ チェック・ボックスをオフにします。 同一サービスの同期バージョンと非同期バージョンの作成 サービスに対して同期サービス定義と非同期サービス定義の両方を設定し、セキュリ ティ・ルール・ベースで選択的に定義を使用できます。 1 新しい TCP、UDP、およびその他のサービスを定義します。既存のサービスと異な る名前を付けます。 2 既存のサービスのすべての定義を、新しいサービスの［Service Properties］ ウィンド ウにコピーします。 3 新しいサービスで［Advanced］ をクリックして、 ［Advanced Services Properties］ ウィン ドウを表示します。 4 既存のサービスのすべての定義を、新しいサービスの［Advanced Service Properties］ ウィンドウにコピーします。 5 既存のサービスの設定と異なるように、新しいサービスの［Synchronize connections on the cluster］ を設定します。 継続時間が制限された同期の設定 継続時間が制限されたサービスの同期の基本的な情報については、23 ページの「継続時 間が制限された同期」を参照してください。 1 28 オブジェクト・ツリーの［Services］ ブランチで、同期させる TCP、UDP、またはそ の他のサービスをダブルクリックします。 継続時間が制限された同期の設定 2 ［Service Properties］ ウィンドウで［Advanced］ をクリックして［Advanced Services Properties］ ウィンドウを表示します。 3 ［Start synchronizing x seconds after connection initiation］ を選択します。 注： この機能は HTTP ベースのサービスに限られているため、［Start synchronizing - seconds after connection initiation］ チェック・ボックスはほかのサービスでは表示されません。 4 接続開始後、［seconds］ フィールドに同期を遅らせる秒数を入力するか、ドロップ ダウン・リストから秒数を選択します。 第2章 クラスタ間での接続情報の同期 29 ステート同期の設定 30 第 3 章 対称通信 この章の構成 対称通信について 31 ページ 対称判定機能 31 ページ 負荷共有構成でサードパーティ製ピアとの VPN トンネルを 許可する方法 32 ページ 対称通信の設定 34 ページ 対称通信について 通信のすべてのパケットが、いずれかの方向において 1 つのクラスタ・メンバによって処 理される場合、通信は対称です。すべての通信が同じクラスタ・メンバ経由でルーティン グされる HA モードはこれに該当するため、対称です。VPN ピア、スタティック NAT ルー ル、または SIP がない負荷共有モードもこれに該当します。 ただし、負荷共有モードでは、場合によっては、特定のクラスタ・メンバで開始した通 信が、両方向とも引き続き同じクラスタ・メンバによって処理されるようにする必要が あります。そのためには、対称判定機能（Sticky Decision Function）を有効にして、特定 の通信を対称にすることができます。 注： 対称通信を必要とする機能の最新情報については、『Check Point Enterprise Suite NGX (R60A) Release Notes』を参照してください。このリリース・ノートは http://www.checkpoint.com/downloads/index.html からダウンロードできます。 対称判定機能 対称判定機能により、特定のサービスを負荷共有構成で動作させることができます。た とえば、L2TP トラフィックや、クラスタがサード・パーティ製ピアとのサイト・ツー・ サイト VPN トンネルに関与している場合は、この機能が必要です。 31 対称通信について 対称判定機能を有効すると、以下のサービスと通信タイプがサポートされます。 ■ ■ サードパーティ製の VPN ピアとの VPN 構成 SecureClient ビジター・モードを含む SecureClient/SecuRemote/SSL Network Extender 暗号化接続 対称判定機能には以下の制限があります。 ■ ■ Performance Pack またはハードウェアベースのアクセラレータ・カードを使用してい る場合、対称判定機能はサポートされません。対称判定機能を有効にすると、これ らのアクセラレータ製品を使用できなくなります。 対称判定機能を VPN と一緒に使用すると、クラスタ・メンバは特定のピアに対して 複数の通信を開けなくなります。別の通信を開くと別の SA が生成され、多くの場 合、サードパーティ製のピアはそれを処理できません。 負荷共有構成でサードパーティ製ピアとの VPN トンネルを許可する方法 チェック・ポイントは、サードパーティ・ベンダーのゲートウェイを VPN-1 Pro ゲート ウェイのピアにすることによって、サードパーティ・ベンダーのゲートウェイとの相互 互換性を提供しています。特別な場合として、特定のサードパーティ製ピア（Microsoft LT2P、Nokia Symbian、および Cisco ゲートウェイとクライアント）は、負荷共有モード で ClusterXL ゲートウェイとの VPN トンネルの確立を試みます。これらのピアでは、SA の保存能力に限界があります。つまり、あるクラスタ・メンバで開始され、負荷共有の ために別のクラスタ・メンバ経由のリターン・トリップ上にルーティングされた VPN セッ ションは、認識されずに廃棄されます。図 3-1 に例を示します。 図 3-1 32 対称判定機能なしの負荷共有モードの ClusterXL に接続されたサードパーティ製ピア ハブ・アンド・スポーク型トポロジでのサードパーティ製ゲートウェイ この例では、以下が行われます。 ■ ■ サードパーティ製ピア（ゲートウェイまたはクライアント）は VPN トンネルの作成を 試みます。 クラスタ・メンバ A と B は、負荷共有モードで ClusterXL ゲートウェイに属します。 サードパーティ製ピアは、複数の SA セットを保存する機能がないため、複数のクラスタ・ メンバと VPN トンネルをネゴシエートできません。したがって、クラスタ・メンバはルー ティング・トランザクションを完了できません。 特定のサードパーティ製ピアまたは 1 つの SA セットしか保存できないゲートウェイの場 合は、通信を対称にすることによってこの問題を解決できます。対称判定機能を有効に すると、すべての VPN セッションは 1 つのクラスタ・メンバによって処理されるように 設定されます。対称判定機能を有効にするには、SmartDashboard でクラスタ・オブジェクト >［ClusterXL］ページ >［Advanced］を選択して、 ［Use Sticky Decision Function］プロパティを 有効にします。 ハブ・アンド・スポーク型トポロジでのサードパーティ製ゲートウェイ 負荷共有モードで対称判定機能が必要なケースとして、特定のサードパーティ製ゲート ウェイをハブ・アンド・スポーク型に構成する場合があります。サードパーティ製ゲー トウェイは、複数の SA セットを保存する機能がないため、重複 SA を避けるために、1 つ のクラスタ・メンバ上で VPN トンネルを保持する必要があります。この構成を図 3-2 に示 します。 図 3-2 スポークとしてサードパーティ製ゲートウェイとのスター型トポロジ VPN を サポートする ClusterXL 第3章 対称通信 33 対称通信の設定 この例では、以下が行われます。 ■ ■ ■ ■ この構成の目的は、スポーク A の後ろにあるホストが、スポーク B の後ろにある ホストと通信できるようにすることです。 ClusterXL ゲートウェイは負荷共有モードでクラスタ・メンバ A と B で構成され、 VPN ハブとして機能しています。 スポーク A はサードパーティ製ゲートウェイで、ハブを経由する VPN トンネルに よってスポーク B と接続されています。 スポーク B は、別のサードパーティ製ゲートウェイまたはチェック・ポイント・ ゲートウェイのどちらでも構いません。 スポーク A と B は、常に同じクラスタ・メンバを使用して通信するように設定する必要 があります。対称判定機能を有効にすると、一方のサードパーティ製ゲートウェイで開 始されたすべての VPN セッションは 1 つのクラスタ・メンバによって処理されるため、こ の問題の一部は解決されます。それでは、スポーク A と B 間のすべての通信が常に同じ クラスタ・メンバを使用するにはどのようにしたらよいでしょうか。user.def ファイル を多少変更することによって、両方のサードパーティ製ゲートウェイは常に同じクラス タ・メンバに接続するように設定できるため、トンネルの整合性が保持され、この問題 を回避できます。設定方法については、35 ページの「ハブ・アンド・スポーク型トポロ ジでサードパーティ製ゲートウェイを確立する方法」を参照してください。 対称通信の設定 対称判定機能の設定 対称判定機能は、SmartDashboard クラスタ・オブジェクト >［ClusterXL］ページ >［Advanced Load Sharing Configuration］ ウィンドウ（図 3-3 を参照）で設定できます。 図 3-3 対称判定機能の設定 デフォルトでは、対称判定機能は無効になっています。 34 ハブ・アンド・スポーク型トポロジでサードパーティ製ゲートウェイを確立する方法 ハブ・アンド・スポーク型トポロジでサードパーティ製ゲートウェイを 確立する方法 ハブ・アンド・スポーク型トポロジでサードパーティ製ゲートウェイをスポークとして 確立するには、管理サーバで以下の手順を実行します。 1 対称判定機能を有効にします。SmartDashboard でクラスタ・オブジェクト > ［ClusterXL］ ページ >［Advanced］ を選択して、 ［Use Sticky Decision Function］ プロパ ティを有効にします。 2 特定のピアからのトラフィックを処理するトンネル・グループを作成します。テキ スト・エディタを使用して $FWDIR/lib/user.def ファイルを編集し、以下の行を 追加します。 all@{member1,member2} vpn_sticky_gws = {<10.10.10.1;1>, <20.20.20.1;1>}; この設定のエレメントは以下のとおりです。 3 エレメント 説明 all クラスタ・ゲートウェイのすべてのインタフェースを表します。 member1,member2 SmartDashboard 内のクラスタ・メンバの名前。 vpn_sticky_gws テーブルの名前。 10.10.10.1 スポーク A の IP アドレス。 20.20.20.1 スポーク B の IP アドレス。 ;1 トンネル・グループ識別子。これらの IP アドレスからのトラ フィックは、同じクラスタ・メンバによって処理する必要がある ことを示します。 前述と同じ書式で IP アドレスを入力して、ほかのピアをトンネル・グループに追加 できます。スポーク C を追加するには、以下のように入力します。 all@{member1,member2} vpn_sticky_gws = {<10.10.10.1;1>, <20.20.20.1;1>,<30.30.30.1;1>}; トンネルグループ識別子 ;1 が同じであることに注意してください。これは、表示さ れたピアは常に同じクラスタ・メンバを経由して通信することを意味します。 注： クラスタ・メンバよりも多い数のトンネル・グループを定義することもできます。 第3章 対称通信 35 対称通信の設定 つまり、この手順を実行すると、影響を受ける通信の負荷共有がオフになります。 複数のサードパーティ製ゲートウェイ・セットが相互に通信するように実装する場 合は、ゲートウェイ・ペアが特定のクラスタ・メンバと並行して動作するように設 定して、負荷共有を実現できます。たとえば、ほかの 2 つのスポーク（C と D）間の 接続をセットアップするには、単に IP アドレスを行に追加して、トンネル・グルー プ識別子を ;1 から ;2 に置き換えます。この場合、行は以下のようになります。 all@{member1,member2} vpn_sticky_gws = {<10.10.10.1;1>, <20.20.20.1;1>,<192.168.15.5;2>,<192.168.1.4;2>,}; ;1 と ;2 の 2 つのピア識別子があることに注意してください。これで、スポーク A と B は 1 つのクラスタ・メンバを経由して接続し、スポーク C と D は別のクラスタ・ メンバを経由して接続します。 注： トンネル・グループは、アクティブなクラスタ・メンバ間で分散されます。クラスタの状態が変化 （たとえば、フェイルオーバーまたはメンバのアタッチ / 切り離し）した場合、新しい状態に従って再割 り当てが行われます。 36 第 4 章 ClusterXL における HA と 負荷共有 この章の構成 HA（ハイ・アベイラビリティ）と負荷共有について 37 ページ ClusterXL トポロジの例 39 ページ ClusterXL のモード 42 ページ フェイルオーバー 49 ページ 導入計画における注意事項 51 ページ ハードウェア要件、互換性、および設定例 52 ページ チェック・ポイントのソフトウェアとの互換性 57 ページ ClusterXL の設定 62 ページ HA（ハイ・アベイラビリティ）と負荷共有について ClusterXL は、冗長構成の VPN-1 Pro ゲートウェイのクラスタ間でネットワーク・トラ フィックを分散するソフトウェアベースの負荷分散および HA ソリューションです。 ClusterXL は以下の機能を提供します。 ■ マシン障害時の透過的なフェイルオーバー ■ ミッション・クリティカルな環境でのダウンタイムの解消（ステート同期使用時） ■ スループットの向上（負荷共有モード時） ■ 透過的なアップグレード 37 HA（ハイ・アベイラビリティ）と負荷共有について クラスタ内のすべてのマシンは、他の各マシンを経由する接続を認識します。クラスタ・ メンバは、安全な同期ネットワークを介して接続とステータス情報を同期します。 クラスタ・コントロール・プロトコル（CCP）は、ClusterXL クラスタ内のマシンを結合 し、クラスタ・メンバ間で同期情報やその他の情報を受け渡します。 負荷共有 ClusterXL 負荷共有はゲートウェイのクラスタ内でトラフィックを分散し、複数のマシン の全体的なスループットを向上させます。 負荷共有構成ではクラスタ内で動作中のすべてのマシンがアクティブであり、ネット ワーク・トラフィックを処理します（アクティブ / アクティブ動作） 。 クラスタ内のチェック・ポイント・ゲートウェイがアクセス不能になった場合、残りの 動作中のマシンに対して透過的なフェイルオーバーが行われ、HA が実現します。すべて の接続が中断されることなく残りのゲートウェイ間で共有されます。 HA HA 機能を使用すると、クラスタ・メンバで障害が発生した場合でも、クラスタ・メンバ 間で負荷共有がなくても接続を維持できます。HA クラスタ内では、1 つのマシンのみが アクティブになります（アクティブ / スタンバイ動作）。アクティブなクラスタ・メンバが アクセス不能になった場合、すべての接続は中断されることなく指定されたバックアップ・ クラスタ・メンバにリダイレクトされます。同期クラスタ内では、バックアップ・クラ スタ・メンバはアクティブなクラスタ・メンバの接続状態を使用して更新されます。 HA クラスタ内では、各マシンに優先順位が与えられます。通常、最も優先順位の高いマ シンがゲートウェイとして機能します。このマシンに障害が発生した場合、次に優先順 位が高いマシンに制御が渡されます。そのマシンに障害が発生した場合、その次に優先 順位が高いマシンに制御が引き継がれます。 ゲートウェイが復帰した場合、現在のアクティブなゲートウェイを維持する（アクティブ・ アップ）か、最も優先順位の高いゲートウェイに切り替える（プライマリ・アップ）ことが できます。アクティブ・アップ構成では、セキュリティ・ポリシーを変更およびインス トールするとメンバで ClusterXL 設定ハンドシェークが再起動され、別のメンバがアク ティブ・マシンとして選択される場合があります。 38 HA ClusterXL トポロジの例 このセクションの構成 クラスタ・メンバの IP アドレスの定義 40 ページ クラスタの仮想 IP アドレスの定義 41 ページ 同期ネットワーク 41 ページ 異なるサブネット上のクラスタ・アドレスの設定 41 ページ ClusterXL は、クラスタ・メンバに対しては固有の物理 IP と MAC アドレスを使用し、クラ スタ自身を表すには仮想 IP アドレスを使用します。クラスタ・インタフェース・アドレス は、どの実マシン・インタフェースにも属しません。 図 4-1 は、2 つのメンバから成る ClusterXL クラスタを示し、クラスタの仮想 IP アドレス とクラスタ・メンバの物理 IP アドレスを対比しています。 各クラスタ・メンバは、外部インタフェース、内部インタフェース、および同期用イン タフェースの 3 つのインタフェースを持っています。各方向のクラスタ・メンバ・インタ フェースは、スイッチ、ルーター、または VLAN スイッチを介して接続されています。 同じ方向のすべてのクラスタ・メンバ・インタフェースは、同じネットワーク内にある 必要があります。たとえば、クラスタ・メンバ間にルータを置くことはできません。 SmartCenter 管理サーバはどこにでも配置できますが、内部または外部クラスタ・アドレ スのいずれかにルーティング可能である必要があります。 この例に示された ClusterXL 構成の説明については、図 4-1 の後続のセクションを参照し てください。 注： 1. HA Legacy モードは別のトポロジを使用するため、付録（149 ページの「HA Legacy モード」）で 説明します。 2. このセクションと後続のセクションの例では、RFC 1918 プライベート・アドレスである、 192.168.0.0 ～ 192.168.255.255 のアドレス範囲を使用して、ルーティング可能な （パブリック）IP アドレスを表します。 第4章 ClusterXL における HA と負荷共有 39 ClusterXL トポロジの例 図 4-1 ClusterXL トポロジの例 クラスタ・メンバの IP アドレスの定義 各クラスタ・メンバ・マシンを構成するためのガイドラインは以下のとおりです。 クラスタ内のすべてのマシンは、少なくとも以下の 3 つのインタフェースを持っている 必要があります。 ■ ■ ■ 外部クラスタ・インタフェースを介してインターネットに接続されるインタ フェース 内部クラスタ・インタフェースを介して内部ネットワークに接続されるインタ フェース 同期に使用するインタフェース 同じ方向へ向かうインタフェースはすべて同一のネットワークに接続する必要があり ます。 40 クラスタの仮想 IP アドレスの定義 たとえば、図 4-1 の構成では Member_A と Member_B の 2 つのクラスタ・メンバがありま す。各メンバには IP アドレスが割り当てられており、ハブまたはスイッチを介してイン ターネットに接続します。これは、Member_A に 192.168.10.1、Member_B に 192.168.10.2 の IP アドレスが割り当てられた外部インタフェースで、クラスタの外部インタフェース からはこのインタフェースは透過的です。 注： NGX には、メンバごとに外部インタフェースと内部インタフェースの 2 つのインタフェースのみを 使用し、内部インタフェース経由で同期を実行するオプションがあります。この構成はお勧めしません。 バックアップの場合にのみ使用してください。詳細については、第 2 章「クラスタ間での接続情報の同期」 を参照してください。 クラスタの仮想 IP アドレスの定義 図 4-1 ではクラスタの IP アドレスは 192.168.10.100 です。 クラスタは外部仮想 IP アドレスと内部仮想 IP アドレスをそれぞれ 1 つずつ持っています。 外部 IP アドレスは 192.168.10.100 で、内部仮想 IP アドレスは 10.10.0.100 です。 同期ネットワーク クラスタ・メンバのステート同期により、フェイルオーバーが発生しても障害の発生し たマシンで処理されていた接続は維持されます。同期ネットワークは、クラスタ・メン バ間で接続同期情報とその他の状態情報を受け渡すために使用されます。つまり、この ネットワークは組織の最も重要なセキュリティ・ポリシー情報を送信するため、ネット ワークを安全に保護する必要があります。バックアップのために複数の同期ネットワー クを定義できます。 同期インタフェースを保護するにはクロス・ケーブルで直接接続するか、メンバが 3 つ以 上のクラスタの場合には専用ハブまたはスイッチを使用して接続する必要があります。 負荷共有クラスタのマシンは、通常のトラフィック・フローで同期が使用されているた め同期させる必要があります。HA クラスタ内のコンピュータは同期させる必要はありま せんが、同期していない場合はフェイルオーバー時に接続が失われます。 図 4-1 は、各マシンに固有の IP アドレスが割り当てられた同期インタフェースを示してい ます。Member_A には 10.0.10.1、Member_B には 10.0.10.2 が割り当てられています。 異なるサブネット上のクラスタ・アドレスの設定 インターネットに接続するクラスタ・インタフェースの場合、ClusterXL クラスタ内でルー ティング可能な IP アドレスが 1 つだけ必要です。すべてのクラスタ・メンバの物理 IP ア ドレスはルーティングできなくても構いません。 第4章 ClusterXL における HA と負荷共有 41 ClusterXL のモード クラスタ IP アドレスとメンバ・アドレスに対して別のサブネットを設定すると、以下が 可能になります。 ■ ■ 新しいアドレスをクラスタ・メンバに割り当てなくても、複数マシンのクラスタが 構成済みのネットワーク内の単一マシン・ゲートウェイと置き換わる。 組織が ClusterXL ゲートウェイ・クラスタの唯一のルーティング可能なアドレスを使 用する。これによりルーティング可能なアドレスが節約されます。 詳細については、133 ページの「異なるサブネット上のクラスタ・アドレスの設定」を 参照してください。 ClusterXL のモード このセクションの構成 ClusterXL のモードについて 42 ページ 負荷共有マルチキャスト・モード 43 ページ 負荷共有ユニキャスト・モード 44 ページ HA New モード 46 ページ 各モードの比較表 48 ページ ClusterXL のモードについて ClusterXL には以下の 4 つの実行モードがあります。このセクションでは、各モードとそ の相対的な利点と欠点について説明します。 ■ 負荷共有マルチキャスト・モード ■ 負荷共有ユニキャスト・モード ■ HA New モード ■ HA Legacy モード HA Legacy モードについては、付録（149 ページの「HA Legacy モード」）で説明します。 下位互換性の問題を回避するためには、HA New モードを使用することをお勧めします。 注： このセクションのすべての例は、40 ページの図 4-1 に示す ClusterXL 構成に基づいています。 42 負荷共有マルチキャスト・モード 負荷共有マルチキャスト・モード 負荷共有により、クラスタ・メンバ間でネットワーク・トラフィックを分散することがで きます。 HA では一度に 1 つのメンバのみがアクティブになるのに対して、 負荷共有ソリュー ションではすべてのクラスタ・メンバがアクティブになりクラスタが各メンバにトラ フィックを割り当てます。この割り当ては判定機能によって実行され、クラスタを通過す る各パケットを調べてどのメンバがそのパケットを処理するかを決定します。このように、 負荷共有クラスタはすべてのクラスタ・メンバを利用するため、通常は合計スループット が向上します。標準的な ClusterXL 構成の例については、40 ページの図 4-1 を参照してくだ さい。 ClusterXL 負荷共有をステート同期と組み合わせることにより、完全な HA も実現できます。 すべてのクラスタ・メンバがアクティブな場合、トラフィックはマシン間で均等に分散さ れます。メンバの 1 つで問題が発生してフェイルオーバー・イベントが発生した場合、故 障したマシンによって処理されていたすべての接続の処理は直ちにほかのメンバに引き 継がれます。 ClusterXL は、Multicast と Unicast の 2 種類の負荷共有ソリューションを提供します。この 2 つのモードでは、クラスタに送信されたパケットをメンバが受信する方法が異なりま す。このセクションでは、マルチキャスト・モードについて説明します。ユニキャスト・ モードについては、44 ページの「負荷共有ユニキャスト・モード」を参照してください。 イーサネットのネットワーク層で提供されるマルチキャスト・メカニズムを使用するこ とにより、複数のインタフェースを 1 つの物理（MAC）アドレスに対応させることがで きます。同じサブネット内のすべてのインタフェースを 1 つのアドレスにバインドするブ ロードキャストと異なり、マルチキャストではネットワーク内のでグループ化が可能で す。つまり、特定の MAC アドレスに送信されたパケットを受信する 1 つのサブネット内 のインタフェースを選択できます。 ClusterXL は、マルチキャスト・メカニズムを使用して仮想クラスタ IP アドレスをすべて のクラスタ・メンバに対応させます。これらの IP アドレスを 1 つのマルチキャスト MAC アドレスにバインドすることにより、ゲートウェイとして機能するクラスタに送信され たすべてのパケットはクラスタ内のすべてのメンバに到達します。各メンバはパケット を処理するかどうかを判定します。この判定が負荷共有メカニズムの主要な機能です。つ まり、少なくとも 1 つのメンバが各パケットを処理し（トラフィックがブロックされない ようにし）、かつ 2 つのメンバが同じパケットを処理しない（トラフィックが重複しない） ようにする必要があります。 判定機能のもう 1 つの要件は、各接続が 1 つのゲートウェイを経由するようにルーティン グし、1 つの接続に属するパケットは必ず同じメンバによって処理されるようにすること です。この要件が常に満たされるとは限らず、場合によっては同じ接続のパケットが異 なるメンバによって処理されることがあります。ClusterXL は、ステート同期メカニズム を使用してすべてのクラスタ・メンバ上の接続をミラーリングすることによりこれらの 状況を処理します。 第4章 ClusterXL における HA と負荷共有 43 ClusterXL のモード 例 この例では、負荷共有マルチキャスト・モードに設定されたファイアウォール・クラス タの背後にある Web サーバにユーザがインターネットからログインする場合について説 明します。 1 ユーザは、192.168.10.78（ユーザのコンピュータ）から 10.10.0.34（Web サーバ ) への接続を要求します。 2 192.168.10.x ネットワーク上のルータは、192.168.10.100（クラスタの仮想 IP アドレス）を 10.10.0.x ネットワークへのゲートウェイとして認識します。 3 ルータは、ARP 要求を 192.168.10.100 に対して発行します。 4 アクティブ・メンバの 1 つはこの ARP 要求を傍受し、クラスタ IP アドレス 192.168.10.100 に割り当てられたマルチキャスト MAC アドレスで応答します。 5 Web サーバはユーザの要求に応答する場合、10.10.0.100 をインターネットへのゲー トウェイとして認識します。 6 Web サーバは 10.10.0.100 に対して ARP 要求を発行します。 7 アクティブ・メンバの1つはこのARP要求を傍受し、クラスタIPアドレス 10.10.0.100 に割り当てられたマルチキャスト MAC アドレスで応答します。 8 ユーザと Web サーバ間で送信されたすべてのパケットはすべてのクラスタ・メンバに 到達し、各クラスタ・メンバは各パケットを処理するか破棄するかを判定します。 9 フェイルオーバーが発生するとクラスタ・メンバの 1 つがダウンします。この場合で も、トラフィックはすべてのアクティブなクラスタ・メンバに到達しているためネッ トワークの ARP ルーティングを変更する必要はありません。変更が行われるのはク ラスタの判定機能のみです。判定機能はメンバの新しい状態を考慮に入れます。 負荷共有ユニキャスト・モード 負荷共有ユニキャスト・モードは、マルチキャスト・イーサネットが動作できない環境 に対応する負荷共有ソリューションを提供します。このモードでは、 「ピボット」と呼ば れる 1 つのクラスタ・メンバにクラスタの仮想 IP アドレスが割り当てられ、これがクラス タに送信されたパケットを受信する唯一のメンバになります。ピボットは他のクラスタ・ メンバにパケットを送信する役割を果たし、負荷共有メカニズムを構築します。負荷共有 は、負荷共有マルチキャスト・モードと同様に、各パケットに判定機能を適用することに よって行われます。異なる点は、1 つのメンバのみがこの選択を行うという点です。ピボッ ト以外のメンバは、転送されたパケットを受信すると判定機能を適用せずにパケットを処 理します。ピボット以外のメンバは依然として「アクティブ」と見なされることに注意し てください。これは、これらのメンバも分担しているトラフィックについて（判定は行い ませんが）ルーティングとファイアウォール作業を行っているためです。 44 負荷共有ユニキャスト・モード ピボット・メンバは判定プロセスを担当しますが、同時にファイアウォール・モジュー ルとしてパケットの処理も行います（たとえば、ローカル・マシン上でパケットを処理 するために判定を行う場合もあります）。ただし、このような作業をピボット・メンバに 追加すると時間がかかる可能性があるため、通常ピボット・メンバには全負荷のうちの 小さな部分のみを割り当てます。 ピボット以外のメンバにフェイルオーバー・イベントが発生すると、そのメンバが処理 していた接続はアクティブなクラスタ・メンバに再配分され、HA New モードや負荷共有 マルチキャスト・モードと同等の HA 機能が提供されます。ピボット・メンバに問題が発 生した場合は、通常のフェイルオーバー・イベントが発生し、さらに別のメンバが新た にピボットの役割を引き継ぎます。ピボット・メンバは常に最も高い優先順位を持つア クティブ・メンバです。これは、前のピボットが回復した場合に以前の役割を保持する ことを意味します。 標準的な ClusterXL 構成の例については、40 ページの図 4-1 を参照してください。 例 この例では、負荷共有ユニキャスト・クラスタをユーザのコンピュータと Web サーバの 間のゲートウェイとして使用しています。 1 ユーザは 192.168.10.78（ユーザのコンピュータ）から 10.10.0.34（Web サーバ ) への 接続を要求します。 2 192.168.10.x ネットワーク上のルータは、192.168.10.100（クラスタの仮想 IP アド レス）を 10.10.0.x ネットワークへのゲートウェイとして認識します。 3 ルータは 192.168.10.100 に対して ARP 要求を発行します。 4 ピボット・メンバはこの ARP 要求を傍受し、自分の固有 IP アドレス 192.168.10.1 に 対応する MAC アドレスで応答します。 5 Web サーバはユーザの要求に応答する場合、10.10.0.100 をインターネットへのゲー トウェイとして認識します。 6 Web サーバは 10.10.0.100 に対して ARP 要求を発行します。 7 ピボット・メンバはこの ARP 要求を傍受し、自分の固有 IP アドレス 10.10.0.1 に対応 する MAC アドレスで応答します。 8 ユーザの要求パケットは、インタフェース 192.168.10.1 上のピボット・メンバに到達 します。 9 ピボットは 2 番目のメンバにこのパケットを処理させることを決定し、パケットを 192.168.10.2 へ転送します。 10 2 番目のメンバは、そのパケットを転送されたパケットとして認識して処理します。 11 それ以降のパケットはピボット・メンバによって処理されるか、転送されてこの 2 番目のメンバによって処理されます。 第4章 ClusterXL における HA と負荷共有 45 ClusterXL のモード 12 ピボットでフェイルオーバーが発生すると2番目のメンバがピボットの役割を引き継 ぎます。 13 新しいピボット・メンバは、192.168.10.x ネットワークと 10.10.0.x ネットワークの 両方に余分に ARP 要求を送信します。これらの要求は、仮想 IP アドレス 192.168.10.100 を固有の IP アドレス 192.168.10.2 に対応する MAC アドレスに関連付 け、仮想 IP アドレス 10.10.0.100 を固有の IP アドレス 10.10.0.2 に対応する MAC ア ドレスに関連付けます。 14 このクラスタに送信されたトラフィックは新しいピボットによって受信され、その ローカル・マシンによって処理されます（これは、現時点ではこのマシンがクラスタ 内で唯一のアクティブなマシンであるためです） 。 15 最初のマシンが復帰すると、クラスタの IP アドレスを自分の固有 MAC アドレスに関 連付けてピボットの役割を再開します。 HA New モード HA New モードは、クラスタ環境で基本的な HA 機能を提供します。これは、スタンドア ロン・モジュール上で発生した場合に完全に接続が失われるような問題がクラスタ上で 発生しても、クラスタはファイアウォール・サービスを提供できることを意味します。 ClusterXL HA をチェック・ポイントのステート同期と組み合わせて使用すると、フェイ ルオーバー・イベントが発生してもユーザに気付かれない方法で接続が維持されるため、 接続性に全く影響はありません。このように、HA はバックアップ・メカニズムを提供し ます。組織はこのバックアップ・メカニズムを利用して、特にミッション・クリティカル な環境（たとえば、インターネットを経由した電子商取引が発生するような環境）で予期 せぬダウンタイムが発生する危険性を軽減することができます。 これを実現するために、ClusterXL の HA New モードではクラスタ・メンバの 1 つをアク ティブ・マシンとして指定して残りのメンバはスタンバイ・モードにしておきます。ク ラスタの仮想 IP アドレスは、アクティブ・マシンの物理ネットワーク・インタフェース に関連付けます（仮想 IP アドレスを該当するインタフェースの固有の MAC アドレスに一 致させます）。このようにして、クラスタへのすべてのトラフィックはアクティブ・メン バによって実際にルーティング（さらにフィルタリング）されます。各クラスタ・メン バの役割はその優先順位に従って選択され、アクティブ・メンバが最高の優先順位を持 ［Gateway Cluster Properties］ ウィンドウの つメンバになります。メンバの優先順位は、 ［Cluster Members］ ページに表示される順序に対応します。最上部に表示されたメンバが 最高の優先順位を持ちます。この優先順位はいつでも変更することができます。 アクティブ・メンバは、ファイアウォール・ゲートウェイとしての役割のほかに自分の 接続テーブルと状態テーブルに対して行われた変更のすべてをスタンバイ・メンバに通 知することにより、現在クラスタを通過しているトラフィックに関する最新情報をメン バに提供する役割も持っています。 46 HA New モード クラスタはフェイルオーバー・イベントが発生するような重大な問題をアクティブ・メ ンバで検出すると、アクティブ・メンバの役割をスタンバイ・マシンの 1 つ（その時点で 最高の優先順位を持っているメンバ）に引き渡します。ステート同期が適用されている 場合は、開始されているすべての接続を新しいアクティブ・マシンが認識し、直前の既 知状態に従って処理します。より高い優先順位を持つメンバが復帰した際には、ユーザの 設定によってアクティブ・マシンの役割がそのメンバに切り替えられる場合と切り替えら れない場合があります。 クラスタはスタンバイ・マシンで問題を検出する場合もあります。この場合、問題が発 生したマシンはフェイルオーバー発生時にアクティブ・メンバの役割を引き継ぐことが できるとは見なさ れません。 標準的な ClusterXL 構成の例については、40 ページの図 4-1「ClusterXL トポロジの例」を 参照してください。 例 この例では、ファイアウォール・クラスタの背後にある Web サーバにユーザがインター ネットからログインする場合について説明します。 1 ユーザは 192.168.10.78（ユーザのコンピュータ）から 10.10.0.34（Web サーバ ) への 接続を要求します。 2 192.168.10.x ネットワーク上のルータは、192.168.10.100（クラスタの仮想 IP アド レス）を 10.10.0.x ネットワークへのゲートウェイとして認識します。 3 ルータは 192.168.10.100 に対して ARP 要求を発行します。 4 アクティブ・メンバはこの ARP 要求を傍受し、自分の固有 IP アドレス 192.168.10.1 に対応する MAC アドレスで応答します。 5 Web サーバはユーザの要求に応答する場合、10.10.0.100 をインターネットへのゲー トウェイとして認識します。 6 Web サーバは 10.10.0.100 に対して ARP 要求を発行します。 7 アクティブ・メンバはこの ARP 要求を傍受し、自分の固有 IP アドレス 10.10.0.1 に対 応する MAC アドレスで応答します。 8 ユーザと Web サーバ間のすべてのトラフィックは、アクティブ・メンバを経由して ルーティングされるようになります。 9 フェイルオーバーが発生すると、スタンバイ・メンバは障害の発生したアクティブ・ メンバに置き換わる必要があると判断します。 10 スタンバイ・メンバは、192.168.10.x ネットワークと 10.10.0.x ネットワークの両方に Gratuitous ARP 要求を送信します。これらの要求は、仮想 IP アドレス 192.168.10.100 を 固有の IP アドレス 192.168.10.2 に対応する MAC アドレスに関連付け、仮想 IP アド レス 10.10.0.100 を固有の IP アドレス 10.10.0.2 に対応する MAC アドレスに関連付 けます。 第4章 ClusterXL における HA と負荷共有 47 ClusterXL のモード 11 スタンバイ・メンバはアクティブ・メンバの役割を持つように切り替えられ、このク ラスタを経由するすべてのトラフィックはこのマシンを経由してルーティングされ ます。 12 以前のアクティブ・メンバは「ダウン」したと見なされ、フェイルオーバー・イベン トを発生させた問題からの復帰待ち状態になります。 各モードの比較表 表 4-1 に、各 ClusterXL モードの共通点と相違点をまとめます。 表 4-1 各 ClusterXL モードの比較表 HA Legacy HA New 負荷共有 マルチキャスト 負荷共有 ユニキャスト HA ○ ○ ○ ○ 負荷共有 X X ○ ○ パフォーマンス 良い 良い 優秀 非常に良い ハードウェア・ サポート すべて すべて サポートされていな いルータあり すべて SecureXL サポート 可能 可能 ステート同期の 必要性 必須でない 必須でない 必須 必須 VLAN タグ付けの サポート 1 サポート サポート サポート サポート 可能 （Performance Pack または SecureXL Turbocard を使用） 可能 詳細については、『Check Point Enterprise Suite NGX (R60) Release Notes』を参照してく ださい。このリリース・ノートは http://www.checkpoint.com/downloads/index.html からダ ウンロードできます。 1 48 フェイルオーバーとは フェイルオーバー このセクションの構成 フェイルオーバーとは 49 ページ フェイルオーバーはいつ発生するか 50 ページ ゲートウェイが復帰した場合の処理 50 ページ 復帰したクラスタ・メンバがセキュリティ・ポリシーを 取得する方法 51 ページ フェイルオーバーとは フェイルオーバーは、ゲートウェイが指定された機能を実行できなくなったときに発生 します。フェイルオーバーが発生すると、クラスタ内の別のゲートウェイが障害が発生 したゲートウェイの役割を引き継ぎます。 負荷共有構成では、ゲートウェイのクラスタ内にある 1 つの VPN-1Pro ゲートウェイがダ ウンすると接続は残りのゲートウェイに分散されます。負荷共有構成ではすべてのゲー トウェイが同期されているため、どの接続も中断されません。 HA 構成では、同期クラスタ内の 1 つのゲートウェイがダウンすると別のゲートウェイが アクティブになり、障害が発生したゲートウェイの接続を「引き継ぎ」ます。ステート 同期を使用していない場合、フェイルオーバーが発生すると既存の接続は切断されます。 ただし新しい接続を開始できます。 ほかのゲートウェイが稼動して機能していることを各クラスタ・メンバに知らせるため、 ClusterXL のクラスタ・コントロール・プロトコルではクラスタ・メンバ間でハート・ビー トが常時やり取りされています。所定の時間が経過してもあるクラスタ・メンバからメッ セージが受信できない場合、このクラスタ・メンバがダウンしフェイルオーバーが発生 した可能性があります。この時点で別のクラスタ・メンバが自動的に障害の起きたクラ スタ・メンバの役割を引き継ぎます。 クラスタ内で上記のいずれかのチェックに失敗した場合、障害が発生したメンバはクラ スタ・メンバとして機能できないと判断し、たとえクラスタ・マシンがまだ機能してい る可能性があったとしてもフェイルオーバーを開始します。 フェイルオーバー・イベントを発生させるような問題が複数のクラスタ・メンバで起こ る 場合 が あり ま す。す べて の クラ ス タ・メ ン バで こ のよ う な問 題 が 発生 し た場 合、 ClusterXL は 1 つのメンバを選択して動作を継続しようとします。選択されたメンバの状 態は「アクティブ・アテンション」として報告されます。この状況は別のメンバが完全に復 帰するまで続きます。たとえば、クラスタ・メンバを接続するクロス・ケーブルが故障 した場合、両方のメンバがインタフェースの問題を検出します。一方が「ダウン」状態に 変化し、もう一方が「アクティブ・アテンション」に変化します。 第4章 ClusterXL における HA と負荷共有 49 フェイルオーバー フェイルオーバーはいつ発生するか フェイルオーバーはアクティブなクラスタ・メンバで以下のいずれかが生じたときに発 生します。 クリティカル・デバイス（たとえば、fwd）の障害。クリティカル・デバイスとは クラスタ・メンバで動作するプロセスで、クラスタ・メンバがメンバとして機能で きなくなった場合にほかのクラスタ・メンバに通知することを可能にします。クリ ティカル・デバイスは自分の現在の状態について ClusterXL メカニズムに報告します。 報告に失敗した場合、ClusterXL はフェイルオーバーが発生してほかのクラスタ・ メンバが引き継いだと判断します。 ■ ■ インタフェースまたはケーブルの障害 ■ マシンのクラッシュ ■ セキュリティ・ポリシーのアンインストール。セキュリティ・ポリシーがアンイン ストールされると、ゲートウェイはファイアウォールとして機能できなくなります。 ファイアウォールとして機能できない場合、クラスタ・メンバとして機能できなく なりフェイルオーバーが発生します。通常、ポリシーが自動的にアンインストール されることはなくユーザによってアンインストールされます。 ゲートウェイが復帰した場合の処理 負荷共有構成では、クラスタ内の障害が発生したゲートウェイが復帰した場合、すべて の接続はすべてのアクティブ・メンバ間で再配分されます。 HA 構成では、クラスタ内の障害が発生したゲートウェイが復帰した場合、復帰方法は クラスタ設定によって異なります。以下のモードを選択できます。 ■ ［Maintain Current Active Gateway］ を選択すると、優先順位の低いマシンに制御が引き 継がれた場合、優先順位の低いアクティブ・マシンに障害が発生した場合にだけ制 御が優先順位の高いマシンに戻ります。すべてのメンバが同じトラフィック処理能 力を備えている場合は、フェイルオーバー・イベントの発生を最小限にするためこ のモードを使用することをお勧めします。 ■ ［Switch to Higher Priority Gateway］を選択すると、優先順位の低いマシンに制御が引 き継がれた場合、優先順位の高いマシンが復帰すると制御は優先順位の高いマシン に戻ります。1 つのメンバがほかのメンバよりも高い接続処理能力を持っている場合 は、このモードを選択することをお勧めします。そのメンバはデフォルト・ゲート ウェイになります。 50 復帰したクラスタ・メンバがセキュリティ・ポリシーを取得する方法 復帰したクラスタ・メンバがセキュリティ・ポリシーを取得する方法 管理者はセキュリティ・ポリシーをクラスタ・メンバごとにではなく、クラスタにイン ストールします。ポリシーは自動的にすべてのクラスタ・メンバにインストールされま す。ポリシーは、クラスタ・メンバ・オブジェクトの［General Properties］ ページで定義 された IP アドレスに送信されます。 障害が発生したクラスタ・メンバが復帰すると、まずほかのクラスタ・メンバのいずれ かからポリシーを取得しようとします。これは、ほかのクラスタ・メンバが新しいポリ シーを持っていることを前提としています。成功しなかった場合、復帰したメンバは自 分のローカル・ポリシーを SmartCenter サーバにあるポリシーと比較します。SmartCenter サーバのポリシーが自分のポリシーよりも新しい場合は、SmartCenter サーバのポリシー を取り込みます。クラスタ・メンバがローカル・ポリシーを持っていない場合、SmartCenter サーバからポリシーを取り込みます。これにより、すべてのクラスタ・メンバは常に同 じポリシーを使用することになります。 導入計画における注意事項 このセクションの構成 HA または負荷共有 51 ページ 負荷共有モードの選択 51 ページ IP アドレスの移行 52 ページ HA または負荷共有 負荷共有（アクティブ / アクティブ）構成と HA（アクティブ / スタンバイ）構成のどちらを 選択するかは、組織の要件によって決まります。HA ゲートウェイ・クラスタは、フェイル セーフな接続性を組織に保証します。負荷共有には、これにパフォーマンスが向上すると いう利点があります。 負荷共有モードの選択 負荷共有マルチキャスト・モードは、負荷がすべてのクラスタ・メンバ間で最適に分散 されるため高い負荷を効率的に処理できます。ただし、一部のルータは負荷共有マルチ キャスト・モードで使用できません。負荷共有マルチキャスト・モードでは、マルチキャ スト MAC アドレスを各ユニキャスト・クラスタ IP アドレスに関連付けます。これによ り、クラスタへのトラフィックはすべてのメンバによって受信されます。したがって、ク ラスタ・メンバが送信する ARP 応答には、マルチキャスト MAC アドレスを介してクラス タ IP アドレスに到達可能であることが示されます。 第4章 ClusterXL における HA と負荷共有 51 ハードウェア要件、互換性、および設定例 一部のルーティング機器はこのような ARP 応答を受け付けません。一部のルータでは、 ルーティング機器上でクラスタ IP アドレスにスタティックな ARP エントリを追加してこ の問題を解決します。ほかのルータは、この種のスタティックな ARP エントリを受け付 けません。 もう 1 つの注意事項は、無差別モードで動作するインタフェースを持つルーティング機器 が導入環境に含まれているかどうかです。同じネットワーク・セグメント上にそのよう なルータ 2 台と負荷共有マルチキャスト・モードの ClusterXL ゲートウェイが存在する場 合、一方のルータから生成されたクラスタへのトラフィックは、もう一方のルータによっ て処理される可能性もあります。 このような場合は負荷共有ユニキャスト・モードを使用します。このモードではクラス タ・アドレスに対してマルチキャストを使用する必要はありません。 サポートされているハードウェア機器の一覧については、55 ページの「ClusterXL のハー ドウェアの互換性」を参照してください。 IP アドレスの移行 既存の単一ゲートウェイ構成に HA 機能または負荷共有機能を追加する場合、現在のゲー トウェイから既存の IP アドレスを取り出してクラスタ・アドレス（クラスタの仮想アド レス）にすることをお勧めします。こうすることにより、多くの場合、現在の IPSec エン ドポイント識別情報を変更せずに Hide NAT 設定もそのまま維持することができます。 ハードウェア要件、互換性、および設定例 このセクションの構成 ClusterXL のハードウェア要件 52 ページ ClusterXL のハードウェアの互換性 55 ページ Cisco Catalyst ルーティング・スイッチの設定例 55 ページ ClusterXL のハードウェア要件 ゲートウェイ・クラスタは通常、スイッチやルータなどのほかのネットワーク機器が存 在する環境に配置されます。これらの機器とゲートウェイは、ネットワークの接続性を 保証するために相互動作する必要があります。このセクションでは、周辺のネットワー ク環境に対する ClusterXL の要件について説明します。 52 ClusterXL のハードウェア要件 このセクションの構成 HA New モードと負荷共有ユニキャスト・モードに対する ハードウェア要件 53 ページ 負荷共有マルチキャスト・モードに対するハードウェア要件 54 ページ HA New モードと負荷共有ユニキャスト・モードに対するハードウェア要件 マルチキャスト・モードは、HA New モードと負荷共有ユニキャスト・モード（および負 荷共有マルチキャスト・モード）におけるデフォルトの CCP（クラスタ・コントロール・ プロトコル）モードです。マルチキャスト・モードで CCP を使用する場合は、スイッチを 以下のように設定する必要があります。 表 4-2 HA New モードと負荷共有ユニキャスト・モードに対するスイッチの設定 スイッチの設定 説明 IGMP とスタ ティック CAM ClusterXL は IGMP の登録（「IGMP スヌーピング」とも呼ばれます）をサポートして いません。IGMP パケットを利用してポートを設定するスイッチではこの機能を無効 にする必要があります。 IGMP の登録を無効にできない場合には、特定のポートでマルチキャスト・トラ フィックを許可するためにスタティック CAM を設定する必要があります。 マルチキャスト 制限の無効化 一部のスイッチでは、ブロードキャスト・ストームを防ぐために通過できるブロード キャストとマルチキャストに上限を設けています。通常この制限は全インタフェース 帯域に対する割合（%）です。 ブロードキャスト・ストーム制御をオフにするか、高レベルのブロードキャストまた はマルチキャストに対してスイッチの通過を許可することができます。 接続するスイッチにこのような設定機能がない場合には、効率は下がりますがスイッ チがブロードキャストを使用してトラフィックを転送したり、クラスタ・メンバを設 定して（63 ページの「クラスタ・メンバでの CCP トランスポート・モードの選択」 を参照）ブロードキャスト CCP を使用することができます。 ルータを以下のように設定する必要があります。 表 4-3 HA New モードと負荷共有ユニキャスト・モードに対するルータの設定 ルータの設定 説明 ユニキャスト MAC クラスタが HA Legacy モード、HA New モード、および負荷共有ユニキャスト・ モードで動作する場合、クラスタの IP アドレスは通常の MAC アドレス（アクティ ブ・メンバの MAC アドレス）にマッピングされます。ルータは通常の ARP メッ セージからこの MAC アドレスを認識できる必要があります。 第4章 ClusterXL における HA と負荷共有 53 ハードウェア要件、互換性、および設定例 負荷共有マルチキャスト・モードに対するハードウェア要件 負荷共有マルチキャスト・モードで動作している場合、スイッチの設定は以下のとおり です。 表 4-4 負荷共有マルチキャスト・モードに対するスイッチの設定 スイッチの設定 説明 マルチキャスト・ モードでの CCP マルチキャスト・モードは、負荷共有マルチキャストにおけるデフォルトのクラスタ・ コントロール・プロトコル・モードです。必須のスイッチ設定の詳細については、 53 ページの表 4-2 を参照してください。 ポートの ミラーリング ClusterXL では、ユニキャスト MAC アドレスでポート・ミラーリングを行ってマル チキャスト負荷共有ソリューションを実現することはできません。 負荷共有マルチキャスト・モードで動作している場合、ルータはマルチキャスト MAC アド レスを使用したユニキャスト IP パケットの送信をサポートする必要があります。これは 必須であるため、すべてのクラスタ・メンバがデータ・パケットを受信します。 ルータのモデルによっては、このモードをサポートするために以下のように設定する必要 があります。 表 4-5 負荷共有マルチキャスト・モードに対するルータの設定 ルータの設定 説明 スタティック MAC ほとんどのルータは、自動的に ARP メカニズムを使用してユニキャスト IP とマルチ キャスト MAC を含む arp エントリを認識できます。ルータが動的にこの種のマッピ ングを認識する機能を持っていない場合は、スタティックな MAC エントリを設定す る必要があります。 IGMP とスタ ティック CAM 一部のルータは、マルチキャスト MAC アドレスを使用したユニキャスト IP パケッ トの送信をサポートするために、IGMP スヌーピングを無効にするかスティック CAM を設定する必要があります。 マルチキャスト 制限の無効化 一部のルータでは、ブロードキャスト・ストームを防ぐために通過できるブロード キャストとマルチキャストに上限を設けています。通常この制限は全インタフェー ス帯域に対する割合（%）です。 ブロードキャスト・ストーム制御をオフにするか高レベルのブロードキャストまた はマルチキャストに対してルータの通過を許可することができます。 ルータへの マルチキャスト・ トラフィック 転送の無効化 一部のルータは、ルータ自身にマルチキャスト・トラフィックを送信します。これ により、ネットワーク全体でパケット・ストームが発生する可能性があるため転送 を無効にする必要があります。 54 ClusterXL のハードウェアの互換性 ClusterXL のハードウェアの互換性 以下のルータとスイッチは、すべての ClusterXL モードと互換性があります。 ルータ ■ Cisco 7200 シリーズ ■ Cisco 1600、2600、3600 シリーズ ルーティング・スイッチ ■ Extreme Networks Blackdiamond（IGMP スヌーピングを無効化） ■ Extreme Networks Alpine 3800 シリーズ（IGMP スヌーピングを無効化） ■ Foundry Network Bigiron 4000 シリーズ ■ Nortel Networks Passport 8600 シリーズ ■ Cisco Catalyst 6500 シリーズ（IGMP スヌーピングを無効化、マルチキャスト MAC を 手動設定） スイッチ ■ ■ Cisco Catalyst 2900、3500 シリーズ Nortel BayStack 450 ■ Alteon 180e ■ Dell PowerConnect 3248 と PowerConnect 5224 Cisco Catalyst ルーティング・スイッチの設定例 以下の例では、Cisco Catalyst 6500 シリーズ・ルーティング・スイッチで ClusterXL をサ ポートするために必要な設定コマンドの実行方法を示します。詳細または他のネット ワーキング機器の手順については、各機器のマニュアルを参照してください。 この例は、64 ページの図 4-2 で説明した構成例に基づいています。 IGMP スヌーピングの無効化 IGMP スヌーピングを無効にするには、以下のコマンドを実行します。 no ip igmp snooping 第4章 ClusterXL における HA と負荷共有 55 ハードウェア要件、互換性、および設定例 スタティック CAM エントリの定義 モジュール 1（ポート 1）とモジュール 2（ポート 1、3、および 8 ～ 12）に対する永続 マルチキャスト・エントリをテーブルに追加するには、以下のコマンドを入力します。 Console> (enable) set cam permanent 01-40-5e-28-0a-64 1/1,2/1,2/3,2/8-12 Permanent multicast entry added to CAM table. Console> (enable) 設定が必要な MAC アドレスを決定するには、以下の手順を使用します。 クラスタ IP アドレスが x.y.z.w のネットワーク上では以下のようになります。 y<=127 の場合、マルチキャスト MAC アドレスは 01:00:5e:y:z:w です。たとえば、 クラスタ IP アドレスが 192.90.10.100 の場合 MAC アドレスは 01:00:5e:5A:0A:64 です。 y>=127 の場合、マルチキャスト MAC アドレスは 01:00:5e:(y-128):z:w です。たとえ ば、クラスタ IP アドレスが 192.168.10.100 の場合、MAC アドレスは 01:00:5e:28:0A:64 です（168-128=40 で、16 進数の「28」 ）。 同期などのクラスタ IP アドレスを持たないネットワーク x.y.z.0 の場合の手順は同じです が、MAC の最後のオクテット 0 の代わりに fa を使用します。 たとえば、10.0.0.X ネットワークの場合 MAC アドレスは 01:00:5e:00:00:fa です。 マルチキャスト制限の無効化 マルチキャスト制限を無効にするには、以下のコマンドを実行します。 no storm-control multicast level ルータでのスタティック arp エントリの設定 スタティック arp エントリを定義するには、以下のコマンドを実行します。 arp 192.168.10.100 01:00:5E:28:0A:64 arpa MAC アドレスを決定するには、スタティック CAM エントリの定義の手順を実行します。 マルチキャスト・パケットがルータに到着できないようにする方法 マルチキャスト・パケットがルータに到着できないようにするには、以下のコマンドを 実行します。 set cam static 01:00:5E:28:0A:64 module/port MAC アドレスを決定するには、スタティック CAM エントリの定義の手順を実行します。 56 サポートするオペレーティング・システム チェック・ポイントのソフトウェアとの互換性 このセクションの構成 57 ページ サポートするオペレーティング・システム 57 ページ サポートするチェック・ポイントのソフトウェア （SmartDefense を除く） ClusterXL がサポートする SmartDefense 機能 60 ページ 転送レイヤ 61 ページ サポートするオペレーティング・システム 表 4-6 で示すオペレーティング・システムが ClusterXL でサポートされています。ただし 以下の注記に示す制限があります。これらのオペレーティング・システムのサポートさ れているバージョンの詳細については、『Check Point Enterprise Suite NGX (R60) Release Notes』を参照してください。このリリース・ノートは http://www.checkpoint.com/downloads/index.html からダウンロードできます。 表 4-6 ClusterX がサポートするオペレーティング・システム オペレーティング・システム 負荷共有 HA Check Point SecurePlatform（1） サポート サポート 注記 1 VLAN はすべてのインタフェースでサポートされます。 サポートするチェック・ポイントのソフトウェア（SmartDefense を除く） 表 4-7 に、ClusterXL がサポートしていない製品と機能（「非サポート」と表記）、または 一部のみサポートしている製品と機能（「サポート」と表記し、注記あり）を示します。 OPSEC 認定クラスタ製品で使用する場合、この表は当てはまりません。 表 4-7 ClusterXL が完全にはサポートしていない製品と機能 製品 機能 SmartCenter 負荷共有 HA 非サポート 非サポート Firewall 認証 / セキュリティ・サーバ サポート（1） サポート（1）（10） Firewall ACE サーバと SecurID サポート（8） サポート（8） Firewall Application Intelligence プロト コル・インスペクション（2） サポート（3） サポート Firewall シーケンス・ベリファイア サポート（4） サポート（1） Firewall UDP のカプセル化 サポート（7） サポート 第4章 ClusterXL における HA と負荷共有 57 チェック・ポイントのソフトウェアとの互換性 表 4-7 ClusterXL が完全にはサポートしていない製品と機能（続き） 製品 機能 負荷共有 HA Firewall SAM サポート（9） サポート（9） Firewall ISP の冗長性 VPN サード・パーティ製 VPN ピア SecuRemote/ SecureClient ソフトウェア配布サーバ （SDS） SecuRemote/ SecureClient オフィス・モードの ユーザごとの IP SecureXL（ハード ウェア・アクセラ レータ（16））また は Performance Pack Check Point QoS SmartLSM VPN-1 VSX 58 ROBO ゲートウェイ サポート（13） （14） サポート（13）（15） サポート（18） サポート 非サポート 非サポート サポート（11） サポート（11） サポート（12） （17） サポート（12） サポート（4） サポート（5） 非サポート 非サポート サポート（6） サポート 1 この機能はパケットごとに状態を追跡する必要があるため、1 つのクラスタ・メンバ でセッションが開始され別のクラスタ・メンバにフェイルオーバーした場合には機能 を保証できません。 2 Application Intelligence プロトコル・インスペクションには、汎用 HTTP ワーム・キャッ チャ、Optimized Protocol Enforcement の設定、および Microsoft ネットワーク・インス ペクションが含まれます。 3 Application Intelligence プロトコル・インスペクションは、接続が単方向の対称性を維 持している場合にサポートされます。単方向の対称性とは、クライアントからサーバ へのパケットはあるクラスタ・メンバによって処理されサーバからクライアントへの パケットは別のクラスタ・メンバによって処理されることを意味します。OPSEC ク ラスタ・ソリューションが OPSEC クラスタとして認められるためには、すべての接 続で少なくとも単方向の対称性を維持する必要があります。 フェイルオーバーによって特定の接続に対する単方向の対称性が破壊されることが あります。その場合は VPN-1 Pro がこれらの接続をリセットします。 4 接続が双方向の対称性を維持する場合にサポートされます。双方向の対称性とは、ク ライアントからサーバへのパケットかサーバからクライアントへのパケットかに関 わらず、接続のすべてのパケットが同一のクラスタ・メンバによって処理されること を意味します。 サポートするチェック・ポイントのソフトウェア（SmartDefense を除く） 5 帯域幅制限付きでサポートし、メンバ間の帯域幅分割が手作業で行われることを保証 します。1.5 Mbps 接続でクラスタ・メンバが 3 つある場合、各メンバは 500 Kbps の帯 域幅を持ち、帯域幅は全帯域の 1/3 に制限されます。クラスタ・メンバで障害が発生し た場合、全帯域幅が自動的に残りのメンバ間で再割り当てされることはありません。 6 OPSEC パートナー・プラットフォームを使用します。 7 SecureClient NG FP3 以降を使用してください。 8 クラスタ環境では ACE サーバを以下のように設定します。 HA： フェイルオーバー・シナリオをサポートするには、ACE サーバによる最初の 認証後に生成されセキュリティで保護されたファイルを最初のメンバから他のすべ てのメンバに手作業でコピーする必要があります。 負荷共有： ■ ■ すべてのクラスタ・メンバを固有の IP アドレスを使用してサーバで別々に定義す る必要があります。 SmartCenter サーバの tables.def ファイルに以下のエントリを追加します。 no_hide_services_ports = {.., <5500, 17> }; これにより、クラスタ・メンバから ACE サーバへの接続はクラスタのアドレス ではなくメンバの IP アドレスを使用して発信されます。クラスタ・メンバの IP アドレスが ACE サーバ・ボックスからルーティング可能であることを確認して、 セキュリティ・ポリシーをインストールします。 ■ 場合によっては、エージェント・ライブラリ（クライアント側）が解読時に 間違ったインタフェース IP アドレスを使用して認証に失敗することがあります。 この問題を解決するには、以下の行を含む新しいテキスト・ファイル sdopts.rec を dconf.rec ファイルと同じディレクトリに挿入します。 CLIENT_IP=x.x.x.x x.x.x.x は、サーバで定義されたプライマリ IP アドレスです。これはサーバが ルーティングされるインタフェースの IP です。 9 2 つのゲートウェイとして動作します。クラスタのダウン中に実行された SAM コマン ドは、このメンバに対しては実行されません。 10 HA 構成ではクライアント認証のウェイト・モードは信頼性が低くなります。ほかの クライアント認証モードを使用してください。 11 ipassignment.conf ファイルは手作業でコピーする必要があります。 12 Performance Pack on Solaris with VLANs はサポートされていません。 13 クラスタ・アドレスが別のサブネットに設定されている場合、ISP の冗長性はサポート されません。 第4章 ClusterXL における HA と負荷共有 59 チェック・ポイントのソフトウェアとの互換性 14 ISPの冗長性は、SecureXLが有効になっている場合にのみ負荷共有ユニキャスト・モー ドの ClusterXL で動作します。 15 Legacy モードではサポートされません。 16 SecureXL ハードウェアベースのアクセラレータについてはサード・パーティ・ベン ダーにお問い合わせください。 17 対称判定機能を無効にする必要があります。 18 VPN ピア・デバイスが 1 つの SA（Security Association）のみをサポートする場合は対称 判定機能を有効にする必要があります。そのようなピアの例として、Access VPN with Microsoft IPSec（L2TP）と Cisco VPN ルータがあります。 ClusterXL がサポートする SmartDefense 機能 表 4-8 で示す SmartDefense 機能が ClusterXL でサポートされています。ただし注記に示す 制限があります。 表 4-8 ClusterXL がサポートする SmartDefense 機能 機能 負荷共有 HA フラグメント・サニティ・チェック サポート（1、3） サポート（1） パターン・マッチング サポート（2、3） サポート（2） シーケンス・ベリファイア サポート（2、4） サポート（2） FTP、HTTP、SMTP のセキュリティ・サーバ サポート（2、5） サポート（2） 注記 60 1 フラグメントの受信中にフェイルオーバーが発生するとパケットは失われます。 2 フェイルオーバーが発生した場合は救済されません。 3 単方向の対称性が必要です。これは、すべての外部パケットを同一のメンバが受信し、 すべての内部パケットを同一のメンバが受信しなければならないが内部パケットと 外部パケットの両方を同一のメンバが受信する必要はないことを意味します。 4 双方向の接続対称性が必要です。 5 次のセクションで説明する転送レイヤを使用します。 転送レイヤ 転送レイヤ 転送レイヤとは、ファイアウォールがローカルで検査した後のパケットをクラスタ・ メンバが他のメンバに渡すことができるようにする ClusterXL のメカニズムです。 この機能により、クラスタ・メンバから外部ホストへの接続を開始できます。 クラスタ・メンバを発信元とするパケットは、クラスタの仮想 IP の背後に隠されます。 したがって、外部ホストからの応答は直接発信元メンバには送信されずクラスタに送信 されます。これが原因で以下の状況下で問題が発生する可能性があります。 クラスタが HA New モードで動作中にスタンバイ・マシンから接続が開始された場合。 外部ホストからのパケットはすべてスタンバイ・マシンではなくアクティ ブ・マシン によって処理されます。 ■ ■ クラスタが負荷共有モードで動作中に判定機能がこの接続を処理するメンバとして 別のメンバを選択した場合。これは、クラスタ IP 宛てのパケットも他の接続と同様 にクラスタ・メンバ間で分散されるためです。 メンバが、ファイアウォールの検査プロセス完了後にパケットが別のクラスタ・メンバ 宛てであると判断した場合、メンバは転送レイヤを使用してパケットをその宛先に渡す ことができます。これは、セキュリティで保護されたネットワーク（同期ネットワーク として指定されたサブネット）を介して直接宛先メンバにパケットを送信することに よって行われます。暗号化されたパケットは検査プロセスで復号化され（暗号化されて いない）クリアテキスト・データとして転送されるため、セキュリティで保護されたネッ トワークのみを使用することが重要です。 転送レイヤ上で送信されるパケットは、特別な発信元 MAC アドレスを使用して別のファイ アウォール・モジュールによってパケットの検査が完了していることを受信側メンバに通 知します。したがって、受信側メンバは受け取ったパケットをローカル・オペレーティン グ・システムに再検査せずに安全に転送できます。同期ネットワークは常に（専用ネット ワークを使用して）他のネットワークから隔離されているためこのプロセスは安全です。 第4章 ClusterXL における HA と負荷共有 61 ClusterXL の設定 ClusterXL の設定 このセクションの構成 クライアント・マシンのルーティングの設定 62 ページ クラスタ・メンバ・マシンの準備 62 ページ クラスタ・メンバでの CCP トランスポート・モードの選択 63 ページ SmartDashboard の設定 64 ページ この手順では、負荷共有マルチキャスト・モード、負荷共有ユニキャスト・モード、お よび HA New モードの設定方法について説明します。設定はすべてのモードで同じです が、SmartDashboard ゲートウェイ・クラスタ・オブジェクトのモードの選択またはゲート ウェイ・クラスタの作成ウィザードを除きます。図 4-2 に従って設定手順を説明します。 注： HA Legacy モードを設定するには、149 ページの「HA Legacy モード」を参照してください。 クライアント・マシンのルーティングの設定 6 クラスタの内側のネットワークとの通信がクラスタの外側のクラスタ IP アドレスを 使用して行われるようにルーティングを設定します。たとえば、64 ページの図 4-2 の外部ルータ上で 192.168.10.100 を経由してネットワーク 10.10.0.255 に到達するよ うなスタティック・ルートを設定します。 7 クラスタの外側のネットワークとの通信がクラスタの内側のクラスタ IP アドレスを 使用して行われるようにルーティングを設定します。たとえば 64 ページの図 4-2 で は、ルータの内側にある各マシン上で 10.10.0.100 をデフォルト・ゲートウェイとし て定義します。 クラスタ・メンバ・マシンの準備 8 ClusterXL の Central ライセンスを取得し、SmartCenter サーバにインストールします。 9 すべてのクラスタ・メンバの各インタフェースの IP アドレスを定義します。たとえ ば、64 ページの図 4-2 では以下のように定義します。 ■ 62 Member_A で内部インタフェースにアドレス 10.10.0.1、外部インタフェースに アドレス 192.168.10.1、同期インタフェースにアドレス 10.0.10.1 をそれぞれ設定 します。 クラスタ・メンバでの CCP トランスポート・モードの選択 ■ Member_B で内部インタフェースにアドレス 10.10.0.2、外部インタフェースにア ドレス 192.168.10.2、同期インタフェースにアドレス 10.0.10.2 をそれぞれ設定し ます。 10 VPN クラスタが正しく機能するためには、クラスタ・メンバのクロックをそれぞれ 1 秒以内に正確に同期させる必要があります。常に稼動しているクラスタ・メンバ では、通常は時刻を一度設定するだけで充分です。NPT や、オペレーティング・シ ステムが提供するその他の時刻同期サービスを使用すると、より信頼性の高い同期 を実現できます。クラスタ・メンバのクロックはその他の（非 VPN）クラスタ機能 とは関係ありません。 11 スイッチを介してクラスタ・ネットワーク・マシンを接続します。同期インタ フェースの場合はクロス・ケーブルまたは専用スイッチを使用してください。 各ネットワーク（内部、外部、同期、DMZ など）が別々の VLAN、スイッチ、 またはハブ上に構成されていることを確認します。 注： WAN を介して同期を実行できます。詳細については、26 ページの「WAN を介したクラスタの同期」 を参照してください。 12 VPN-1 Pro をすべてのクラスタ・メンバにインストールします。 13 設定段階で、Unix マシンで［Enable cluster membership for this gateway］、または Windows で［This Gateway is part of a cluster］を選択して ClusterXL とステート同期を 有効にします。 インストール中にこれを選択しなくても、いつでもチェック・ポイントの Configuration Tool を使用できます。コマンドラインから cpconfig ユーティリティを 実行して、モジュールのクラスタ機能をオンにするオプションを選択します。一部の プラットフォームでは再起動する必要があります。 クラスタ・メンバでの CCP トランスポート・モードの選択 14 接続するスイッチがマルチキャストを転送できない場合には、効率は下がりますが スイッチはブロードキャストを使用してトラフィックを転送することができます。 マルチキャストの方がブロードキャストよりも効率が良いため、クラスタ・メンバ の ClusterXL CCP（クラスタ・コントロール・プロトコル）はデフォルトでマルチ キャストを使用します。CCP モードをブロードキャストまたはマルチキャストに切 り替えるには、各クラスタ・メンバで以下のコマンドを使用します。 cphaconf set_ccp broadcast/multicast 第4章 ClusterXL における HA と負荷共有 63 ClusterXL の設定 SmartDashboard の設定 図 4-2 に物理的なクラスタ・トポロジと必要な SmartDashboard 設定との関係を示します。 SmartDashboard で ClusterXL ク ラス タを 設定 する 場合 は、ク ラス タ・オ ブジ ェク トの ［Topology］ ページを使用してクラスタとクラスタ・メンバの両方のトポロジを設定します。 クラスタ IP アドレスは仮想で、物理インタフェースに属していません。各クラスタ・ メンバの 1 つ（または複数）のインタフェースは同期ネットワーク内にあります。 図 4-2 ClusterXL のトポロジと設定の例 新しいゲートウェイ・クラスタ・オブジェクトを定義するには、 ［Network Objects］ツリーを ［New Check Point］>［Gateway Cluster...］ を選択します。ゲートウェイ・ 右クリックして、 クラスタ・オブジェクトの設定は、以下のいずれかのモードを使用して実行できます。 ■ ■ 64 シンプル・モード（ウィザード）：表示される手順に従って設定プロセスを実行します。 詳細については、オンライン・ヘルプを参照してください。 クラシック・モード：次のセクションで説明します。 SmartDashboard の設定 クラシック・モードによる設定 1 ゲートウェイ・クラスタ・オブジェクトの［General］ タブで、クラスタにインス トールされている製品として［ClusterXL］ をオンにします。 2 クラスタの全体 IP アドレスを定義します。仮想クラスタ・インタフェースの 1 つの IP アドレスと同じアドレスを定義します。 3 ［Cluster Members］ ページで［Add］>［New Cluster Member］ を選択して、クラスタ・ メンバをクラスタに追加します。クラスタ・メンバはゲートウェイ・クラスタ・オブ ジェクト内にのみ存在します。各クラスタ・メンバに対して以下の操作を行います。 ■ ［Cluster Members Properties］ ウィンドウの［General］ タブで、 ［Name］ と［IP Address］ を定義します。セキュリティ・ポリシーをインストールできるように、 SmartCenter サーバからルーティング可能な IP アドレスを選択します。内部アド レス、外部アドレス、専用管理インタフェースのいずれでも構いません。 ■ ［Communication］ をクリックして、SIC（Secure Internal Communication）を初期化 します。 ■ 必要に応じて［NAT］ タブと［VPN］ タブを定義します。 ［Cluster Members］ ページで［Add］>［Add Gateway to Cluster］ を選択し、 ［Add Gateway to Cluster］ ウィンドウの一覧からゲートウェイを選択して既存ゲートウェイ をクラスタ・メンバとして追加することもできます。 クラスタからゲートウェイを削除するには、［Cluster Members］ ページで［Remove］ ページをクリックして［Detach Member from Cluster］ を選択するか、［Network Objects］ ツリーのクラスタ・メンバを右クリックして［Detach from Cluster］ を選択 します。 4 ［ClusterXL］ ページ（図 4-3）で、以下のいずれかを実行します。 ■ ［High Availability］ の［New Mode］ を選択し、 ［Upon Gateway Recovery］ で復帰時の アクションを指定します。詳細については、50 ページの「ゲートウェイが復帰 した場合の処理」を参照してください。 ■ ［Load Sharing］ を選択します。ルータの機能に従って負荷共有モード（［Multicast Mode］ または［Unicast Mode］）を選択します。 第4章 ClusterXL における HA と負荷共有 65 ClusterXL の設定 図 4-3 ［ClusterXL］ページ 5 ［Use State Synchronization］ をオン / オフにするかどうかを選択します。 ■ ■ 負荷共有構成ではクラスタ・メンバ間で同期する必要があるため、このオプション はオンで灰色表示されます。 HA New モードでは、このオプションはデフォルトでオンになっています。これを オフにすると、クラスタ・メンバは同期されなくなり、フェイルオーバーの発生 時に障害が発生したゲートウェイ上の既存の接続は切断されます。 6 ［Topology］ ページで、仮想クラスタ IP アドレスと少なくとも 1 つの同期ネットワー クを定義します。［Edit Topology］ ウィンドウで、以下の操作を行います。 ■ ■ 各クラスタ・メンバ・インタフェースのトポロジを定義します。メンバ・ インタフェースに対して定義済みのすべての設定を自動的に読み込むには、 ［Get all members’ topology］ をクリックします。 ［Network Objective］ カラムでドロップダウン・リストからいずれかのオプション ［1st Sync.］ など）を選択してネットワークの目的を定義します。 （［Cluster］、 オプションについては、オンライン・ヘルプを参照してください。新しいネット ワークを定義するには、［Add Network］ をクリックします。 64 ページの図 4-2 の例の［Edit Topology］ ウィンドウを以下に示します。 66 SmartDashboard の設定 図 4-4 ［Edit Topology］ページの例 7 ［Topology］ ページで各仮想クラスタ・インタフェースのトポロジを定義します。仮 想クラスタ・インタフェース・セルを右クリックして [Edit Interface］ を選択します。 ［Interface Properties］ ウィンドウが開きます。 ■ ［General］ タブで仮想インタフェースの［Name］ を入力し、 ［IP Address］ を定義 します（図 4-2 では、192.168.10.100 が仮想インタフェースの 1 つです） 。 ■ ［Topology］ タブでインタフェースが内部か外部かどうかを定義し、スプーフ対策 機能を設定します。 ■ ［Member Networks］ タブでメンバ・ネットワークとそのネットマスク（必要な場 合）を定義します。この詳細オプションについては、133 ページの「異なるサブ ネット上のクラスタ・アドレスの設定」を参照してください。 8 必要に応じて、クラスタ・オブジェクトのほかのページ（［NAT］、［VPN］、［Remote Access］ ページなど）を定義します。 9 セキュリティ・ポリシーをクラスタにインストールします。 第4章 ClusterXL における HA と負荷共有 67 ClusterXL の設定 68 第 5 章 OPSEC 認定クラスタ製品の使用 この章の構成 OPSEC 認定クラスタ製品について 69 ページ OPSEC 認定クラスタ製品の設定 70 ページ OPSEC クラスタにおける CPHA コマンド・ラインの働き 74 ページ OPSEC 認定クラスタ製品について 多くの OPSEC 認定製品が HA（ハイ・アベイラビリティ）機能（「ホット・スタンバイ」 とも呼ばれます）と負荷共有機能（「負荷バランス」とも呼ばれます）を提供しています。 これらの製品を使用して、可用性の高い VPN-1 Pro ゲートウェイ・クラスタを構築し、 クラスタ化されたゲートウェイ間で均等にトラフィックを分散させることができます。 各 OPSEC 認定クラスタリング・アプリケーションは、監視、管理、またはパフォーマン スにおいて、それぞれ固有の強みと能力を持っています。これらのクラスタリング・ア プリケーションの役割は以下のとおりです。 1 各通信を処理するクラスタ・メンバを決定する。 2 ヘルス・チェックを行う。これには、クラスタ・メンバの状態チェック（たとえば、 アクティブ、スタンバイ、またはダウン）と、メンバ・インタフェースの状態チェッ クが含まれます。 3 フェイルオーバーを実行する。 OPSEC 認定クラスタ製品は、VPN-1 Pro ステート同期メカニズム（第 2 章「クラスタ間で の接続情報の同期」を参照）を使用して、クラスタ・メンバ間で通信情報やその他の状 態情報の交換と更新を行います。 ここでは、OPSEC 認定クラスタ製品を使用する際の一般的なガイドラインについて説明 します。設定の詳細は、クラスタ製品ごとに異なりますので、OPSEC 製品に添付されて いるマニュアルに従ってください。 69 OPSEC 認定クラスタ製品の設定 OPSEC 認定クラスタ製品の設定 ここでは、OPSEC 認定 VPN-1 Pro ゲートウェイ・クラスタリング・ソリューションの設 定方法について説明します。 スイッチの準備とルーティングの設定 以下については、クラスタ製品マニュアルの説明に従ってください。 ■ スイッチとルータの準備 ■ ルーティングの設定 クラスタ・メンバ・マシンの準備 1 すべてのクラスタ・メンバ上で、すべてのインタフェースの IP アドレスを定義し ます。 2 スイッチを介してクラスタ・ネットワーク・マシンを接続します。同期インタ フェースの場合は、クロス・ケーブルまたは専用スイッチを使用してください。 注： WAN を介して同期を実行できます。詳細については、26 ページの「WAN を介したクラスタの同期」 を参照してください。 3 Nokia クラスタの場合は、VRRP または IP クラスタリング機能を設定してから VPN-1 Pro をインストールします。その他の OPSEC 認定クラスタの場合は、ベン ダーの推奨方法に従ってください。 インストールが終了したら、Nokia 設定マネージャで［Enable VPN-1/FW-1 monitoring］ オプションが［Enable］ に設定されていることを確認します。これにより、IPSO は ファイアウォールの状態の変化を監視するようになります。IPSO 3.8.2 以降の VRRP と IP クラスタリング機能の場合、フェイルオーバーのためにファイアウォールの状 態が Nokia クラスタに報告されます。 4 VPN-1 Pro をすべてのクラスタ・メンバにインストールします。設定段階で（また は後で cpconfig 設定ツールを使用して）以下を行います。 ■ ■ 70 各クラスタ・メンバに VPN-1 Pro のライセンスをインストールします。OPSEC 認 定製品を VPN-1 Pro と共に動作させるための特別なライセンスは不要です。 設定段階で、Unix マシンで［Enable cluster membership for this gateway］、または Windows で［This Gateway is part of a cluster］ を選択して、ステート同期を有効に します。 OPSEC クラスタに対する SmartDashboard の設定 OPSEC クラスタに対する SmartDashboard の設定 1 SmartDashboard を使用して、ゲートウェイ・クラスタ・オブジェクトを作成します。 新しいゲートウェイ・クラスタ・オブジェクトを定義するには、［Network Objects］ ツリーを右クリックして、［New Check Point］>［Gateway Cluster...］ を選択します。 ゲートウェイ・クラスタ・オブジェクトの設定は、以下のいずれかのモードを使用 して実行できます。 ■ ■ シンプル・モード（ウィザード）：表示される手順に従って、設定プロセスを実行し ます。詳細については、オンライン・ヘルプを参照してください。 クラシック・モード：以下で説明します。 クラシック・モードの設定 2 ゲートウェイ・クラスタ・オブジェクトの［General Properties］ ページで、クラスタ の全体 IP アドレスを定義します。通常は、クラスタの外部仮想 IP アドレスを使用 します。 ［Check Point Products］ リストで、ClusterXL が選択されていないことを確認します。 3 ［Cluster Members］ ページで、［Add］>［New Cluster Member］ を選択して、クラスタ・ メンバをクラスタに追加します。クラスタ・メンバは、ゲートウェイ・クラスタ・ オブジェクト内にのみ存在します。各クラスタ・メンバに対して、以下の操作を行 います。 ■ ［Cluster Members Properties］>［General］ タブで、 ［Name］ と［IP Address］ を定義 します。セキュリティ・ポリシーをインストールできるように、SmartCenter サー バからルーティング可能な IP アドレスを選択します。内部アドレス、外部アドレ ス、専用管理インタフェースのいずれでも構いません。 ■ ［Communication］ をクリックして、SIC（Secure Internal Communication）を初期化 します。 ■ 必要に応じて、［NAT］ タブと［VPN］ タブを定義します。 ［Cluster Members］ページで［Add］>［Add Gateway to Cluster］を選択し、 ［Add Gateway to Cluster］ウィンドウの一覧からゲートウェイを選択して、既存ゲートウェイをクラ スタ・メンバとして追加することもできます。 クラスタからゲートウェイを削除するには、［Cluster Members］ ページで［Remove］ ページをクリックして［Detach Member from Cluster］を選択するか、 ［Network Objects］ ツリーのクラスタ・メンバを右クリックして［Detach from Cluster］ を選択します。 4 ［3rd Party Configuration］ ページで、クラスタの動作モードを指定し、［3rd Party Solution］ に OPSEC を指定して、 ［Use State Synchronization］ をオンにします。 第5章 OPSEC 認定クラスタ製品の使用 71 OPSEC 認定クラスタ製品の設定 5 ［Topology］ ページを使用して、仮想クラスタ IP アドレスとクラスタ・メンバ・アド レスを定義します。 各クラスタ・メンバに対して、各メンバのインタフェースを定義します。 OPSEC 認定製品の場合、一部の製品では仮想クラスタ IP の設定は必須ですが、ほかの 製品では設定は禁止されています。詳細については、クラスタ製品のマニュアルを 参照してください。 同期ネットワークを定義します。OPSEC の実装方法によっては、OPSEC 設定がすで に定義されていれば、OPSEC 設定から同期ネットワークを「取得」できます。特定 の OPSEC 製品でこの機能が実装されているかどうか確認するには、OPSEC のマニュ アルを参照してください。 6 ［3rd Party Configuration］ ページに戻ります。 非対称通信は、クライアントからサーバへのパケットとサーバからクライアントへ のパケットが異なるクラスタ・メンバを通過する通信です。非対称通信では、状態 の一致しないパケットをクラスタ・メンバが受信する可能性があるため問題となり ます。VPN-1 Pro は、有効な通信に属するパッケージであっても、状態が合致しなけ れば拒否します。 このような通信がクラスタを通過するのを VPN-1 Pro に許可させるには、同期メカ ニズムまたは OPSEC 認定クラスタ製品のどちらかが、有効な非対称通信を識別でき る必要があります。 OPSEC 認定クラスタ製品が有効な非対称通信を識別できるかどうかを確認します。 クラスタ製品が有効な非対称通信を識別できない場合には、代わりに同期メカ ニズムが識別できます。その場合、［Support non-sticky connections］ をオンにし ます。 ■ ■ クラスタ製品が有効な非対称通信を識別できる場合、同期メカニズムはこの処理 を行う必要はありません。その場合、［Support non-sticky connections］ をオフに します。HA ソリューション（負荷共有ではなく）では、このオプションをオフ にしたほうがセキュリティ上安全です。このオプションをオフにすると、通信確 立の速度も少し向上します。 ［Hide Cluster Members’ outgoing traffic behind the Clusters IP Address］オプションを オンにする場合は、（OPSEC クラスタ製品のマニュアルで特に指示されていない ［Support non-sticky connections］ もオンにして、スタンバイ・マシンからの 限り） 発信通信をサポートする必要があります。 72 OPSEC クラスタに対する SmartDashboard の設定 7 多くのゲートウェイ・クラスタは物理クラスタ・メンバ・インタフェース・アドレ スのほかに、クラスタ・オブジェクトの［Topology］ ページで定義された仮想クラス ［3rd Party タ IP アドレスを持っています。仮想クラスタ IP アドレスを使用すると、 Configuration］ ページの設定に影響を与えます。 クラスタ・メンバからインターネットへの発信通信を確立する場合、発信パケット 内の発信元アドレスは通常、クラスタ・メンバ・インタフェースの物理 IP アドレス になります。仮想クラスタ IP アドレスを使用している場合、クラスタ製品は通常、 発信元 IP アドレスを、クラスタの外部仮想 IP アドレスを使用した発信元 IP アドレス に（NAT を使用して）変換します。 この動作は、［Hide Cluster Members’ outgoing traffic behind the Cluster’s IP address］ が オンになっている場合のデフォルト設定に対応します。 クライアントがクラスタの外部仮想アドレスに対して着信通信を確立する場合、 クラスタ製品は宛先 IP アドレスを、クラスタ・メンバの 1 つの物理外部アドレスを 使用した宛先 IP アドレスに（NAT を使用して）変換します。 この動作は、［Forward Cluster’s incoming traffic to Cluster Members’ IP addresses］ が オンになっている場合のデフォルト設定に対応します。［Topology］ ページで、 各メンバのインタフェースを定義します。ほとんどの OPSEC ソリューションでは、 クラスタ IP アドレスを各メンバの［Topology］ タブに追加する必要はありません。 詳細については、クラスタ製品のマニュアルを参照してください。 8 必要に応じて、クラスタ・オブジェクトのほかのページ（［NAT］、［VPN］、［Remote Access］ ページなど）を定義します。 9 セキュリティ・ポリシーをクラスタにインストールします。 注： IPSO バージョン 3.9 以降の Nokia クラスタ（VRRP または IP クラスタリング）を定義する場合は、 初めてポリシーをインストールする前に monitor fw state 機能を無効にする必要があります。 ［Gateway Cluster Properties］ 無効にしないと、クラスタ IP アドレスの設定ができなくなり、その結果、 ウィンドウの［Topology］ セクションでの［Get Interfaces］ 操作は失敗します。ポリシーのインストー ル後、 monitor fw state 機能を再び有効にすることができます。 第5章 OPSEC 認定クラスタ製品の使用 73 OPSEC クラスタにおける CPHA コマンド・ラインの働き OPSEC クラスタにおける CPHA コマンド・ラインの働き このセクションの構成 OPSEC クラスタにおける cphastart コマンドと cphastop コマンド 74 ページ OPSEC クラスタにおける cphaprob コマンド 74 ページ このセクションでは、OPSEC クラスタでの特定のコマンド・ラインの働きについて説明 します。 注： cpha コマンド・ラインの詳細については、77 ページの「ゲートウェイ・クラスタの監視とトラブ ルシューティング」を参照してください。 OPSEC クラスタにおける cphastart コマンドと cphastop コマンド ClusterXL クラスタにおける cphastart コマンドと cphasstop コマンドの働きについて は、91 ページの「cphastart コマンドと cphastop コマンド」を参照してください。 OPSEC クラスタでは、cphastart コマンドでクラスタ・メンバが起動されない場合があ ります。Nokia クラスタでは、cphastart コマンドの働きは ClusterXL クラスタの場合と同じ です。 OPSEC クラスタでは、cphastop コマンドがフェイルオーバーを発生させない場合があり ます。Nokia IP クラスタリング・クラスタ（VRRP クラスタでは異なります）では、cphastop コマンドの働きは ClusterXL クラスタの場合と同じです。 ClusterXL クラスタの場合と同様、これらのコマンドは VPN-1 Pro によってのみ実行され、 ユーザは直接実行しません。 OPSEC クラスタにおける cphaprob コマンド クラスタとクラスタ・メンバが正常に動作していることを確認するには、cphaprob コマ ンドを使用します。このコマンドは、Nokia IP クラスタリングと Nokia VRRP にのみ関係 します。 Nokia 以外の OPSEC クラスタでは、出力に何も印刷されないか、コマンドを実行しても 何も起こりません。 74 OPSEC クラスタにおける cphaprob コマンド cphaprob の使い方を印刷して使用可能なすべてのコマンドを確認するには、コマンド・ ライン に「cphaprob」と入力して、Enter キーを押します。各コマンドの意味を以下の セクションで説明します。 cphaprob cphaprob cphaprob cphaprob cphaprob cphaprob cphaprob -d <device> -t <timeout(sec)> -s <ok|init|problem> [-p] register -f <file> register -d <device> [-p] unregister -d <device> -s <ok|init|problem> report [-i[a]] [-e] list state [-a] if cphaprob state： マシン状態はチェック・ポイントの状態だけであり、実際にはマシン 状態ではありません。完全同期の正常終了と、ポリシーが正常にインストールされたか どうかを監視します。IP クラスタリングの場合、状態は正確で、Nokia クラスタの状態も 含めてレポートされます。VRRP の場合、状態はファイアウォールについては正確です が、Nokia マシンの状態は正確には反映されません（たとえば、インタフェースの障害は 検出されません）。 cphaprob [-a] if：関連情報のみを表示します （インタフェース名と、同期インタフェー スであるかどうか）。 「Multicast」/「Broadcast」はクラスタ・コントロール・プロトコルを 意味し、同期インタフェースにのみ関係します。インタフェースの状態は監視されてい ないため、印刷されません （これは Nokia マシンの場合も同様です） 。 第5章 OPSEC 認定クラスタ製品の使用 75 OPSEC クラスタにおける CPHA コマンド・ラインの働き 76 第 6 章 ゲートウェイ・クラスタの監視と トラブルシューティング この章の構成 クラスタの正常動作を確認する方法（cphaprob） 78 ページ SmartConsole クライアントを使用したクラスタ状態監視 86 ページ ClusterXL 設定コマンド（cphaconf、cphastart、cphastop） 90 ページ フェイルオーバーの開始方法 91 ページ 同期の監視（fw ctl pstat） 92 ページ 同期のトラブルシューティング（cphaprob [-reset] syncstat） 96 ページ ClusterXL のエラー・メッセージ 107 ページ Solaris プラットフォーム固有の問題： VLAN スイッチ・ ポートのフラッピング 114 ページ メンバの再起動の失敗 114 ページ 77 クラスタの正常動作を確認する方法（cphaprob） クラスタの正常動作を確認する方法（cphaprob） このセクションの構成 cphaprob コマンド 78 ページ クラスタの状態監視（cphaprob state） 79 ページ クラスタ・インタフェースの監視（cphaprob [-a] if） 81 ページ クリティカル・デバイスの監視（cphaprob list） 83 ページ クリティカル・デバイスの登録（cphaprob -d ... register） 84 ページ ファイルにリストしたクリティカル・デバイスの登録 （cphaprob -f <file> register） クリティカル・デバイスの登録削除（cphaprob -d ... unregister） ClusterXL へのクリティカル・デバイス状態報告 （cphaprob -d ... report） cphaprob スクリプトの例 84 ページ 85 ページ 85 ページ 85 ページ cphaprob コマンド クラスタとクラスタ・メンバが正常に動作していることを確認したり、クリティカル・デ バイスを定義する場合は、cphaprob コマンドを使用します。クリティカル・デバイスと は、クラスタ・メンバで動作するプロセスで、クラスタ・メンバがメンバとして機能で きなくなった場合にほかのクラスタ・メンバに通知することを可能にします。クリティ カル・デバイスは自分の現在の状態について ClusterXL メカニズムに報告します。また、 報告に失敗することもありますが、その場合、ClusterXL はフェイルオーバーが発生して ほかのクラスタ・メンバが引き継いだと判断します。クリティカル・デバイス（問題通 知または pnote とも呼ばれます）に障害が発生した場合、クラスタ・メンバに障害が発生 したと見なされます。 多くの組み込みクリティカル・デバイスがあり、さらに管理者がクリティカル・デバイ スを追加定義することもできます。デフォルトのクリティカル・デバイスは以下のとお りです。 ■ クラスタ・メンバ上のクラスタ・インタフェース ■ Synchronization ■ Filter — 完全同期の正常終了 — セキュリティ・ポリシーおよびセキュリティ・ポリシーがロードされた かどうか ■ ■ 78 — cphamcset と呼ばれる ClusterXL プロセスの次に実行されるプロセス fwd — VPN-1 Pro デーモン cphad クラスタの状態監視（cphaprob state） これらのコマンドは、スクリプトに記述することにより自動的に実行できます。 cphaprob の使い方を出力して使用可能なすべてのコマンドを確認するには、コマンド・ ラインに「cphaprob」と入力して Enter キーを押します。各コマンドの意味は、次のセク ションで説明します。 cphaprob cphaprob cphaprob cphaprob cphaprob cphaprob cphaprob -d <device> -t <timeout(sec)> -s <ok|init|problem> [-p] register -f <file> register -d <device> [-p] unregister -d <device> -s <ok|init|problem> report [-i[a]] [-e] list state [-a] if クラスタの状態監視（cphaprob state） クラスタ・メンバとクラスタ内のほかのすべてのメンバの状態を表示するには、クラスタ・ メンバ上で以下のコマンドを実行します。 cphaprob state このコマンドは、クラスタをセットアップした後、およびクラスタの状態を監視する場 合に実行します。cphaprob state の出力例を以下に示します。 cphaprob state Cluster mode: ■ Load sharing (Multicast) Number Unique Address State 1 (local) 2 30.0.0.1 30.0.0.2 active active Cluster mode に表示される内容は、以下のとおりです。 ■ Load Sharing（Multicast）（負荷共有（マルチキャスト）） ■ Load Sharing（Unicast）（負荷共有（ユニキャスト）） ■ ■ ■ High Availability New Mode（Primary Up または Active Up）（HA New モード （プライマリ・アップまたはアクティブ・アップ）） High Availability Legacy Mode（Primary Up または Active Up）（HA Legacy モード （プライマリ・アップまたはアクティブ・アップ）） Service（サービス）（サード・パーティ製クラスタ製品の場合） 詳細については、17 ページの「クラスタの定義と用語」を参照してください。 第6章 ゲートウェイ・クラスタの監視とトラブルシューティング 79 クラスタの正常動作を確認する方法（cphaprob） ■ ■ メンバの番号は、負荷共有の場合はメンバ ID を、HA（ハイ・アベイラビリティ）の 場合は優先順位を、それぞれ表します。 負荷共有構成の場合、完全に機能しているクラスタ内ではすべてのマシンがアクティ ブになります。HA 構成の場合、正常に機能しているクラスタ内では 1 つのマシンの みがアクティブになり、ほかのマシンはスタンバイ状態になります。 サード・パーティ製のクラスタ製品の場合は、メンバの 1 つがスタンバイ状態で あっても Active/Active と表示されます。これは、このコマンドが完全同期プロセスの 状態のみを報告するためです。Nokia VRRP の場合、このコマンドはファイアウォー ルそのものの状態を表示しますが、クラスタ・メンバの状態は表示しません（たと えば、メンバが正常に動作していない場合でも、ファイアウォールの状態はアク ティブになります）。 クラスタ・メンバの状態を調べる際は、そのメンバがパケットの転送中かどうか、および パケットの転送を停止させるような問題が発生しているかどうかを確認する必要があり ます。各状態には、クリティカル・デバイスでのテスト結果が反映されます。表 6-1 に、 発生する可能性のあるクラスタ状態のリストを示し、各状態の説明およびその状態に問 題があるかどうかを示します。 80 クラスタ・インタフェースの監視（cphaprob [-a] if） クラスタ・インタフェースの監視（cphaprob [-a] if） 表 6-1 クラスタの状態 状態 説明 パケットの 転送状態 問題の有無 アクティブ すべてが正常な状態です。 転送中 問題なし アクティブ・ アテンション 問題が検出されましたが、このクラスタ・メンバがクラス タ内で唯一のマシンであるか、クラスタ内にほかのアク ティブ・マシンが存在しないため、クラスタ・メンバが パケットの転送を継続しています。これ以外の状況では、 マシンの状態はダウンとなります。 転送中 問題あり ダウン クリティカル・デバイスの 1 つがダウンしています。 転送中 ではない 問題あり レディ 以下の状況で発生する可能性があります。 転送中 ではない 問題なし 1 あるクラスタでVPN-1 Proのバージョンがアップグレー ドされたが、クラスタのメンバはほかのバージョンの VPN-1 Pro を使用しており、新しいバージョンを持つ メンバがレディ状態である一方、旧バージョンを持つ メンバがアクティブ状態になっています。 2 クラスタ・メンバがアクティブになる前にクラスタ内の ほかのメンバにメッセージを送信し、ほかのクラスタ・ メンバからアクティブになることを了承する確認メッ セージを受信するのを待っています。確認メッセージを 受信するまでの間、マシンはレディ状態になります。 スタンバイ HA 設定にのみ適用されます。アクティブ・マシンに障害 が発生した場合にパケット転送を開始できるよう、待機し ていることを意味します。 転送中 ではない 問題なし 初期化中 クラスタ・メンバは初期の過渡的状態にあります。クラス タ・メンバが起動中で、ClusterXL 製品はすでに動作して いますが、VPN-1 Pro はまだ準備ができていません。 転送中 ではない 問題なし ローカル・マシンは、このクラスタ・メンバから何も受信 できません。 判断不可 問題あり クラスタ・メンバのインタフェースと仮想クラスタのインタフェースの状態を表示する には、クラスタ・メンバ上で以下のコマンドを実行します。 cphaprob [-a] if 第6章 ゲートウェイ・クラスタの監視とトラブルシューティング 81 クラスタの正常動作を確認する方法（cphaprob） このコマンドの出力は、クラスタ・オブジェクトの［Topology］ ページの設定と同じでな ければなりません。以下に例を示します。 cphaprob -a if Required interfaces: 4 Required secured interfaces: 1 qfe4 qfe5 qfe6 qfe7 UP UP DOWN (4810.2 secs) UP (secured, unique, multicast) (non secured, unique, multicast) (non secured, unique, multicast) (non secured, unique, multicast) Virtual cluster interfaces: 2 qfe5 30.0.1.130 qfe6 30.0.2.130 これらのインタフェースは ClusterXL のクリティカル・デバイスです。ClusterXL は正常な インタフェースの数を確認し、Required interfaces の値として、直前の再起動以後に検出さ れた正常インタフェースの最大値を設定します。正常なインタフェース数が必要な数より 少ない場合、ClusterXL はフェイルオーバーを開始します。secured interfaces でも同様に、 正常な同期インタフェースだけがカウントされます。 インタフェースは以下のように表示されます。 ■ Non-secured（安全に保護されていない） または Secured（安全に保護されている） 。安全に 保護されたインタフェースは同期インタフェースです。 ■ ■ Shared（共有） または unique（固有）。共有インタフェースは、HA Legacy モードにの み適用されます。 Multicast（マルチキャスト）または Broadcast（ブロードキャスト） 。クラスタ内で使用さ れるクラスタ・コントロール・プロトコル（CCP）モード。CCP を変更してブロー ドキャストを使用することができます。これらの 2 つのモードを切り替えるには、 cphaconf set_ccp <broadcast|multicast> コマンドを使用します。 Nokia IP クラスタリングを除くサード・パーティ製クラスタ製品の場合、cphaprob -a if は常に仮想クラスタ IP アドレスを示します。 インタフェースに「DOWN」と表示された場合は、インタフェースが CCP パケットの送 信および受信ができないことを意味します。これはインタフェースが誤作動した場合、正 しくないサブネットに接続された場合、マルチキャスト・イーサネット・パケットを取 り出せない場合などに発生します。また、インタフェースが CCP パケットの受信はでき るが送信ができない場合もあります。この場合、状態フィールドが読み取られます。表 示される時間は、インタフェースが最後に CCP パケットを受信または送信してから経過 した秒数です。 詳細については、131 ページの「Disconnected インタフェースの定義」を参照してくだ さい。 82 クリティカル・デバイスの監視（cphaprob list） クリティカル・デバイスの監視（cphaprob list） クリティカル・デバイスに障害が発生すると、クラスタ・メンバに障害が発生したと見 なされます。クラスタ・メンバ上のクリティカル・デバイスとクラスタ内のほかのすべて のマシンのリストを表示するには、クラスタ・メンバ上で以下のコマンドを実行します。 cphaprob [-i[a]] [-e] list 多くの組み込みクリティカル・デバイスがあり、さらに管理者がクリティカル・デバイスを 追加定義することもできます。デフォルトのクリティカル・デバイスは以下のとおりです。 ■ クラスタ・メンバ上のクラスタ・インタフェース ■ Synchronization ■ Filter — 完全同期の正常終了 — セキュリティ・ポリシーおよびセキュリティ・ポリシーがロードされたか どうか ■ ■ — cphamcset と呼ばれる ClusterXL プロセスの次に実行されるプロセス fwd — VPN-1 Pro デーモン cphad Nokia IP クラスタリングの場合、出力は ClusterXL 負荷共有の場合と同じです。ほかのサー ド・パーティ製品の場合は、このコマンドの出力はありません。以下の出力例は、fwd プ ロセスがダウンしたことを示しています。 cphaprob list Built-in Devices: Device Name: Interface Active Check Current state: OK Registered Devices: Device Name: Synchronization Registration number: 0 Timeout: none Current state: OK Time since last report: 15998.4 sec Device Name: Filter Registration number: 1 Timeout: none Current state: OK Time since last report: 15644.4 sec Device Name: fwd Registration number: 3 Timeout: 2 sec Current state: problem Time since last report: 4.5 sec 第6章 ゲートウェイ・クラスタの監視とトラブルシューティング 83 クラスタの正常動作を確認する方法（cphaprob） クリティカル・デバイスの登録（cphaprob -d ... register） cphaprob -d <device> -t <timeout(sec)> -s <ok|init|problem> [-p] register ユーザ定義のクリティカル・デバイスを、クリティカル・デバイスのデフォルト・リス トに追加できます。このコマンドを使用して <device> をクリティカル・プロセスとして 登録し、クラスタ・メンバがアクティブとして見なされるために動作していなければな らないデバイスのリストに追加します。<device> に障害が発生すると、クラスタ・メンバ に障害が発生したと見なされます。 <device> が <timeout> 秒以内にクラスタ・メンバとのコンタクトに失敗した場合、<device> に障害が発生したと見なされます。タイムアウトを使用しない場合は、値 0 を指定します。 登録時に ClusterXL に報告される <device> の状態を定義します。初期状態として、以下の いずれかを指定できます。 ■ ■ — <device> は動作中。 init — <device> は初期化中。マシンはダウンしています。この状態はマシンがアク ok ティブになるのを防止します。 ■ problem — <device> に障害が発生。 [-p] を指定すると、これらの変更が固定されます。再起動後または VPN-1 Pro カーネル・ モジュール（たとえば、Linux または IPSO で）を削除後に再アタッチした場合でも、 このフラグ付きで登録したクリティカル・デバイスの状態は保存されます。 ファイルにリストしたクリティカル・デバイスの登録 （cphaprob -f <file> register） cphaprob -f <file> register <file> にリストされたユーザ定義のクリティカル・デバイスをすべて登録します。<file> は ASCII ファイルで、各デバイスは別々の行に記述する必要があります。各行には、以下 のように 3 つのパラメータを記述し、各パラメータは少なくとも 1 個のスペースまたはタ ブで区切る必要があります。 <device> <timeout> <status> ■ ■ ■ <device> — クリティカル・デバイスの名前。15 文字以内で、スペースを含むことは できません。 <timeout> — <device> が <timeout> 秒以内にクラスタ・メンバとのコンタクトに失敗 した場合、<device> に障害が発生したと見なされます。タイムアウトを使用しない 場合は、値 0 を指定します。 <status> — 以下のいずれかを指定します。 ■ ■ ■ 84 — <device> は動作中。 init — <device> は初期化中。マシンはダウンしています。この状態はマシンが ok アクティブになるのを防止します。 problem — <device> に障害が発生。 クリティカル・デバイスの登録削除（cphaprob -d ... unregister） クリティカル・デバイスの登録削除（cphaprob -d ... unregister） cphaprob -d <device> [-p] unregister ユーザ定義の <device> をクリティカル・プロセス登録から削除します。このデバイスは クリティカルと見なされなくなります。クリティカル・デバイス（したがってクラスタ・ メンバ）を「problem」として登録した後でこのコマンドを実行した場合、このコマンド 実行後のクラスタの状態は、残りのクリティカル・デバイスにのみ依存します。 [-p] を指定すると、これらの変更が固定されます。すなわち、再起動後またはカーネル （たとえば Linux または IPSO で）を削除後に再アタッチした場合でも、これらのクリティ カル・デバイスは未登録の状態になります。 ClusterXL へのクリティカル・デバイス状態報告（cphaprob -d ... report） cphaprob -d <device> -s <ok|init|problem> report ユーザ定義のクリティカル・デバイスの状態を ClusterXL に報告するには、このコマンドを 使用します。 <device> は、クラスタ・メンバがアクティブと見なされるために動作していなければなら ないデバイスです。<device> に障害が発生すると、クラスタ・メンバに障害が発生したと 見なされます。 報告される状態は、以下のいずれかです。 ok — <device> は動作中。 — <device> は初期化中。マシンはダウンしています。この状態はマシンがアクティ ブになるのを防止します。 init — <device> に障害が発生。この状態が ClusterXL に報告されると、クラスタ・ メンバは直ちに別のクラスタ・メンバにフェイルオーバーします。 problem 登録時に定義されたタイムアウト時間以内に <device> がクラスタ・メンバとコンタクトでき なかった場合、その <device>、つまりクラスタ・メンバに障害が発生したと見なされます。 これは、タイムアウトを定義されたクリティカル・デバイスにのみ当てはまります。クリ ティカル・デバイスが -t 0 パラメータを指定して登録されている場合はタイムアウトは発 生せず、デバイスから何らかの状態が報告されるまで、最後に報告された状態のままである と見なされます。 cphaprob スクリプトの例 事前定義済みの cphaprob スクリプトは、$FWDIR/bin にあります。以下の 2 つのスクリプ トを利用できます。 clusterXL_monitor_ips clusterXL_monitor_process 第6章 ゲートウェイ・クラスタの監視とトラブルシューティング 85 SmartConsole クライアントを使用したクラスタ状態監視 付録の章である 157 ページの「cphaprob スクリプトの例」に記載されている clusterXL_monitor_process スクリプトは、ルータやほかのネットワーク・デバイス に対するエンド・ツー・エンド接続を確認する手段を提供し、ping に失敗した場合に フェイルオーバーを発生させるように設計されています。このスクリプトは、特定のプ ロセスの存在を監視して、プロセスが動作停止した場合にフェイルオーバーを発生させ ます。このスクリプトでは、通常の pnote メカニズムが使用されています。 157 ページの「cphaprob スクリプトの例」を参照してください。 SmartConsole クライアントを使用したクラスタ状態監視 このセクションの構成 SmartView Monitor 86 ページ SmartView Tracker 87 ページ SmartView Monitor SmartView Monitor は、企業内のすべての ClusterXL クラスタ・メンバのスナップショッ トを表示し、リアルタイムの監視と警告を可能にします。各クラスタ・メンバについて、 状態変化とクリティカル・デバイスの問題通知が表示されます。SmartView Monitor を使 用すると、クラスタ・メンバの状態が変わったときの処置を指定することもできます。 たとえば、VPN-1 Pro で警告を表示して、管理者に疑わしいアクティビティを通知する こともできます。 SmartView Monitor を使用した ClusterXL の起動と停止 マシン上の ClusterXL を停止させてほかのマシンへのフェイルオーバーを発生させるに は、SmartView Monitor を開いてクラスタ・オブジェクトをクリックます。メンバ・ゲー トウェイ・ブランチの 1 つを選択し、クラスタ・メンバを右クリックして［Down］を選択 します。 ClusterXL を再起動するには、SmartView Monitor を開いてクラスタ・オブジェクトをク リックします。メンバ・ゲートウェイ・ブランチの 1 つを選択し、クラスタ・メンバを右 クリックして［Up］ を選択します。 注： SmartView Monitor は完全同期を開始しないため、通信の一部が失われる場合があります。完全同 期を開始するには、 cpstart を実行するか、 cphaprob コマンドを使用してクラスタ・メンバを起動 してください。 86 SmartView Tracker SmartView Tracker クラスタ・メンバの状態の変化はすべて、クラスタ・オブジェクトの［ClusterXL］ページ の［Fail-Over Tracking］ オプションの設定に従って SmartView Tracker に記録されます。 ClusterXL のログ・メッセージ このセクションでは、以下の表記法を使用します。 1 大括弧はプレース・ホルダを表し、実際のログ・メッセージが発行されるときに関 連データで置き換えられます（たとえば、[NUMBER] は数値で置き換えられます） 。 2 角括弧は選択肢を表し、実際のログ・メッセージにこれらの選択肢の 1 つが使用さ れます。個々の選択肢は垂直線で区切られます（たとえば、<up|down> は「up」また は「down」を使用することを表します）。 3 以下のプレース・ホルダは、頻繁に使用されます。 ■ ■ ■ ID：「1」から始まる固有のクラスタ・メンバ識別子。これは、メンバがクラスタ・ オブジェクトの GUI 上に表示される順序に対応します。 IP： メンバに属する固有の IP アドレス。 MODE：クラスタ・モード（たとえば、HA New モード、負荷共有マルチキャスト・ モードなど）。 ■ STATE： メンバの状態（たとえば、アクティブ、ダウン、スタンバイなど）。 ■ DEVICE： pnote デバイスの名前（たとえば、fwd、Interface Active Check など）。 全体ログ Starting <ClusterXL|State Synchronization>. 報告しているメンバ上で ClusterXL（サード・パーティ・クラスタの場合はステート同期） が正常に起動されたことを表します。このメッセージは、通常、メンバ起動後、または cphastart の明示的な呼び出し後に発行されます。 Stopping <ClusterXL|State Synchronization>. ClusterXL（またはステート同期）がこのマシン上で非アクティブ化されたことを通知し ます。設定に関係なく、ClusterXL が再起動されるまで、マシンはクラスタに属さなくな ります。 Unconfigured cluster Machines changed their MAC Addresses. Please reboot the cluster so that the changes take affect. このメッセージは、通常、マシンがシャット・ダウンされたとき、または cphastop の明 示的な呼び出しの後に発行されます。 第6章 ゲートウェイ・クラスタの監視とトラブルシューティング 87 SmartConsole クライアントを使用したクラスタ状態監視 状態ログ Mode inconsistency detected: member [ID] ([IP]) will change its mode to [MODE]. Please re-install the security policy on the cluster. このメッセージが出力されることはほとんどありません。このメッセージは、ローカル・ メンバが知らないクラスタ・モードをほかのクラスタ・メンバが報告したことを示します。 このメッセージは、通常、セキュリティ・ポリシーを全クラスタ・メンバにインストール するのに失敗した場合に発生します。この問題を解決するには、セキュリティ・ポリシー を再インストールしてください。 注： クラスタ・モードの不一致が検出された後でも、報告しているマシンのモードをほかのクラスタ・ メンバに合致するように変更すれば、クラスタは動作を継続します。ただし、できるだけ早くポリシー を再インストールしてください。 State change of member [ID] ([IP]) from [STATE] to [STATE] was cancelled, since all other members are down. Member remains [STATE]. メンバが自分の状態を変更する必要がある場合（たとえば、アクティブ・メンバに問題 が発生して自分自身をダウンさせる必要がある場合）、最初にほかのメンバの状態を問い 合わせます。ほかのすべてのメンバがダウンしている場合、このメンバは自分の状態を 非アクティブな状態に変更できません（変更すると、すべてのメンバがダウンし、クラ スタは機能しなくなります）。したがって、報告しているメンバは、問題があったとして も機能し続けます（ただし、通常は自分の状態を「アクティブ・アテンション」として 報告します）。 member [ID] ([IP]) <is active|is down|is stand-by|is initializing> ([REASON]). このメッセージはクラスタ・メンバが自分の状態を変更するときに必ず発行されます。 ログ・テキストには、メンバの新しい状態が示されます。 Pnote ログ PNote ログ・メッセージは、pnote デバイスが自分の状態を変更したときに発行されます。 [DEVICE] on member [ID] ([IP]) status OK ([REASON]). ■ pnote デバイスは正常に動作しています。 ■ [DEVICE] on member [ID] ([IP]) detected a problem ([REASON]). pnote デバイスによりエラーが検出されたか、デバイスが自分の状態を一定時間 （pnote の「timeout」オプションで設定された秒数）報告していないことを示します。 ■ [DEVICE] on member [ID] ([IP]) is initializing ([REASON]). デバイスは pnote メカニズムを使用してデバイス自身を登録しましたが、その状態が まだ確定していないことを示します。 ■ [DEVICE] on member [ID] ([IP]) is in an unknown state ([STATE ID]) ([REASON]). このメッセージは、通常は表示されません。チェック・ポイントのサポートにお問 い合わせください。 88 SmartView Tracker インタフェース・ログ interface [INTERFACE NAME] of member [ID] ([IP]) is up. ■ このインタフェースが正常に動作していることを示します。つまり、インタフェース は所定のサブネット上でパケットを送受信できます。 ■ interface [INTERFACE NAME] of member [ID] ([IP]) is down (receive <up|down>, transmit <up|down>). このメッセージは、パケットの受信または送信中にインタフェースに問題が発生し た場合に必ず発行されます。この場合、インタフェースは OS に関する限り正常に動 作を続行できますが、クラスタ設定が正しくないためにほかのクラスタ・メンバと 通信することはできません。 ■ interface [INTERFACE NAME] of member [ID] ([IP}) was added. 新しいインタフェースが VPN-1 Pro により登録されたこと（すなわち、このインタ フェースに到着するパケットはファイアウォールによりフィルタされるということ） をユーザに通知します。通常、このメッセージはインタフェースを起動したとき （たとえば UNIX システムで ifconfig up コマンドを発行したときなど）に発行され ます。以後、インタフェースは ClusterXL の報告に含まれるようになります（たとえ 。た ば、SmartView Monitor に表示されたり、cphaprob -a if で出力されたりします） だし、ClusterXL で「Disconnected」と設定されている場合は、インタフェースがそ のように報告される場合があります。 ■ interface [INTERFACE NAME] of member [ID] ([IP}) was removed. インタフェースが VPN-1 Pro から切り離されたため、ClusterXL から監視できなく なったことを示します。 SecureXL ログ ■ SecureXL device was deactivated since it does not support CPLS. このメッセージは、負荷共有をサポートしていないアクセラレーション・デバイス を使用して、負荷共有マルチキャスト・モードで VPN-1 Pro モジュール上に ClusterXL を設定しようとした場合に出力されます。この結果、アクセラレーション は停止しますが、クラスタはチェック・ポイント負荷共有モード（CPLS）で動作し ます。 理由を表す文字列 ■ member [ID] ([IP]) reports more interfaces up. このメッセージは pnote ログ・メッセージに含まれることがあり、問題の理由を示 します。別のメンバが、ローカル・メンバより多くの動作中のインタフェースを 持っていることを報告しています。これは、ローカル・メンバのインタフェースに 障害が発生していること、および相手のメンバのほうがクラスタ・メンバとしてよ り良い機能を提供できることを意味します。したがって、ローカル・メンバはダウ ンし、メッセージで指定されたメンバにトラフィックの処理が委ねられます。 第6章 ゲートウェイ・クラスタの監視とトラブルシューティング 89 ClusterXL 設定コマンド（cphaconf、cphastart、cphastop） ■ member [ID] ([IP]) has more interfaces - check your disconnected interfaces configuration in the <discntd.if file|registry>. このメッセージは、同じクラスタ内のメンバが持っているインタフェースの数が異 なる場合に発行されます。クラスタ内の最大数よりインタフェースの数が少ないメ ンバ（報告しているメンバ）は、正常に動作していない可能性があります。これは、 クラスタ IP アドレス、または同期ネットワークに対して動作するために必要なイン タフェースが欠けているためです。ほかのクラスタ・メンバのインタフェースの一部 が冗長で、ClusterXL から監視するべきではない場合、これらのインタフェースは明 示的に「Disconnected」として指定する必要があります。この指定を行うには、ファ 、または Windows のレジス イル $FWDIR/conf/discntd.if（UNIX システムの場合） トリを使用します。 ■ [NUMBER] interfaces required, only [NUMBER] up. ClusterXL が、監視している 1 つ以上のインタフェースで問題を検出しました。この メッセージは、必ずしもメンバがダウンすることを意味しません。ほかのメンバが 持つ動作中のインタフェースの方が少ない場合があるためです。このような条件で は、もっとも多くの動作中のインタフェースを持つメンバが動作を続行し、その他 はダウンします。 ClusterXL 設定コマンド（cphaconf、cphastart、cphastop） cphaconf コマンド このコマンドは実行しないことをお勧めします。このコマンドは通常 VPN-1 Pro によって 実行されます。 cphaconf [-i <machine id>] [-p <policy id>] [-b <db_id>] [-n <cluster num>][-c <cluster size>] [-m <service >] [-t <secured IF 1>...] start cphaconf cphaconf cphaconf cphaconf cphaconf cphaconf cphaconf cphaconf cphaconf cphaconf 90 [-t <secured IF 1>...] [-d <disconnected IF 1>...] add clear-secured clear-disconnected stop init forward <on/off> debug <on/off> set_ccp <broadcast/multicast> mc_reload debug_data cphastart コマンドと cphastop コマンド cphastart コマンドと cphastop コマンド クラスタ・メンバで cphastart を実行すると、そのメンバ上で ClusterXL が起動されます。 完全同期は開始されません。クラスタ・メンバを起動する場合は、cpstart を使用してく ださい。 クラスタ・メンバで cphastop を実行すると、クラスタ・メンバのトラフィック転送が停 止されます。ステート同期も停止されます。ただし、クラスタ・メンバに対して直接通 信を開始することは可能です。HA Legacy モードでは、cphastop を実行するとクラスタ 全体の機能が停止する場合があります。 これらのコマンドは通常 VPN-1 Pro によってのみ実行し、管理者が直接実行しないでくだ さい。 フェイルオーバーの開始方法 このセクションの構成 クラスタ・メンバの停止 91 ページ クラスタ・メンバの起動 92 ページ クラスタ・メンバの状態を手動で制御することにより、クラスタ・メンバを停止させる ことができます。負荷共有の場合、クラスタ・メンバを停止させるとほかのクラスタ・メ ンバ（1 つまたは複数）へのフェイルオーバーが開始され、HA の場合は、次に高い優先 順位を持つクラスタ・メンバにフェイルオーバーが開始されます。 クラスタ・メンバの停止 マシン上の ClusterXL を停止させてほかのマシンへのフェイルオーバーを発生させるに は、以下のいずれかを実行します。 ■ ■ cphaprob -d faildevice -t 0 -s ok register コマンドを使用してダミーのク リティカル・デバイス（たとえば faildevice）を登録し、次のコマンドを実行して クリティカル・デバイス faildevice に問題が発生していることを ClusterXL に報告 します。cphaprob -d faildevice -s problem report. 別のクラスタ・メンバへ のフェイルオーバーが直ちに発生します。 SmartView Monitor を開いてクラスタ・オブジェクトをクリックします。メンバ・ ゲートウェイ・ブランチの 1 つを選択し、クラスタ・メンバをクリックして［Down］ を選択します。 第6章 ゲートウェイ・クラスタの監視とトラブルシューティング 91 同期の監視（fw ctl pstat） クラスタ・メンバの起動 クラスタ・メンバ上で VPN-1 Pro が起動（cpstart）されると、ClusterXL が自動的に起動 します。ClusterXL の再起動を開始するには、以下のいずれかを実行します。 cphaprob -d faildevice -s problem report コマンドを使用してダウンさせた クラスタ・メンバを再度アクティブにするには、以下のコマンドのどちらかを使用 します。 ■ cphaprob -d faildevice -s ok report cphaprob -d faildevice unregister ■ SmartView Monitor を開いてクラスタ・オブジェクトをクリックします。メンバ・ ゲートウェイ・ブランチの 1 つを選択し、クラスタ・メンバをクリックして［Up］ を選択します。 注： SmartView Monitor からクラスタ・メンバを起動しても完全同期は開始されないため、通信の 一部が失われる場合があります。完全同期を開始するには、 cpstart コマンドを実行します。 同期の監視（fw ctl pstat） ClusterXL またはサード・パーティ OPSEC 認定クラスタ製品上の同期メカニズムを監視す るには、クラスタ・メンバ上で以下のコマンドを実行します。 fw ctl pstat このコマンドを実行すると、VPN-1 Pro ゲートウェイの統計データの長いリストが出力さ れます。リストの最後には、 「Synchronization」というセクションがあり、ゲートウェイ・ クラスタ・メンバに適用されます。統計データのほとんどはカウント・アップ専用のカ ウンタです。標準的な出力を以下に示します。 Version: new Status: Able to Send/Receive sync packets Sync packets sent: total : 3976, retransmitted : 0, retrans reqs : 58, acks : 97 Sync packets received: total : 4290, were queued : 58, dropped by net : 47 retrans reqs : 0, received 0 acks retrans reqs for illegal seq : 0 Callback statistics: handled 3 cb, average delay : 1, max delay : 2 Delta Sync memory usage: currently using XX KB mem Callback statistics: handled 322 cb, average delay : 2, max delay : 8 Number of Pending packets currently held: 1 Packets released due to timeout: 18 92 クラスタ・メンバの起動 このプリント出力の各行の意味を以下に示します。 Version: new 同期が設定された場合は、この行は必ず表示されます。この行は、 （バージョン 4.1 の旧 同期ではなく）新しい同期が動作中であることを示します。 Status: Able to Send/Receive sync packets 同期がパケットを送信または受信できない場合、問題が発生しています。起動中であれ ば、同期は一時的にパケットを送受信できなくなる場合がありますが、通常の動作で送 受信できなくなることはありません。完全同期の実行時は、同期パケットの受信が中断 される場合があります。 Sync packets sent: total : 3976, retransmitted : 0, retrans reqs : 58, acks : 97 送信された同期パケットの合計数が表示されます。同期パケットの合計数はゼロ以外の 数値であり、増加します。 同期パケットの受信順序が正しくない場合、クラスタ・メンバは再送要求を送信します。 この数値は負荷があると増加します。 ほかのクラスタ・メンバによって確認応答が要求されると、受信した同期パケットに対 して送信された確認応答が Acks として示されます。 Sync packets received: total : 4290, were queued : 58, dropped by net : 47 受信された同期パケットの合計数が表示されます。以下のいずれかの条件に該当する同 期パケットが受信されると、「queued」で示されるパケット数が増加します。 1 受信された同期パケットのシーケンス番号が、前に処理された同期パケットのシーケ ンス番号と連続していない。 2 同期パケットがフラグメント化している。これは MTU 制限を解消するために発生しています。 この数値は減少することはありません。ゼロ以外の数値が表示されても問題を示してい るわけではありません。 第6章 ゲートウェイ・クラスタの監視とトラブルシューティング 93 同期の監視（fw ctl pstat） dropped by net の数値は、ネットワーク輻輳を示している場合があります。負荷がある 場合、この数値はゆっくりと増加します。この数値が急速に増加する場合は、ネットワー ク・エラーが同期プロトコルを阻害している可能性があります。この場合は、ネットワー クを確認してください。 retrans reqs : 0, received 0 acks retrans reqs for illegal seq : 0 Callback statistics: handled 3 cb, average delay : 1, max delay : 2 前述のメッセージが送信された再送要求の数を示しているのに対し、このメッセージは受 信された再送要求の数を示します。この数値が急速に増加する場合は、マシンの負荷が高 くなりすぎて同期が処理できなくなっている可能性があります。 Acks は、 「cb request」同期パケット、つまり確認応答要求付きの同期パケットに対して受 信された確認応答の数を示します。 Retrans reqs for illegal seq は、このメンバに存在していないパケットに対する再 送要求数を示します。この値は、同期に問題があることを示している場合があります。 Callback statistics は、 Flush and Ackを呼び出す受信パケットに関連する値を示します。 この統計は、ゼロ以外の値に対してのみ表示されます。 コールバックの average delay は、メンバがほかのすべてのメンバから ACK を受信した ときに、パケットが開放される前にこのメンバで生じた遅延を示します。遅延が生じる のは、ほかのすべてのクラスタ・メンバから同期パケットを受信したことを示す確認応 答が返されるまでパケットが保持されるためです。 この値はパケット数で測定されます。通常、これは小さい値（1 ～ 5 程度）でなければなり ません。この値が大きい場合、同期トラフィックの過負荷を表している可能性があります。 この場合、同期の確認応答を要求する通信に若干の遅延が生じます。 dropped updates as a result of sync overload: 0 負荷の大きいシステムでは、クラスタ・メンバはほかのクラスタ・メンバから送信され た同期アップデートを破棄する場合があります。 Delta Sync memory usage: currently using XX KB mem 94 クラスタ・メンバの起動 Delta Sync memory usage は、ゼロ以外の値に対してのみ表示されます。差分同期では、 完全同期が発生している間のみメモリが必要です。完全同期が発生するのは、再起動後 にシステムが立ち上がったときなどです。ほかの場合は、差分同期のアップデートは即 座に適用されるため、差分同期ではメモリは消費されません。差分同期の詳細について は、21 ページの「ステート同期の動作」を参照してください。 Number of Pending packets currently held: 1 Packets released due to timeout: 18 Number of Pending packets currently held は、ゼロ以外の値に対してのみ表示され ます。ClusterXL は、非対称通信で状態に合致しないパケットが発生するのを防止します。 これを行うために、ほかのすべてのアクティブなクラスタ・メンバから SYN-ACK が受信さ れるまで、パケットが保持されます。何らかの理由で SYN-ACK が受信されない場合、クラ スタ・メンバ上の VPN-1 Pro はパケットを開放しないため、通信は確立されません。 Packets released due to timeout は、ゼロ以外の値に対してのみ表示されます。処 理待ちパケット数が多い場合（Number of Pending Packets の値が 100 を超える場合） で、かつ Packets released due to timeout（タイムアウトにより開放されるパケット 数）が小さい場合、処理待ちパケット数を減らす処置を行う必要があります。この問題 の対処法については、129 ページの「処理待ちパケット数の削減」を参照してください。 第6章 ゲートウェイ・クラスタの監視とトラブルシューティング 95 同期のトラブルシューティング（cphaprob [-reset] syncstat） 同期のトラブルシューティング（cphaprob [-reset] syncstat） cphaprob [-reset] syncstat の概要 96 ページ cphaprob [-reset] syncstat コマンドの出力 97 ページ 同期のトラブルシューティング・オプション 105 ページ cphaprob [-reset] syncstat の概要 負荷の高いクラスタと地理的に隔離されているメンバを持つクラスタには特別な処置が 必要です。高速な通信速度およびメンバ間の距離によって、クラスタの動作に影響を与 える遅延が生じる可能性があります。 cphaprob [-reset] syncstat コマンドは、高負荷の分散クラスタにおいて、ステート 同期メカニズムの動作を監視するツールです。このツールは、ClusterXL とサード・パー ティ OPSEC 認定クラスタ製品の両方で使用できます。 トラブルシューティング手順を以下に示します。 1 cphaprob syncstat コマンドを実行します。 2 出力される統計データを調査して理解します。 3 関連する同期のグローバル設定パラメータを調整します。 4 コマンドを再実行します。このとき、-reset オプションを使用して統計カウンタを リセットします。 cphaprob -reset syncstat 5 出力される統計データを調査して、問題が解決されているかどうかを確認します。 97 ページの「cphaprob [-reset] syncstat コマンドの出力」で、各出力パラメータおよび 出力に問題がある場合について説明します。 認識した問題は、105 ページの「同期のトラブルシューティング・オプション」で説明 する 1 つまたは複数のヒントを実施することで解決できます。 96 cphaprob [-reset] syncstat コマンドの出力 cphaprob [-reset] syncstat コマンドの出力 cphaprob syncstat コマンドの出力パラメータを表 6-2 に示します。出力される値（記載 されていません）を調べることで、同期ネットワークの状態と特徴が分かります。各パ ラメータと発生する可能性のある値の意味については、次のセクションで説明します。 表 6-2 cphaprob syncstat コマンドの出力パラメータ 97 ページの「Sync Statistics (IDs of F&A Peers - 1):」 98 ページの「Other Member Updates:」 98 98 98 99 99 99 ページの「Sent retransmission requests」 ページの「Avg missing updates per request」 ページの「Old or too-new arriving updates」 ページの「Unsynced missing updates」 ページの「Lost sync connection（num of events）」 ページの「Timed out sync connection」 99 ページの「Local Updates:」 100 100 100 100 101 101 102 102 103 103 103 104 ページの「Total generated updates」 ページの「Recv Retransmission requests」 ページの「Recv Duplicate Retrans request」 ページの「Blocking Scenarios」 ページの「Blocked packets」 ページの「Max length of sending queue」 ページの「Avg length of sending queue」 ページの「Hold Pkts events」 ページの「Unhold Pkt events」 ページの「Not held due to no members」 ページの「Max held duration（ticks）」 ページの「Avg held duration（ticks）」 104 ページの「Timers:」 104 ページの「Sync tick（ms）」 104 ページの「CPHA tick（ms）」 104 ページの「Queues:」 104 ページの「Sending queue size」 105 ページの「Receiving queue size」 Sync Statistics (IDs of F&A Peers - 1): これらの統計はステート同期メカニズムに関連します。F&A（Flush and Ack）ピアは、 このメンバがクラスタの一部として認識するクラスタ・メンバです。ID は、cphaprob state コマンドによって生成される ID と IP アドレスに対応しています。 第6章 ゲートウェイ・クラスタの監視とトラブルシューティング 97 同期のトラブルシューティング（cphaprob [-reset] syncstat） Other Member Updates: このセクションの統計は、ほかのクラスタ・メンバによって生成されたアップデート、 またはほかのメンバから受信されたものではないアップデートに関連します。アップ デートにより、クラスタ・メンバによって処理された通信の変更が通知されます。アッ プデートはメンバ間で送受信されます。アップデートはシーケンス番号で識別されます。 Sent retransmission requests このメンバによって送信された再送要求の数です。再送要求は、送信しているメンバは すでに次のシーケンスを持つアップデートを受信しているにも関わらず、（指定された シーケンス番号を持つ）特定のパケットがない場合に送信されます。 この値が高い場合は、通信に問題がある可能性があります。 ヒント：再送要求の数をほかのメンバの Total Regenerated Updates（再生成されたアップデートの合 計数）と比較します（100 ページの「Total generated updates」を参照）。 この値が過度に高い（ほかのメンバの Total Generated Updates の 30% を超える）場合は、全出力および ネットワーク・トポロジと設定に関する詳細な説明を準備して、技術サポートにお問い合わせください。 Avg missing updates per request 各再送要求では、最大 32 個の欠落している連続したパケットを含むことができます。 このフィールドの値は、再送要求ごとに要求されるシーケンスの平均数です。 各再送要求に 20 個を超える連続したシーケンスが欠落している場合は、通信に問題が ある可能性があります。 ヒント：この値が過度に高い場合は、全出力およびネットワーク・トポロジと設定に関する詳細な説明 を準備して、技術サポートにお問い合わせください。 Old or too-new arriving updates 到着する同期アップデートの中でシーケンス番号が小さすぎるアップデートの数です。 これは、アップデートが古い転送に属していることを示します。または、シーケンス番 号が大きすぎて新しい転送に属せないアップデートの数です。 この値が大きい場合は、通信に問題があることを示しています。 ヒント：105 ページの「受信キューの拡張」を参照してください。この値が過度に高い（送信された 全アップデートの 10% を超える）場合は、全出力およびネットワーク・トポロジと設定に関する詳細 な説明を準備して、技術サポートにお問い合わせください。 98 cphaprob [-reset] syncstat コマンドの出力 Unsynced missing updates 受信しているメンバが待機を中断した、失われた同期アップデートの数です。新しく到 着するアップデートと失われたアップデートのシーケンス番号の差が受信キューの長さ を超える場合に、メンバは待機を中断します。 この値は通常はゼロです。ただし、失われたアップデートの数が生成された全アップデー トの 1% に満たない場合は、アップデートの一部が失われていても許容されます。 ヒント：失われたアップデートの数を減らすには、受信キューの容量を拡張します。105 ページの 「受信キューの拡張」を参照してください。 Lost sync connection（num of events） ほかのメンバへのセキュリティ・ポリシーのインストール、または期待されるシーケン ス番号と受信したシーケンス番号の違いが大きいために、ほかのメンバとの同期が失わ れてから再取得されたイベントの数です。 この値は通常はゼロです。この値が正の数の場合は、通信に問題があることを示します。 ヒント：同期メカニズムがシーケンス番号の大きな違いを処理できるようにするには、受信キューの 容量を拡張します。105 ページの「受信キューの拡張」を参照してください。 Timed out sync connection ほかのメンバが接続されていないことをメンバが宣言したイベントの数です。一定時間 （1 秒間）ACK パケットがそのメンバから受信されなかったため、そのメンバのために Flush and Ack パケットが保持されていますが、メンバは切断されていると判断されます。 この値は通常はゼロです。同期ネットワークのラウンド・トリップ・タイムが 100 ミリ秒 の場合でも、1 秒あれば ACK を受信するには充分であると考えられます。この値が正の 数の場合は、通信に問題があることを示します。 ヒント：同期タイマを増加してみてください（106 ページの「同期タイマの拡張」を参照）。ただし、 全出力およびネットワーク・トポロジと設定に関する詳細な説明を準備して、技術サポートに連絡する 必要がある可能性があります。 Local Updates: このセクションの統計データは、ローカル・クラスタ・メンバによって生成されたアップ デートに関連します。アップデートにより、クラスタ・メンバによって処理された通信の 変更について通知されます。アップデートはメンバ間で送受信されます。アップデート はシーケンス番号で識別されます。 第6章 ゲートウェイ・クラスタの監視とトラブルシューティング 99 同期のトラブルシューティング（cphaprob [-reset] syncstat） Total generated updates 前回統計がリセットされてから、同期メカニズムによって生成された同期アップデート・ パケットの数です。この値は、-reset オプションを適用したときのシーケンス番号と現 在のシーケンス番号の差に等しくなります。 この値には範囲は定められていません。 Recv Retransmission requests 受信した再送要求の数です。すでに受信したシーケンス番号よりも小さいシーケンス番 号を持つ指定されたパケットが失われている場合に、メンバは再送を要求します。 この値が高い場合は、通信に問題がある可能性があります。 ヒント：この値が過度に高い（100 ページの「Total generated updates」の 30% を超える）場合は、 全出力およびネットワーク・トポロジと設定に関する詳細な説明を準備して、技術サポートにお問い 合わせください。 Recv Duplicate Retrans request メンバによって受信された重複する再送要求の数です。重複する要求はすでに処理され ているため破棄されます。 この値が大きい場合は、ネットワーク上の問題または同期ネットワーク上にストームが 発生している可能性があります。 ヒント：この値が過度に高い（100 ページの「Total generated updates」の 30% を超える）場合は、 全出力およびネットワーク・トポロジと設定に関する詳細な説明を準備して、技術サポートにお問い 合わせください。 Blocking Scenarios 極度の高負荷状態では、クラスタは新しい通信を阻止します。このパラメータは、同期 の負荷が大きすぎるために、クラスタ・メンバが新しい接続の遮断を開始した回数を示 します。 送信キューが容量のしきい値に達すると、メンバは通信を阻止し始めます。容量のしき い値は、現在のシーケンス番号とほかのすべての動作中のメンバからメンバが受信した ACK のシーケンス番号の差の 80% として計算されます。 この値が正の数の場合は、負荷が高すぎることを示します。この場合は、101 ページの 「Blocked packets」に従って阻止されたパケット数を確認します。破棄されたパケット 1 個につき、1 つの通信が阻止されたことを意味します。 100 cphaprob [-reset] syncstat コマンドの出力 このパラメータは、新しい接続の遮断メカニズム（127 ページの「高負荷状態での新しい 接続の阻止」を参照）がアクティブの場合にのみ測定されます。新しい接続の遮断メカ ニズムを有効にするには、すべてのクラスタ・メンバ上で以下のコマンドを適用します。 fw ctl set int fw_sync_block_new_conns 0 ヒント：通信阻止に関する深刻な問題に対処する最良の方法は、送信キューを拡張することです。 105 ページの「送信キューの拡張」を参照してください。 ほかの対処方法としては、メンバが ACK を開始した後のタイムアウトを減少させる方法があります。 106 ページの「確認応答タイムアウトの再設定」を参照してください。これにより、送信キューの 容量をより正確にアップデートして、阻止プロセスをより厳密に実施することができます。 Blocked packets クラスタ・メンバがすべての新しい通信を阻止していたために阻止されたパケット数です （100 ページの「Blocking Scenarios」を参照してください）。阻止されたパケット数は、通 常、新しい通信が試行されるごとに 1 パケットです。 送信キューの 5% を超える値（102 ページの「Avg length of sending queue」を参照）は、 通信上の問題、または ACK の送信頻度が低いことを示している場合があります。 このパラメータは、新しい接続の遮断メカニズム（127 ページの「高負荷状態での新しい 接続の阻止」を参照）がアクティブの場合にのみ測定されます。新しい接続の遮断メカ ニズムを有効にするには、クラスタ・メンバ上で以下のコマンドを適用します。 fw ctl set int fw_sync_block_new_conns 0 ヒント：通信阻止に関する深刻な問題に対処する最良の方法は、送信キューを拡張することです。 105 ページの「送信キューの拡張」を参照してください。 ほかの対処方法としては、メンバが ACK を開始した後のタイムアウトを減少させる方法があります。 106 ページの「確認応答タイムアウトの再設定」を参照してください。これにより、送信キューの 容量をより正確にアップデートして、阻止プロセスをより厳密に実施することができます。 Max length of sending queue 送信キューのサイズは固定されています。デフォルトでは、これは 512 個の同期アップ デートです。シーケンス番号の大きい新しいアップデートがキューに入ると、シーケン ス番号の小さい古いアップデートはキューから破棄されます。古いアップデートは、メ ンバがほかのすべてのメンバからそのアップデートに関する ACK を受信する前にキュー から破棄される場合があります。 このパラメータは、現在の同期シーケンス番号とメンバがほかのすべてのメンバから該 当する ACK を受信した最後のシーケンス番号との差です。このため、このパラメータの 値は 512 を上回ることがあります。 第6章 ゲートウェイ・クラスタの監視とトラブルシューティング 101 同期のトラブルシューティング（cphaprob [-reset] syncstat） このパラメータの値は 512 未満でなければなりません。512 を上回る場合でも、必ずしも 同期に問題があるとは限りません。ただし、メンバは、キューに存在しないアップデー トに対する再送要求に応えることができなくなります。 このパラメータは、新しい接続の遮断メカニズム（127 ページの「高負荷状態での新しい 接続の阻止」を参照）がアクティブの場合のみ測定されます。新しい接続の遮断メカニ ズムを有効にするには、クラスタ・メンバ上で以下のコマンドを適用します。 fw ctl set int fw_sync_block_new_conns 0 ヒント：送信キューを拡張して、この値より大きい値に変更します。105 ページの「送信キューの 拡張」を参照してください。 Avg length of sending queue 再起動後または同期統計のリセット後の Max length of sending queue パラメータの平均値 です。 この値は、最大で送信キューのサイズの 80% です。 このパラメータは、新しい接続の遮断メカニズム（127 ページの「高負荷状態での新しい 接続の阻止」を参照）がアクティブの場合のみ測定されます。新しい接続の遮断メカニ ズムを有効にするには、クラスタ・メンバ上で以下のコマンドを適用します。 fw ctl set int fw_sync_block_new_conns 0 ヒント：送信キューを拡張して、この値が新しいキューのサイズの 80% を上回らないようにします。 105 ページの「送信キューの拡張」を参照してください。 Hold Pkts events 同期アップデートが Flush and Ack を必要とし、動作中のその他すべてのメンバから ACK が到着するまでシステム内に保持された回数です。 Unhold Pkt events の数値と同じでなければなりません。 ヒント：全出力およびネットワーク・トポロジと設定に関する詳細な説明を準備して、技術サポートに お問い合わせください。 102 cphaprob [-reset] syncstat コマンドの出力 Unhold Pkt events 動作中のほかのメンバから要求されたすべての ACK をメンバが受信した回数です。 Hold Pkts events の数値と同じでなければなりません。 ヒント：全出力およびネットワーク・トポロジと設定に関する詳細な説明を準備して、技術サポートに お問い合わせください。 Not held due to no members ほかに動作中のメンバがなかったために、システム内に保持すべきであったにも関わら ず開放されたパケット数です。 クラスタに最低 2 つのアクティブなメンバがある場合は、通常、この値は 0 です。 ヒント：クラスタに通信上の問題が発生しています。パラメータの値を調査する必要があります。 99 ページの「Lost sync connection（num of events）」と 99 ページの「Timed out sync connection」を 確認して、自分が唯一のクラスタ・メンバであるとメンバが判断した原因を調査してください。 また、全出力およびネットワーク・トポロジと設定に関する詳細な説明を準備して、技術サポートに 連絡する必要がある可能性もあります。 Max held duration（ticks） Flush and Ack のために保持されているパケットがシステム内で遅延した最大時間（単位は ティック。1 ティックは 100 ミリ秒）です。 一定時間後に保持されているパケットを開放する処理待ちタイムアウト・メカニズムの ため、この値は 50（5 秒）より小さい値でなければなりません。デフォルトでは、開放す るまでのタイムアウトは 50 ティックです。この値が高い場合は、メンバ間で通信上の問 題が発生していることを示します。 ヒント：必要に応じて、fwldbcast_pending_timeout グローバル値を変更して、デフォルトのタイム アウトを変更してください。125 ページの「モジュール設定パラメータの設定方法」と 129 ページの 「処理待ちパケット数の削減」を参照してください。 また、99 ページの「Timed out sync connection」のパラメータも調査して、パケットが長時間保持され た原因を確認してください。 また、全出力およびネットワーク・トポロジと設定に関する詳細な説明を準備して、技術サポートに 連絡する必要がある可能性もあります。 第6章 ゲートウェイ・クラスタの監視とトラブルシューティング 103 同期のトラブルシューティング（cphaprob [-reset] syncstat） Avg held duration（ticks） Flush and Ack のために保持されているパケットがシステム内で遅延した平均時間（単位 はティック。1 ティックは 100 ミリ秒）です。 平均時間は、同期ネットワークのラウンドトリップ時間とほぼ同じです。この値が大き い場合は、通信に問題があることを示します。 ヒント：この値が大きい場合は、問題の原因を調査するために、全出力およびネットワーク・トポロジ と設定に関する詳細な説明を準備して、技術サポートにお問い合わせください。 Timers: Sync タイマと CPHA タイマは、同期とクラスタに関連する処理を一定時間ごとに実施し ます。 Sync tick（ms） 同期タイマは、クラスタに関連する処理を一定時間ごとに実施します。デフォルトでは、 同期タイマの間隔は 100 ミリ秒です。基本となる時間単位は 100 ミリ秒（または 1 ティック） で、これが最小値です。 CPHA tick（ms） CPHA タイマは、クラスタに関連する処理を一定時間ごとに実施します。デフォルトでは、 CPHA タイマの間隔は 100 ミリ秒です。基本となる時間単位は 100 ミリ秒（または 1 ティック） で、これが最小値です。 Queues: 各クラスタ・メンバには 2 つのキューがあります。送信キューと受信キューです。 Sending queue size クラスタ・メンバ上の送信キューには、ローカルで生成された同期アップデートが格納さ れます。送信キュー内のアップデートは、より最新のアップデートに置き換えられます。 このため、負荷の高いクラスタでは、アップデートは短時間しか保持されません。アップ デートを再送信するようにメンバに要求があった場合、アップデートが送信キューにある 場合にのみ送信できます。送信キューのデフォルト・サイズ（最小値と同じ）は 512 です。 各メンバには 1 つの送信キューがあります。 104 同期のトラブルシューティング・オプション Receiving queue size クラスタ・メンバ上の受信キューは、アップデートのシーケンスをすべて受信し終えるま で、各クラスタ・メンバからのアップデートを保持します。受信キューのデフォルト・サ イズ（最小値と同じ）は 256 です。各メンバは、ピア・メンバごとに受信キューを保持します。 同期のトラブルシューティング・オプション 以下のオプションでは、利用可能なトラブルシューティング・オプションを明記します。 各オプションでは、グローバル・システム設定パラメータを編集して、デフォルトとは 異なる値にシステムを再設定します。 送信キューの拡張 クラスタ・メンバ上の送信キューには、ローカルで生成された同期アップデートが格納さ れます。送信キュー内のアップデートは、より最新のアップデートに置き換えられます。 このため、負荷の高いクラスタでは、アップデートは短時間しか保持されません。アップ デートを再送信するようにメンバに要求があった場合、アップデートが送信キューにある 場合にのみ送信できます。送信キューのデフォルト・サイズ（最小値と同じ）は 512 です。 各メンバには 1 つの送信キューがあります。 送信キューのサイズを拡張するには、グローバル・パラメータ fw_sync_sending_queue_size の値を変更します。125 ページの「モジュール設定パラ メータの設定方法」を参照してください。また、必要なキュー・サイズが、オペレー ティング・システムの起動時に変更されないことを確認してください。126 ページの 「モジュール設定パラメータを起動時に有効にする方法」を参照してください。 このキューを拡張すると、このメンバはほかのメンバからのアップデートをより多く保 存できるようになります。ただし、保存された各アップデートはメモリを消費すること に注意してください。この変数を変更する場合は、メモリへの影響を考慮してください。 変更は、再起動後に適用されます。 受信キューの拡張 クラスタ・メンバ上の受信キューは、アップデートのシーケンスをすべて受信し終える まで、各クラスタ・メンバからのアップデートを保持します。受信キューのデフォルト・ サイズ（最小値と同じ）は 256 です。各メンバは、ピア・メンバごとに受信キューを保持 します。 受信キューのサイズを拡張するには、グローバル・パラメータ fw_sync_recv_queue_size の値を変更します。125 ページの「モジュール設定パラメータの設定方法」を参照して ください。また、必要なキュー・サイズが、オペレーティング・システムの起動時に変 更されないことを確認してください。126 ページの「モジュール設定パラメータを起動 時に有効にする方法」を参照してください。 第6章 ゲートウェイ・クラスタの監視とトラブルシューティング 105 同期のトラブルシューティング（cphaprob [-reset] syncstat） このキューを拡張すると、このメンバはほかのメンバからのアップデートをより多く保 存できるようになります。ただし、保存された各アップデートはメモリを消費すること に注意してください。この変数を変更する場合は、メモリへの影響を考慮してください。 変更は、再起動後に適用されます。 同期タイマの拡張 同期タイマは、同期に関連する処理を一定時間ごとに実施します。デフォルトでは、同期 タイマの間隔は 100 ミリ秒です。基本となる時間単位は 100 ミリ秒（または 1 ティック） で、これが最小値です。 同期タイマを拡張するには、グローバル・パラメータ fwha_timer_sync_res の値を変更し ます。125 ページの「モジュール設定パラメータの設定方法」を参照してください。この 変数の値は、システムの動作中に変更できます。再起動は必要ありません。 デフォルトでは、fwha_timer_sync_res は 1 の値を保持しており、同期タイマは基本の時 間単位（100 ミリ秒）ごとに動作します。この値を n に変更すると、タイマは n*100 ミリ秒 ごとに動作します。 CPHA タイマの拡張 CPHA タイマは、クラスタに関連する処理を一定時間ごとに実施します。デフォルトでは、 CPHA タイマの間隔は 100 ミリ秒です。基本となる時間単位は 100 ミリ秒（または 1 ティック） で、これが最小値です。 クラスタ・メンバがお互いに地理的に離れた場所にある場合、CPHA タイマを同期ネット ワークのラウンドトリップ遅延の約 10 倍に設定します。 この値を拡張すると、フェイルオーバーの検出にかかる時間が長くなります。たとえば、 インタフェース障害の検出に 0.3 秒かかるときに、タイマが 2 倍の 200 ミリ秒に設定され た場合、インタフェース障害の検出に必要な時間は 2 倍の 0.6 秒になります。 CPHA タイマを拡張するには、グローバル・パラメータ fwha_timer_cpha_res の値を変 更します。125 ページの「モジュール設定パラメータの設定方法」を参照してください。 この変数の値は、システムの動作中に変更できます。再起動は必要ありません。 デフォルトでは、fwha_timer_cpha_res は 1 の値を保持しており、CPHA タイマは基本 の時間単位（100 ミリ秒）ごとに動作します。この値を n に変更すると、タイマは n*100 ミリ秒ごとに動作します。 確認応答タイムアウトの再設定 クラスタ・メンバは、定期的に送信キューからのアップデートを削除します（104 ページ の「Sending queue size」を参照）。これにより、キュー内のスペースを開放し、より最新 のアップデートを格納できます。 106 同期のトラブルシューティング・オプション ピア・メンバからアップデートに関する ACK を受信すると、クラスタ・メンバはこの キューからのアップデートを削除します。 ピア・メンバは、新しい接続の遮断メカニズム（127 ページの「高負荷状態での新しい接 続の阻止」を参照）が有効な場合は、以下の 2 つの状況のどちらかに当てはまる場合に ACK を送信します。 ■ ■ 特定数のアップデートの受信後。 一定時間 ACK を送信していない場合。これは、同期ネットワークの回線で大きな遅 延が発生している場合に重要です。これはクラスタ・メンバがお互いに地理的に離 れた場所にある場合に発生する可能性があります。 メンバが ACK を送信した後のタイムアウトを設定するには、グローバル・パラメータ fw_sync_ack_time_gap の値を変更します。125 ページの「モジュール設定パラメータの 設定方法」を参照してください。この変数の値は、システムの動作中に変更できます。再 起動は必要ありません。 この変数のデフォルト値は 10 ティック（10*100 ミリ秒）です。このため、メンバが 1 秒間 ACK を送信していない場合、受信したアップデートに対して ACK を送信します。 技術サポートへの問い合わせ ここで紹介したトラブルシューティングを実行しても問題が解決しない場合は、技術サ ポートにお問い合わせください。 ClusterXL のエラー・メッセージ このセクションの構成 ClusterXL の一般的なエラー・メッセージ 108 ページ SmartView Tracker のアクティブ・モード・メッセージ 109 ページ 同期関連のエラー・メッセージ 110 ページ TCP Out-of-State エラー・メッセージ 111 ページ プラットフォーム固有のエラー・メッセージ 112 ページ このセクションでは、ClusterXL のエラー・メッセージについて説明します。このほかの 一般的でないエラー・メッセージについては、https://secureknowledge.checkpoint.com にあ る SecureKnowledge のソリューション sk23642 を参照してください。 第6章 ゲートウェイ・クラスタの監視とトラブルシューティング 107 ClusterXL のエラー・メッセージ ClusterXL の一般的なエラー・メッセージ ■ FW-1: changing local mode from <mode1> to <mode2> because of ID <machine_id> このログ・メッセージは、クラスタ・メンバ間で動作モードが統一されていない場 合、たとえば、1 つのマシンが HA モードで動作し、別のマシンが負荷共有マルチ キャストまたはユニキャスト・モードで動作しているような場合に出力されます。 この場合、ClusterXL の内部メカニズムは動作モードを最も低い共通モードに変更す ることにより、クラスタ・メンバ間の設定を同期化しようとします。動作モードの 優先順位は（最高から最低の順）、1. 同期のみ、2. 負荷共有、3.HA（アクティブ・ アップ） 、4.HA（プライマリ・アップ）の順になります。 ■ CPHA: Received confirmations from more machines than the cluster size このログ・メッセージは、クラスタにポリシーをインストールするときに出力さ れます。このメッセージは、クラスタ内に重大な設定上の問題があることを意味 します。ほかのクラスタに同一のパラメータがすでに設定されており、両クラス タが共通のネットワークを持っていることが考えられます。 ■ fwldbcast_timer: peer X probably stopped... このログ・メッセージは、このメッセージを出力したメンバが、特定の種類のメッ セージをメンバ X から受信待ちしなくなった場合に出力されます。cphaprob state ですべてのメンバがアクティブとして表示されており、fw ctl pstat に同期が正し く設定されていて、なおかつすべてのメンバ上で正常に動作しているかを確認して ください。このような場合、一時的に通信上の問題が発生した後、しばらくして問 題が解消したことが考えられます。2 つのメンバ間で一時的な同期上の問題が発生し たために、複数の通信で問題が発生した可能性があります。また、このメッセージ はほかのメンバが実際にダウンしていることを示している可能性があります。 ■ FW-1: fwha_notify_interface: there are more than 4 IPs on interface <interface name> notifying only the first ones 報告しているマシンと同一クラスタ内にあるメンバが、同一のインタフェース上に 3 つを超える仮想 IP アドレスを定義していることを意味します。この設定はサポート されていないため、ClusterXL の機能を使用できなくなる可能性があります。 ■ Sync could not start because there is no sync license ライセンス・エラー・メッセージです。VPN-1 Pro の基本ライセンスを持っていれ ば、同期もライセンスが許可されます。cplic print と cplic check を使用して、 VPN-1 Pro の基本ライセンスを調べてください。 ■ FW-1: h_slink: an attempt to link to a link kbuf id not found fw_conn_post_inspect: fwconn_init_links failed 完全同期セッションでは、完全同期プロセス中に接続の開設と切断が行われると、 このような問題が発生する場合があります。完全同期はある程度は自動的に行われ ますが、パフォーマンス上の理由で完全には自動化されていません。ゲートウェイ は完全同期サーバとして機能している間もトラフィックを処理し続けます。このた め、接続が 2 回削除されたり、既存のリンクにリンクされたりするなどの軽度の問 題が発生する場合があります。通信が失われたり、セキュリティ上の問題が発生し たりすることはありません。 108 SmartView Tracker のアクティブ・モード・メッセージ ■ Error SEP_IKE_owner_outbound: other cluster member packet in outbound クラスタが同期化されていません。一般に、OPSEC 認定サード・パーティ負荷共 有製品で、クラスタ・オブジェクトの［3rd Party Configuration］ ページの［Support non-sticky connections］ がオフになっている場合に出力されます （NG FP3 クラス タで、プロパティ use_limited_flushnack が false に設定されている場合も同 様です）。 ■ FW-1: fwha_pnote_register: too many registering members, cannot register クリティカル・デバイス（問題通知または pnote とも呼ばれます）メカニズムに保存 できる異なるデバイス数は最大 16 個です。17 個目のデバイスを（cphaprob.conf ファイルを編集するか cphaprob -d ... register コマンドを使用することによ り）設定しようとすると、このメッセージが出力されます。 ■ FW-1: fwha_pnote_register: <NAME> already registered (# <NUMBER>) pnote メカニズムに登録する各デバイスには、固有の名前を付ける必要があります。 このメッセージは、新しい pnote デバイスを登録するときに出力され、デバイス <NAME> は pnote 番号 <NUMBER> ですでに登録されていることを示します。 ■ FW-1: fwha_pnote_unregister: attempting to unregister an unregistered device <DEVICE NAME> 現在登録されていないデバイスの登録を削除しようとしたことを示します。 ■ FW-1: alert_policy_id_mismatch: failed to send a log 2 つ以上のメンバ間に異なるポリシー ID が存在することを示すログが送信されませ んでした。すべてのクラスタ・メンバが同一のポリシーを持っていることを確認し てください（fw stat を使用）。ポリシーの再インストールをお勧めします。 ■ FW-1: fwha_receive_fwhap_msg: received incomplete HAP packet (read <number> bytes) このメッセージは、ClusterXL がバージョン 4.1 のクラスタの CCP パケットを受信し た場合に出力されることがあります。この場合、メッセージを無視しても問題あり ません。 SmartView Tracker のアクティブ・モード・メッセージ 以下のエラー・メッセージは、SmartView Tracker のアクティブ・モードで表示されるこ とがあります。これらのエラーは、エントリの一部が正常に処理されていないため、ク ラスタ・メンバ上の同期情報が失われ、SmartView Tracker で不正確な報告が行われる可 能性があることを示します。 ■ FW-1: fwlddist_adjust_buf: record too big for sync. update Y for table <id> failed. fwlddist_state=<val> クラスタ化されたマシン上で設定上の問題が発生したことを示します。同期の設定 が正しくないか、同期インタフェースで転送されているパケットに問題があります。 問題の原因に関する情報を入手するには、以下のいずれかを実行します。 ■ fw ctl pstat を実行します（92 ページの「同期の監視（fw ctl pstat） 」を参照）。 第6章 ゲートウェイ・クラスタの監視とトラブルシューティング 109 ClusterXL のエラー・メッセージ ■ ClusterXL のクラスタで、cphaprob -a if を実行し、インタフェースの状態を取 得します（81 ページの「クラスタ・インタフェースの監視（cphaprob [-a] if）」 を参照）。 この問題に対処するには、128 ページの「SmartView Tracker のアクティブ・モード の使用」を参照してください。 ■ FW-1: fwldbcast_flush: active connections is currently enabled and due to high load it is making sync too slow to function properly. X active updates were dropped 同期機能を維持するために、クラスタ化されたマシンが SmartView Tracker のアク ティブ・モードのアップデートを破棄したことを示します。この問題に対処するに は、128 ページの「SmartView Tracker のアクティブ・モードの使用」を参照してく ださい。 同期関連のエラー・メッセージ ■ FW-1: fwldbcast_retreq: machine <MACHINE_ID> sent a retrans request for seq <SEQ_NUM> which is no longer in my possession (current seq <SEQ_NUM>) このメッセージは、送信ウィンドウに存在しないシーケンス番号に対する再送要求を ローカル・メンバが受信したときに表示されます。送信しているメンバが要求された シーケンスを受信していない場合、同期上の問題を示している可能性があります。 ■ FW-1: fwlddist_save: WARNING: this member will not be fully synchronized ! FW-1: fwlddist_save: current delta sync memory during full sync has reached the maximim of <MEM_SIZE> MB FW-1: fwlddist_save: it is possible to set a different limit by changing fw_sync_max_saved_buf_mem value これらのメッセージは完全同期時にのみ表示されます。完全同期の実行中は、差分 同期アップデートは保存され、完全同期プロセスが完了した後に適用されます。差 分同期アップデートの保存に使用されるメモリを制限するには、 fw_sync_max_saved_buf_mem 変数に制限値を設定します。 ■ FW-1: fwldbcast_flush: fwlddist_buf_ldbcast_unread is not being reset fast enough (ur=<UNREAD_LOC>,fwlddist_buflen=<BUFFER_LEN>) このメッセージは、同期バッファが読み取られるよりも早く満たされたために負荷 が高くなった場合に表示されることがあります。考えられる解決策は、128 ページ の「SmartView Tracker のアクティブ・モードの使用」で説明するように、 fwlddist_buf_size を拡張することです。 ■ FW-1: fwlddist_mode_change: Failed to send trap requesting full sync このメッセージは、完全同期プロセスの開始上の問題のために表示されている可能性 があり、深刻な問題であることを示します。技術サポートにお問い合わせください。 110 TCP Out-of-State エラー・メッセージ ■ FW-1: State synchronization is in risk. Please examine your synchronization network to avoid further problems! このメッセージは、負荷が極度に高い場合に出力され、同期アップデートが恒久的 に失われたことを示します。アップデート発生元の送信キューに同期アップデート が存在しないために再送が不可能になった場合、同期アップデートは恒久的に失わ れたと見なされます。この状況は VPN-1 Pro が誤作動する可能性があることを意味 しているのではなく、潜在的な問題があることを意味します。失われた同期アップ デートが非暗号化（クリア）接続の場合のように 1 つのメンバ上でのみ実行される 接続に対するものであれば、この潜在的な問題は実害がありません（ただし、フェ イルオーバーの場合は、ほかのメンバがこのアップデートを必要とします）。 失われた同期アップデートが、暗号化接続の場合のように非対称な通信（23 ページ の「非対称通信」を参照）に関するものであった場合、この潜在的な問題により実 害が発生する可能性があります。この場合、ほかのクラスタ・メンバがこの通信に 関するパケットを破棄し始め、通常、TCP out of state エラー・メッセージを出 力します（111 ページの「TCP Out-of-State エラー・メッセージ」を参照） 。このよ うな場合、高負荷状態であれば、127 ページの「高負荷状態での新しい接続の阻止」 で説明するように、新しい通信を阻止することが重要です。 以下のエラー・メッセージはこの問題に関連しています。 ■ FW-1: fwldbcast_recv: delta sync connection with member <MACHINE_ID> was lost and regained. <UPDATES_NUM> updates were lost. FW-1: fwldbcast_recv: received sequence <SEQ_NUM> (fragm <FRAG_NUM>, index <INDEX_NUM>), last processed seq <SEQ_NUM> これらのメッセージは、一時的な同期上の問題が発生したために、同期アップデー トの一部がメンバ間で同期できなかった場合に出力されます。この結果として、通 信の一部はフェイルオーバーによって失われる可能性があります。 前述のエラー・メッセージはこの問題に関連しています。 ■ FW-1: The use of the non_sync_ports table is not recommended anymore. Refer to the user guide for configuring selective sync instead 以前のバージョンが non_sync_ports というカーネル・テーブルを使用して選択同 期を実施しました。これは同期する必要がないサービスを選択する方法です。これ 以降は、選択同期は SmartDashboard から設定できます。22 ページの「同期の不要な サービスの選択」を参照してください。 TCP Out-of-State エラー・メッセージ 同期メカニズムに負荷がかかると、TCP packet out-of-state エラー・メッセージが SmartView Tracker の［Information］カラムに表示されます。このセクションでは、各エラーを解決す る方法を説明します。 第6章 ゲートウェイ・クラスタの監視とトラブルシューティング 111 ClusterXL のエラー・メッセージ ■ TCP packet out of state - first packet isn't SYN tcp_flags: FIN-ACK TCP packet out of state - first packet isn't SYN tcp_flags: FIN-PUSH-ACK これらのメッセージは、通信テーブルからの通信が削除された後で FIN パケットが 再送された場合に出力されます。この問題を解決するには、SmartDashboard の ［Global properties］ の［Stateful Inspection］ で、 ［TCP end timeout］ を 20 秒から 60 秒に 増加させます。必要に応じて、通信テーブルも大きくし、満杯にならないようにし ます。 ■ SYN packet for established connection このメッセージは、確立された通信で SYN が受信され、シーケンス・ベリファイア が停止した場合に出力されます。シーケンス・ベリファイアは、クラスタ内（また は SecureXL 内）の非対称通信に対しては停止します。アプリケーションによって は、（ポートを再利用するため）RST パケットで通信を切断するものがあります。こ の問題を解決するには、特定のポートまたはすべてのポートについて、この動作を 有効にします。たとえば、以下のコマンドを実行します。 fw ctl set -1 fw_trust_rst_on_port <port> これは、1 つのポートでは不充分な場合に、VPN-1 Pro がどのポートから入ってくる RST も信頼することを意味します。 プラットフォーム固有のエラー・メッセージ Solaris 固有のエラー・メッセージ ■ WARNING: IP: Proxy ARP problem? Hardware address <MULTICAST MAC ADDRESS> think it is <VIRTUAL CLUSTER IP> この Solaris コンソール（または /var/adm/messages）メッセージは、負荷共有マル チキャスト・モードのクラスタで出力される場合があります。このメッセージは無 視しても問題ありません。 このメッセージは、CCP パケットが IP スタックによって受信されたが、クラスタリ ング・メカニズムによって処理されていない場合に出力されます。この状況は、ク ラスタリング・メカニズムが起動時に完全に初期化されていないにも関わらず、ほ かのメンバはすでにこれらの種類のパケットを送信している場合に発生します。 Nokia 固有のエラー・メッセージ ■ FW-1: fwha_nok_get_mc_mac_by_ip: received a NULL query FW-1: fwha_nok_get_mc_mac_by_ip: nokcl_get_clustermac returned unknown type <TYPE> これらのメッセージは、Static NAT 設定の自動プロキシ ARP のエントリが適切にイン ストールされていないことを意味します。 112 プラットフォーム固有のエラー・メッセージ ■ FW-1: fwha_nokcl_sync_rx_f: received NULL mbuf from ipso. Packet dropped. FW-1: fwha_nokcl_sync_rx_f: received packet with illegal flag=<FLAG>. drop packet. これらのメッセージは、不正な CPHA パケットが受信されたため破棄することを意 味します。起動時にこの状況が何度も発生する場合、クラスタが誤作動しています。 ■ ■ FW-1: fwha_nokcl_reregister_rx: unregister old magic mac values with IPSO. FW-1: fwha_nokcl_reregister_rx: new magic mac values <MAC,FORWARD MAC> registered successfully with IPSO. fw ctl set int fwha_magic_mac の処理に成功したことを示す通知です。 FW-1: fwha_nokcl_reregister_rx: error in de-registration to the sync_rx (<ERR NUM>) new magic macs values will not be applied fw ctl set int fwha_magic_mac の処理に失敗したことを示す通知です。以前の MAC 値が保持されます。 ■ FW-1: fwha_nokcl_creation_f: error in registration ... FW-1: fwha_nok_init: NOT calling nokcl_register_creation since did not de-register yet. FW-1: fwha_nok_fini: failed nokcl_deregister_creation with rc=<ERROR NUM> これらのメッセージは、IPSO クラスタリング・メカニズムへの登録で内部エラーが 発生したことを意味します。IPSO のバージョンがこのバージョンの VPN-1 Pro で サポートされていること、および Nokia IP クラスタリングまたは VRRP クラスタが 適切に設定されていることを確認してください。 ■ FW-1: successfully (dis)connected to Nokia Clustering 通常、VPN-1 Pro 実施モジュールの初期化および削除時に受信される通知です。 ■ FW-1: fwha_pnote_register: noksr_register_with_status failed FW-1: fwha_nokia_pnote_expiration: mismatch between nokia device to ckp device <DEVICE NAME> FW-1: fwha_nokia_pnote_expiration: can not find the device nokia claims to be expired FW-1: fwha_noksr_report_wrapper: attempting to report an unregistered device <DEVICE NAME> これらのメッセージは、Nokia と ClusterXL のデバイス監視メカニズム間の通信に問 題があるために出力される場合があります。通常、再起動によってこの問題は解決 します。この問題が繰り返し発生する場合は、チェック・ポイントの技術サポート にお問い合わせください。 第6章 ゲートウェイ・クラスタの監視とトラブルシューティング 113 Solaris プラットフォーム固有の問題：VLAN スイッチ・ポートのフラッピング Solaris プラットフォーム固有の問題：VLAN スイッチ・ポートの フラッピング Solaris のクラスタ・メンバがすべてのインタフェースに対して同一の MAC アドレスを保 持しており（一部のネットワーク・カードではデフォルト） 、各インタフェースが同一ス イッチ上の異なる VLAN に接続されている場合、スイッチ・ポートでフラッピングが発 生する場合があります。 この状況は、各ポートが異なる VLAN にある場合でも、同一の MAC アドレスを持つパ ケットが複数のスイッチ・ポートに入ってくることを許可する機能がスイッチにない場 合に発生する可能性があります。 この問題を解決するには、local-mac-addresses?=true を設定して、各クラスタ・メン バの eeprom を設定します。 メンバの再起動の失敗 クラスタに高い負荷がかかっている状態で、クラスタ・メンバで再起動（または cpstop と cpstart を続けて実施）を実施した場合、メンバが正常に起動できない場合があります。 起動中のメンバは既存のアクティブ・メンバとの完全同期を試み、処理中にリソースと利 用可能なメモリのすべてを使い果たす可能性があります。このために予期しない動作が発 生する可能性があります。 この問題を解決するには、起動時にアクティブ・メンバとの通信を同期するためにメン バが使用可能なメモリの最大量を定義します。デフォルトでは、この量は制限されてい ません。必要なメモリの量は、以下のように判断します。 表 6-3 完全同期に必要なメモリ（MB） 新しい通信 / 秒 開設されている通信の数 100 1000 5000 10,000 1000 1.1 6.9 10000 11 69 329 20000 21 138 657 1305 50000 53 345 1642 3264 注： これらの数値は、Windows プラットフォームと Pentium 4 プロセッサ（2.4 GHz で動作）を使用した クラスタ・メンバに基づいています。 114 プラットフォーム固有のエラー・メッセージ たとえば、クラスタが 10,000 個の通信を持っており、接続速度が毎秒 1000 個の通信の場 合、完全同期には 69 MB が必要です。 メモリの最大量は、次のモジュール・グローバル・パラメータを使用して定義します。 fw_sync_max_saved_buf_mem 単位はメガバイトです。詳細については、125 ページの「モジュール設定パラメータを使 用した高度なクラスタ設定」を参照してください。 第6章 ゲートウェイ・クラスタの監視とトラブルシューティング 115 メンバの再起動の失敗 116 第 7 章 ClusterXL の高度な設定 この章の構成 ClusterXL クラスタのアップグレード 118 ページ NAT とクラスタの使用 119 ページ VLAN とクラスタの使用 121 ページ クラスタリング・タイマと同期タイマの制御 127 ページ 高負荷状態での新しい接続の阻止 127 ページ SmartView Tracker のアクティブ・モードの使用 128 ページ 処理待ちパケット数の削減 129 ページ 完全同期詳細オプションの設定 130 ページ Disconnected インタフェースの定義 131 ページ ポリシー更新タイムアウトの設定 131 ページ TCP 3 ウェイ・ハンドシェーク実施の強化 132 ページ 異なるサブネット上のクラスタ・アドレスの設定 133 ページ HA Legacy モードから HA New モードまたは負荷共有モードへの 移行（簡易的方法） 139 ページ HA Legacy モードから HA New モードまたは負荷共有モードへの 移行（ダウンタイムを最小限にする方法） 141 ページ 単一ゲートウェイから ClusterXL クラスタへの移行 143 ページ 既存クラスタへの別メンバの追加 144 ページ クラスタの ISP 冗長性の設定 145 ページ クラスタ構成でのダイナミック・ルーティング・ プロトコルの有効化 146 ページ 117 ClusterXL クラスタのアップグレード ClusterXL クラスタのアップグレード ClusterXL または OPSEC 認定ゲートウェイ・クラスタのアップグレード方法の詳細につい ては、 『アップグレード・ガイド』を参照してください。 VPN とクラスタの使用 このセクションの構成 VPN とクラスタの設定方法 118 ページ 別のマネージャ下の VPN ピアにクラスタ・オブジェクトを 定義する方法 119 ページ VPN とクラスタの設定方法 SmartDashboard で VPN-1 Pro ゲートウェイ・クラスタを設定する方法は、1 つの VPN-1 Pro ゲートウェイを設定する方法と良く似ています。VPN のすべての属性は、クラスタ・メ ンバごとに定義する 2 つの属性を除きゲートウェイ・クラスタ・オブジェクト内で定義 します。 1 ［Gateway Cluster Properties］ ウィンドウの［Cluster Members］ ページを開きます。各 クラスタ・メンバの［Cluster member Properties］ ウィンドウで［VPN］ タブを以下の ように設定します。 ■ ■ 2 Office Mode for Remote access ― リモート・アクセスにオフィス・モードを使用す る場合、各クラスタ・メンバに割り当てる IP プールを定義します。 Hardware Certificate Storage List ― クラスタ・メンバが IKE 証明書のハードウェ ア・ストレージをサポートしている場合、証明書の属性を定義します。この場 合、SmartCenter サーバはクラスタ・メンバに対して鍵を作成し、証明書要求の 作成に必要な情報だけを提供するよう指示します。証明書は、ポリシーのインス トール時にクラスタ・メンバにダウンロードされます。 VPN クラスタ内で IKE 鍵が同期されます。［Gateway Cluster Properties］ ウィンドウの ［Synchronization］ページで、 ［Use State Synchronization］が選択されていることを確認 します。これは、HA（ハイ・アベイラビリティ）構成の場合も同様です。 3 ［Gateway Cluster Properties］ウィンドウの［Topology］ページでクラスタの暗号化ドメ ［VPN Domain］の下で、以下の 2 つの設定のいずれかを選択します。 インを定義します。 ■ All IP addresses behind cluster members based on topology information ― これはデ フォルト・オプションです。 ■ 118 Manually Defined ― クラスタの IP アドレスがメンバ・ネットワーク上にない場合、 つまりクラスタの仮想 IP アドレスがクラスタ・メンバ・インタフェースとは異なる サブネット上にある場合は、このオプションを選択します。この場合、クラスタの 仮想 IP アドレスを含むネットワークまたはネットワーク・グループと、クラスタの 背後にあるネットワークまたはネットワーク・グループを選択してください。 別のマネージャ下の VPN ピアにクラスタ・オブジェクトを定義する方法 別のマネージャ下の VPN ピアにクラスタ・オブジェクトを定義する方法 チェック・ポイントのゲートウェイ・クラスタとして使用する VPN ピアが別の SmartCenter サーバによって管理されている場合、別のクラスタ・オブジェクトを定義するのではな く以下の手順を行います。 1 オブジェクト・ツリーの［Network Objects］ ブランチで右クリックし、［New Check Point Externally Managed Gateway］ を選択します。 2 ［Topology］ ページで、VPN ピアの外部クラスタ・インタフェースと内部クラスタ・ インタフェースのアドレスを追加します。以下の場合を除き、クラスタ・メンバ・ インタフェースのアドレスは使用しないでください。 ■ ■ 外部クラスタがバージョン 4.1 の場合はクラスタ・メンバ・インタフェースの IP アドレスを追加します。 クラスタが OPSEC 認定製品の場合（Nokia を除く） 、クラスタ・メンバの IP アド レスの追加が必要になる場合があります。 クラスタ・メンバ・インタフェースの IP アドレスを追加する場合は、インタフェー スの［Topology］ タブでインタフェースを［Internal］ として定義し、［IP Addresses behind this interface］ を［Not defined］ と定義します。 3 このページの［VPN Domain］ セクションで、外部から管理されるゲートウェイの暗 号化ドメインをゲートウェイの内部仮想 IP アドレスの背後に置くように定義します。 暗号化ドメインが 1 つのサブネットだけの場合は［All IP addresses behind cluster members based on topology information］ を選択します。暗号化ドメインに複数のサブ ネットが含まれる場合は［Manually Defined］ を選択します。 NAT とクラスタの使用 このセクションの構成 クラスタのフォールドとクラスタの隠蔽 119 ページ ゲートウェイ・クラスタ上での NAT 設定 120 ページ クラスタ・メンバ上での NAT 設定 120 ページ クラスタのフォールドとクラスタの隠蔽 ネットワーク・アドレス変換（NAT）は、ClusterXL の動作に必要な基本的な機能です。 ClusterXL クラスタ・メンバからインターネットへの発信接続を確立する場合、発信パケッ ト内の発信元アドレスはクラスタ・メンバ・インタフェースの物理 IP アドレスになります。 発信元 IP アドレスは NAT を使用し、クラスタの外部仮想 IP アドレスを使用した発信元 IP アドレスに変換されます。このアドレス変換は「クラスタの隠蔽」と呼ばれます。 第7章 ClusterXL の高度な設定 119 NAT とクラスタの使用 OPSEC 認定クラスタ製品の場合、クラスタ・オブジェクトの［3rd Party Configuration］ペー ジでデフォルト設定として［Hide Cluster Members’ outgoing traffic behind the Cluster’s IP address］ がオンになっている場合に対応します。 クライアントがクラスタの外部（仮想）アドレスに対する 着信 接続を確立する場合、 ClusterXL は NAT を使用して宛先 IP アドレスをクラスタ・メンバの 1 つの物理外部アドレ スを使用した宛先 IP アドレスに変換します。このアドレス変換は「クラスタのフォール ド」と呼ばれます。 OPSEC 認定クラスタ製品の場合、クラスタ・オブジェクトの［3rd Party Configuration］ ページで、デフォルト設定として［Forward Cluster’s incoming traffic to Cluster Members’ IP addresses］ がオンになっている場合に対応します。 ゲートウェイ・クラスタ上での NAT 設定 ゲートウェイ・クラスタ上でのネットワーク・アドレス変換（NAT）は、単一のゲート ウェイ上での場合と同じ方法で実行できます。この NAT は、自動的な「クラスタのフォー ルド」アドレス変換および「クラスタの隠蔽」アドレス変換とは別に実行できる機能です。 NAT を設定するには、ゲートウェイ・クラスタ・オブジェクトを編集し［Gateway Cluster Properties］ ウィンドウで［NAT］ ページを選択します。クラスタ・メンバ・オブジェクト の［NAT］ タブは設定しないでください。 クラスタ・メンバ上での NAT 設定 クラスタ・メンバの非クラスタ・インタフェースでネットワーク・アドレス変換（NAT） を実行できます。 この NAT を実行するのは、クラスタ・メンバの非クラスタ・インタフェースが別の（非 クラスタ）内部 VPN-1 Pro ゲートウェイに接続されており、クラスタ・メンバの非クラス タ・インタフェースのアドレスを隠す必要があるような場合です。 この NAT が実行されると、クラスタ・メンバの非クラスタ・インタフェース上またはそ の背後から発信されたパケットが内部 VPN-1 Pro ゲートウェイの反対側のホストに送ら れる場合にパケットの発信元アドレスが変換されます。 クラスタ・メンバ・ゲートウェイの非クラスタ・インタフェースに対して以下のように NAT を設定します。 1 ゲートウェイ・クラスタ・オブジェクトを編集します。 2 ［Gateway Cluster Properties］ ウィンドウの［Cluster Member］ ページでクラスタ・ メンバ・オブジェクトを編集します。 3 ［Cluster Member Properties］ ウィンドウで［NAT］ タブをクリックします。 4 120 必要に応じてスタティック NAT または Hide NAT を設定します。 ClusterXL の VLAN サポート VLAN とクラスタの使用 このセクションの構成 ClusterXL の VLAN サポート 121 ページ 同一 VLAN への複数クラスタの接続 122 ページ ClusterXL の VLAN サポート VLAN 内で発信されたパケットがスイッチに到達すると、スイッチはパケットが入ってき たスイッチ・ポートを示す 4 バイトのヘッダをパケットに付けます。パケットは、あるス イッチ・ポートから別の VLAN に所属するほかのスイッチ・ポートへ移動することはで きません。ただし、すべての VLAN に属すると定義されたポート（「グローバル」ポート） は例外です。 クラスタ・メンバは VLAN スイッチのグローバル・ポートに接続されます。この結果、1 つ の物理ポートは複数の VLAN ポートに理論的に分割され、各 VLAN ポートはクラスタ・ メンバの VLAN タグ付きインタフェース（VLAN インタフェース）に関連付けられます。 インタフェースに対して VLAN タグを定義する場合、クラスタの IP アドレスは VLAN イン タフェース（タグ付きインタフェース）に対してのみ定義できます。VLAN を持っている 物理インタフェースに対してクラスタの IP アドレスを定義することはできません。この ［Network Objective］カラムで［Monitored Private］を選択し ような物理インタフェースは、 て定義する必要があります。 注： VLAN サポートの詳細については、 『Check Point Enterprise Suite NGX (R60) Release Notes』を 参照してください。このリリース・ノートは http://www.checkpoint.com/downloads/index.html から ダウンロードできます。 Solaris GigaSwift インタフェースに対して仮想インタフェースを設定しても、対応する物 理インタフェースが定義されていなければ、ClusterXL は仮想インタフェースを認識しな い可能性があります。仮想インタフェースが認識されなければ、仮想インタフェースに 対する監視メカニズムは実行されないためフェイルオーバーは実質的に発生しません。 このような仮想インタフェースに対して ClusterXL を正常に動作させるには、対応する物 理インタフェースを定義する必要があります。たとえば、CE デバイスがインスタンス 0 でシステムに定義されている場合、/etc/hostname.ce0 ファイルを作成し、物理インタ フェースに割り当てる任意の IP アドレスをファイルに記述する必要があります。 注： ClusterXL は、Windows 2000 または Windows 2003 Server 上の VLAN をサポートしていません。 第7章 ClusterXL の高度な設定 121 VLAN とクラスタの使用 同一 VLAN への複数クラスタの接続 複数のクラスタの安全に保護されていないインタフェース（たとえば、内部クラスタ・イ ンタフェースまたは外部クラスタ・インタフェース）を同一の VLAN に接続することは お勧めできません。各クラスタに個別の VLAN および / またはスイッチが必要です。 複数のクラスタの安全に保護されたインタフェース（同期インタフェース）を接続する ことも、同じ理由からお勧めできません。したがって、クラスタの安全に保護されたイ ンタフェースを接続する際は、クロス・ケーブルを介して接続するか、孤立した VLAN に接続することをお勧めします。 複数のクラスタの安全に保護されたインタフェースまたは安全に保護されていないイン タフェースを同一の VLAN に接続する必要がある場合は、以下の変更を行う必要があり ます。 宛先 MAC アドレスの変更。クラスタとクラスタ外部のマシンの間の通信を可能に するために必要です（ClusterXL 負荷共有マルチキャスト・モードのクラスタの場 合のみ） 。 ■ ■ クラスタの発信元 MAC アドレスの変更。クラスタ・メンバ間のクラスタ・コント ロール・プロトコル通信を可能にするために必要です。 宛先 MAC アドレスの変更 このセクションは、ClusterXL 負荷共有マルチキャスト・モードにのみ関連しています。 負荷共有マルチキャスト・モードでの宛先クラスタ MAC アドレスの割り当て方法 クラスタの外部のマシンがクラスタと通信しようとする場合は、クラスタの（仮想）IP ア ドレスについての ARP クエリを送信します。クラスタは、IP アドレスがユニキャスト・ アドレスであってもマルチキャスト MAC アドレスを使用して ARP 要求に応答します。 このクラスタの宛先マルチキャスト MAC アドレスは、クラスタのユニキャスト IP アドレ スに対応しています。上位 3 バイトは 01.00.5E であり、標準的なマルチキャスト MAC と して識別されます。下位 3 バイトには IP アドレスの下位 3 バイトが使用されます。図 7-1 に IP アドレス 10.0.10.11 に基づく MAC アドレスの例を示します。 図 7-1 122 クラスタのマルチキャスト MAC アドレス 同一 VLAN への複数クラスタの接続 マルチキャスト MAC アドレスの重複：発生する問題 複数のクラスタが同一の VLAN に接続されている場合、VLAN に接続されるクラスタ・イン タフェースの IP アドレスの最後の 3 バイトは異なっている必要があります。同じ場合、外部 から 1 つのクラスタに向けられた通信が両方のクラスタに到達して通信上の問題が発生 します。 たとえば、VLAN に接続されたクラスタのうち最初のクラスタのクラスタ・インタフェー ス・アドレスが 10.0.10.11 で、2 番目のクラスタのクラスタ・インタフェース・アドレス が 10.0.10.12 であれば問題ありません。ただし、最初のクラスタと 2 番目のクラスタのク ラスタ・インタフェース・アドレスがそれぞれ 10.0.10.11 と 20.0.10.11 である場合は混乱 が生じます。 マルチキャスト MAC アドレスの重複：解決法 最善の解決法は、IP アドレスの最後の 3 バイトが共通しているクラスタ・インタフェースの うち、1 つを除くすべてのクラスタ・インタフェースについて IP アドレスの最後の 3 バイト を変更することです。 クラスタ・インタフェースの IP アドレスを変更できない場合は、1 つを除くすべてのク ラスタについて自動的に割り当てられたマルチキャスト MAC アドレスを変更し、ユー ザ定義のマルチキャスト MAC アドレスで置き換える必要があります。以下の手順に従 います。 1 クラスタ・オブジェクトの［ClusterXL］ ページで［Load Sharing］>［Multicast Mode］ を選択します。［Topology］ タブで、ほかのクラスタと同じ VLAN に接続されている クラスタ・インタフェースを編集します。 2 ［Interface Properties］ ウィンドウの［General］ タブで［Advanced］ をクリックします。 3 デフォルトの MAC アドレスを変更し、新たにユーザ定義の MAC アドレスを入力し ます。MAC アドレスは 01:00:5e:xy:yy:yy の形式で入力します。ここで x は 0 ～ 7 で、 y は 0 ～ f (16 進数 ) です。 発信元 MAC アドレスの変更 このセクションは、HA と負荷共有を含むすべての ClusterXL モードおよび OPSEC 認定ク ラスタ製品に関連しています。 発信元クラスタ MAC アドレスの割り当て方法 クラスタ・メンバはクラスタ・コントロール・プロトコル（CCP）を使用して互いに通信 します。CCP パケットには固有の発信元 MAC アドレスが付加され、この MAC アドレス によって普通のネットワーク・トラフィックと区別されます。 発信元 MAC アドレスの先頭の 4 バイトはすべてゼロです（00.00.00.00）。 ■ 第7章 ClusterXL の高度な設定 123 VLAN とクラスタの使用 ■ 発信元 MAC アドレスの 5 バイト目はマジック・ナンバで、値は用途を表します。 表 7-1 ■ 5 バイト目のデフォルト値 用途 0xfe CCP トラフィック 0xfd 転送レイヤ・トラフィック 6 バイト目は送信クラスタ・メンバの ID です。 発信元 MAC アドレスの重複：発生する問題 複数のクラスタが同一の VLAN に接続されている場合、CCP トラフィックと転送レイヤ・ トラフィックでマルチキャストが使用されていれば、トラフィックは意図したクラスタ にのみ到達します。 ただし、CCP トラフィックと転送レイヤ・トラフィックでブロードキャストが使用され ている場合（その他の場合でも）、1 つのクラスタに向けられたクラスタ・トラフィック が接続されているすべてのクラスタから透過的ではないため、意図しないクラスタに よって処理されて通信上の問題が発生します。 発信元 MAC アドレスの重複：解決法 同一の VLAN に接続されている別々のクラスタから送信されたパケットの発信元 MAC ア ドレスを確実に区別できるようにするため、1 つを除くすべてのクラスタについて VLAN に接続されたクラスタ・インタフェースの MAC 発信元アドレスを変更してください。 同一 VLAN 上に複数のクラスタを設定するには、以下のモジュール設定パラメータを使用 します。これらのパラメータは、ClusterXL 製品と OPSEC 認定クラスタ製品の両方に適用 されます。 表 7-2 パラメータ デフォルト値 fwha_mac_magic 0xfe fwha_mac_forward_magic 0xfd これらのモジュール設定パラメータの値を変更すると、クラスタ・コントロール・プロ トコル・パケットと転送パケットの発信元 MAC アドレスの 5 バイト目が変更されます。 2 つのモジュール設定パラメータが異なっていれば、どんな値を使用しても構いません。 混乱を避けるため、値 0x00 は使用しないでください。 124 モジュール設定パラメータの設定方法 Performance Pack を使用して ClusterXL 負荷共有マルチキャスト・モードのパフォーマン スを向上させる場合は、fwha_mac_magic と fwha_mac_forward_magic の値を連続した数 値にし、小さいほうの数値を偶数にすることをお勧めします（たとえば、0x10 と 0x11 また は 0xBE と 0xBF など）。 これらのパラメータの変更方法については、125 ページの「モジュール設定パラメータの 設定方法」を参照してください。 モジュール設定パラメータを使用した高度なクラスタ設定 このセクションの構成 モジュール設定パラメータの設定方法 125 ページ モジュール設定パラメータを起動時に有効にする方法 126 ページ クラスタリング・タイマと同期タイマの制御 127 ページ 高負荷状態での新しい接続の阻止 127 ページ SmartView Tracker のアクティブ・モードの使用 128 ページ 処理待ちパケット数の削減 129 ページ 完全同期詳細オプションの設定 130 ページ ポリシー更新タイムアウトの設定 131 ページ モジュール設定パラメータの設定方法 同期機能と ClusterXL 機能の多くは、VPN-1 Pro 実施モジュール設定パラメータを使用し て制御されます。これらのコマンドは VPN-1 Pro ゲートウェイ・マシン上で以下のように 実行できます。 fw ctl set int Parameter <value> Parameter は、以下の各セクションで説明するパラメータを指します。 これらの設定パラメータは、NG with Application Intelligence 以降のバージョンのクラスタ でのみ使用可能です。 デフォルト値を変更する場合は、すべてのクラスタ・メンバに適用してください。各ク ラスタ・メンバに別々の値を設定すると、設定上の問題が生じて接続障害が発生する可 能性があります。 すべてのモジュール設定パラメータは、起動時に有効になるように設定できます。この 設定方法は、オペレーティング・システムによって異なります。 第7章 ClusterXL の高度な設定 125 モジュール設定パラメータを使用した高度なクラスタ設定 モジュール設定パラメータを起動時に有効にする方法 fw ctl set int コマンドを使用して変更したモジュール設定パラメータは、 起動時に有 効になりません。これらを起動時に有効にする方法は、オペレーティング・システムに よって異なります。以下の手順では、Parameter は以下の各セクションで説明するパラメー タを指します。 Linux/SecurePlatform 1 ファイル $FWDIR/boot/modules/fwkern.conf を編集します。 2 行 Parameter=<value in hex> を追加します。 3 マシンを再起動します。 Solaris 1 ファイル /etc/system を編集します。 2 行 set fw:Parameter=<value in hex> を追加します。 3 マシンを再起動します。 Windows 1 レジストリを編集します。 2 キー HKEY_LOCAL_MACHINE¥SYSTEM¥CurrentControlSet¥Services¥FW1¥ Parameters¥Globals の下に Parameter という名前の DWORD 値を追加します。 3 マシンを再起動します。 Nokia 以下のコマンドを実行します。 modzap _Parameter $FWDIR/boot/modules/fwmod.o <value in hex> Parameter の前のアンダーラインは誤りではありません。 126 クラスタリング・タイマと同期タイマの制御 クラスタリング・タイマと同期タイマの制御 以下のモジュール設定パラメータは、クラスタリング・タイマと同期タイマの制御に使 用します。デフォルト値を変更することはお勧めできません。 表 7-3 クラスタリング・タイマと同期タイマ パラメータ 意味 デフォルト値 fwha_timer_cpha_res クラスタ上での ClusterXL の処理頻度。 1 以下の間隔で処理が行われます。 10 x fwha_timer_cpha_res x fwha_timer_base_res ミリ秒 fwha_timer_sync_res クラスタ上での同期フラッシュ処理の頻度。 1 以下の間隔で処理が行われます。 10 xfwha_timer_sync_res x fwha_timer_base_res ミリ秒 fwha_timer_base_res 10 10 の倍数にする必要があります。 高負荷状態での新しい接続の阻止 新しい接続を阻止する理由は、新しい接続は新しい同期トラフィックが発生する主な原 因となり、高負荷状態で新しいトラフィックの処理を継続するとすべての同期が危険に さらされる可能性があるためです。 関連するエラー・メッセージは、111 ページの「FW-1: State synchronization is in risk. Please examine your synchronization network to avoid further problems!」です。 VPN-1 Pro を通過するトラフィック量を減らすことにより、同期メカニズムを保護でき ます。 ■ fw_sync_block_new_conns を使用して VPN-1 Pro で高負荷を検出し、新しい接続の 阻止を開始できます。ファイアウォールの同期送信キューが満杯になって fw_sync_buffer_threshold の値を超えた場合、負荷が高いと見なされます。 ■ 負荷検出を有効にするには、0 を設定します。 ■ 負荷検出を無効にするには、-1（デフォルト値）を設定します。 ClusterXL 負荷共有構成の場合のみ、同期がビジーなときに新しい接続を阻止するこ とをお勧めします。HA モードでも新しい接続を阻止できますが、同期の不一致は解 決されません。これは、HA モードは同期の不一致を防止するからです。このパラ メータは、126 ページの「モジュール設定パラメータを起動時に有効にする方法」で 説明したメカニズムを使用して起動時でも有効になるように設定できます。 第7章 ClusterXL の高度な設定 127 モジュール設定パラメータを使用した高度なクラスタ設定 ■ ■ fw_sync_buffer_threshold は、バッファが許容する最大パーセント値です。この 値に達するとバッファが満杯になったと見なされ、新しい接続の阻止が開始されま す。デフォルト値はバッファ・サイズ 512 で 80 に設定されています。デフォルトで は、410 個を超えるパケットが一度も ACK を返されることなく連続送信された場合 に新しい接続が破棄されます。接続阻止が開始されると、 fw_sync_block_new_conns は 1 に設定されます。状況が安定すると、この値は 0 に 戻されます。 fw_sync_allowed_protocols を使用して、システムが接続阻止状態になった場合 でも開設を許可する接続のタイプを決定します。これにより、管理者は負荷異常時 でもシステムの動作を制御できます。fw_sync_allowed_protocols 変数は、各種 の 接続タイプを指定するフラグの組合せです。変数の値は個々のフラグ値の和です。 たとえば、この変数のデフォルト値は 24 ですが、これは TCP_DATA_CONN_ALLOWED （8）と UDP_DATA_CONN_ALLOWED（16）の和であり、デフォルトでは高負荷状態で TCP 接続と UDP データ接続のみ開設を許可することを意味します。 ICMP_CONN_ALLOWED TCP_CONN_ALLOWED UDP_CONN_ALLOWED TCP_DATA_CONN_ALLOWED UDP_DATA_CONN_ALLOWED 1 2（データ接続を除く） 4（データ接続を除く） 8（制御接続は確立されるか許可される） 16（制御接続は確立されるか許可される） SmartView Tracker のアクティブ・モードの使用 SmartView Tracker のアクティブ・モードでは、管理サーバ上の現在アクティブなログ・ ファイルにログを送信している任意の VPN-1 Pro 実施モジュールを介して現在開いてい る接続が表示されます。 アクティブ・モードは同期の速度を低下させる傾向があります。速度が低下した場合、同 期メカニズムは同期を維持するためにアクティブな接続更新をランダムに廃棄します。 廃棄時には、109 ページの「SmartView Tracker のアクティブ・モード・メッセージ」で 説明するエラー・メッセージの 1 つが表示されます。 高負荷状態のクラスタにはアクティブ・モード・ビューを使用しないでください。高負 荷状態のアクティブな接続に関する正確なレポートを取得するために、以下の 2 つの解 決法を使用できます。これらは、クラスタと単一 VPN-1 Pro ゲートウェイの両方に適用 されます。 128 処理待ちパケット数の削減 1 fwlddist_buf_size の拡大 fwlddist_buf_size パラメータは、同期バッファのサイズ（ワード数）を制御します （ワード数は、同期と SmartView Tracker のアクティブ・モードの両方で使用されます。 1 ワードが 4K バイトです）。デフォルト値は 16,000 ワードです。最大値は 64,000 ワー ドで最小値は 2,000 ワードです。 このパラメータを変更した場合、変更は起動後に初めて適用されるため、パラメータ が起動時に有効になるように設定されていることを確認してください。126 ページの 「モジュール設定パラメータを起動時に有効にする方法」で説明したメカニズムを使 用してください。 2 技術サポートからのホットフィックスの入手 チェック・ポイントの技術サポートからホットフィックスを入手してください。この ホットフィックスには、管理サーバに送信される前にアクティブな接続が実施モ ジュールで fwd によって読み取られる速度を制御する変数が含まれています。この解 決法を実行するには、追加の CPU リソースが必要です。 処理待ちパケット数の削減 ClusterXL は、非対称通信での out-of-state パケットの発生を防止します。これを行うため に、ほかのすべてのアクティブなクラスタ・メンバから SYN-ACK が受信されるまでパ ケットを保持します。何らかの理由で SYN-ACK が受信されない場合、クラスタ・メンバ 上の VPN-1 Pro がパケットを解放しないため、接続は確立されません。 保持されたパケットが解放されていないかどうか確認するには、fw ctl pstat コマンド を実行します。コマンド出力に示される Number of Pending Packets（処理待ちパケッ ト数）の値が通常の負荷状態にもかかわらず大きく（100 を超える）、時間が経っても減 少しない場合は、fwldbcast_pending_timeout パラメータを使用して処理待ちパケット 数を減らしてください。 fwldbcast_pending_timeout の値をデフォルト値の 50 から 50 よりも小さい値に変更し ます。 値の単位はティックです。1 ティックは 0.1 秒に等しいので、 50 ティックは 5 秒になります。 この値で示された時間が経過すると、SYN-ACK が受信されていなくてもパケットは解放 されます。 第7章 ClusterXL の高度な設定 129 モジュール設定パラメータを使用した高度なクラスタ設定 完全同期詳細オプションの設定 クラスタ・メンバは再起動後（または cpstart 後）にアクティブになった場合、完全同 期を実行する必要があります。完全同期プロセスの最初のステップとして、ほかのアク ティブなクラスタ・メンバの 1 つとハンドシェークを実行します。このハンドシェークが 成功した場合だけ、クラスタ・メンバは完全同期プロセスを継続します。 実行される詳細ハンドシェークでは（デフォルトで）クラスタ・メンバ間で情報を交換 します。この情報には、バージョン情報、インストールされているチェック・ポイント 製品に関する情報が含まれており、現在アクティブな VPN-1 Pro カーネル・テーブルに関 する情報を含めることもできます。詳細ハンドシェークは、後の完全同期で行われるカー ネル・テーブル情報の交換とは関係ありません。 すべてのクラスタ・メンバには同じチェック・ポイント製品とバージョンがインストー ルされている必要があります。異なる製品がクラスタ・メンバにインストールされてい る場合には、詳細ハンドシェークによって特定されます。異なる製品がインストールさ れている場合、コンソールへの警告とログ・メッセージが発行されます。 下位互換性をサポートするために、以下のモジュール設定パラメータを使用して詳細ハ ンドシェークの動作を変更できます。これらのパラメータの編集方法については、 125 ページの「モジュール設定パラメータを使用した高度なクラスタ設定」を参照してく ださい。 ■ fw_sync_simplified_fullsync のデフォルト値は 0 です。NG with Application Intelligence（R54）とそれ以前のバージョンで使用されています。 『アップグレード・ ガイド』で説明されている完全接続アップグレードでは詳細ハンドシェークによって バージョンの違いを克服する必要があるため、完全接続アップグレードを実行する場 合にはデフォルト値に設定する必要があります。 NG AI（R54）の場合のように完全同期で簡易ハンドシェークを使用するには、1 に 設定します。 ■ ■ ■ fw_sync_no_ld_trans のデフォルト値は 1 です。完全同期プロセスの最初の段階で メンバ間でカーネル・テーブル情報を交換するには、0 に設定します。 fw_sync_no_conn_trans のデフォルト値は 0 です。完全同期プロセスの最初の段階 でメンバ間でインストールされている製品の情報を交換するには、1 に設定します。 fw_sync_fcu_ver_check のデフォルト値は 1 です。バージョン要件を満たしていな いバージョンに対して完全接続アップグレードを許可するには、0 に設定します。 これらの要件については、『アップグレード・ガイド』を参照してください。 130 Unix での Disconnected インタフェースの定義 Disconnected インタフェースの定義 Disconnected インタフェースとは、ClusterXL メカニズムによる監視を行わないクラスタ・ メンバ・インタフェースです。Disconnected インタフェースに障害が発生してもフェイル オーバーは発生しません。 イ ン タ フ ェ ー ス が 長 時 間 ダ ウ ン し て い る 場 合、ダ ウ ン し て い る イ ン タ フ ェ ー ス を Disconnected インタフェースとして定義することにより、クラスタ・メンバをアクティブ に保つことができます。 ［Topology］ ページから非監視対象インタフェースを定義する方 以下に示すプロセスは、 法と同じです。ただし、GUI による方法は IP アドレスを定義したインタフェースのみに 使用できます。 Unix での Disconnected インタフェースの定義 $FWDIR/conf/discntd.if の下にファイルを作成し、ClusterXL で監視しないインタ フェースの名前を 1 行に 1 つずつ書き込みます。 Windows での Disconnected インタフェースの定義 1 2 regedt32 レジストリ・エディタを開きます。regedit は使用しないでください。 HKEY_LOCAL_MACHINES¥System¥CurrentControlSet¥Services¥CPHA に以下の特性 を持つ新しい値を作成します。 Value Name : DisconnectedInterfaces Data Type : REG_MULTI_SZ 3 インタフェース名を追加します。インタフェース・システム名を取得するには、 以下のコマンドを実行します。 fw getifs 4 以下の書式に従って、この名前を Disconnected インタフェースのリストに追加し ます。 ¥device¥<System Interface Name> 5 cphastop を実行し、次に cphastart を実行して変更を適用します。 ポリシー更新タイムアウトの設定 ポリシーがゲートウェイ・クラスタにインストールされている場合、クラスタ・メンバ はネゴシエーション・プロセスを実行してすべてのクラスタ・メンバが同じポリシーを 受け取ったことを確認してから、ポリシーを実際に適用します。このネゴシエーション・ プロセスには、クラスタ・メンバがほかのクラスタ・メンバからの応答を待たずに済む ようにするタイムアウト・メカニズムが用意されています。このメカニズムは、たとえ ばポリシーのインストール中に別のクラスタ・メンバがダウンしている場合などに役立 ちます。 第7章 ClusterXL の高度な設定 131 TCP 3 ウェイ・ハンドシェーク実施の強化 ポリシーのインストールに長時間かかる構成（通常多くのルールがポリシーに含まれて いるため）、3 つ以上のマシンから成るクラスタ、および速度の遅いマシンでは、このタイ ムアウト・メカニズムは早めに時間切れになる場合があります。 タイムアウトは、以下のパラメータを設定して調整できます。 fwha_policy_update_timeout_factor デフォルト値は 1 で、ほとんどの構成はこれで充分です。上記のような状況が発生する構 成の場合には、このパラメータを 2 に設定して対応できます。このパラメータを 4 以上に 設定しないでください。 TCP 3 ウェイ・ハンドシェーク実施の強化 標準的な 3 ウェイ・ハンドシェークを実施して TCP 接続を開始すると、単方向の対称性が 保証されるため適切なセキュリティが実現されます。この方法では、SYN のあとで必ず SYN-ACK が到達することが保証されます。ただし、SYN-ACK のあとで必ず ACK が到達 すること、および ACK のあとで必ず最初のデータ・パケットが到達することは保証され ません。 特に厳格なポリシーを実施してすべての out-of-state パケットを拒否する場合は、すべての TCP 接続開始パケットが正しいシーケンス（SYN、SYN-ACK、ACK、データの順）で到 達するように同期メカニズムを設定できます。この特別なセキュリティ強化を実施する 代償として、接続確立の速度がかなり低下します。 実施強化を設定するには、データベース・ツールを使用してグローバル・プロパティ sync_tcp_handshake_mode をデフォルト値 minimal_sync から complete_sync に変更し ます。 132 異なるサブネット上のクラスタ・アドレスについて 異なるサブネット上のクラスタ・アドレスの設定 このセクションの構成 異なるサブネット上のクラスタ・アドレスについて 133 ページ 異なるサブネット上のクラスタ・アドレスの設定 134 ページ 異なるサブネット上のクラスタ・アドレスの例 135 ページ 異なるサブネット上のクラスタ・アドレスの制限事項 137 ページ 異なるサブネット上のクラスタ・アドレスについて クラスタ IP は ClusterXL オブジェクトに割り当てる仮想 IP アドレスであり、個々のクラス タ・メンバ・マシンの固有 IP アドレスとは異なります。これらのアドレスを使用すると クラスタが単一のゲートウェイと見なされるため、クラスタはネットワーク上のルータ としてクラスタ自身の内部構造や状態を意識せずに動作できるようになります。 従来は、クラスタ IP アドレスをクラスタ・メンバの固有アドレスが使用しているサブネッ トと同じサブネットに設定する必要がありました。NG with Application Intelligence では、 クラスタ IP をメンバのサブネットと異なるサブネットに置くことができるようになりま した。この機能の利点は以下のとおりです。 ■ ■ ネットワーク内の設定済み単一マシン・ゲートウェイを複数マシン・クラスタで 置き換える際に、クラスタ・メンバ用に新しいアドレスを追加で割り当てる必要 がない。 ClusterXL ゲートウェイ・クラスタに対してルーティング可能なアドレスを 1 つだけ 使用できる。 注： この機能は、ClusterXL ゲートウェイ・クラスタに対してのみサポートされています。OPSEC 認定 クラスタの詳細については、ベンダーのマニュアルを参照してください。 この新機能の重要な点は、クラスタ・メンバから送信されたパケットが（メンバ間をルー ティングされるパケットとは異なり）クラスタ IP アドレスとクラスタ MAC アドレスの背 後に隠されることです。クラスタ MAC は以下のとおりです。 ■ HA New モードの場合はアクティブ・マシンの MAC ■ 負荷共有マルチキャスト・モードの場合はマルチキャスト MAC ■ 負荷共有ユニキャスト・モードの場合はピボット・メンバ MAC この機能を使用すると、メンバは周辺のネットワークと通信できるようになりますが、 137 ページの「異なるサブネット上のクラスタ・アドレスの制限事項」で説明するよう に制約もあります。 第7章 ClusterXL の高度な設定 133 異なるサブネット上のクラスタ・アドレスの設定 異なるサブネット上のクラスタ・アドレスの設定 ClusterXL が異なるサブネット上に置かれたクラスタ IP を使用して正しく動作するために は、2 つの主要なステップを実行する必要があります。 最初のステップは、各クラスタ・メンバにおいてクラスタ・ネットワーク（クラスタ IP が属するサブネット）に対するスタティック・ルートを作成することです。このルートに より、クラスタ・ネットワークに接続されるインタフェースが決定されます。これらのエ ントリが作成されない限り、OS はクラスタ・ネットワークを宛先とするパケットをルー ティングできません。クラスタ・メンバにアドレスを追加する必要はありません。ただ し、メンバに割り当てられている固有の IP がクラスタのそれぞれの「側」で共通のサブ ネットを共有する必要があることに注意してください（つまり、各マシンの各インタ フェースは同じサブネットを使用するマシン相互間でインタフェースを持つ必要があり ます） 。 2 つ目のステップは、クラスタ・トポロジの設定に関係します。クラスタ IP はクラスタ・ トポロジで決定され、クラスタ・メンバのインタフェースに関連付けられます（各メン バは各クラスタ IP に対応するインタフェースを持つ必要があります）。通常クラスタ IP は 共通のサブネットに基づいてインタフェースに関連付けられます。この場合、これらの サブネットは同じではありません。どのメンバ・サブネットをクラスタ IP に関連付ける か を明 示 的 に 指定 す る 必 要が あ り ま す。［Interface Properties］ ウィ ン ド ウ の［Member Network］ タブを使用してメンバ・ネットワークを指定できます（図 7-2 を参照） 。 このインタフェースは、実際にはクラスタ・トポロジでの決定に従ってクラスタの仮想 IP アドレスを参照します。 134 異なるサブネット上のクラスタ・アドレスの例 図 7-2 ［Interface Properties］ウィンドウの［Member Network］タブ 異なるサブネット上のクラスタ・アドレスの例 この例では、ネットワーク 172.16.6.0（「A」側）とネットワーク 172.16.4.0（「B」側）を 分離している単一ゲートウェイ・ファイアウォールが ClusterXL クラスタで置き換えられ ます。ただし、クラスタ・メンバはネットワーク 192.168.1.0 を「A」側に、ネットワーク 192.168.2.0 を「B」側に、ネットワーク 192.168.3.0 を同期ネットワークにそれぞれ使用し ています（この例で示されているネットワーク・アドレスはすべてクラス「C」です） 。 斜体のアドレスはクラスタ IP アドレスです。この設定を図 7-3 に示します。 第7章 ClusterXL の高度な設定 135 異なるサブネット上のクラスタ・アドレスの設定 図 7-3 異なるサブネット上のクラスタ・アドレス メンバに対するスタティック・ルートの設定 各メンバには以下の 2 つのスタティック・ルートを設定する必要があります。 ■ ■ IP アドレス 192.168.1.x をネットワーク 172.16.6.0 に対するゲートウェイとして 設定するルート IP アドレス 192.168.2.x をネットワーク 172.16.4.0 に対するゲートウェイとして 設定するルート SecurePlatform でスタティック・ルートを設定するには、コマンド・プロンプトで sysconfig を実行し、 ［Routing］>［Add New Network Route］を選択して画面の指示に従い ます。 SmartDashboard でのクラスタ IP アドレスの設定 以下の手順に従って、この例のクラスタ・インタフェースの IP アドレスを設定します。 1 ゲートウェイ・クラスタ・オブジェクトの［Topology］>［Edit Topology］ ウィンドウ で、クラスタ・インタフェースを編集して、［Interface Properties］ ウィンドウを開き ます。 2 クラスタ・インタフェースごとに［Interface Properties］ ウィンドウで以下の表に 従って設定します。 表 7-4 136 ClusterXL の［Topology］>［Interface Properties］ウィンドウの設定例 クラスタ・ インタフェース A の IP アドレス クラスタ・ インタフェース B の IP アドレス ［General］タブ 172.16.6.100 172.16.4.100 ［Member Network］タブ 192.168.1.0 192.168.2.0 異なるサブネット上のクラスタ・アドレスの制限事項 すべての IP アドレスがネットマスク 255.255.255.0 を持ちます。 注： 同期ネットワークに対してはクラスタ IP アドレスを定義しないでください。同期インタフェース は、ゲートウェイ・クラスタ・オブジェクトの［Edit Topology］ ページでも定義されます。 異なるサブネット上のクラスタ・アドレスの制限事項 この新しい機能は、まだ ClusterXL のすべての機能はサポートしていません。機能によって は正常に動作するために追加設定が必要です。一部の機能については全く動作しません。 クラスタ・メンバ間の接続性 クラスタ・メンバが発行した ARP 要求はクラスタ IP とクラスタ MAC の背後に隠される ため、1 つのクラスタ・メンバからほかのメンバに送信された要求が宛先マシンから無視 される場合があります。クラスタ・メンバが相互に通信できるようにするには、各クラ スタ・メンバに対してスタティック ARP を設定してクラスタ内のほかのすべてのマシン の MAC アドレスを記述する必要があります。メンバ間で送信される IP パケットは変更さ れないので、ルーティング・テーブルは変更しないでください。 注： クラスタ同期プロトコルは ARP を使用しないため、マシンがクラスタとして正しく動作するために スタティック ARP は必要ありません。 「部分的にサポートする」ハードウェアによる負荷共有マルチキャスト・モード すべてのタイプのネットワーク・ハードウェアがマルチキャスト MAC アドレスで動作す るわけではありませんが、ルータによってはマルチキャスト MAC アドレスを含む ARP 応 答を処理することはできないがパケットを通過させることはできるものがあります。負 荷共有マルチキャスト・モードを部分的にサポートしているルータでは、ルータの内部テー ブルにクラスタMACをスタティックARPエントリとして設定してクラスタと通信させる ことが可能です。 クラスタ IP に対して別々のサブネットが使用されている場合、各クラスタ・メンバ上で ルータの MAC を含むスタティック ARP エントリを設定する必要があります。この種の ルータはマルチキャスト発信元 MAC を含む ARP 要求に応答しないため、この設定が必要 になります。マルチキャスト MAC アドレスを完全にサポートしているルータを使用する 場合は、この特別な手順は不要です。 第7章 ClusterXL の高度な設定 137 異なるサブネット上のクラスタ・アドレスの設定 自動プロキシ ARP スタティック NAT を使用する場合、クラスタが自分の背後に隠されているホストを自動 的に認識し、クラスタ MAC を使用して ARP 応答をホストの代わりに発行するように設定 できます。このプロセスは自動プロキシ ARP と呼ばれます。クラスタ IP に対して別々のサ ブネットを使用している場合はこのメカニズムが働かないため、手作業でプロキシ ARP を 設 定 す る 必 要 が あ り ま す。こ の 設 定 は、フ ァ イ ア ウ ォ ー ル の 設 定 デ ィ レ ク ト リ （$FWDIR/conf）に local.arp という名前のファイルを作成することによって行います。こ の際、SmartDashboard 内の［Automatic proxy arp］ チェック・ボックスをオフにします。 このファイルの各エントリには以下の 3 項目が含まれます。 ■ 公開されるホスト・アドレス ■ IP アドレスに関連付ける必要のある MAC アドレス ■ ARP 要求に応答するインタフェースの固有の IP 使用する MAC アドレスは、負荷共有マルチキャスト・モードを使用する場合は応答する インタフェースに定義したクラスタのマルチキャスト MAC です。ほかのすべてのモード では応答するインタフェースの固有の IP です。 たとえば、ホスト 172.16.4.3 がアドレス 172.16.6.25 を使用して隠され、かつクラスタが 負荷共有マルチキャスト・モードである場合、メンバ 1 の local.arp ファイルに以下の行 を追加する必要があります。 172.16.6.25 00:01:5e:10:06:64 192.168.1.1 この行の 2 つ目のパラメータがクラスタ IP172.16.6.100 のマルチキャスト MAC アドレス であり、172.16.6.25 に対する ARP 要求はこのアドレスを介して受信されます。メンバ 2 上では、この行は以下のようになります。 172.16.6.25 00:01:5e:10:06:64 192.168.1.2 クラスタが負荷共有ユニキャスト・モードまたは HA モードである場合、メンバ 1 とメンバ 2 のエントリは以下のようになります。 172.16.6.25 00:A0:C9:E8:C7:7F 192.168.1.1 および 172.16.6.25 00:A0:C9:E8:CB:3D 192.168.1.2 ここで、各行の 2 つ目のエントリは一致するローカル・インタフェースの固有の MAC アド レスです。 クラスタ・ネットワークからクラスタ・メンバへの接続 固有の IP は任意に選択できるため、これらのアドレスにクラスタ IP のサブネットからア クセスできる保証はありません。固有の IP を使用してメンバにアクセスできるようにす るには、アクセスするマシン上でクラスタ IP がその固有の IP のサブネットに対するゲー トウェイとなるようなルートを設定する必要があります。上記の例では、172.16.6.100 を サブネット 192.168.1.0 に対するゲートウェイにする必要があります。 138 異なるサブネット上のクラスタ・アドレスの制限事項 SecurePlatform のデフォルト・ゲートウェイ ［sysconfig］>［routing］>［add network route］>［add the routable network with its subnet］を 実行し、この方向の適切な物理インタフェースを選択します。 ・ゲー 次に［routing］>［add default gateway］ を実行し、デフォルト（ルーティグ可能な） トウェイの IP アドレスを追加します。これは通常ルータの外部 IP アドレスで、クラスタ IP のいずれかのサブネット内にあります。 複数のインタフェースで別々のサブネット機能を設定してある場合は、それらすべてのイ ンタフェースに対してネットワーク・アドレスの追加を上記のように行います（ほかの サブネットに対してデフォルト・ゲートウェイを定義する必要はありません）。 アンチ・スプーフィング 別々のサブネット 機能を外部インタフェース以外のインタフェースに設定してある場合 は、［Cluster Topology］ タブ のク ラス タ IP に、クラ スタ・イン タフ ェー スの［Interface Properties］ ウィンドウの［Topology］ タブで［Network defined by interface IP and Net Mask］ 定義を行わないでください。ルーティング可能なネットワークとルーティングできない ネットワークの両方を含むネットワーク・グループを追加し、このインタフェースに対 するアンチ・スプーフィングは新しいネットワーク・グループを specific ネットワークと して定義してください。 136 ページの図 7-3 に示す例で、「B」側を内部ネットワークとすると、172.16.4.0 ネッ トワークと 192.168.2.0 ネットワークの両方を含むネットワーク・グループを定義し、 ［Topology］タブ内の［specific］フィールドに新しいネットワーク・グループを定義します。 HA Legacy モードから HA New モードまたは負荷共有モードへの移行 （簡易的方法） ここでは、ダウンタイムを最小限に抑えることよりも設定の簡易性を重視して、 HA Legacy モードから負荷共有マルチキャスト・モードまたは HA New モードへ移行 する手順について説明します。 共有内部インタフェースおよび共有外部インタフェースがクラスタ・インタフェースに なります。したがって、クラスタの全体IPアドレスは外部クラスタIPアドレスのままです。 第7章 ClusterXL の高度な設定 139 HA Legacy モードから HA New モードまたは負荷共有モードへの移行（簡易的方法） モジュールの設定 1 すべてのメンバで cpstop を実行します。すべてのネットワーク接続が失われます。 2 共有（複製）IP アドレスではなく固有の IP アドレスになるように、すべてのクラス タ・メンバで IP アドレスを設定し直します。 注： SecurePlatform の場合のみ： これらのアドレスを変更すると、既存のスタティック・ルートは削除 されます。手順 4 での復元のためにスタティック・ルートをコピーしてください。 3 以下のコマンドを実行して共有 MAC アドレスを削除します。 cphaconf uninstall_macs 4 SecurePlatform クラスタ・メンバの場合のみ、手順 2 で削除したスタティック・ ルートを定義し直します。 5 メンバを再起動します。 SmartDashboard からの設定 SmartDashboard でクラスタ・オブジェクトを開き、 ［ClusterXL］タブを選択してクラスタ・ モードを［Legacy Mode］ から［New Mode］ または［Load Sharing］ モードに変更します。 その後、ゲートウェイ・クラスタ・ウィザードの指示に従います。手動で設定する場合は、 以下の手順に従います。 1 クラスタ・オブジェクトの［Topology］ タブで以下を実行します。 ■ ■ 2 140 各クラスタ・メンバについて、IP アドレスが変更されたために変更されたインタ フェースを取得します。前に共有インタフェースとして使用されていたインタ フェースは、トポロジ上でクラスタ・インタフェースとして定義されます。 クラスタのクラスタ IP アドレスを定義します。必要に応じてクラスタ・インタ フェース名を定義できます。これらは IP アドレスに従って物理インタフェースに バインドされます。 特定のインタフェースのクラスタ・メンバの新しい IP アドレスがこの方向のクラ スタ IP アドレスと別のサブネットにある場合は、クラスタ・メンバのネットワー クをクラスタ・インタフェースの［Members Network］ フィールドで定義する必要 があります（133 ページの「異なるサブネット上のクラスタ・アドレスの設定」）。 新しいクラスタ・オブジェクトにポリシーをインストールします（セキュリティ・ ポリシー、QoS ポリシーなど）。 SmartDashboard からの設定 HA Legacy モードから HA New モードまたは負荷共有モードへの移行 （ダウンタイムを最小限にする方法） ここでは、HA Legacy モードから HA New モードまたは負荷共有モードへ、クラスタの ダウンタイムを最小限に抑えながら移行する手順について説明します。 共有内部インタフェースおよび共有外部インタフェースがクラスタ・インタフェースに なります。クラスタ・メンバに追加する IP アドレスをあらかじめ用意しておく必要があ ります。 変更時のクラスタのダウンタイムが特に問題にならない場合は、139 ページの「HA Legacy モードから HA New モードまたは負荷共有モードへの移行（簡易的方法）」に示す 簡単な手順に従って移行することをお勧めします。 注： 1. このセクションで説明する変更を実施する前に、必要な IP アドレスがすべて用意されていることを 確認してください。 2. この手順では SmartDashboard でオブジェクトをいったん削除して再度作成します。手順を開始する 前に設定をバックアップしてください。 この手順では、マシン「A」とマシン「B」を例として使用し、マシン「A」がアクティブ、 マシン「B」がスタンバイである時点から手順を開始します。 1 マシン「B」を、管理に接続しているインタフェース（管理インタフェース）以外の すべてのインタフェースから切り離します。 2 マシン「B」で cphastop を実行します。 3 マシン「B」の IP アドレスを（新しい構成の必要に応じて）変更します。 注： SecurePlatform の場合のみ： これらのアドレスを変更すると、既存のスタティック・ルートは削除 されます。手順 5 での復元のためにスタティック・ルートをコピーしてください。 4 cphaconf uninstall_macs を実行してマシン「B」の MAC アドレスをリセットします。 Windows マシンの場合は、MAC アドレスの変更を有効にするためにここで再起動し ます。 5 SecurePlatform クラスタ・メンバの場合のみ、手順 3 で削除したスタティック・ ルートを定義し直します。 6 ［Detach from cluster］ を選択します。 SmartDashboard でメンバ「A」を右クリックし、 7 ［Cluster Member Properties］ ウィンドウの［Topology］ タブで［Get...］ をクリックして クラスタ・メンバ「B」のトポロジを定義します。適切なインタフェースを［Cluster Interfaces］ としてください。 第7章 ClusterXL の高度な設定 141 HA Legacy モードから HA New モードまたは負荷共有モードへの移行（ダウンタイムを最小限にする方法） 8 クラスタ・オブジェクトでクラスタの新しいトポロジを定義します（クラスタの ［Topology］ タブでクラスタ・インタフェースを定義します） 。 9 ［ClusterXL］ ページで、クラスタの［High Availability］ モードを［Legacy Mode］ から ［New Mode］ へ変更するか、 ［Load Sharing］ モードを選択します。 10 クラスタ・オブジェクトのほかのページ（［NAT］ ページ、［VPN］ ページ、［Remote Access］ ページなど）の設定が正しいことを確認します。HA Legacy モードではク ラスタ・メンバごとの定義でしたが、ここではクラスタ自身の定義に変更されてい ます。 11 ポリシーを（クラスタ・メンバ「B」のみが含まれている）クラスタにインストール します。 12 マシン「B」を（ステップ 1 で切り離した）ネットワークに再接続します。 13 この例ではクラスタは 2 台のメンバだけで構成されていますが、クラスタのメンバ が 2 台を超える場合は各クラスタ・メンバについてステップ 1 ～ 9 を繰り返します。 14 負荷共有マルチキャスト・モードの場合は、54 ページの表 4-5 の説明に従ってルー タを設定します。 15 マシン「A」を管理ネットワーク以外のすべてのネットワークから切り離します。 クラスタはトラフィックの処理を停止します。 16 マシン「A」で cphastop を実行します。 17 マシン「B」で cpstop を実行し、次に cpstart を実行します（2 台を超えるマシン がある場合は、「A」以外のすべてのマシンでこの 2 つのコマンドを実行します）。 18 マシン「B」がアクティブになり、トラフィックの処理を開始します。 19 マシン「A」の IP アドレスを（新しい構成の必要に応じて）変更します。 20 cphaconf uninstall_macs を実行してマシン「A」の MAC アドレスをリセットします。 Windows マシンの場合は、MAC アドレスの変更を有効にするためにここで再起動し ます。 21 Windows マシンを再起動して MAC アドレスの変更を有効にします。 22 SmartDashboard でクラスタ・オブジェクトを開き、 ［Cluster Members］ ページを選択します。 ［Add］>［Add Gateway to Cluster］ をクリックし、メンバ「A」を選択してクラスタに 再接続します。 23 マシン「A」をステップ 13 で切り離したネットワークに再接続します。 24 セキュリティ・ポリシーをクラスタにインストールします。 25 マシン「A」で cpstop を実行し、次に cpstart を実行します。 26 スタティック・ルートを定義し直します。 クラスタは新しいモードで動作するようになります。 142 単一ゲートウェイ・マシンの設定 単一ゲートウェイから ClusterXL クラスタへの移行 ここでは、新しいゲートウェイ・モジュール（マシン「B」）をスタンドアロンの VPN-1 Pro 実施モジュール（マシン「A」）に追加してクラスタを作成する手順について説明し ます。 単一ゲートウェイ・マシンの設定 単一ゲートウェイで SmartCenter サーバと実施モジュールに同じマシンが使用されている 場合には、以下の手順に従います。 1 SmartCenter サーバと実施モジュールを切り離して別のマシンに配置します。 2 切り離した実施モジュール（マシン「A」 ）で SIC を初期化します。 マシン「B」の設定 1 マシン「A」で策定する予定のクラスタ・インタフェースと同期インタフェースの それぞれについて、対応するインタフェースをマシン「B」で同じサブネットを使用 して定義します。 2 マシンに VPN-1 Pro をインストールします。インストール時に ClusterXL を有効に する必要があります。 マシン「B」に対する SmartDashboard での設定 1 ClusterXL オブジェクトを作成します。 2 ［Cluster Members］ページで［Add］をクリックし、 ［New Cluster Member］を選択します。 3 マシン「B」に接続してトポロジを定義します。 4 クラスタの同期ネットワークを定義します。 5 クラスタ・トポロジを定義します。クラスタ IP アドレスは、マシン「A」で策定する 予定のクラスタ・インタフェースのアドレスと同じにします。 6 ポリシーを（現在はメンバ「B」のみを含む）クラスタにインストールします。 マシン「A」の設定 1 策定する予定のすべてのクラスタ・インタフェースと同期インタフェースを切り離 します。新しい接続はマシン「A」からではなくクラスタから開設されるようにな ります。 2 切り離したインタフェースのアドレスをほかの固有の IP アドレス（前と同じサブ ネット上にあるアドレスが望ましい）に変更します。 第7章 ClusterXL の高度な設定 143 既存クラスタへの別メンバの追加 3 同一サブネット上にある各インタフェース・ペアを専用ネットワークを使用して接 続します。前に単一ゲートウェイに接続されていたすべてのホストまたはゲート ウェイを、ハブ /VLAN を使用して両方のマシンに接続します。 注： WAN を介して同期を実行できます。詳細については、26 ページの「WAN を介したクラスタの同期」 を参照してください。 マシン「A」に対する SmartDashboard での設定 1 ［Cluster Members］ ページで［Add］ をクリックし、 ［Add Gateway to Cluster］ を選択し ます。 2 ウィンドウでマシン「A」を選択します。 3 ［Edit Topology］ ページを開き、どのインタフェースをクラスタ・インタフェース、 内部インタフェース、外部インタフェースにするかを決定します。 4 ポリシーをクラスタにインストールします。 既存クラスタへの別メンバの追加 1 クラスタ・メンバで cpconfig を実行して ClusterXL を有効にします。 2 新しいクラスタ・メンバの IP アドレスを正しいトポロジに合わせて（クラスタリ ング・ソリューションに従って共有 IP アドレスまたは固有 IP アドレスに）変更し ます。 3 必要なすべてのチェック・ポイント製品が新しいクラスタ・メンバにインストール されたことを確認します。 4 ゲートウェイ・クラスタ・オブジェクトの［Cluster Members］ ページで適切なプロ パティを使用して新しいクラスタ・メンバを作成する（新しい VPN-1 Pro マシンの 場合）か、既存のゲートウェイをクラスタ・メンバに変換します。 5 新しい VPN-1 Pro マシンの場合は SIC が初期化されていることを確認します。 ［Edit Topology］ ページでトポロジが正しく定義されていることを確認します。 6 ［Cluster Mode］ が［Load Sharing］ または［New HA］ の場合、新しいクラスタ・メン バの該当するインタフェースが［Cluster Interfaces］ として設定されていることを確 認します。 144 7 セキュリティ・ポリシーをクラスタにインストールします。 8 これで新しいメンバがクラスタの一部になります。 マシン「A」に対する SmartDashboard での設定 クラスタの ISP 冗長性の設定 ClusterXL ゲートウェイ・クラスタがある場合には、2 つのインタフェースを使用して LAN 経由で各クラスタ・メンバを両方の ISP と接続します。クラスタ固有の設定を図 7-4 に示 します。 メンバ・インタフェースは、クラスタの外部インタフェースと同じサブネット上にある 必要があります。 通常の方法で ClusterXL を設定します。 ISP 冗長性を設定するには、FireWall-1 のマニュアルを参照してください。 図 7-4 2 つの ISP リンクに接続されたゲートウェイ・クラスタ 第7章 ClusterXL の高度な設定 145 クラスタ構成でのダイナミック・ルーティング・プロトコルの有効化 クラスタ構成でのダイナミック・ルーティング・プロトコルの有効化 ClusterXL は、SecurePlatform Pro NGX（R60A）の一部としてダイナミック・ルーティン グ（ユニキャストおよびマルチキャスト）・プロトコルをサポートしています。ネット ワーク・インフラストラクチャはクラスタ・ゲートウェイを 1 つの論理エンティティと見 なすため、クラスタ・メンバの障害はネットワーク・インフラストラクチャには透過的 で、それ以上の影響はありません。 システムのコンポーネント 仮想 IP の統合 すべてのクラスタ・メンバかクラスタ IP アドレスを使用します。 ルーティング・テーブル同期 ルーティング情報は、転送情報ベース（FIB）マネージャ・プロセスを使用してクラスタ・ メンバ間で同期されます。ルーティング情報の同期はフェイルオーバーの際にトラ フィックの中断を防ぐために行われ、ClusterXL 負荷共有モードで使用されます。FIB マ ネージャがルーティング情報を処理します。 FIB マネージャは、クリティカル・デバイス（pnote）として登録されています。スレーブ が非同期状態になると pnote が発行され、スレーブ・メンバは FIB マネージャが同期され るまでダウンします。 障害からの復旧 ClusterXL のダイナミック・ルーティングは、ルータがメンテナンス・モードを抜け出し たことを隣接するルータに通知してフェイルオーバーへの影響を防ぎます。隣接する ルータは、ネットワーク内のほかのルータに通知せずにクラスタとの関係を確立し直し ます。これらの再起動プロトコルは、あらゆる主要ネットワーキング・ベンダーで幅広 く採用されています。以下の表に、チェック・ポイントのダイナミック・ルーティング に準拠した RFC とドラフトを示します。 表 7-5 146 準拠するプロトコル プロトコル RFC またはドラフト OSPF LLS draft-ietf-ospf-lls-00 OSPF Graceful restart RFC 3623 BGP Graceful restart draft-ietf-idr-restart-08 ClusterXL のダイナミック・ルーティング ClusterXL のダイナミック・ルーティング 上記のコンポーネントは「バックグランドで」機能します。ClusterXL でダイナミック・ ルーティングを設定する場合、ルーティング・プロトコルは単一デバイスの場合のよう にクラスタに自動的に関連付けられます。 各クラスタ・メンバでルーティング・プロトコルを設定する場合、各メンバは全く同じ に定義され、（メンバの物理 IP アドレスではなく）クラスタ IP アドレスを使用します。 OSPF の場合、各クラスタ・メンバでルータ ID を全く同じに定義する必要があります。 OSPF の再起動を設定する場合には、再起動タイプを signaled または graceful として定 義する必要があります。Cisco デバイスの場合は、signaled タイプを使用してください。 SecurePlatform のコマンド・ライン・インタフェースを使用して、各クラスタ・メンバを 設定します。図 7-5 はクラスタ・メンバ A の適切な構文の例です。 図 7-5 クラスタ・メンバ A での OSPF の有効化 --------- Launch the Dynamic Routing Module [Expert@GWa]# router localhost>enable localhost#configure terminal --------- Enable OSPF and provide an OSPF router ID localhost(config)#router ospf 1 localhost(config-router-ospf)#router-id 192.168.116.10 localhost(config-router-ospf)#restart-type [graceful | signaled] localhost(config-router-ospf)#redistribute kernel --------- Define interfaces/IP addresses on which OSPF runs (Use the cluster IP address as defined in topology) and the area ID for the interface/IP address localhost(config-router-ospf)#network 1.1.10.10 0.0.0.0 area 0.0.0.0 localhost(config-router-ospf)#network 1.1.10.20 0.0.0.0 area 0.0.0.0 -------- Exit the Dynamic Routing Module localhost(config-router-ospf)#exit localhost(config)#exit -------- Write configuration to disk localhost#write memory IU0 999 Configuration written to '/etc/gated.ami' 各クラスタ・メンバに同じ設定を適用する必要があります。 FIB マネージャはルーティング情報同期に TCP 2010 を使用するので、セキュリティ・ ポリシーではすべてのクラスタ・メンバ間との TCP 2010 を受け付ける必要があります。 ダイナミック・ルーティングの詳細については、『SecurePlatform Pro & Advanced Routing Command Line Interface』を参照してください。 第7章 ClusterXL の高度な設定 147 クラスタ構成でのダイナミック・ルーティング・プロトコルの有効化 148 付録 A HA Legacy モード この付録の構成 HA Legacy モードについて 149 ページ HA Legacy モードのトポロジ例 150 ページ HA Legacy モードの導入計画における注意事項 151 ページ HA Legacy モードの設定 153 ページ HA Legacy モードについて HA（ハイ・アベイラビリティ）構成では、同時にアクティブになるのは 1 つのマシンの みです。アクティブ・マシンに障害が発生すると、クラスタ内で次に高い優先順位を持つ マシンへのフェイルオーバーが発生します。 HA Legacy モードは、NG FP3 より前の製品では唯一の HA モードでした。HA モードを初 めて設定する場合には、HA New モードに設定することをお勧めします。 Legacy モードでは、各クラスタ・メンバが同一の IP アドレスと MAC アドレスを共有する ため、アクティブなクラスタ・メンバは、クラスタ IP アドレスに送信されたすべてのパ ケットをハブまたはスイッチから受け取ります。共有インタフェースとは、ほかのインタ フェースと同一の MAC アドレスおよび IP アドレスを持つインタフェースです。 単一ゲートウェイ構成から HA Legacy モード・クラスタへ移行する際は、IP アドレス（す なわち、ルーティング）を変更する必要はなく、どのスイッチまたはハブを使用してイン タフェースを接続しても構いません。ただしこのモードの設定は複雑であるため、正しく 設定するためには正確な手順に従う必要があります。SmartCenter サーバは共有されていな いクラスタ・ネットワーク（すなわち、クラスタの同期ネットワーク）または管理専用ネッ トワークに接続する必要があります。 149 HA Legacy モードのトポロジ例 このセクションの構成 共有インタフェースの IP アドレスと MAC アドレスの設定 150 ページ 同期インタフェース 151 ページ 図 A-1 に、HA Legacy モードの ClusterXL トポロジ例を示します。この図では、物理的な クラスタ・トポロジと必要な SmartDashboard 設定との関係を示しています。この図では、 Member_A（プライマリ）、Member_B（セカンダリ）という 2 つのクラスタ・メンバがあ り、それぞれ 3 つのインタフェースを持っています。これらのインタフェースは、同期、 外部共有インタフェース、および内部共有インタフェースに使用されます。 図 A-1 HA Legacy モードのトポロジ例 共有インタフェースの IP アドレスと MAC アドレスの設定 HA Legacy モードでは、同じ方向のインタフェース上のすべてのクラスタ・メンバに対して 同じ IP アドレスと MAC アドレスを使用します。共有インタフェースは同一の IP アドレス に設定され、同じ MAC アドレスを自動的に取得します。各クラスタ・メンバ上の 1 つの共 有インタフェースがハブまたはスイッチを介してインターネットに接続され、1 つまたは 複数のインタフェースがハブまたはスイッチを介してローカル・ネットワークに接続さ れます。 150 いつの時点でも 1 つのクラスタ・メンバだけがアクティブであるため、常に 1 つのマシン 上の共有インタフェースだけが外部から透過的です。 図 A-1 に共有インタフェースを示します。外部インタフェース（インターネット側）は Member_A と Member_Bの両方で IP アドレス192.168.0.1 を持ち、 内部インタフェース （ロー カル・ネットワーク側）は Member_A と Member_B の両方で IP アドレス 172.20.10.1 を持っ ています。 同期インタフェース クラスタ・メンバのステート同期により、フェイルオーバーが発生しても障害の発生し たマシンで処理されていた接続は維持されます。同期ネットワークは、クラスタ・メン バ間で接続同期情報とその他の状態情報を受け渡すために使用されます。つまり、この ネットワークは組織の最も重要なセキュリティ・ポリシー情報を送信するため、ネット ワークを安全に保護する必要があります。バックアップのために複数の同期ネットワー クを定義できます。 同期インタフェースを保護するためにはクロス・ケーブルで直接接続するか、メンバが 3 つ以上のクラスタの場合には専用ハブ、スイッチ、または VLAN を使用して接続する必 要があります。 HA クラスタ内のコンピュータは同期させる必要はありませんが、同期していない場合は フェイルオーバー時に接続が失われます。 図 A-1 は、各マシンに固有の IP アドレスが割り当てられた同期インタフェースを示して います。Member_A には 10.0.10.1、Member_B には 10.0.10.2 が割り当てられています。 HA Legacy モードの導入計画における注意事項 このセクションの構成 IP アドレスの移行 151 ページ SmartCenter サーバの場所 152 ページ ルーティングの設定 152 ページ スイッチ（レイヤ 2 転送）に関する注意事項 152 ページ IP アドレスの移行 ClusterXL をインストールする目的の多くは、既存の単一ゲートウェイ構成に HA 機能また は負荷共有機能を追加することです。この場合、できれば、現在のゲートウェイから既存 IP アドレスを取り出してクラスタ・アドレス（クラスタの仮想アドレス）とすることをお 勧めします。これにより、現在の IPSec エンドポイント識別を変更せずに済み、多くの場合 Hide NAT 設定もそのまま維持できます。 付録 A HA Legacy モード 151 SmartCenter サーバの場所 SmartCenter 管理サーバは、セキュリティ・ポリシーをすべてのクラスタ・メンバにダウ ンロードできる必要があります。このためには、すべてのクラスタ・メンバが SmartCenter サーバから常に「透過的」である必要があります。したがって HA Legacy モードでは、共 有されていないクラスタ・ネットワークに SmartCenter サーバを接続する必要があります。 SmartCenter サーバは、共有 IP アドレスを持つクラスタ・インタフェースを含むネットワー クには接続できません。これは、これらのネットワークには同じ IP アドレスと MAC アド レスが設定されているためです。 したがって、SmartCenter サーバをクラスタ内のクラスタ同期ネットワークに接続する必 要があります。これは、各クラスタ・メンバ上の同期インタフェースは固有の IP アドレ スを持っているからです。接続できない場合は、クラスタにアタッチされた管理専用の ネットワークに接続する必要があります。 ルーティングの設定 クラスタの外側との通信が、クラスタの内側のクラスタ IP アドレスを使用して行われる ようにルーティングを設定します。 たとえば、図 A-1 でルーティングを以下のように設定します。 ルータの内側の各マシン上で、172.20.0.1 をデフォルト・ゲートウェイとして定義し ます。 ■ ■ 外部ルータ上で、192.168.10.1 を経由してネットワーク 172.20.0.1 に到達するような スタティック・ルートを設定します。 スイッチ（レイヤ 2 転送）に関する注意事項 HA New モード構成と負荷共有モード構成で使用されるクラスタ・コントロール・プロト コル（CCP）は、レイヤ 2 マルチキャストを使用しています。マルチキャスト規格に従い、 このマルチキャスト・アドレスは宛先としてのみ使用され、 「安全に保護されていない」 インタフェースに送信されるすべての CCP パケットに付加されます。 安全に保護されていないインタフェースに接続されるレイヤ 2 スイッチは、スイッチの ポートまたは VLAN 内部のポート（VLAN スイッチの場合）にマルチキャスト・パケッ トを転送可能である必要があります。スイッチは、このようなトラフィックをすべての ポートまたは特定の VLAN 内のすべてのポートに転送することもできます。ただし、ク ラスタ・メンバに接続されているポートにのみ転送するほうが効率的です。 ほとんどのスイッチはデフォルトで、マルチキャスト・トラフィックをサポートしてい ます。詳細については、スイッチのマニュアルを参照してください。 152 接続されているスイッチがマルチキャスト・トラフィックを転送できない場合は、ブロー ドキャスト・トラフィックを使用するように CCP を変更できます。2 つのモードを切り替 えるには、以下のコマンドを使用します。 'cphaconf set_ccp broadcast/multicast' HA Legacy モードの設定 構成例については、150 ページの図 A-1 を参照してください。 1 ClusterXL の Central ライセンスを取得し、SmartCenter サーバにインストールします。 2 HA Legacy 構成のメンバとするマシンをハブ / スイッチから切り離します。 3 HA Legacy 構成のメンバとする各マシンの共有インタフェースにのみ、同じ IP アド レスを定義します。MAC アドレスの共有によりネットワーク競合が起きないように、 マシンを HA Legacy トポロジに接続する前に IP アドレスを定義してください。 4 同じバージョン（およびビルド番号）の VPN-1 Pro を各クラスタ・メンバにインス トールします。設定段階で、ClusterXL/ ステート同期を有効にします。これ以降は、 すべての設定が完了するまでマシンを再起動しないでください。 5 HA Legacy 構成のメンバとするマシンをハブ / スイッチに接続（または再接続） します。設定したインタフェースは、必ず対応する物理ネットワークのコネクタに 接続してください。各ネットワーク（内部、外部、同期、DMZ など）を別々の VLAN、スイッチ、またはハブに接続します。スイッチには特別な設定は必要あり ません。 ルーティングの設定 6 クラスタの内側のネットワークとの通信が、クラスタの外側のクラスタ IP アドレス を使用して行われるようにルーティングを設定します。たとえば、図 A-1 の外部 ルータ上で 192.168.10.100 を経由してネットワーク 10.255.255.100 に到達するような スタティック・ルートを設定します。 7 クラスタの外側のネットワークとの通信が、クラスタの内側のクラスタ IP アドレス を使用して行われるようにルーティングを設定します。たとえば、図 A-1 で、ルー タの内側にある各マシン上で 10.255.255.100 をデフォルト・ゲートウェイとして定 義します。 8 クラスタ・メンバを再起動します。MAC アドレスの設定は自動的に行われます。 付録 A HA Legacy モード 153 SmartDashboard の設定 1 SmartDashboard を使用して、ゲートウェイ・クラスタ・オブジェクトを定義します。 ゲートウェイ・クラスタ・オブジェクトの［General Properties］ ページで、クラスタ のルーティング可能な外部 IP アドレスをクラスタの全体 IP アドレスとして指定し ます。クラスタにインストールされている製品として［ClusterXL］ をオンにします。 2 ［Cluster Members］ ページで［Add］>［New Cluster Member］ を選択して、クラスタ・ メンバをクラスタに追加します。クラスタ・メンバは、ゲートウェイ・クラスタ・ オブジェクト内のみに存在します。各クラスタ・メンバに対して以下の操作を行い ます。 ■ ［Cluster Members Properties］ ウィンドウの［General］ タブで［Name］ と［IP Address］ を定義します。セキュリティ・ポリシーをインストールできるように、 SmartCenter サーバからルーティング可能な IP アドレスを選択します。内部アド レス、外部アドレス、専用管理インタフェースのいずれでも構いません。 ■ ［Communication］ をクリックして、SIC（Secure Internal Communication）を初期化 します。 ■ 必要に応じて、［NAT］ タブと［VPN］ タブを定義します。 ［Cluster Members］ ページで［Add］>［Add Gateway to Cluster］ を選択し、 ［Add Gateway to Cluster］ ウィンドウの一覧からゲートウェイを選択して既存ゲートウェイ をクラスタ・メンバとして追加することもできます。 クラスタからゲートウェイを削除するには、［Cluster Members] ページで［Remove］ ページをクリックして［Detach Member from Cluster］ を選択するか、［Network Objects］ ツリーのクラスタ・メンバを右クリックして［Detach from Cluster］ を選択 します。 3 ［ClusterXL］ ページで以下を実行します。 ［High Availability Legacy Mode］ をオンにします。 ■ ■ ［Use State Synchronization］ をオン / オフにするかどうかを選択します。このオプ ションはデフォルトでオンになっています。これをオフにすると、クラスタ・メ ンバは同期されなくなり、フェイルオーバーの発生時に障害が発生したゲート ウェイ上の既存の接続は切断されます。 ■ ［Upon Gateway Recovery］ で復帰時のアクションを指定します（詳細については、 50 ページの「ゲートウェイが復帰した場合の処理」を参照してください） 。 ■ 154 [Fail-over Tracking] 方法を定義します。 4 ［Topology］ ページでクラスタ・メンバ・アドレスを定義します。仮想クラスタ・ インタフェースは定義しないでください。別のクラスタ・モードから変換すると、 仮想クラスタ・インタフェース定義は削除されます。［Edit Topology］ ウィンドウで、 以下の操作を行います。 ■ ■ 各クラスタ・メンバ・インタフェースのトポロジを定義します。メンバ・インタ フェースに対して定義済みのすべての設定を自動的に読み込むには、［Get all members’ topology］ をクリックします。 ［Network Objective］ カラムでドロップダウン・リストからいずれかのオプション を選択して、ネットワークの目的を定義します。共有 IP アドレスを持つインタ フェースは［Monitored Private］ ネットワークに属するものとして定義し、各クラ スタ・メンバの 1 つ（または複数の）インタフェースは同期ネットワーク内の同 期インタフェース（［1st Sync］ /［2nd Sync］ /［3rd Sync］）として定義します。オ プションについては、オンライン・ヘルプを参照してください。新しいネット ［Add Network］ をクリックします。 ワークを定義するには、 5 必要に応じて、ゲートウェイ・クラスタ・オブジェクトのほかのページ（［NAT］、 ［VPN］、 ［Remote Access］ ページなど）を定義します。 6 セキュリティ・ポリシーをクラスタにインストールします。 7 クラスタ・メンバ上の MAC アドレス設定を有効にするには、すべてのクラスタ・ メンバを再起動します。 付録 A HA Legacy モード 155 156 付録 B cphaprob スクリプトの例 下記の clusterXL_monitor_process スクリプトは、 （ping を使用して）ルータまたはそ の他のネットワーク・デバイスまでのエンド・ツー・エンド接続をチェックし、接続が失 敗した場合にフェイルオーバーを発生する方法の一例を示すように設計されています。 このスクリプトは特定のプロセスの有無を監視し、そのプロセスが停止するとフェイル オーバーが発生します。このスクリプトでは、通常の pnote メカニズムを使用しています。 clusterXL_monitor_process スクリプトは $FWDIR/bin にあります。 関連情報 ■ ■ cphaprob コマンドについては、78 ページの「クラスタの正常動作を確認する方法 （cphaprob）」を参照してください。 第 6 章「ゲートウェイ・クラスタの監視とトラブルシューティング」 clusterXL_monitor_process スクリプト #!/bin/sh # # This script monitors the existence of processes in the system. The process names should be written # in the $FWDIR/conf/cpha_proc_list file one every line. # # USAGE : # cpha_monitor_process X silent # where X is the number of seconds between process probings. # if silent is set to 1, no messages will appear on the console. # # # We initially register a pnote for each of the monitored processes # (process name must be up to 15 characters) in the problem notification mechanism. # when we detect that a process is missing we report the pnote to be in "problem" state. # when the process is up again - we report the pnote is OK. 157 if [ "$2" -le 1 ] then silent=$2 else silent=0 fi if [ -f $FWDIR/conf/cpha_proc_list ] then procfile=$FWDIR/conf/cpha_proc_list else echo "No process file in $FWDIR/conf/cpha_proc_list " exit 0 fi arch=`uname -s` for process in `cat $procfile` do $FWDIR/bin/cphaprob -d $process -t 0 -s ok -p register > /dev/null 2>&1 done while [ 1 ] do result=1 for process in `cat $procfile` do ps -ef | grep $process | grep -v grep > /dev/null 2>&1 status=$? if [ $status = 0 ] then if [ $silent = 0 ] then echo " $process is alive" fi # echo "3, $FWDIR/bin/cphaprob -d $process -s ok report" $FWDIR/bin/cphaprob -d $process -s ok report else if [ $silent = 0 ] then echo " $process is down" fi fi done 158 $FWDIR/bin/cphaprob -d $process -s problem report result=0 if [ $result = 0 ] then if [ $silent = 0 ] then echo " One of the monitored processes is down!" fi else if [ $silent = 0 ] then echo " All monitored processes are up " fi fi if [ "$silent" = 0 ] then echo "sleeping" fi sleep $1 done 付録 B cphaprob スクリプトの例 159 160 付録 C ClusterXL のコマンドライン・ インタフェース 以下のコマンドライン・コマンドは ClusterXL に関連するコマンドで、 『コマンドライン・ インタフェース』ガイドで説明されています。 表 7-6 ClusterXL のコマンドライン・インタフェース コマンド 説明 cphaconf ClusterXL の設定に使用します。このコマンドを実行することは お勧めしません。VPN-1 Pro によってのみ実行する必要があり ます。90 ページの「cphaconf コマンド」を参照してください。 cphaprob クラスタとクラスタ・メンバが正常に動作していることを確認 します。78 ページの「クラスタの正常動作を確認する方法 （cphaprob）」を参照してください。 Nokia VRRP とその他の OPSEC 認定クラスタでは、このコマ ンドの働きは異なります。74 ページの「OPSEC クラスタにお ける cphaprob コマンド」を参照してください。 cphastart クラスタ・メンバで cphastart を実行すると、メンバの ClusterXL が有効になります。完全同期は開始されません。 クラスタ・メンバを起動する場合は、cpstart を使用することを お勧めします。91 ページの「cphastart コマンドと cphastop コ マンド」を参照してください。 cphastop クラスタ・メンバで cphastop を実行すると、クラスタ・メンバ がトラフィックの通過を停止します。ステート同期も停止し ます。ただし、クラスタ・メンバに対して直接接続を開始する ことは可能です。HA Legacy モードでは、cphastop を実行する とクラスタ全体の機能が停止する場合があります。91 ページ の「cphastart コマンドと cphastop コマンド」を参照してくだ さい。 161 162 索引 C I と cphastart 92 cphastop 91 IP アドレス 固有 151 F あ 同期されたファイアウォール 制限 26 同期されたファイアウォール・ モジュール 実装に対する制限 26 fw_sync_allowed_protocols 127 fw_sync_block_new_conns 127 fw_sync_buffer_threshold 127 fw_sync_max_saved_buf_mem 114 fw_sync_simplified_fullsync 130 fwha_timer_base_res 127 fwha_timer_cpha_res 127 fwha_timer_sync_res 127 fwldbcast_pending_timeout 129 アカウンティング 同期された ファイアウォール 27 H く HA SmartView Tracker 87 異なるバージョンのファイ アウォール・モジュール の同期 26 異なるプラットフォーム 上のファイアウォール・ モジュールの同期 26 セキュリティ・サーバ 27 ユーザ認証接続 27 リソース 27 い インタフェースの障害 50 クライアント認証 HA 27 ふ ファイアウォール・モジュール 同期に対する制限 26 ファイアウォール・モジュール の同期 異なるプラットフォーム 26 フェイルオーバー いつ発生するか 50 定義 17 も モジュール設定パラメータ 125 け ケーブルの障害 50 こ ゆ ユーザ認証 HA 27 固有の IP アドレス 151 163 164