（オプション）完全修飾ドメイン名を使用してクラスタを形成する

この章では、ピアが FQDN を使用してクラスタを形成するように、IP アドレスを使用して形成されたクラスタを変更する方法について説明します。 これは、ピア間の TLS 検証を強制する場合に必要です。 クラスタを形成していない場合は、「クラスタを形成する方法」を参照してください。

Expressway-E のクラスタを作成している場合、DMZ などの隔離されたネットワークにある可能性があり、TLS 検証を実施する場合は、ローカル マッピングを使用する必要があります。 Expressway-C のクラスタを形成している場合、クラスタ アドレス マッピングを使用する必要はありません。

この章では、次の項目について説明します。

Expressway-E クラスタのクラスタアドレスマッピング

MRA のようなセキュアな展開の場合、各 Expressway-E ピアにはパブリック FQDN を含む SAN の証明書が必要です。 FQDN はパブリック DNS で Expressway-E のパブリック IP アドレスにマッピングされます。 この構成により、MRA エンドポイントのような外部エンティティは、Expressway-E のパブリック インターフェイスを検出し、セキュアな接続を確立できます。

クラスタアドレスマッピングが必要か

  • Expressway-E ピアをクラスタ化するだけで、ピア間の TLS 検証が必要ない場合は、ノードのプライベート IP アドレスを使用してクラスタを形成できます。 クラスタ アドレス マッピングは必要ありません。

  • クラスタ内の Expressway-E ピアに、証明書を使用して互いのアイデンティティを確認させたい場合、DNS を使用して、クラスタ ピア FQDN をパブリック IP アドレスに解決することを許可できます。 Expressway-E ノードが NIC を 1 つだけ持ち、静的 NAT を使用しておらず、ルーティング可能な IP アドレスを持っている場合、これはクラスタを形成するための完全に許容可能な方法です。 クラスタ アドレス マッピングは必要ありません。

  • セキュリティポリシーがピア間の TLS 検証を強制することを指示している場合、および Expressway-E が静的 NAT、またはデュアル NIC、またはその両方を使用している場合、クラスタから外部インターフェイスまたは静的 NAT アドレスを使用することは推奨しません。

    また、パブリック DNS を使用してピアのパブリック FQDN をプライベート IP アドレスにマッピングしないでください。外部接続が切断されるためです。

    このような状況では、クラスタ アドレス マッピングを使用する必要があります。

クラスタ アドレス マッピングの仕組み

完全修飾ドメイン名を使用してクラスタを形成する場合、ピアはこれらの名前を IP アドレスに変換できる必要があります。 この変換が DNS の主な理由ですが、ピアが DNS にアクセスできない場合、または FQDN をプライベート IP アドレスに変換する必要がある場合は、クラスタアドレスマッピングテーブルを設定して、DNS のローカルな代替値を提供できます。

クラスタ アドレス マッピングは FQDN:IP ペアで、クラスタ全体で共有されます (各ピアに対して 1 ペア)。 ピアは DNS にクエリを実行する前に、マッピング テーブルを参照し、一致が見つかった場合、DNS にクエリを実行しません。

TLS を強制することを選択した場合、ピアは互いの証明書の SAN フィールドから名前を読み取り、マッピングの FQDN 側に対して各名前を確認する必要があります。 SAN がマッピングの FQDN 側と一致し、証明書を提示した IP アドレスがマッピングの IP 側と一致する場合、ピアは他のピアを信頼し、TLS 接続を確立できます。

DNS を使用しない場合、クラスタ アドレス マッピングはこの検証を行う唯一の方法です。

推奨されるマッピングの出所

クラスタがすでに IP アドレスを使用して形成されており、ピアがすでにシステムのホスト名と DNS 名を [システム（System）] > [DNS] ページで設定している場合、次のように想定されるマッピングをクラスタアドレスマッピングテーブルに自動的に入力するオプションがあります。

Peer1Hostname.Peer1DNSName のマッピング先 <Peer1 Private IP address>

….

Peer6Hostname.Peer6DNSName のマッピング先 <Peer6 Private IP address>


（注）  

この自動マッピングは間違っている可能性があります。 ピアの証明書の SAN フィールドにこれらの想定される FQDN が含まれていない場合、[TLS 検証モード（TLS verification mode）] が [強制（Enforce）] に変更されると、クラスタが形成されません。 ピア FQDN フィールドに配置したエントリが SAN に含まれていることを確認する必要があります。

クラスタ アドレス マッピングの構成 (Expressway-E クラスタ)

プライマリピアでマッピングを入力することを強く推奨します。 アドレス マッピングはクラスタを通して動的に複製します。

マッピングの順序は重要ではありませんが、アドレスマッピングを使用している場合は、すべてのクラスタピアに対してマッピングを作成し、 プライベート IP アドレスのみを使用する必要があります。

手順

ステップ 1

IP アドレス（Expressway ピアの新しいクラスタを作成するおよび クラスタにピアを追加するを参照）を使用してクラスタを形成し、[TLS 検証モード（TLS verification mode）] を [許可（Permissive）] に設定します。

ステップ 2

ピアアドレスフィールドに対して緑色の クラスタリング ステータスメッセージを確認して、クラスタが正しく形成されていることを確認します。

また、青色の [証明書: 無効（Certificate: Invalid）] ...ステータスメッセージも表示されます。 これは、FQDN によってピアを識別するために証明書が正しく形成されていると想定して、証明書が内部/プライベート IP アドレスと対応するべきではないためです。 これは予期される動作であり、続行を妨げるものではありません。

ステップ 3

プライマリピアの [システム（System）] > [クラスタリング（Clustering）] に移動し、[クラスタアドレスマッピングが有効（Cluster address mapping enabled）] ドロップダウンを [オン（On）]（デフォルトは [オフ（Off）]）に変更します。

