Cisco ASA シリーズ VPN CLI コンフィギュレーション ガイド

インターフェイス内トラフィックにおける NAT の注意事項

ASAがインターフェイスを介して暗号化されていないトラフィックを送信するには、そのインターフェイスに対する NAT をイネーブルにし、プライベート IP アドレスをパブリックにルーティング可能なアドレスに変換する必要があります（ただし、ローカル IP アドレス プールですでにパブリック IP アドレスを使用している場合は除きます）。次の例では、クライアント IP プールから発信されたトラフィックに、インターフェイス PAT ルールを適用しています。

ただし、ASAがこの同じインターフェイスから暗号化された VPN トラフィックを送信する場合、NAT は任意です。VPN 間ヘアピニングは、NAT を使用してもしなくても機能します。すべての発信トラフィックに NAT を適用するには、上記のコマンドを実装するだけです。VPN 間トラフィックを NAT から免除するには、次のように、VPN 間トラフィックの NAT 免除を実装するコマンドを（上記のコマンドに）追加します。

NAT ルールの詳細については、このマニュアルの「NAT の適用」の章を参照してください。

制限事項

ルーティングの問題のため、この機能が必要でない場合は、この機能の使用は推奨しません。

• レガシー Cisco VPN Client（IKEv1）と AnyConnect クライアントだけをサポートします。

• NAT ポリシーおよび VPN ポリシーが適用されるように、パブリック IP アドレスへのリターン トラフィックは ASA にルーティングされる必要があります。

• 割り当てられた IPv4 およびパブリック アドレスだけをサポートします。

• NAT/PAT デバイスの背後にある複数のピアはサポートされません。

• ロード バランシングはサポートされません（ルーティングの問題のため）。

• ローミングはサポートされません。

手順の詳細

ステップ 1 グローバル コンフィギュレーション モードで、 tunnel general を入力します。

ステップ 2 アドレス変換をイネーブルにするには、次の構文を使用します。

このコマンドは、送信元のパブリック IP アドレスに、割り当てられた IP アドレスの NAT ポリシーをダイナミックにインストールします。 interface は、NAT の適用先を決定します。

ステップ 3 アドレス変換をディセーブルにするには、次の構文を使用します。

VPN NAT ポリシーの表示

アドレス変換は、基礎となるオブジェクト NAT メカニズムを使用します。そのため、VPN NAT ポリシーは、手動設定されたオブジェクト NAT ポリシーと同様に表示されます。次の例では、割り当てられた IP として 95.1.226.4 を使用して、ピアのパブリック IP として 75.1.224.21 を使用します。

outside は AnyConnect クライアントが接続するインターフェイスであり、 inside は新しいトンネル グループに固有のインターフェイスです。

（注） VPN NAT ポリシーがダイナミックであり、設定に追加されないため、VPN NAT オブジェクトおよび NAT ポリシーは、show run オブジェクトおよび show run nat reports レポートから非表示になります。

ロード バランシングとフェールオーバーの比較

ロード バランシングとフェールオーバーはどちらもハイ アベイラビリティ機能ですが、これらは機能も要件も異なります。場合によっては、ロード バランシングとフェールオーバーの両方を使用できます。次の項では、これらの機能の違いについて説明します。

ロード バランシング

ロード バランシングとは、リモートアクセス VPN トラフィックを、仮想クラスタ内のデバイス間で均等に分配するメカニズムのことです。この機能は、スループットまたはその他の要因を考慮しない単純なトラフィックの分散に基づいています。ロードバランシング クラスタは 2 つ以上のデバイスで構成され、そのうちの 1 つが仮想マスターとなり、それ以外のデバイスはバックアップとなります。これらのデバイスは、完全に同じタイプである必要はなく、同じソフトウェア バージョンやコンフィギュレーションを使用する必要もありません。

仮想クラスタ内のすべてのアクティブなデバイスがセッションの負荷を伝送します。ロードバランシングにより、トラフィックはクラスタ内の最も負荷の少ないデバイスに転送され、負荷はすべてのデバイス間に分散されます。これにより、システム リソースが効率的に使用され、パフォーマンスが向上し、ハイ アベイラビリティが実現されます。

フェールオーバー

フェールオーバー設定には、同じASAが 2 台、専用のフェールオーバー リンク（オプションで、ステートフル フェールオーバー リンク）で相互に接続されている必要があります。アクティブ インターフェイスおよび装置のヘルスがモニタされて、所定のフェールオーバー条件に一致しているかどうかが判断されます。これらの条件に一致した場合は、フェールオーバーが行われます。フェールオーバーは、VPN とファイアウォールの両方のコンフィギュレーションをサポートします。

ASA は、アクティブ/アクティブ フェールオーバーとアクティブ/スタンバイ フェールオーバーの 2 つのフェールオーバーをサポートします。

アクティブ/アクティブ フェールオーバーでは、両方の装置がネットワーク トラフィックを渡すことができます。これは、同じ結果になる可能性がありますが、真のロード バランシングではありません。フェールオーバーが行われると、残りのアクティブ装置が、設定されたパラメータに基づいて結合されたトラフィックの通過を引き継ぎます。したがって、アクティブ/アクティブ フェールオーバーを構成する場合は、両方の装置の合計トラフィックが各装置の容量以内になるようにする必要があります。

アクティブ/スタンバイ フェールオーバーでは、1 つの装置だけがトラフィックを通過させることができ、もう 1 つの装置はスタンバイ状態で待機して、トラフィックを通過させません。アクティブ/スタンバイ フェールオーバーでは、2 番目の ASA を使用して、障害の発生した装置の機能を引き継ぎます。アクティブ装置が故障すると、スタンバイ状態に変わり、そしてスタンバイ装置がアクティブ状態に変わります。アクティブになる装置が、障害の発生した装置の IP アドレス（または、トランスペアレント ファイアウォールの場合は管理 IP アドレス）および MAC アドレスを引き継いで、トラフィックの転送を開始します。現在スタンバイになっている装置が、アクティブ装置のスタンバイの IP アドレスを引き継ぎます。アクティブ装置で障害が発生すると、スタンバイ装置は、クライアント VPN トンネルを中断することなく引き継ぎます。

ロード バランシングの実装

ロード バランシングをイネーブルにするには、次の手順を実行します。

• 共通仮想クラスタ IP アドレス、UDP ポート（必要に応じて）、およびクラスタの IPsec 共有秘密情報を確立することによりロードバランシング クラスタを設定する。クラスタ内のすべてのデバイスに対してこれらの値を同一に設定します。

• デバイスでロード バランシングをイネーブルにし、デバイス固有のプロパティを定義することにより、参加デバイスを設定する。これらの値はデバイスによって異なります。

（注） VPN ロード バランシングには、アクティブな 3DES または AES ライセンスが必要です。ASAは、ロード バランシングをイネーブルにする前に、この暗号化ライセンスの存在をチェックします。アクティブな 3DES または AES ライセンスを検出できない場合、ASAは、ロード バランシングのイネーブル化を回避し、さらにライセンスがこの使用を許可していない限り、ロード バランシング システムによる 3DES の内部コンフィギュレーションも回避します。

前提条件

ロード バランシングはデフォルトではディセーブルになっています。ロード バランシングは明示的にイネーブルにする必要があります。

まず、パブリック（外部）インターフェイスおよびプライベート（内部）インターフェイスを設定し、さらに仮想クラスタ IP アドレスが参照するインターフェイスを事前に設定しておく必要があります。これらのインターフェイスに異なる名前を設定するには、 interface コマンドと nameif コマンドを使用します。この項では、これ以降の参照に外部および内部の名前を使用します。

クラスタに参加するすべてのデバイスは、同じクラスタ固有の値（IP アドレス、暗号化設定、暗号キー、およびポート）を共有する必要があります。

適格なプラットフォーム

ロードバランシング クラスタには、ASA モデルの ASA 5512-X（Security Plus ライセンスあり）および Model 5515-X 以降を含めることができます。クラスタには Cisco VPN 3000 シリーズのコンセントレータも含めることができます。混合コンフィギュレーションは可能ですが、通常は、同種クラスタにする方が容易に管理できます。

適格なクライアント

ロード バランシングは、次のクライアントで開始されるリモート セッションでのみ有効です。

• Cisco AnyConnect VPN Client（Release 2.0 以降）

• Cisco VPN Client（Release 3.0 以降）

• Cisco ASA 5505 ASA（Easy VPN クライアントとして動作している場合）

• Cisco VPN 3002 Hardware Client（Release 3.5 以降）

• Easy VPN クライアントとして動作している場合、Cisco PIX 501/506E

• IKE リダイレクトをサポートする Cisco IOS EZVPN クライアント デバイス（IOS 831/871）

• クライアントレス SSL VPN（クライアントではない）

ロード バランシングは、IPsec クライアント セッションと SSL VPN クライアントおよびクライアントレス セッションで機能します。LAN-to-LAN を含む他のすべての VPN 接続タイプ（L2TP、PPTP、L2TP/IPsec）は、ロード バランシングがイネーブルになっているASAに接続できますが、これらの接続タイプはロード バランシングには参加できません。

VPN ロードバランシングのアルゴリズム

マスター デバイスには、バックアップ クラスタ メンバーを IP アドレスの昇順にソートしたリストが保持されます。各バックアップ クラスタ メンバーの負荷は、整数の割合（アクティブ セッション数）として計算されます。AnyConnect の非アクティブ セッションは、ロード バランシングの SSL VPN 負荷に数えられません。マスター デバイスは、IPsec トンネルと SSL VPN トンネルを負荷が最も低いデバイスに、その他のデバイスより負荷が 1% 高くなるまでリダイレクトします。すべてのバックアップ クラスタ メンバーの負荷がマスターより 1% 高くなると、マスター デバイスは自分自身に対してリダイレクトします。

たとえば、1 つのマスターと 2 つのバックアップ クラスタ メンバーがある場合に、次のサイクルが当てはまります。

（注） すべてのノードは 0% から始まり、すべての割合は四捨五入されます。

1. マスター デバイスは、すべてのメンバにマスターよりも 1% 高い負荷がある場合に、接続を使用します。