クラスタアドレスマッピング フィールドが表示されます。

ステップ 4

[オプション、上記のメモを参照] [システム情報に基づいてマッピングを提示（Suggest mappings based on system information）] をクリックし、各クラスタピアのマッピングフィールドを自動入力します。 これは、各ピアの [システム（System）] > [DNS ページ（DNS pages）] で設定された [システムホスト名（System host name）] と [DNS 名（DNS name）] を使用し、それらを内側向きのNIC の IP アドレスにマッピングします。

ステップ 5

[自動入力オプションを使用した場合] 推奨されるマッピングがピアの証明書の名前、およびクラスタリングする NIC の IP アドレスに対応していることを確認します。 (データは証明書または DNS と一致しない情報に基づいて構築されます。)

ステップ 6

Expressway-E ピアのパブリック FQDN が内部に面する NIC の IP アドレスに対応するように、マッピングを編集します。

(証明書の SAN フィールドで、または DNS を照会することで、パブリック FQDN を確認できます)。

ステップ 7

[保存（Save）] をクリックします。

マッピングが保存され、他のクラスタ ピアにコピーされます。

（注）  

 

クラスタはまだ IP アドレスを使用して形成されており、TLS 検証の [許可（Permissive）] モードをまだ使用しています。 [ピア N アドレス（Peer N address）] フィールドをパブリック FQDN に変更し、[TLS 検証モード（TLS verification mode）] を [強制（Enforce）] に変更すると、クラスタはこれらのマッピングの使用を開始します。

FQDN を使用するようにクラスタを変更する

このトピックでは、IP アドレスを FQDN に置き換えて、ピア アドレスを体系的に変更する方法について説明します。 次のアドレスに移動する前に、クラスタ全体で一度に 1 つのピア アドレスを変更できます。

FQDN を使用するように Expressway-E クラスタを変更するには、マッピングテーブル ( Expressway-E クラスタのクラスタアドレスマッピング を参照) に入力されているアドレスを使用します。


（注）  

ピアアドレスを変更している間、ピア間の通信は一時的に影響を受け、変更が完了し、クラスタが新しいアドレスに一致するまで、アラームが表示され続けます。

手順

ステップ 1

すべてのクラスタピアにサインインし、それぞれで [システム（System）] > [クラスタリング（Clustering）] に移動します。

ステップ 2

最初に変更するピア アドレスを選択します。 リスト内のすべてのピアアドレスに対して次のプロセスを 1 つずつ繰り返す必要があるため、ピア 1 アドレスから開始することをおすすめします。

ステップ 3

クラスタ内の各ピア:

  • 選択したピアアドレスフィールドを IP アドレスから対応する FQDN に変更します（マッピングを行っている場合、この段階ですべてのピアでマッピングを複製する必要があります）。

  • [保存（Save）] をクリックします。

注意    

 

各ボックスで 1 つのピアアドレスのみを変更するようにしてください。

ステップ 4

現在変更しているピアアドレスで識別されるピアに切り替え、このピアを再起動（[メンテナンス（Maintenance）] > [再起動オプション（Restart options）] に移動）した後、[再起動（Restart）] をクリックし、[OK] をクリックして確認します。

（注）  

 

すべてのピアでピア アドレスを変更する場合、1 回の再起動が必要です。

ステップ 5

一時的なクラスタリングアラームが解決するまで待ちます。

クラスタ全体で、このピアのクラスタリング アドレスを IP アドレスから FQDN に正常に変更しました。

ステップ 6

次に変更するピアアドレスを選択し、ステップ 3 ～ 5 を繰り返します。 すべてのピアアドレスを変更し、すべてのピアを再起動するまで、このループを繰り返します。

クラスタ全体が FQDN で動作しているはずですが、クラスタはまだ 許可 モードのままです。

クラスタが Expressway-E クラスタで、ピア間で TLS 検証を強制することを目指している場合、ピア アドレス フィールドは証明書で提示されたアイデンティティと一致する必要があります。 クラスタリングと証明書 の両方のステータスメッセージが緑であることを確認します。

TLS 検証の強制

事前準備


注意    

証明書 SAN に、ピア N アドレス フィールドにある FQDN が含まれていることを確認します。 続行する前に、各アドレス フィールドの隣に、クラスタリングと証明書の緑色のステータス メッセージが表示されるはずです。

TLS 検証を強制するプロセス

手順

ステップ 1

プライマリピアで、[TLS 検証モード（TLS verification mode）] を [強制（Enforce）] に設定します。

注意    

 

証明書が無効な場合、警告が表示され、クラスタが強制 TLS 検証モードで適切に動作することを妨げます。

新しい TLS 検証モードはクラスタ全体で複製されます。

ステップ 2

[TLS 検証モード（TLS verification mode）] が他の各ピアで [強制（Enforce）] になっていることを確認します。

ステップ 3

[ 保存 ] をクリックして、プライマリピアを再起動します。

ステップ 4

他の各ピアにサインインし、ピアを再起動します。

ステップ 5

クラスタが安定するのを待ち、すべてのピアについて、クラスタリングと証明書のステータスが緑であることを確認します。

Expressway-E トラバーサルゾーンの使用上の注意

これは初期セットアップではなく、運用上の使用法に関するものですが、便宜上、ここで説明します。 Expressway-C クラスタの FQDN は、Expressway-E トラバーサルゾーンの TLS 検証サブジェクト名フィールドで構成する必要があることに注意してください。 Expressway は、受け取った証明書を検証するために、CN (共通名) ではなく、SAN 属性 (サブジェクト代替名) を使用します。