2. マスターが接続を使用しない場合、セッションは、最もロード率が低いバックアップ デバイスが処理します。

3. すべてのメンバに同じ割合の負荷がかかっている場合、セッション数が最も少ないバックアップ デバイスがセッションを取得します。

4. すべてのメンバに同じ割合の負荷と同じ数のセッションがある場合、IP アドレス数が最も少ないデバイスがセッションを取得します。

VPN ロードバランシング クラスタ コンフィギュレーション

ロードバランシング クラスタは、次の制限に従って、同じリリース、または混在リリースのASAと、VPN 3000 コンセントレータ、あるいはこれらの組み合わせで構成できます。

• 同じリリースの ASA、またはすべて VPN 3000 コンセントレータで構成されるロードバランシング クラスタは、IPsec、AnyConnect、およびクライアントレス SSL VPN セッションの組み合わせに対してロードバランシングを実行できます。

• 同じリリースのASAおよび VPN 3000 コンセントレータの両方で構成されるロードバランシング クラスタは、IPsec、AnyConnect、およびクライアントレス SSL VPN クライアントとクライアントレス セッションの組み合わせに対してロード バランシングを実行できます。

• 混在リリースのASAまたは同じリリースのASAおよび VPN 3000 コンセントレータあるいはこれら両方で構成されるロードバランシング クラスタは、IPsec セッションのみをサポートできます。ただし、このようなコンフィギュレーションでは、ASAは、それぞれの IPsec のキャパシティに完全に到達しない可能性があります。 シナリオ 1：SSL VPN 接続のない混在クラスタ は、この状況を示しています。

Release 7.1(1) 以降、IPsec セッションと SSL VPN セッションは、クラスタ内の各デバイスが伝送する負荷を決定するときに均等にカウントまたは重み付けします。これは、ASA Release 7.0(x) ソフトウェアと VPN 3000 コンセントレータのロードバランシング計算からの変更です。両方のプラットフォームで、一部のハードウェア プラットフォームが SSL VPN セッションの負荷を IPSec セッションの負荷とは異なる方法で計算する重み付けアルゴリズムが使用されます。

クラスタの仮想マスターは、クラスタのメンバにセッション要求を割り当てます。ASAは、すべてのセッション、SSL VPN または IPsec を同等と見なし、それらを同等に割り当てます。許可する IPsec セッションと SSL VPN セッションの数は、コンフィギュレーションおよびライセンスで許可されている最大数まで設定できます。これらの制限の設定方法については、 VPN セッション制限の設定を参照してください。

ロードバランシング クラスタで最大 10 のノードはテスト済みです。これよりクラスタが多くても機能しますが、そのようなトポロジは正式にはサポートされていません。

一部の一般的な混在クラスタのシナリオ

混在コンフィギュレーション、つまりロードバランシング クラスタにさまざまな ASA ソフトウェア リリースを実行しているデバイスが含まれている、または ASA Release 7.1(1) 以降および VPN 3000 コンセントレータを実行しているASAが少なくとも 1 つ含まれる場合、最初のクラスタ マスターで障害が発生し、別のデバイスがマスターを引き継ぐときに、重み付けアルゴリズムの違いが問題になります。

次のシナリオは、ASA Release 7.1(1)、ASA Release 7.0(x) ソフトウェアを実行しているASAと VPN 3000 シリーズ コンセントレータの混在で構成されているクラスタでの VPN ロードバランシングの使用を示しています。

シナリオ 1：SSL VPN 接続のない混在クラスタ

このシナリオでは、クラスタは ASA と VPN 3000 コンセントレータの混在で構成されています。ASA クラスタ ピアには、ASA Release 7.0(x) を実行しているものも、Release 7.1(1) を実行しているものもあります。7.1(1) 以前のピアおよび VPN 3000 ピアには、SSL VPN 接続はなく、7.1(1) クラスタ ピアには、SSL VPN の基本ライセンスのみあり、2 つの SSL VPN セッションは許可されますが、SSL VPN 接続はありません。この場合、すべての接続は IPsec であり、ロード バランシングは良好に機能します。

2 つの SSL VPN ライセンスは、ユーザの最大 IPsec セッション制限の活用にはほとんど影響を及ぼしません。また、これは VPN 3000 コンセントレータがクラスタ マスターの場合に限られます。一般に、混在クラスタ内のASAの SSL VPN ライセンスの数が少なければ少ないほど、IPsec セッションしかないシナリオで IPsec セッションの制限に達することができる ASA 7.1(1) デバイスへの影響も小さくなります。

シナリオ 2：SSL VPN 接続を処理する混在クラスタ

たとえば、ASA Release 7.1(1) ソフトウェアを実行している ASA が最初のクラスタ マスターで、そのデバイスに障害が発生したとします。クラスタ内の別のデバイスが自動的にマスターを引き継ぎ、そのクラスタ内のプロセッサの負荷を決定するためにそのデバイス独自のロードバランシング アルゴリズムを適用します。ASA Release 7.1(1) ソフトウェアを実行しているクラスタ マスターは、そのソフトウェアが提供する方法以外では、セッションの負荷を重み付けすることはできません。そのため、IPsec および SSL VPN セッションの負荷の組み合わせを、以前のバージョンを実行する ASA デバイスにも、VPN 3000 コンセントレータにも適切に割り当てることができません。これとは逆に、クラスタ マスターとして動作している VPN 3000 コンセントレータは、ASA Release 7.1(1) ASA に負荷を適切に割り当てることができません。 次のシナリオは、 このジレンマを示しています。

このシナリオは、クラスタが ASA と VPN 3000 コンセントレータの混在で構成されているという点において、前述のシナリオと似ています。ASA クラスタ ピアには ASA Release 7.0(x) を実行しているものも、Release 7.1(1) を実行しているものもあります。ただし、この場合は、クラスタは SSL VPN 接続だけでなく IPsec 接続も処理されます。

ASA Release 7.1(1) 以前のソフトウェアを実行しているデバイスがクラスタ マスターである場合、マスターは実質的に Release 7.1(1) 以前のプロトコルとロジックを適用します。つまり、セッションはそのセッション制限を超えているロードバランシング ピアに転送される場合もあります。その場合、ユーザはアクセスを拒否されます。

クラスタ マスターが ASA Release 7.0(x) ソフトウェアを実行しているデバイスである場合、古いセッション重み付けアルゴリズムは、クラスタ内の 7.1(1) 以前のピアにのみ適用されます。この場合、アクセスが拒否されることはありません。これは、7.1(1) 以前のピアは、セッション重み付けアルゴリズムを使用するため、負荷がより軽くなっています。

ただし、7.1(1) ピアが常にクラスタ マスターであることは保証できないため、問題が発生します。クラスタ マスターで障害が発生すると、別のピアがマスターの役割を引き継ぎます。新しいマスターは、適格なピアのいずれかになります。結果を予測することは不可能であるため、このタイプのクラスタを構成しないことを推奨します。

ロード バランシング用のパブリック インターフェイスとプライベート インターフェイスの設定

ロードバランシング クラスタ デバイス用のパブリック（外部）インターフェイスとプライベート（内部）インターフェイスを設定するには、次の手順を実行します。

ステップ 1 vpn-load-balancing コンフィギュレーション モードで、 lbpublic キーワードを指定して interface コマンドを入力し、ASAにパブリック インターフェイスを設定します。このコマンドは、このデバイスのロード バランシングのためのパブリック インターフェイスの名前または IP アドレスを指定します。

ステップ 2 vpn-load-balancing コンフィギュレーション モードで、 lbprivate キーワードを指定して interface コマンドを入力し、ASAにプライベート インターフェイスを設定します。このコマンドで、このデバイスのロード バランシングのためのプライベート インターフェイスの名前または IP アドレスを指定します。

ステップ 3 このデバイスを割り当てるためのクラスタ内でのプライオリティを設定します。指定できる範囲は 1 ～ 10 です。プライオリティは、起動時または既存のマスターで障害が発生したときに、このデバイスが仮想クラスタ マスターになる可能性を表します。プライオリティを高く設定すると（たとえば 10）、このデバイスが仮想クラスタ マスターになる可能性が高くなります。

たとえば、このデバイスにクラスタ内でのプライオリティ 6 を割り当てるには、次のコマンドを入力します。

ステップ 4 このデバイスにネットワーク アドレス変換を適用する場合は、デバイスに割り当てられた NAT アドレスを指定して nat コマンドを入力します。IPv4 および IPv6 アドレスを定義するか、デバイスのホスト名を指定できます。

たとえば、このデバイスに NAT アドレス 192.168.30.3 および 2001:DB8::1 を割り当てるには、次のコマンドを入力します。

ロード バランシング クラスタ属性の設定

クラスタ内の各デバイスのロードバランシング クラスタ属性を設定するには、次の手順を実行します。

ステップ 1 グローバル コンフィギュレーション モードで vpn load-balancing コマンドを入力して、VPN ロードバランシングをセットアップします。

これで vpn-load-balancing コンフィギュレーション モードに入るため、ここで残りのロードバランシング属性を設定できます。

ステップ 2 このデバイスが属しているクラスタの IP アドレスまたは完全修飾ドメイン名を設定します。このコマンドは、仮想クラスタ全体を表す単一の IP アドレスまたは FQDN を指定します。仮想クラスタ内のすべてのASAが共有するパブリック サブネットのアドレス範囲内で、IP アドレスを選択します。IPv4 アドレスまたは IPv6 アドレスを指定できます。

たとえば、クラスタ IP アドレスを IPv6 アドレス 2001:DB8::1 に設定するには、次のコマンドを入力します。

ステップ 3 クラスタ ポートを設定します。次のコマンドは、このデバイスが参加する仮想クラスタの UDP ポートを指定します。デフォルト値は 9023 です。別のアプリケーションでこのポートが使用されている場合は、ロード バランシングに使用する UDP の宛先ポート番号を入力します。

たとえば、クラスタ ポートを 4444 に設定するには、次のコマンドを入力します。

ステップ 4 （任意）クラスタに対する IPsec 暗号化をイネーブルにします。デフォルトでは暗号化は使用されません。このコマンドは、IPsec 暗号化をイネーブルまたはディセーブルにします。このチェック属性を設定する場合は、まず共有秘密情報を指定して検証する必要があります。仮想クラスタ内のASAは、IPsec を使用して LAN-to-LAN トンネル経由で通信します。デバイス間で通信されるすべてのロードバランシング情報が暗号化されるようにするには、この属性をイネーブルにします。

（注） 暗号化を使用する場合、事前にロードバランシング内部インターフェイスを設定しておく必要があります。そのインターフェイスがロードバランシング内部インターフェイスでイネーブルになっていない場合、クラスタの暗号化を設定しようとするとエラー メッセージが表示されます。

クラスタの暗号化を設定したときにロードバランシング Inside インターフェイスがイネーブルになっており、仮想クラスタ内の参加デバイスを設定する前にディセーブルになった場合、participate コマンドを入力する（または、ASDM で、[Participate in Load Balancing Cluster] チェックボックスをオンにする）と、エラー メッセージが表示され、そのクラスタに対する暗号化はイネーブルになりません。

クラスタの暗号化を使用するには、内部インターフェイスを指定して crypto isakmp enable コマンドを使用し、内部インターフェイス上の ISAKMP をイネーブルにする必要があります。

ステップ 5 クラスタの暗号化をイネーブルにする場合、 cluster key コマンドを入力して IPsec 共有秘密情報も指定する必要があります。このコマンドは、IPsec 暗号化をイネーブルにしてある場合、IPsec ピア間に共有秘密を指定します。ボックスに入力する値は、連続するアスタリスク文字として表示されます。

たとえば、共有秘密情報を 123456789 に設定するには、次のコマンドを入力します。

ステップ 6 participate コマンドを入力して、クラスタへのこのデバイスの参加をイネーブルにします。

完全修飾ドメイン名を使用したリダイレクションのイネーブル化

VPN ロードバランシング モードで完全修飾ドメイン名を使用したリダイレクトをイネーブルまたはディセーブルにするには、グローバル コンフィギュレーション モードで redirect-fqdn enable コマンドを使用します。この動作は、デフォルトではディセーブルになっています。

デフォルトで、ASA はロードバランシング リダイレクションの IP アドレスだけをクライアントに送信します。DNS 名に基づく証明書が使用されている場合、その証明書はバックアップ デバイスにリダイレクトされたときに無効になります。

VPN クラスタ マスターとして、ASA は、VPN クライアント接続を別のクラスタ デバイスにリダイレクトする場合に、DNS 逆ルックアップを使用して、そのクラスタ デバイス（クラスタ内の別の ASA）の外部 IP アドレスではなく Fully Qualified Domain Name（FQDN; 完全修飾ドメイン名）を送信できます。

クラスタ内のロードバランシング デバイスのすべての外部および内部ネットワーク インターフェイスは、同じ IP ネットワーク上に存在する必要があります。

IP アドレスではなく、FQDN を使用して SSL 接続または IPsec/IKEv2 接続のロード バランシングを実行するには、次の設定手順を実行します。

ステップ 1 redirect-fqdn enable コマンドを使用して、ロード バランシングのための FQDN の使用をイネーブルにします。

redirect-fqdn {enable | disable}
no redirect-fqdn {enable | disable}

ステップ 2 DNS サーバに、各 ASA outside インターフェイスのエントリを追加します（エントリが存在しない場合）。それぞれの ASA 外部 IP アドレスに、ルックアップ用にそのアドレスに関連付けられた DNS エントリが設定されている必要があります。これらの DNS エントリに対しては、逆ルックアップもイネーブルにする必要があります。

ステップ 3 dns domain-lookup inside コマンドを使用して、ASA で DNS ルックアップをイネーブルにします。inside の部分には、DNS サーバへのルートを持つ任意のインターフェイスを指定します。

ステップ 4 ASA 上の DNS サーバ IP アドレスを定義します。たとえば、 dns name-server 10.2.3.4 （DNS サーバの IP アドレス）。

次に、完全修飾ドメイン名のリダイレクトをイネーブルにし、クラスタのパブリック インターフェイスを test と指定し、クラスタのプライベート インターフェイスを foo と指定するインターフェイス コマンドを含む、VPN ロードバランシング コマンド シーケンスの例を示します。

ロード バランシングについての FAQ

IP アドレス プールの枯渇

Q： ASAは、IP アドレス プールの枯渇をその VPN ロードバランシング方式の一部と見なしますか。

A： いいえ。リモート アクセス VPN セッションが、IP アドレス プールが枯渇したデバイスに転送された場合、セッションは確立されません。ロードバランシング アルゴリズムは、負荷に基づき、各バックアップ クラスタ メンバが提供する整数の割合（アクティブ セッション数および最大セッション数）として計算されます。

固有の IP アドレス プール

Q： VPN ロード バランシングを実装するには、異なるASA上の AnyConnect クライアントまたは IPsec クライアントの IP アドレス プールを固有にする必要がありますか。

A： はい。IP アドレス プールはデバイスごとに固有にする必要があります。

同じデバイスでのロード バランシングとフェールオーバーの使用

Q： 単一のデバイスで、ロード バランシングとフェールオーバーの両方を使用できますか。

A： はい。この設定では、クライアントはクラスタの IP アドレスに接続し、クラスタ内で最も負荷の少ないASAにリダイレクトされます。そのデバイスで障害が発生すると、スタンバイ装置がすぐに引き継ぎ、VPN トンネルにも影響を及ぼしません。

複数のインターフェイスでのロード バランシング

Q： 複数のインターフェイスで SSL VPN をイネーブルにする場合、両方のインターフェイスにロード バランシングを実装することはできますか。

A： パブリック インターフェイスとしてクラスタに参加するインターフェイスは 1 つしか定義できません。これは、CPU 負荷のバランスをとることを目的としています。複数のインターフェイスは、同じ CPU に集中するため、複数のインターフェイスにおけるロード バランシングの概念には意味がありません。

ロード バランシング クラスタの最大同時セッション

Q： それぞれが 100 ユーザの SSL VPN ライセンスを持つ 2 つの ASA 5525-X が構成されているとします。この場合、ロードバランシング クラスタで許可されるユーザの最大合計数は、200 同時セッションでしょうか。または 100 同時セッションだけでしょうか。さらに 100 ユーザ ライセンスを持つ 3 台目のデバイスを追加した場合、300 の同時セッションをサポートできますか。

A： VPN ロード バランシングを使用すると、すべてのデバイスがアクティブになるため、クラスタでサポートできる最大セッション数は、クラスタ内の各デバイスのセッション数の合計になります。この例の場合は、300 になります。

ロード バランシングの表示

ロードバランシング クラスタのマスターは、アクティブな AnyConnect セッション、クライアントレス セッション、そして設定された制限またはライセンス数制限に基づく最大許可セッションがあるクラスタ内の各 ASA からメッセージを定期的に受信します。クラスタ内のある ASA の容量が 100% いっぱいであると示される場合、クラスタ マスターはこれに対してさらに接続をリダイレクトすることはできません。ASA がいっぱいであると示されても、ユーザによっては非アクティブまたは再開待ち状態となり、ライセンスを消費する可能性があります。回避策として、セッション合計数ではなく、セッション合計数から非アクティブ状態のセッション数を引いた数が各 ASA によって提供されます （コマンド リファレンスの -sessiondb summary コマンドを参照してください）。つまり、非アクティブなセッションはクラスタ マスターに報告されません。ASA が（非アクティブなセッションによって）いっぱいになっている場合でも、クラスタ マスターは必要に応じて接続を ASA に引き続きリダイレクトします。ASA が新しい接続を受信すると、最も長く非アクティブになっていたセッションがログオフされ、新しい接続がそのライセンスを引き継ぎます。

次の例は、100 個の SSL セッション（Active のみ）と 2% の SSL 負荷を示しています。これらの数字には、非アクティブなセッションは含まれていません。つまり、非アクティブなセッションはロード バランシングの負荷に数えられません。

制限事項

• 暗号化コア再分散ができるのは、次のプラットフォームです。

– 5585-X

– 5545-X

– 5555-X

– ASASM

手順の詳細

IP アドレス タイプ別のアクティブな AnyConnect セッションの表示

コマンドライン インターフェイスを使用して、アクティブな AnyConnect セッションを表示するには、特権 EXEC モードで show vpn-sessiondb anyconnect filter p-ipversion または show vpn-sessiondb anyconnect filter a-ipversion コマンドを入力します。

例

例 3-1 show vpn-sessiondb anyconnect filter p-ipversion [v4 | v6] コマンドの出力

例 3-2 show vpn-sessiondb anyconnect filter a-ipversion [v4 | v6] コマンドの出力

IP アドレス タイプ別のアクティブなクライアントレス SSL VPN セッションの表示

コマンドライン インターフェイスを使用して、アクティブなクライアントレス SSL VPN セッションを表示するには、特権 EXEC モードで show vpn-sessiondb webvpn filter ipversion コマンドを入力します。

例

例 3-3 show vpn-sessiondb webvpn filter ipversion [v4 | v6] コマンドの出力

IP アドレス タイプ別のアクティブな LAN-to-LAN VPN セッションの表示

コマンドライン インターフェイスを使用して、アクティブなクライアントレス SSL VPN セッションを表示するには、特権 EXEC モードで show vpn-sessiondb l2l filter ipversion コマンドを入力します。

RADIUS サーバ グループの設定

認証、許可、またはアカウンティングに外部 RADIUS サーバを使用する場合は、まず RADIUS プロトコルあたり少なくとも 1 つの AAA サーバ グループを作成して、各グループに 1 つ以上のサーバを追加する必要があります。AAA サーバ グループは名前で識別されます。

RADIUS サーバ グループを追加するには、次の手順を実行します。

手順の詳細

	コマンド	目的
ステップ 1	aaa-server server_tag protocol radius   hostname(config)# aaa-server servergroup1 protocol radius hostname(config-aaa-server-group)#	サーバ グループ名とプロトコルを識別します。 aaa-server protocol コマンドを入力する場合は、コンフィギュレーション モードを開始します。
ステップ 2	merge-dacl { before-avpair | after-avpair }   hostname(config)# aaa-server servergroup1 protocol radius hostname(config-aaa-server-group)# merge-dacl before-avpair	ダウンロード可能 ACL と、RADIUS パケットから Cisco AV ペアで受信した ACL を結合します。デフォルト設定は no merge dacl で、ダウンロード可能な ACL は Cisco AV ペア ACL と結合されません。AV ペアおよびダウンロード可能な ACL の両方を受信した場合は、AV ペアが優先し、使用されます。 before-avpair オプションは、ダウンロード可能な ACL エントリが Cisco-AV-Pair エントリの前に配置されるように指定します。 after-avpair オプションは、ダウンロード可能な ACL エントリが Cisco-AV-Pair エントリの後に配置されるように指定します。このオプションは、VPN 接続にのみ適用されます。VPN ユーザの場合は、ACL は Cisco AV ペア ACL、ダウンロード可能 ACL、および ASA で設定される ACL の形式になります。このオプションでは、ダウンロード可能 ACL と AV ペア ACL が結合されているどうかを判断します。ASA で設定される ACL には適用されません。
ステップ 3	max-failed-attempts number   hostname(config-aaa-server-group)# max-failed-attempts 2	次のサーバを試す前にグループ内の RADIUS サーバに送信する要求の最大数を指定します。 number 引数の範囲は 1 ～ 5 です。デフォルト値は 3 です。 ローカル データベースを使用してフォールバック方式（管理アクセス専用）を設定している場合で、グループ内のすべてのサーバが応答しないとき、グループは応答なしと見なされ、フォールバック方式が試行されます。サーバ グループで、追加の AAA 要求によるアクセスがない、非応答と見なされる時間が 10 分間（デフォルト）続くと、ただちにフォールバック方式が使用されます。非応答時間をデフォルトから変更するには、次のステップの reactivation-mode コマンドを参照してください。 フォールバック方式として設定されていない場合、ASAは引き続きグループ内のサーバにアクセスしようとします。
ステップ 4	reactivation-mode { depletion [ deadtime minutes ] | timed }   hostname(config-aaa-server-group)# reactivation-mode deadtime 20	グループ内で障害の発生したサーバを再度アクティブ化する方法（再アクティブ化ポリシー）を指定します。 depletion キーワードを指定すると、グループ内のすべてのサーバが非アクティブになった後に、障害の発生したサーバが再度アクティブ化されます。 deadtime minutes キーワード引数のペアには、グループ内の最後のサーバをディセーブルにしてから、次にすべてのサーバを再度イネーブルにするまでの経過時間を分単位で 0 ～ 1440 から指定します。デフォルトは 10 分です。 timed キーワードは、30 秒間のダウンタイムの後に障害が発生したサーバを再度アクティブ化します。
ステップ 5	accounting-mode simultaneous   hostname(config-aaa-server-group)# accounting-mode simultaneous	グループ内のすべてのサーバにアカウンティング メッセージを送信します。 アクティブ サーバだけ送信メッセージをデフォルトに戻すには、 accounting-mode single コマンドを入力します。
ステップ 6	aaa-server server_group [ interface_name ] host server_ip   hostname(config)# aaa-server servergroup1 outside host 10.10.1.1	サーバと、そのサーバが属する AAA サーバ グループを識別します。 aaa-server host コマンドを入力すると、AAA サーバのホスト コンフィギュレーション モードを開始します。
ステップ 7	dynamic-authorization {port port-number}   (config-aaa-server-group)# dynamic-authorization port 1700	AAA サーバ グループの RADIUS の動的認可（CoA）サービスをイネーブルにします。 定義されると、対応する RADIUS サーバ グループが CoA 通知用に登録され、ASA は ISE からの CoA ポリシー更新用ポートをリッスンします。 CoA のリスニング ポート番号の有効な範囲は、1 ～ 65535 です。 このコマンドの「no」形式で指定されたポート番号またはインターフェイスが現在のコンフィギュレーションの行に一致しない場合は、エラー メッセージが表示されます。
ステップ 8	authorize-only   (config-aaa-server-group)# authorize-only	RADIUS サーバ グループ用の認可専用モードをイネーブルにします。これで、このサーバ グループが認可に使用されている場合に RADIUS アクセス要求メッセージが現在利用可能になっている設定済みのパスワード方式ではなく、「認可専用」要求として構築されることが示されます。認可専用要求には値 Authorize-Only（17）を持つサービス タイプ属性と、アクセス要求内のメッセージ認証子が含まれます。 認可専用モードのサポートにより、アクセス要求に RADIUS 共通パスワードを含める必要がなくなります。したがって、AAA サーバ ホスト モードで radius Common pw CLI を使用して共通パスワードを設定する必要はありません。 （注） 認可専用モードはサーバ グループに対して設定されますが、共通パスワードはホストに固有です。したがって、認可専用モードを設定すると、個々の AAA サーバに設定された共通パスワードは無視されるようになります。
ステップ 9	without-csd {anyconnect}   (config-tunnel-webvpn)# without-csd anyconnect	特定のトンネル グループに行われる接続のホストスキャン処理をオフに切り替えます。この設定は現在、クライアントレスおよび L3 接続に適用されます。このコマンドは、この設定を AnyConnect 接続にのみ適用するように変更されています。
ステップ 10	interim-accounting-update {periodic interval}   (config-aaa-server-group)# interim-accounting-update periodic 12	RADIUS 中間アカウンティング アップデート メッセージの生成をイネーブルにします。現在、これらのメッセージは、VPN トンネル接続がクライアントレス VPN セッションに追加された場合にだけ生成されます。これが発生した場合、新たに割り当てられた IP アドレスを RADIUS に通知するためのアカウンティング アップデートが生成されます。現在の機能を許可する、またはアカウンティング メッセージを指示されたサーバ グループに送信するように設定されたすべてのセッションに対して定期的なアカウンティング アップデートの生成を許可する設定ができるように、このコマンドにキーワードが追加されています。 [periodic]：このオプションのキーワードは、対象のサーバ グループにアカウンティング レコードを送信するように設定されたすべての VPN セッションのアカウンティング レコードの定期的な生成と伝送をイネーブルにします。 [interval]：定期的なアカウンティング アップデート間の間隔の長さを時間単位で表す数値です。有効な範囲は 1 ～ 120 で、デフォルト値は 24 です。

構成例

I次に、単一サーバで 1 つの RADIUS グループを追加する例を示します。

次に、認可専用の動的認可（CoA）の更新と時間ごとの定期的なアカウンティングの ISE サーバ オブジェクトを設定する例を示します。

次に、ISE でパスワード認証用のトンネル グループを設定する例を示します。

次に、ISE でローカル証明書の検証と認可用のトンネル グループを設定する例を示します。

hostname(config-tunnel-general)# exit

CoA をイネーブルにする方法の詳細については、『Cisco ASA Series General Operations CLI Configuration Guide』の「Configuring RADIUS Servers for AAA」を参照してください。

コマンドの概要

コマンド	目的
(config-aaa-server-group)# dynamic-authorization {port port-number}	AAA サーバ グループの RADIUS の動的認可（CoA）サービスをイネーブルにします。 定義されると、対応する RADIUS サーバ グループが CoA 通知用に登録され、ASA は ISE からの CoA ポリシー更新用ポートをリッスンします。 CoA のリスニング ポート番号の有効な範囲は、1 ～ 65535 です。 このコマンドの「no」形式で指定されたポート番号またはインターフェイスが現在のコンフィギュレーションの行に一致しない場合は、エラー メッセージが表示されます。
(config-aaa-server-group)# authorize-only	RADIUS サーバ グループ用の認可専用モードをイネーブルにします。これで、このサーバ グループが認可に使用されている場合に RADIUS アクセス要求メッセージが現在利用可能になっている設定済みのパスワード方式ではなく、「認可専用」要求として構築されることが示されます。認可専用要求には値 Authorize-Only（17）を持つサービス タイプ属性と、アクセス要求内のメッセージ認証子が含まれます。 認可専用モードのサポートにより、アクセス要求に RADIUS 共通パスワードを含める必要がなくなります。したがって、AAA サーバ ホスト モードで radius Common pw CLI を使用して共通パスワードを設定する必要はありません。 （注） 認可専用モードはサーバ グループに対して設定されますが、共通パスワードはホストに固有です。したがって、認可専用モードを設定すると、個々の AAA サーバに設定された共通パスワードは無視されるようになります。
(config-tunnel-webvpn)# without-csd {anyconnect}	特定のトンネル グループに行われる接続のホストスキャン処理をオフに切り替えます。この設定は現在、クライアントレスおよび L3 接続に適用されます。このコマンドは、この設定を AnyConnect 接続にのみ適用するように変更されています。
(config-aaa-server-group)# interim-accounting-update {periodic interval}	RADIUS 中間アカウンティング アップデート メッセージの生成をイネーブルにします。現在、これらのメッセージは、VPN トンネル接続がクライアントレス VPN セッションに追加された場合にだけ生成されます。これが発生した場合、新たに割り当てられた IP アドレスを RADIUS に通知するためのアカウンティング アップデートが生成されます。現在の機能を許可する、またはアカウンティング メッセージを指示されたサーバ グループに送信するように設定されたすべてのセッションに対して定期的なアカウンティング アップデートの生成を許可する設定ができるように、このコマンドにキーワードが追加されています。 [periodic]：このオプションのキーワードは、対象のサーバ グループにアカウンティング レコードを送信するように設定されたすべての VPN セッションのアカウンティング レコードの定期的な生成と伝送をイネーブルにします。 [interval]：定期的なアカウンティング アップデート間の間隔の長さを時間単位で表す数値です。有効な範囲は 1 ～ 120 で、デフォルト値は 24 です。

トラブルシューティング

次のコマンドは、デバッグに使用できます。

CoA のアクティビティを追跡するには：

リダイレクト URL 機能を追跡するには：

URL リダイレクト機能に対応する NP 分類ルールを表示するには：