Cisco Identity Services Engine ユーザ ガイド リリース 1.1.1
インライン ポスチャの設定
インライン ポスチャの設定
発行日;2013/01/21 | 英語版ドキュメント(2012/08/16 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 18MB) | フィードバック

目次

インライン ポスチャの設定

インライン ポスチャの既知の制限

インライン ポスチャの役割について

インライン ポスチャ展開の計画

インライン ポスチャの設定について

インライン ポスチャ動作モードの選択

インライン ポスチャのベスト プラクティス

スタンドアロン モードとハイ アベイラビリティ

インライン ポスチャのハイ アベイラビリティ

分散展開でのインライン ポスチャのガイドライン

インライン ポスチャ ノードの展開

ハイ アベイラビリティを実現するためのインライン ポスチャの設定

ハイ アベイラビリティ ペアの設定

インライン ポスチャ ノードの同期

RADIUS クライアントとしてのインライン ポスチャの追加

インライン ポスチャ ノードのモニタリング

展開からのインライン ポスチャ ノードの削除

リモート アクセス VPN の使用例

インライン ポスチャ ノードを使用する Cisco ISE 展開の設定

インライン ポスチャの設定

この章では、インライン ポスチャ ノードをスタンドアロン モードで、またはハイ アベイラビリティ ペアとして設定する方法を説明します。この項では、次のトピックを扱います。

「インライン ポスチャの既知の制限」

「インライン ポスチャの役割について」

「インライン ポスチャ展開の計画」

「インライン ポスチャ ノードの展開」

「ハイ アベイラビリティを実現するためのインライン ポスチャの設定」

「RADIUS クライアントとしてのインライン ポスチャの追加」

「インライン ポスチャ ノードのモニタリング」

「展開からのインライン ポスチャ ノードの削除」

「リモート アクセス VPN の使用例」

インライン ポスチャの既知の制限

ここでは、Cisco ISE でのインライン ポスチャに関する既知の制限について説明します。

インライン ポスチャは、VMware などの仮想環境ではサポートされません。

バックアップと復元は、インライン ポスチャ ノードに対しては使用できません。

簡易ネットワーク管理プロトコル(SNMP)エージェントは、インライン ポスチャではサポートされません。

Cisco Discovery Protocol(CDP)は、インライン ポスチャではサポートされません。

これらをはじめとする既知の問題については、『 Release Notes for the Cisco Identity Services Engine, Release 1.1.1 』の「Known Issues」の項を参照してください。

インライン ポスチャの役割について

インライン ポスチャ ノードは、アクセス ポリシーを適用し、許可変更(CoA)リクエストを処理するゲートキーパーです。インライン ポスチャ ノードは、ワイヤレス LAN コントローラ(WLC)やバーチャル プライベート ネットワーク(VPN)デバイスなど、CoA を処理できないネットワーク上のネットワーク アクセス デバイスの背後に配置されます。

クライアントの初期認証(EAP/802.1x と RADIUS を使用)の後に、クライアントは引き続きポスチャ評価を受ける必要があります。ポスチャ評価プロセスによって、クライアントからネットワークへのアクセスを制限するか、拒否するか、フル アクセスを許可するかが決定されます。クライアントが WLC または VPN デバイスを経由してネットワークにアクセスする場合、インライン ポスチャは、これらのデバイスが対応できないポリシー適用と CoA に対応します。

インライン ポスチャによるポリシー適用

インライン ポスチャは、コントロール プレーンの RADIUS プロキシと URL リダイレクトの機能を使用してエンドポイントのデータ プレーン トラフィックを管理します。RADIUS プロキシとしてのインライン ポスチャは、ネットワーク アクセス デバイス(NAD)と RADIUS サーバとの間の RADIUS セッションに介入することができます。NAD は、クライアント トラフィックをすべて通過させることができます。ただし、インライン ポスチャは、クライアントからの限定的なトラフィックのみを通過させます。このように帯域幅が制限されていると、クライアントでのエージェントのプロビジョニング、ポスチャ評価、および修復が可能になります。このような制限を行うには、個々のクライアント フローに合わせて調整された DACL をダウンロードしてインストールします。

完全準拠した状態になると、CoA がポリシー サービス ISE ノードからインライン ポスチャ ノードに送信され、インライン ポスチャ ノードは、準拠しているクライアント エンドポイントのすべてのトラフィックを通過させます。RADIUS プロキシによってフル アクセス DACL がダウンロードされてインストールされ、クライアント IP アドレスが関連付けられます。インストールされた DACL は、多数のユーザ グループの間で共通とすることもできるので、DACL の内容が Cisco ISE サーバ側で変更されることがなければ、何度もダウンロードする必要はありません。

図 10-1 に、インライン ポスチャのポリシー適用プロセスを示します。この例では、ポリシー サービス ISE ノードへのトラフィックに対する WLC 適用のフローが示されています。ただし、アクセスのステップは、VPN ゲートウェイがある場合のインライン展開でも同様です。

図 10-1 インライン ポスチャ ポリシー適用のフロー

 

図 10-1 に示すインライン ポスチャ ポリシー適用のステップは次のとおりです。

1. エンドポイントがワイヤレス ネットワークへの .1X 接続を開始します。

2. WLC(これは NAD です)が、RADIUS Access-Request メッセージを RADIUS サーバ(通常はポリシー サービス ISE ノード)に送信します。

3. RADIUS プロキシとして機能するインライン ポスチャ ノードが、Access-Request メッセージを RADIUS サーバにリレーします。

4. ユーザの認証後に、RADIUS サーバは RADIUS Access-Accept メッセージをインライン ポスチャ ノードに返送します。

Access-Accept メッセージが送信される前に、エンドポイント、WLC、インライン ポスチャ ノード、および Cisco ISE RADIUS サーバの間で、多数の RADIUS トランザクションが発生することがあります。この例で説明するプロセスは、簡潔にするために、ある程度省略しています。

5. インライン ポスチャ ノードは、Access-Accept メッセージを WLC に渡し、これを受けて WLC は、メッセージに付随しているプロファイルに従ってエンドポイントにアクセスを許可します。

6. プロキシされた Access-Accept メッセージがトリガーとなり、インライン ポスチャが Authorization-Only リクエストをポリシー サービス ISE ノードに送信し、セッションのプロファイルを取得します。

7. ポリシー サービス ISE ノードから Access-Accept メッセージが、必要なインライン ポスチャ プロファイルとともに返されます。

8. プロファイルで定義されているアクセス コントロール リスト(ACL)がまだインライン ポスチャ ノード上にない場合、ポリシー サービス ISE ノードでは、(Cisco ISE RADIUS サーバへの)RADIUS リクエストを使用してダウンロードされます。

9. Cisco ISE RADIUS サーバは、応答として完全な ACL を送信します。これがインライン ポスチャ データ プレーンにインストールされ、エンドポイント トラフィックが通過できるようになります。

完全な ACL がダウンロードされる前、特に、ACL が大きすぎて 1 つのトランザクションでは送信できない場合は、多数のトランザクションが発生することがあります。

10. エンドポイント トラフィックが WLC に到着すると、WLC はセッションの RADIUS Accounting-Start メッセージをインライン ポスチャ ノードに送信します。

エンドポイントからの実際のデータ トラフィックがインライン ポスチャの非信頼側に到着した時点では、まだインライン ポスチャ ノードが Accounting-Start メッセージを受信していないことがあります。RADIUS Accounting-Start メッセージを受信すると、インライン ポスチャ ノードはそのセッションに関与するエンドポイントの IP アドレスを学習し、エンドポイントに ACL(このセッションですでにダウンロードおよびインストールされたもの)を関連付けます。このクライアント エンドポイントの初期プロファイルではアクセスを制限しておき、クライアントにフル アクセス権を付与する前にポスチャを確認できます。

11. この制限的な ACL で許可されるのが Cisco ISE サーバへのアクセスのみであるとすると、エンドポイントに許可されるアクションは、たとえばエージェントのダウンロードやデータ プレーン上でのポスチャ評価のみとなります。

12. クライアント エンドポイントがポスチャ準拠である(Cisco ISE のサービスとのこれまでの制限的な通信の一部として)場合は、ポリシー サービス ISE ノードによって、新しいプロファイルでの RADIUS 許可変更(CoA)が開始されます。したがって、インライン ポスチャ ノードでは、新しい ACL がそのセッションに適用されます。新しい ACL は即座にインストールされて、エンドポイント トラフィックに適用されます。

13. これで、エンドポイントは企業ネットワークへのフル アクセスが可能となります。これは、インライン ポスチャに新しいプロファイルが適用された結果です。

特定のセッションに対する RADIUS stop メッセージが WLC から発行されると、対応するエンドポイント アクセスがインライン ポスチャ ノードにおいてリセットされます。

例に示したような展開においては、ワイヤレス ネットワークに追加のエンドポイントが接続されるときに、これらのエンドポイントは多くの場合、認証と許可が完了してネットワークに接続しているユーザが属している ID グループの 1 つに分類されます。

たとえば、従業員、役員、ゲストのそれぞれに、これまでに説明したステップを通してアクセス権が付与されているとします。この状況では、これらの ID グループのそれぞれに対応する限定的またはフル アクセスのプロファイルが、すでにインライン ポスチャ ノードにインストールされています。それ以降のエンドポイントの認証と許可では、インライン ポスチャ ノードに存在するインストール済みプロファイルが使用されます。ただし、元のプロファイルが Cisco ISE ポリシー設定において変更済みの場合を除きます。後者のケースでは、変更済みのプロファイルと ACL がダウンロードされてインライン ポスチャ ノードにインストールされ、前のバージョンが置き換えられます。

信頼/非信頼インターフェイス

次の用語は、インライン ポスチャ展開において重要な役割を果たします。このような理由から、インライン ポスチャに関連する次の用語の定義を理解しておくことが重要です。

信頼:Cisco ISE ネットワークの 内側にある ポリシー サービス ISE ノードやその他の信頼できるデバイスと通信するインターフェイス。信頼インターフェイスの名前は常に Eth0 となります。

非信頼:Cisco ISE ネットワークの 外側にある WLC、VPN、その他のデバイスと通信するインターフェイス。非信頼インターフェイスの名前は常に Eth1 となります。

インライン ポスチャ専用ノード

他のペルソナ サービスとは異なり、インライン ポスチャはノードを他のサービスと共有できません。ノードを共有できないため、インライン ポスチャは、ネットワーク上のプライマリ管理 ISE ノードに専用ノードとして登録されていることが必要になります。

Cisco ISE では、ハイ アベイラビリティを実現するために、最大 2 つのインライン ポスチャ ノードをアクティブ/スタンバイ ペアとして設定できます。

Cisco ISE 分散展開の詳細については、「分散環境での Cisco ISE の設定」を参照してください。

インライン ポスチャ展開の計画

ネットワークのインライン ポスチャの設定を開始する前に、インライン ポスチャの動作モードと展開オプションと、インライン ポスチャに当てはまるフィルタと管理対象サブネットの基本について理解しておいてください。

この項は、次のトピックで構成されています。

「インライン ポスチャの設定について」

「インライン ポスチャ動作モードの選択」

「インライン ポスチャのベスト プラクティス」

「管理対象サブネットおよびスタティック ルートの設定」

「スタンドアロン モードとハイ アベイラビリティ」

「ハイ アベイラビリティを実現するためのインライン ポスチャの設定」

「分散展開でのインライン ポスチャのガイドライン」


) Cisco ISE ノードのインストール方法については、『Cisco Identity Services Engine Hardware Installation Guide, Release 1.1.1』を参照してください。


インライン ポスチャの設定について

インライン ポスチャとは、管理 ISE ノードに登録されている専用ノードです。インライン ポスチャの設定は管理コンソールから行い、その設定内容はインライン ポスチャ ノードにプッシュされます。設定のコピーが、ローカルの管理データベースに保存されます。登録が行われると、インライン ポスチャ ノードが再起動されます。

インライン ポスチャのハイ アベイラビリティ(HA)ペアの場合は、設定は自動的に両方のインライン ポスチャ ノードにプッシュされます。設定変更時にセカンダリ ノードがダウンしている場合は、そのノードが起動したときにプライマリ ノードでデータベース同期ボタンをクリックすると、最新の設定が自動的にセカンダリ ノードに適用されます。設定はローカル データベースに保持されます。


) インライン ポスチャ ノードが登録されると、システムが再起動します。インフラストラクチャ設定、たとえば eth1 IP アドレス、インライン ポスチャ モード、およびハイ アベイラビリティを変更した場合も、システム再起動が必要です。


インライン ポスチャ ノードを管理 ISE ノードに登録した後は、eth0(信頼)IP アドレスを管理者インターフェイスから変更することはできません。これは、登録済みインライン ポスチャ ノードの eth0 IP アドレスを変更すると、管理 ISE ノードと通信できなくなるからです。インライン ポスチャ ノードと管理 ISE ノードとの間で通信しようとしても失敗し、その結果、例外が発生する可能性があります。


警告 Cisco ISE ネットワークに登録された後は、CLI からインライン ポスチャ ノードの IP アドレスを変更しないことを強く推奨します。


インライン ポスチャ動作モードの選択

どのインライン ポスチャ動作モードを選択するかは、主に既存のネットワークのアーキテクチャによって決まります。ただし、この選択は、展開のために指定が必要な他の多数の設定オプションの基準となります。このような理由から、次に示すインライン ポスチャの動作モードのそれぞれについて、機能を理解しておくことが重要です。

ルーテッド モード:このモードは、レイヤ 3 の「hop in the wire」として動作し、選択的にパケットを指定のアドレスに転送します。このモードを使用すると、ネットワーク トラフィックを分離できるので、選択した宛先アドレスに対するアクセス権を持つユーザを指定できるようになります。

ブリッジ モード:このモードは、レイヤ 2 の「bump in the wire」として動作し、パケットを宛先アドレスにかかわらず転送します。

メンテナンス モード:このモードではノードがオフラインになるので、管理手順を実行できます。このモードは、ノードが初めてネットワークに接続され、他の設定がまだ行われていないときのデフォルト モードでもあります。

ブリッジ モードとルーテッド モードについては、この項の残りの部分で詳しく説明します。

インライン ポスチャ ルーテッド モード

ルーテッド モードでは、インライン ポスチャ ノードはレイヤ 3 ルータとして動作し、非信頼ネットワークとその管理対象クライアントのデフォルト ゲートウェイとして機能します。非信頼ネットワークと信頼ネットワーク間のすべてのトラフィックは、インライン ポスチャ ノードを通過します。インライン ポスチャ ノードは、IP フィルタリング ルール、アクセス ポリシー、および設定されたその他のトラフィック処理メカニズムを適用します。

インライン ポスチャをルーテッド モードで設定する場合は、次の 2 つのインターフェイスの IP アドレスを指定する必要があります。

信頼できる(Eth0)

信頼できない(Eth1)

信頼できるアドレスと信頼できないアドレスは、異なるサブネットに属する必要があります。インライン ポスチャは、1 つまたは複数のサブネットを管理でき、非信頼インターフェイスは管理対象サブネットのゲートウェイとして機能します。

図 10-2 に、インライン ポスチャ ルーテッド モードの設定を示します。下記のルーテッド モードの例では、インライン ポスチャは VPN ゲートウェイ(GW)からポリシー サービス ISE ノードに向かうクライアント トラフィックのホップの 1 つです。他のルータと同様に、インライン ポスチャも、サブネット 10.20.80.0/24 および 10.20.90.0/24 に対して、VPN ゲートウェイへのスタティック ルートが設定済みであることを必要とします。ネットワークの信頼側にある企業ルータも、同じサブネットに対して、インライン ポスチャ ノードへのスタティック ルートが設定済みであることを必要とします。

図 10-2 インライン ポスチャ ルーテッド モードの構成

 

インライン ポスチャ ブリッジ モード

ブリッジ モードでは、インライン ポスチャ ノードは標準のイーサネット ブリッジとして動作します。通常、この設定は、非信頼ネットワーク内にゲートウェイがすでに配置されていて、既存の設定を変更したくない場合に使用します。

図 10-3 に、WLC から Cisco ISE ネットワーク(ポリシー サービス ISE によって管理される)へのレイヤ 2 クライアント トラフィックに対してブリッジとして動作するインライン ポスチャ ノードを示します。この設定では、インライン ポスチャは、アドレス解決プロトコル(ARP)ブロードキャストに応答し、ARP ブロードキャストを適切な VLAN に送信できる、サブネット 10.20.80.0/24 と 10.20.90.0/24 に対応するサブネット エントリを必要とします。

図 10-3 インライン ポスチャ ブリッジ モードの設定

 

 

インライン ポスチャ ノードがブリッジ モードのときは、次のことが当てはまります。

インライン ポスチャ eth0 と eth1 の IP アドレスを同一にすることができます

ブリッジド サブネットのすべてのエンド デバイスは、非信頼ネットワーク上に配置する必要があります。

インライン ポスチャのベスト プラクティス

ここでは、インライン ポスチャを分散環境に展開するためのベスト プラクティスの概念を紹介します。

フィルタを使用してアクセス権限を定義する

フィルタを設定するときは、次のことを考慮してください。

一般的な実装では、インライン ポスチャは、ネットワークにアクセスしようとしているエンドポイントに認証要件を適用します。デバイスとサブネットのフィルタは、WLC や VPN のデバイスを許可するか拒否するかを決定するのに使用されます。

特定のデバイスでは、認証、ポスチャ評価、ロール割り当てのうち 1 つ以上をバイパスしたい場合があります。バイパスするデバイスのタイプの一般的な例としては、プリンタ、IP Phone、サーバ、非クライアント マシン、ネットワーク デバイスがあります。

インライン ポスチャによって、デバイスの MAC アドレス、MAC と IP アドレスの組み合わせ、またはサブネット アドレスが照合され、デバイスに対してバイパス機能が有効になっているかどうかが判断されます。管理者は、ポリシー適用をバイパスするか、強制的にアクセスをブロックするかを選択できます。


警告 直接接続された適応型セキュリティ アプライアンス(ASA)VPN デバイスの MAC アドレスを MAC フィルタで設定するときは、必ず IP アドレスも入力してください。IP アドレス(任意)が追加されていない場合は、VPN クライアントがポリシー適用をバイパスできてしまいます。このようにバイパスできるのは、VPN がクライアントにとってはレイヤ 3 のホップであり、デバイスは自身の MAC アドレスを送信元アドレスとして使用して、インライン ポスチャ ノードに向けてパケットをネットワークで送信するからです。


管理対象サブネットおよびスタティック ルートの設定

インライン ポスチャの管理対象サブネットを設定するときは、次のことを考慮してください。

エンドポイント用の管理対象サブネットは、インライン ポスチャ ノードに近接するレイヤ 2 で設定します。たとえば、インライン ポスチャ ノードの非信頼インターフェイスにパケットを直接配信する WLC などです。

エンドポイント用のサブネットを、インライン ポスチャ ノードに近接するレイヤ 2 で設定するには、インライン ポスチャ用の管理対象サブネットも設定する必要があります。このように設定すると、非信頼インターフェイス上のクライアント デバイスに対する適切な VLAN ID を指定して、インライン ポスチャ ノードからアドレス解決プロトコル(ARP)クエリーを送信できるようになります。非信頼(認証)VLAN を、管理対象サブネットの [VLAN ID] フィールドで設定してください。

インライン ポスチャ用の管理対象サブネットを設定するときは、IP アドレスを設定し、サブネット アドレスは設定しないでください。このようにすれば、インライン ポスチャから送信される ARP リクエストの送信元 IP アドレスが正しく設定されます。

インライン ポスチャ ノードの信頼側のサブネットは、非信頼側のサブネットと似たものにしないでください。

管理 ISE ノードとインライン ポスチャ ノードが同一のサブネット上に存在していてはなりません。ただし、スタティック ルートを定義済みの場合を除きます。

インライン ポスチャのスタティック ルートを設定するときは、次のことを考慮してください。

インライン ポスチャ ノードからの距離が 1 ホップよりも大きい(レイヤ 3)エンドポイントに対しては、スタティック ルートを設定します。

VPN アドレス プールによく見られるすべてのダウンストリーム ホスト ネットワークには、スタティック ルートを設定してください。

ハイ アベイラビリティ

ハイ アベイラビリティを実現するためにインライン ポスチャを設定するときは、次のことを考慮してください。

サービス IP(仮想 IP と呼ばれることもあります)を、インライン ポスチャの両側のインターフェイス、つまり信頼側(eth0)と非信頼側(eth1)のそれぞれに割り当てます。

リンク検出 IP アドレスを、信頼(eth0)と非信頼(eth1)それぞれのインターフェイスに対して指定します。リンク検出は、任意設定としてユーザ インターフェイスに表示されますが、設定することを強く推奨します。

スタンドアロン モードとハイ アベイラビリティ

インライン ポスチャ展開に関する意思決定において最も重要なものの 1 つが、単一のスタンドアロン ノードを展開するか、ハイ アベイラビリティを確実にするためのアクティブ/スタンバイ ペアを展開するかです。

スタンドアロンのインライン ポスチャ ノードとは、単独でサービスを実行するインライン ポスチャ ノードであり、他のすべてのノードからは独立して動作します。単一のスタンドアロン インライン ポスチャ ノードの展開を選択するのは、たとえばネットワークが小規模であり、冗長性が大きな問題にならない場合です。

インライン ポスチャのハイ アベイラビリティ展開は、1 つのアクティブ/スタンバイ ペアとして設定された 2 つのインライン ポスチャ ノードから成ります。アクティブ ノードが RADIUS プロキシとして機能し、すべてのネットワーク パケットを転送します。このノードで障害が発生した時点で、スタンバイ ノードがその処理を引き継ぎます。アクティブ ノードが正しく機能している間は、スタンバイ ノードはパッシブのままです。ただし、アクティブ ノードに問題が生じた場合は、スタンバイ ノードがインライン ポスチャ機能の実行を引き継ぎます。

図 10-2 は単純なインライン ポスチャ スタンドアロン設定であり、クライアントのアクセスは WLC や VPN のデバイスを通過します。図 10-4 はルーテッド モードのハイ アベイラビリティ インライン ポスチャ設定を示しています。

インライン ポスチャのハイ アベイラビリティ

インライン ポスチャのステートレス ハイ アベイラビリティ展開には、1 つのアクティブ/スタンバイ ペア ノード設定があります。スタンバイ ノードはバックアップ ユニットとして機能し、インターフェイス間のパケット転送は行いません。ステートレスとは、アクティブ ノードにより認証および許可されたセッションがフェールオーバーの発生後に再び自動的に許可されることを意味します。

スタンバイ ノードは、ハートビート プロトコルを使用してアクティブ ノードをモニタリングします(eth2 と eth3 のインターフェイスを使用)。このプロトコルは、2 つのノード間でメッセージが一定の間隔で送信されることを必要とします。ハートビートが停止するか、割り当てられた時間内に応答がない場合は、フェールオーバーが発生し、復元アクションが実行されます。


) インライン ポスチャのハイ アベイラビリティ設定においてハートビート プロトコルがアクティブであるときは、ハイ アベイラビリティ ペアの両ノードの eth2 インターフェイスがイーサネット ケーブルで直接接続されている必要があります。同様に、2 つのノードの eth3 インターフェイスがイーサネット ケーブルで直接接続されている必要があります。図 10-4 は、この原則を表したものです。


ハートビートのモニタリングに加えて、リンク検証メカニズムを使用することもできます(使用することを強く推奨します)。リンク検出が使用されているときは、インライン ポスチャの信頼と非信頼のインターフェイスそれぞれが、外部 IP アドレスに対して ping を実行します。両方のノードが外部 IP アドレスに対して ping を実行できない場合は、フェールオーバーが発生します。ただし、ノードの一方が到達不可能になった場合は、機能している方のノードが自動的にアクティブ ノードになります。

フェールオーバーが発生すると、次のことが行われます。

1. スタンバイのインライン ポスチャ ノードが、サービス IP アドレス(SIP)を引き継ぎます。

2. フェールオーバーが発生した場合は、障害が発生したノードを管理者が修復し、必要に応じて以前の設定に戻します。

障害が発生したノードがオンラインに戻ったら、手動同期操作を実行してノードに最新の情報を反映する必要があります。インライン ポスチャ ノードの同期操作を実行する方法については、「インライン ポスチャ ノードの同期」を参照してください。

3. アクティブ セッションは自動的に再認証および許可されます。

ハイ アベイラビリティのキー ポイント

「プライマリ」と「セカンダリ」という用語の意味は、インライン ポスチャのハイ アベイラビリティに関する場合と Cisco ISE ノード関連の場合とで異なります。インライン ポスチャのハイ アベイラビリティの場合、プライマリとセカンダリは、アクティブ状態を引き継ぐデバイスと、競合が発生した場合(たとえば、両方のノードが同時に起動したとき)にスタンバイの役割を担うデバイスを指します。

アクティブとスタンバイという用語は、ハイ アベイラビリティの状態を表します。プライマリまたはセカンダリのインライン ポスチャ ノードは、アクティブとスタンバイのどちらの状態にもなることができます。

ハートビートが両方のインライン ポスチャのハイ アベイラビリティ ノードで同時に停止した場合は、その結果としてパーティショニング状態となることがあります。パーティショニング状態とは、両方のノードが他方を完全に停止しているものと見なし、両方がアクティブ コントロールを引き継ごうとしている状態です。

セカンダリのインライン ポスチャ ノードは読み取り専用であり、どのような種類の設定にも(ハイ アベイラビリティであっても)使用することはできません。

インライン ポスチャのハイ アベイラビリティ ペア(プライマリとセカンダリ)の両ノードの eth2 および eth3 インターフェイスは、ハートビート プロトコル交換を使用して通信することによって、ノードの健全性を特定します。ハートビートを機能させるには、プライマリ インライン ポスチャ ノードの eth2 インターフェイスを、イーサネット ケーブルを使用してセカンダリ ノードの eth2 インターフェイスに接続する必要があります。同様に、プライマリ インライン ポスチャ ノードの eth3 インターフェイスを、イーサネット ケーブルを使用してセカンダリ ノードの eth3 インターフェイスに接続する必要があります。図 10-4 は、この原則を表したものです。


) ハートビートとは、インライン ポスチャのハイ アベイラビリティ ペアの一方のノードから他方のノードに、一定の間隔で送信されるメッセージです。ハートビートが受信されない状態が長時間にわたる場合(通常はハートビート間隔の数個分)は、ハートビートを送信しているはずのノードで障害が発生したと見なされます。障害が発生したのがプライマリのインライン ポスチャ ノードの場合は、セカンダリ ノードに引き継がれるので、サービスの中断は発生しません。


ハイ アベイラビリティ ペアのノードの 1 つが停止しているときに、ただ 1 つのアクティブなノードに対して設定変更が行われた場合に、停止していたノードが起動したときに新しい設定を自動的に反映するメカニズムはありません。アクティブ ノードでのインライン ポスチャのハイ アベイラビリティ ユーザ インターフェイスにある [ピア ノードを同期(Sync-up Peer Node)] ボタンを使用すると、スタンバイ ノードを、アクティブ ノードからの最新のインライン ポスチャ データベースと手動で同期できます。

ハイ アベイラビリティを実現するためには、2 つのインライン ポスチャ ノードを登録してから、プライマリとなるノードを 1 つ選択し、ハイ アベイラビリティを有効にします。詳細については、「ハイ アベイラビリティを実現するためのインライン ポスチャの設定」を参照してください。

ルーテッド モードでのインライン ポスチャのハイ アベイラビリティの設定

インライン ポスチャのハイ アベイラビリティ(HA)ペアは、1 つのクラスタとして構成される、2 つの物理的インライン ポスチャ ノードから成ります。これらのノードの専用ケーブルで接続された eth2 と eth3 インターフェイスの間にはハートビート リンクが存在します。各インライン ポスチャ ノードの、信頼と非信頼のイーサネット インターフェイスそれぞれに専用の物理 IP アドレスがありますが、それとは別のサービス IP アドレスをクラスタ全体に割り当てる必要があります。


) サービス IP アドレス(仮想 IP アドレスと呼ばれることもあります)は、RADIUS 認証に必要になります。SIP は、アクティブ/スタンバイ ペアの両ノードの、信頼と非信頼の両方のインターフェイスに割り当てます。したがって、SIP がクラスタのアドレスとなり、このクラスタをネットワークの他の部分に対して、1 つのエンティティとして表すことができます。


たとえば、IPEP1 の非信頼 IP アドレスを 10.20.70.101 とし、IPEP2 の非信頼 IP アドレスを 10.20.70.102 とします。しかし、ネットワークの非信頼側での両ノードのサービス IP アドレスは、10.20.70.100 となります。ペアのうち、アクティブ インライン ポスチャ ノードは、どの時点でも、ネットワークの非信頼側のサービス IP アドレスを担当しています。同じことが、ネットワークの信頼側にも当てはまります。

図 10-4 に、インライン ポスチャのハイ アベイラビリティのルーテッド モード設定の例を示します。2 つのノードの eth2 と eth3 のインターフェイスを接続する専用ケーブルは、アクティブ ノードの障害の有無を調べるハートビート通信のためのものです。

図 10-4 インライン ポスチャ ルーテッド モードのハイ アベイラビリティの例

 

ブリッジ モードでのインライン ポスチャのハイ アベイラビリティの設定

ブリッジ モードのインライン ポスチャのハイ アベイラビリティの設定のガイドラインは次のとおりです。

インライン ポスチャ eth0 と eth1 の IP アドレスは、同一サブネット内であることが必要です。IP アドレスを同一にすることを推奨します。

ネットワークの信頼側にあるデバイスの IP アドレスが属するサブネットが、ブリッジ モードのインライン ポスチャによって管理されている場合は、明示的なスタティック ルートがインライン ポスチャ ノードにおいて設定されている必要があります。この設定が必要になるのは、デフォルトではインライン ポスチャが管理するサブネット(ユーザ インターフェイスの [管理対象サブネット(Managed Subnets)] ページで設定されます)全体がネットワークの非信頼側にあると見なされるからです。

分散展開でのインライン ポスチャのガイドライン

分散展開でのインライン ポスチャ ノードの設定を開始する前に、次の内容を理解していることを確認してください。

1. インライン ポスチャは、管理、ポリシー サービス、またはモニタリングのペルソナと同時に実行することはできないため、専用ノードとなります。

2. インライン ポスチャ ノードは、ネットワーク上のプライマリ管理 ISE ノードに対するセカンダリ ノードとして登録する必要があります。

3. スタンドアロンのインライン ポスチャ ノードを展開することも、アクティブ/スタンバイ ペアを展開することもできます。

4. ネットワークで一度に最大 2 つのインライン ポスチャ ノードを設定できます。インライン ポスチャのハイ アベイラビリティ アクティブ/スタンバイ ペアの場合は、2 つのノードを設定します。一方のノードがプライマリとして指定され、他方のノードがセカンダリ ノードとして指定されます。両方のノードが同時に起動した場合、プライマリ ノードの方が優先してアクティブ ノードになります。

5. インライン ポスチャ アクティブ/スタンバイ ペア設定の場合は、この機能に関連する設定作業はすべて、ペアのアクティブ ノードから行う必要があります。Cisco ISE ユーザ インターフェイスでは、スタンバイ ノードのユーザ インターフェイスには基本的な設定テーブルのみが表示されます。

6. インライン ポスチャのアクティブ ノード設定をピア スタンバイ ノードに同期させる処理は、アクティブ ノードの [フェールオーバー(Failover)] タブから実行できます。詳細については、「インライン ポスチャ ノードの同期」を参照してください。


) WLC 認証、許可、アカウンティング(AAA)サーバ(Cisco 2100 または 4400 シリーズ ワイヤレス LAN コントローラ)がネットワーク上にある場合は、RADIUS 認証サーバのタイムアウト値を 30 秒以上に設定する必要があります。この最小値以上であれば、RADIUS フェールオーバーが、インライン ポスチャと組み合わせたときに確実に動作します。詳細については、WLC サーバ ハードウェアのマニュアルを参照してください。


インライン ポスチャ ノードの展開

インライン ポスチャ ノードを設定するための最初のプロセスは、スタンドアロン ノードの場合でも、アクティブ/スタンバイ ペアの場合でも同じです。ここでは、Cisco ISE ネットワーク上でインライン ポスチャ ノードを設定するために実行が必要な一連の作業について説明します。

インライン ポスチャ ノードを設定するには、次の作業を実行します。

1. 「ブリッジまたはルーテッド モードでのインライン ポスチャの設定」

2. 「インライン ポスチャのダウンロード可能アクセス コントロール リストの作成」

3. 「インライン ポスチャ ノード プロファイルの作成」

4. 「インライン ポスチャ許可ポリシーの作成」

ブリッジまたはルーテッド モードでのインライン ポスチャの設定

インライン ポスチャ ノードを Cisco ISE ネットワークに導入するには、初めにインライン ポスチャ ノードをプライマリのポリシー サービス ISE ノードに登録し、インライン ポスチャの設定を指定してから、許可プロファイルとポリシーを作成する必要があります。これによって、インライン ポスチャのゲートキーピング ポリシーが確立します。

インライン ポスチャ ノードは RADIUS プロキシであり、RADIUS サーバとして NAD と連携し、これにより NAD(VPN ゲートウェイ、WLC)は RADIUS クライアントとなります。プロキシとしてのインライン ポスチャは、クライアントとしてポリシー サービス ISE ノードと、これにより、ポリシー サービス ISE ノードはインライン ポスチャの RADIUS サーバとなります。


) 次に示す手順を完了すると、インライン ポスチャ ノードに対応する NAD エントリが自動的に作成されます。スタンドアロン ノードの場合は、そのノードの IP アドレスが使用されます。HA ペアの場合は、アクティブ ノードのサービス IP アドレスが使用されます。


インライン ポスチャ用の証明書設定のガイドライン

管理ノードとインライン ポスチャ ノード間の通信をセキュリティ保護するには、相互認証が必要です。つまり、インライン ポスチャ ノードが自身のアイデンティティを管理ノードに対して証明するだけでなく、その逆も必要です。これらのノード上で証明書を設定するときは、次のガイドラインに従ってください。

管理ノードとインライン ポスチャ ノードのローカル証明書の属性の組み合わせによっては、相互認証が動作しなくなることがあります。

その属性は次のとおりです。

キーの拡張用途(EKU):サーバ認証

キーの拡張用途(EKU):クライアント認証

Netscape 証明書タイプ:SSL サーバ認証

Netscape 証明書タイプ:SSL クライアント認証

管理証明書については、次の組み合わせを推奨します。

EKU 属性は、両方とも無効にするか(インライン ポスチャ証明書で両方の EKU 属性が無効の場合)、両方とも有効にします(インライン ポスチャ証明書でサーバ属性が有効の場合)。

Netscape 証明書タイプ属性は、両方とも無効にするか、両方とも有効にします。

インライン ポスチャ証明書については、次の組み合わせを推奨します。

EKU 属性は、両方とも無効にするか、両方とも有効にするか、サーバ属性のみを有効にします。

Netscape 証明書タイプ属性は、両方とも無効にするか、両方とも有効にするか、サーバ属性のみを有効にします。

自己署名ローカル証明書が管理ノードとインライン ポスチャ ノードで使用されている場合は、管理ノードの自己署名証明書をインライン ポスチャ ノードの信頼リストにインストールする必要があります。加えて、プライマリとセカンダリの両方の管理ノードが展開内にある場合は、両方の管理ノードの自己署名証明書をインライン ポスチャ ノードの信頼リストにインストールする必要があります。

CA 署名付きのローカル証明書が管理ノードとインライン ポスチャ ノードで使用されている場合、相互認証は正しく動作します。この場合は、登録の前に署名 CA の証明書が管理ノードにインストールされ、この証明書がインライン ポスチャ ノードに複製されます。

管理ノードとインライン ポスチャ ノード間の通信をセキュリティ保護するために CA 発行のキーが使用される場合は、インライン ポスチャ ノードを登録する前に、管理ノードからの公開キー(CA 証明書)をインライン ポスチャ ノードの CA 証明書リストに追加する必要があります。

前提条件

プライマリ管理 ISE ノードに対する管理権限が必要です。

「インライン ポスチャ用の証明書設定のガイドライン」の説明に従って、これを適用します。

「セカンダリ ノードの登録および設定」の説明に従って、インライン ポスチャ ノードをプライマリ管理 ISE ノードに登録します。Cisco ISE 分散システムのメンバーとして動作するには、すべてのノードがプライマリ管理 ISE ノードに登録されている必要があります。必ず [インライン ポスチャ(Inline Posture)] チェックボックスをオンにしてください。[管理(Administration)]、[モニタリング(Monitoring)]、および [ポリシー サービス(Policy Service)] の各チェックボックスは自動的にオフになります。


) インライン ポスチャ ノードを登録すると、システムが再起動します。同様に、インフラストラクチャ設定、たとえば eth1 IP アドレス、インライン ポスチャ モード、およびハイ アベイラビリティを変更した場合も、システム再起動が必要です。再起動は自動的に行われます。ただし、CLI から手動でノードを再起動するには、application stop ise コマンドと application start ise コマンドを使用してください。


RADIUS 設定は必須です。最低でも 1 つのクライアントと 1 つのサーバ設定が必要です。この手順を完了するには、両側の対応する共有秘密情報が必要です。

インストールに必要なすべての設定情報を手元に用意してください。たとえば、信頼と非信頼の IP アドレス、サービス IP アドレス、他の Cisco ISE ノードの IP アドレス、RADIUS 設定用の共有秘密、管理 VLAN ID、WLC、または VPN IP アドレスなどです。必要な情報のリストについては、システム設計者に確認してください。


警告 直接接続された ASA VPN デバイスの MAC アドレスを MAC フィルタで設定するときは、必ず IP アドレスも入力してください。IP アドレス(任意)が追加されていない場合は、VPN クライアントがポリシー適用をバイパスできてしまいます。このようにアクセスできるのは、VPN がクライアントにとってはレイヤ 3 のホップであり、デバイスは自身の MAC アドレスを送信元アドレスとして使用して、インライン ポスチャ ノードに向けてパケットをネットワークで送信するからです。


インライン ポスチャをブリッジ モードまたはルーテッド モードで設定するには、次の手順を実行します。


ステップ 1 プライマリ管理 ISE ノードで、[管理(Administration)] > [システム(System)] > [展開(Deployment)] を選択します。

ステップ 2 [展開(Deployment)] ナビゲーション ペインの [展開(Deployment)] をクリックしてから、[展開ノード(Deployment Nodes)] ページでインライン ポスチャ ノードのチェックボックスをオンにして [編集(Edit)] をクリックします。

ステップ 3 [全般設定(General Settings)] タブの [インライン PEP(Inline PEP)] チェックボックスをオンにします。[管理(Administration)]、[モニタリング(Monitoring)]、および [ポリシー サービス(Policy Service)] の各チェックボックスは自動的にオフになります。

図 10-5 インライン ポスチャ ノードの編集

 

 

タブは、[全般設定(General Settings)]、[基本情報(Basic Information)]、[展開モード(Deployment Modes)]、[フィルタ(Filters)]、[RADIUS 設定(Radius Config)]、[管理対象サブネット(Managed Subnets)]、[スタティック ルート(Static Routes)]、[ロギング(Logging)]、および [フェールオーバー(Failover)] に変化します。


) 新規登録されたインライン ポスチャ ノードは、デフォルト IP アドレス 192.168.1.100、サブネット マスク 255.255.255.0、およびデフォルト ゲートウェイ 192.168.1.1 が設定されています。これらの値は、実際の展開に合わせてステップ 3 で変更してください。


ステップ 4 [基本情報(Basic Information)] タブをクリックし、次のオプションに対して適切な情報を入力します。

[時刻同期サーバ(Time Sync Server)]:[プライマリ(Primary)]、[セカンダリ(Secondary)]、[ターシャリ(Tertiary)]

[DNS サーバ(DNS Server)]:[プライマリ(Primary)]、[セカンダリ(Secondary)]、[ターシャリ(Tertiary)]

[信頼インターフェイス(保護されたネットワークへの)(Trusted Interface (to protected network))]:[管理 VLAN ID を設定(Set Management VLAN ID)](他のすべての情報は自動的に入力されます)

[非信頼インターフェイス(管理ネットワークへの)(Untrusted Interface (to management network))]:[IP アドレス(IP Address)]、[サブネット マスク(Subnet Mask)]、[デフォルト ゲートウェイ(Default Gateway)]、[管理 VLAN ID を設定(Set Management VLAN ID)]

図 10-6 は、ブリッジ モード設定の例です。図 10-7 は、ルーテッド モード設定の例です。

図 10-6 [基本情報(Basic Information)](ブリッジ)

 

図 10-7 [基本情報(Basic Information)](ルーテッド)

 

 

ステップ 5 [展開モード(Deployment Modes)] タブをクリックします。新規登録されたインライン ポスチャ ノードは、メンテナンス モードとなっています。実稼働目的の場合は、次のいずれかを選択してください。

[ルーテッド モード(Routed Mode)]:インライン ポスチャのためのルータ(hop in the wire)機能を実行します。図 10-8 に、ルーテッド モードの例を示します。

[ブリッジ モード(Bridged Mode)]:インライン ポスチャによって管理されるサブネットのための、VLAN マッピング機能を実行します。[ブリッジ モード(Bridged Mode)] チェックボックスをオンにした後で、[非信頼ネットワーク(Untrusted Network)] と [信頼ネットワーク(Trusted Network)] の VLAN ID 情報を入力します。図 10-9 に、ブリッジ モードの例を示します。

VLAN マッピングの場合は、次の作業も行ってください。

管理トラフィックのためのマッピングを追加します。信頼ネットワークと非信頼ネットワークの該当する VLAN ID を入力してください。

クライアント トラフィックのためのマッピングを追加します。信頼ネットワークと非信頼ネットワークの該当する VLAN ID を入力してください。

図 10-8 [展開モード(Deployment Modes)](ルーテッド)

 

図 10-9 [展開モード(Deployment Modes)](ブリッジ)

 

 

ステップ 6 [フィルタ(Filters)] タブをクリックし、クライアント デバイスのサブネット アドレスとサブネット マスクを入力するか、フィルタリングするデバイスの MAC アドレスと IP アドレスを入力します。

MAC とサブネットのフィルタを使用すると、ネットワークの非信頼側にある特定のエンドポイントやデバイスについて、インライン ポスチャ適用をバイパスすることができます。たとえば、VPN または WLC の管理トラフィックがインライン ポスチャを通過できるようにする必要がある場合に、その NAD を Cisco ISE のポリシー適用対象外とします。その NAD の MAC アドレスと IP アドレスをフィルタで指定しておくと、インライン ポスチャ経由でユーザ インターフェイスや設定ターミナルに、制約なくアクセスできるようになります。

[MAC フィルタ(MAC filters)]:ポリシーを適用しない MAC アドレスと IP アドレスの一方または両方

[サブネット フィルタ(Subnet Filters)]:ポリシーを適用しないサブネット アドレスとサブネット マスク


) セキュリティ上の理由から、MAC フィルタ エントリでは常に IP アドレスを MAC アドレスとともに指定することを推奨します。詳細については、「前提条件」の「警告」を参照してください。


図 10-10 フィルタ

 

 

ステップ 7 [RADIUS 設定(RADIUS Config)] タブをクリックし、次のそれぞれの IP アドレスと共有秘密を入力します。

プライマリ サーバ:プライマリ RADIUS サーバ、通常はポリシー サービス ISE ノード

セカンダリ サーバ:任意

クライアント:クライアントの代理としてアクセスをリクエストするデバイス、WLC または VPN


) Cisco ISE Release 1.1.1 では、WLC ローミングはサポートされません。


RADIUS 設定は必須です。インライン ポスチャには、最低でも 1 つのクライアントと 1 つのサーバの設定が必要です。RADIUS プロキシ サービスの詳細については、「プロキシ サービス」を参照してください。

図 10-11 RADIUS の設定

 

 

ステップ 8 (任意)[KeyWrap を有効にする(Enable KeyWrap)] チェックボックスをオンにして、次の認証設定を指定します。

キー暗号キー(Key Encryption Key)

メッセージ オーセンティケータ コード キー(Message Authenticator Code Key)

[キー入力形式(Key Input Format)]:[ASCII] または [16 進数(Hexadecimal)]

展開においてワイヤレス LAN 技術を利用している場合は、RADIUS サーバからネットワーク アクセス ポイントへの送信のセキュリティを保護する必要があります。キーラップの属性によって、保護が強化され、柔軟性が高まります。

ステップ 9 [管理対象サブネット(Managed Subnets)] タブをクリックし、それぞれの管理対象サブネットについて次の情報を入力します。

IP アドレス

サブネット マスク

VLAN ID

説明

インライン ポスチャ ノードと近接するレイヤ 2 にあるエンドポイントのサブネットについては(たとえば WLC)、管理対象サブネットを設定する必要があります。このように設定するには、管理対象サブネットと同じサブネットにある未使用の IP アドレスが 1 つとサブネットの VLAN(ある場合)が必要になります。複数の管理対象サブネット エントリを指定できます。

図 10-12 管理対象サブネット

 

 

ステップ 10 [スタティック ルート(Static Routes)] タブをクリックしてから、サブネット アドレスとサブネット マスクを入力し、[インターフェイス タイプ(Interface Type)] ドロップダウン リストで [信頼(Trusted)] または [非信頼(Untrusted)] を選択します。このステップを、実際の設定に合わせて必要なだけ繰り返します。

Cisco ISE の制御下にあるエンドポイントのサブネットがインライン ポスチャ ノードからレイヤ 3 分離れている場合は、スタティック ルート エントリが必要です。たとえば、VPN ゲートウェイ デバイス(管理対象サブネット トラフィックをインライン ポスチャ非信頼インターフェイスに送信するデバイス)が 2 ホップ離れている場合は、そのクライアント サブネットに対してはインライン ポスチャのためのスタティック ルートが定義されている必要があります。信頼側のネットワークは、トラフィックをインライン ポスチャ信頼インターフェイスに送信すべきということを認識している必要があります。

図 10-13 スタティック ルート

 

 

ステップ 11 [ロギング(Logging)] タブをクリックし、ロギング サーバ(一般的にはモニタリング ISE ノード)の IP アドレスとポート番号を入力します。

インライン ポスチャのイベントをログに記録するための IP アドレスとポート(デフォルト 20514)は必須です。この要件が守られていれば、インライン ポスチャ ノードの動作ステータスが Cisco ISE ダッシュボードの [システム概要(System Summary)] ダッシュレットに表示されるようになり、そのノードに関するその他のログ情報も利用できるようになります。

図 10-14 ロギング

 

 

ステップ 12 [保存(Save)] をクリックします。ノードが再起動します。

ステップ 13 自動生成されたインライン ポスチャ NAD リスティングを確認するには、[管理(Administration)] > [ネットワーク リソース(Network Resources)] > [デフォルト デバイス(Default Device)] に移動します。

スタンドアロン ノードの場合は、そのノードの IP アドレスが使用されます。HA ペアの場合は、アクティブ ノードのサービス IP アドレスが使用されます。


 

次の手順

インライン ポスチャ ノードのセットアップを完了するには、次の手順を実行し、不明、準拠、非準拠の 3 つの DACL、許可プロファイル、および許可ポリシー ルールを作成します。

1. 「インライン ポスチャのダウンロード可能アクセス コントロール リストの作成」

2. 「インライン ポスチャ ノード プロファイルの作成」


) 適切なダウンロード可能アクセス コントロール リスト(DACL)を、対応するプロファイルに関連付けることが重要です。たとえば、不明 DACL には不明許可プロファイルを関連付けます。


3. 「インライン ポスチャ許可ポリシーの作成」

トラブルシューティング項目

「プライマリとセカンダリの Inline Posture ノードのハートビート リンクが機能しない」

インライン ポスチャのダウンロード可能アクセス コントロール リストの作成

ダウンロード可能アクセス コントロール リスト(DACL)とは、許可プロファイルの構築ブロックであり、プロファイルはこのリストで定められたルールに従うことになります。アクセス コントロール リスト(ACL)は、望ましくないトラフィックがネットワークに入るのを防ぐためのものであり、具体的には送信元と宛先の IP アドレス、トランスポート プロトコル、およびその他の変数を、RADIUS プロトコルを使用してフィルタリングします。

名前付き権限オブジェクトとして作成した DACL を許可プロファイルに追加します。その後、これらの許可プロファイルを許可ポリシーの結果として指定します。DACL の詳細については、「許可ポリシーについて」を参照してください。

図 10-15 インライン ポスチャ DACL

 


) 各管理者アカウントには、1 つ以上の管理ロールが割り当てられています。アカウントに割り当てられているロールに応じて、次の手順で説明する操作を実行できる場合とできない場合があり、説明しているオプションが表示される場合と表示されない場合があります。


インライン ポスチャ用の DACL を作成するには、次の手順を実行します。


ステップ 1 「ダウンロード可能 ACL の権限の設定」の説明に従って、次の DACL を作成します。

ipep-unknown(ポスチャ前):1 つ以上の ACL を使用して、サプリカントとポリシー サービスに、ポスチャ評価のための相互アクセスを許可します。この DACL を使用すると、認証を通過していないユーザをブロックまたは隔離することができます。図 10-16 の例を参照してください。

ipep-compliant(すべて許可): permit ip any any を使用します。

ipep-noncompliant(すべて拒否): deny ip any any を使用します。

図 10-16 インライン ポスチャ DACL コンプライアンス不明

 

図 10-17 インライン ポスチャ DACL 準拠

 

 

ステップ 2 DACL を保存してから、「インライン ポスチャ ノード プロファイルの作成」に進みます。


 

トラブルシューティング項目

「プライマリとセカンダリの Inline Posture ノードのハートビート リンクが機能しない」

インライン ポスチャ ノード プロファイルの作成

ここでは、インライン ポスチャ用の許可プロファイルを作成する方法を説明します。インライン ポスチャ許可プロファイルを 3 つ作成し、さらに NAD 用の許可プロファイルを 1 つ作成します。詳細については、「Cisco ISE 許可ポリシーおよびプロファイル」を参照してください。

すべてのインライン ポスチャ インバウンド プロファイルは自動的に、 cisco-av-pair=ipep-authz=true に設定されます。これで、インライン ポスチャ ノードによって確実にそのルールが適用されるようになります(プロキシとしてそのまま NAD にプロキシするのではなく)。 URL リダイレクト はクライアント プロビジョニングに欠かせないものであり、エージェント検出リダイレクションにも必要です。

NAD とインライン ポスチャのための許可プロファイルを作成するには、次の手順を実行します。


ステップ 1 「新しい標準許可プロファイルの権限の作成および設定」の説明に従って、NAD 許可プロファイルを作成します。


) RADIUS 応答メッセージ = NAD プロファイルと設定すると、NAD プロファイルがインライン ポスチャの RADIUS ログ メッセージに表示されるようになります。この設定は、後でトラブルシューティングするときに役立つ可能性があります。


ステップ 2 「インライン ポスチャのダウンロード可能アクセス コントロール リストの作成」で作成した DACL に対応する、インライン ポスチャの許可プロファイルを作成します。

図 10-18 インライン ポスチャのプロファイル

 

 

次の許可プロファイルのそれぞれについて、適切な DACL を指定します。

Unknown-Compliant(ポスチャ前):このプロファイルには、URL リダイレクトを入力する必要があります。

[インライン ポスチャ許可プロファイル(Inline Posture Authorization Profiles)] ページで、「Unknown-Compliant」という DACL 名をドロップダウン リストから選択し、次に示す URL リダイレクトをテキスト フィールドに入力して [送信(Submit)] をクリックします。

url-redirect=https://ip:8443/guestportal/gateway?sessionld=SessionValue&Action=cpp

この URL リダイレクトは、[属性詳細(Attributes Details)] フィールドに表示されます。

図 10-19 Unknown-Compliant 許可プロファイル

 

 

ユーザは、エージェントをダウンロードしてインストールするための Web ページにリダイレクトされます。このエージェントが、ユーザのシステムをスキャンします。システムが合格の場合、ユーザにはフル アクセス権が自動的に付与されます。システムが不合格の場合は、ユーザはアクセスを拒否されます。

IPEP-Compliant(すべて許可)

IPEP-Noncompliant(すべて拒否)

図 10-20 Non-Compliant 許可プロファイル

 

 

ステップ 3 許可プロファイルをそれぞれ保存したら、「インライン ポスチャ許可ポリシーの作成」に進みます。


 

インライン ポスチャ許可ポリシーの作成

許可ポリシーは、ネットワークおよびそのリソースに対するアクセスを制御する手段となります。Cisco ISE では、多数の許可ポリシーを定義できるようになっています。

許可ポリシーを定義する要素は、ポリシー ルールを作成するときに参照されます。選択した条件と属性によって、許可プロファイルが定義されます。図 10-21 に、VPN および WLC のアクセスに必要な許可ルールを示します。

図 10-21 VPN および WLC のアクセスのための許可ルール

 

 

許可ポリシーの詳細については、「Cisco ISE 許可ポリシーおよびプロファイル」を参照してください。

許可ポリシーを作成するには、次の手順を実行します。


ステップ 1 「新しい許可ポリシーの作成」の説明に従って、許可ポリシーを作成します。その際、デフォルト ルールはそのままにしてください。

ステップ 2 不明ポスチャ ステータス ルールを次のとおりに作成します。

[ID グループ(Identity Group)]:[任意(Any)]

[条件(Condition)]:[Session:PostureStatus] [等しい(EQUALS)] = [不明(Unknown)]

[権限(Permissions)]:ipep-unknown-compliant + nad-authorization-profile

ステップ 3 準拠ポスチャ ルールを次のとおりに作成します。

[ID グループ(Identity Group)]:[任意(Any)]

[条件(Condition)]:[Session:PostureStatus] [等しい(EQUALS)] = [準拠(Compliant)]

[権限(Permissions)]:ipep-compliant + nad-authorization-profile

ステップ 4 非準拠ポスチャ ルールを次のとおりに作成します。

[ID グループ(Identity Group)]:[任意(Any)]

[条件(Condition)]:[Session:PostureStatus] [等しい(EQUALS)] = [非準拠(Noncompliant)]

[権限(Permissions)]:ipep-noncompliant + nad-authorization-profile

ステップ 5 ポリシーを保存します。インライン ポスチャ ノードの設定プロセスは、これで完了です。


 

次の手順

「RADIUS クライアントとしてのインライン ポスチャの追加」を実行します。

ハイ アベイラビリティを実現するためのインライン ポスチャの設定

ここでは、ハイ アベイラビリティを実現するために 2 つのインライン ポスチャ ノードを設定する方法を説明します。一方のノードがペアのプライマリ ユニットとして指定され、デフォルトではこのノードがアクティブになります。他方がセカンダリ ノードとなり、デフォルトでスタンバイ ユニットとなります。

ハイ アベイラビリティ ノードのフェールオーバーが発生すると、スタンバイ ノードがサービス IP アドレスを引き継ぎます。このプロセスが発生した後で、管理者は障害が発生したインライン ポスチャ ノードを修復する必要があります。必要に応じて、以前の設定に戻します。ハイ アベイラビリティ フェールオーバーはステートレスであるため、すべてのアクティブ セッションは自動的に、フェールオーバーの発生後に再び許可されます。

この項では、次のトピックを扱います。

「ハイ アベイラビリティ ペアの設定」

「インライン ポスチャ ノードの同期」

ハイ アベイラビリティ ペアの設定

ここでは、2 つの登録済みインライン ポスチャ ノードの間にハイ アベイラビリティ関係を定義する方法を説明します。

ここに示す例では、ブリッジ モードのハイ アベイラビリティ ペアに使用されるサービス IP アドレスは、インライン ポスチャ ノードの物理 IP アドレスとは異なるものであり、実質的にクラスタが作成されます。このクラスタは 1 つのユニットとして、サービス IP アドレスを使用して WLC と相互作用します。このような理由から、サービス IP は信頼と非信頼それぞれのネットワークに対して定義されます。

プライマリとセカンダリのインライン ポスチャ ノードの設定


警告 ハイ アベイラビリティ ペアの両方のノードが、同一のモード(ブリッジまたはルータ)を使用する必要があります。混合モードは、インライン ポスチャのハイ アベイラビリティ ペアではサポートされません。


前提条件

プライマリ管理 ISE ノードに対する管理権限が必要です。

インライン ポスチャ ノード 2 つが正常に設定され、Cisco ISE ネットワーク上で登録されている必要があります。「ブリッジまたはルーテッド モードでのインライン ポスチャの設定」を参照してください。

インライン ポスチャのハイ アベイラビリティ ペア(プライマリとセカンダリ)の両ノードの eth2 および eth3 インターフェイスは、ハートビート プロトコル交換を使用して通信することによって、ノードの健全性を特定します。ハートビートを機能させるには、プライマリ インライン ポスチャ ノードの eth2 インターフェイスを、イーサネット ケーブルを使用してセカンダリ ノードの eth2 インターフェイスに接続する必要があります。同様に、プライマリ インライン ポスチャ ノードの eth3 インターフェイスを、イーサネット ケーブルを使用してセカンダリ ノードの eth3 インターフェイスに接続する必要があります。図 10-4 は、この原則を表したものです。

RADIUS 用に、サービス IP アドレスが必要です。このアドレスは、この手順の中で、インライン ポスチャ アクティブ/スタンバイ クラスタの信頼と非信頼の両方のインターフェイスに割り当てるためのものです。

インストールに必要なすべてのネットワーク設定情報を手元に用意してください。たとえば、両方のインライン ポスチャ ノードの IP アドレス、クラスタのサービス IP アドレス、ポリシー サービス ISE ノードの IP アドレス、および RADIUS 設定用の共有秘密です。他にも、管理対象 VLAN ID、WLC IP アドレス、VLAN IP アドレスなどが必要になることがあります。必要な情報のリストについては、システム設計者に確認してください。

インライン ポスチャのハイ アベイラビリティ ペアを設定するには、次の手順を実行します。


ステップ 1 プライマリ管理 ISE ノードで、[管理(Administration)] > [システム(System)] > [展開(Deployment)] を選択します。

ステップ 2 [展開(Deployment)] ナビゲーション ペインの [展開(Deployment)] リンクをクリックします。次に、[展開ノード(Deployment Nodes)] ページで、プライマリ ノードとして指定するインライン ポスチャ ノードの横のチェックボックスをオンにして [編集(Edit)] をクリックします。

ステップ 3 [全般設定(General Settings)] タブで、ノード名を確認し、[インライン PEP(Inline PEP)] チェックボックスがオンであることを確認してから、[HA 役割(HA Role)] ドロップダウン リストで [アクティブ(Active)] を選択します。

ステップ 4 [フェールオーバー(Failover)] タブをクリックし、[HA 有効(HA Enabled)] チェックボックスをオンにします。

ステップ 5 ドロップダウン リストから [HA ピア ノード(HA Peer Node)] を選択します。選択可能なスタンドアロンのインライン ポスチャ ノードが一覧表示されます。

ステップ 6 アクティブ ノードについて、次の情報を指定します。

a. プライマリ ノードのトラフィック インターフェイスの信頼サービス IP アドレス(eth0)と非信頼サービス IP アドレス(eth1)を入力します。この後のブリッジ モードの例では、同じサービス IP アドレスを信頼と非信頼の両方のネットワークに使用しています。

b. 任意で(ただしベスト プラクティスとして推奨します)、信頼側と非信頼側の両方のリンク検出システム用 IP アドレスを入力します。このアドレスは、通常はポリシー サービス ISE ノードの IP アドレスです。アクティブとスタンバイの両方のノードが常に、ポリシー サービス ISE ノードに到達可能であることが必要であるからです。

次に、[リンク検出タイムアウト(Link-Detect Timeout)] の値を入力します。デフォルト値である 30 秒を推奨します。ただし、最大値はありません。

リンク検出とは、インライン ポスチャ ノードとポリシー サービス ISE ノードとの通信を確実に維持するための機能です。アクティブ ノードが通知(ping)をポリシー サービス ISE ノードから指定の間隔で受信していない場合は、アクティブ ノードはスタンバイ ノードにフェールオーバーします。

ステップ 7 [ハートビート タイムアウト(Heart Beat Timeout)] の値を入力します。デフォルト値である 30 秒を推奨します。ただし、最大値はありません。

ハートビートとは、2 つのインライン ポスチャ ノードの間で指定の間隔で送信されるメッセージです。ハートビートには、eth2 と eth3 のインターフェイスが使用されます。ハートビートが停止するか、割り当てられた時間内に応答がない場合は、フェールオーバーが発生します。

図 10-22 フェールオーバー

 

 

ステップ 8 ドロップダウン リストから [HA ピア ノード(HA Peer Node)] を選択します。セカンダリ ノードはプライマリ ノードに同期します。

[複製ステータス(Replication Status)]:(表示されるのはセカンダリ ノードの場合のみ)プライマリ ノードからセカンダリ ノードへの差分複製が完了したかどうかを示します。次の状態のいずれかが表示されます。

[失敗(Failed)]:データベースの差分複製に失敗しました。

[進行中(In-Progress)]:データベースの差分複製が現在進行中です。

[完了(Complete)]:データベースの差分複製が完了しました。

[該当なし(Not Applicable)]:ISE ノードがスタンドアロンまたはプライマリ ノードの場合に表示されます。

[同期ステータス(Sync Status)]:(表示されるのはセカンダリ ISE ノードの場合のみ)プライマリ ノードからセカンダリ ノードへの複製が完了したかどうかを示します。複製が行われるのは、ノードをセカンダリとして登録したときや、複製を強制的に実行するために [同期を更新(Syncup)] がクリックされたときです。次の状態のいずれかが表示されます。

[同期完了(Sync Completed)]:データベースの完全複製が完了しました。

[同期進行中(Sync in Progress)]:データベースの完全複製が現在進行中です。

[同期していない(Out of Sync)]:セカンダリ ノードがプライマリ ISE ノードに登録されたときにデータベースがダウンしていました。

[該当なし(Not Applicable)]:ISE ノードがスタンドアロン ノードの場合に表示されます。

ステップ 9 セカンダリ ノードの同期ステータスが「同期していない」になっている場合は、そのノードの隣のチェックボックスをオンにしてから、[同期を更新(Syncup)] をクリックしてデータベースの完全複製を強制的に実行します。


) [同期を更新(Syncup)] オプションを使用して完全複製を強制的に実行する必要があるのは、[同期ステータス(Sync Status)] が [同期していない(Out of Sync)] であるか、[複製ステータス(Replication Status)] が [失敗(Failed)] である場合です。


ステップ 10 [保存(Save)] をクリックします。両方のインライン ポスチャ ノードが再起動します。

ノードが再び起動したときは、指定された設定に応じて、プライマリおよびセカンダリとして設定された状態になっています。ノードの状態を表示するには、ステップ 2 の説明に従って編集するノードを選択してから、[フェールオーバー(Failover)] タブをクリックします。

プライマリ ノードの方が、編集できるオプションが多いことに注意してください。設定の変更はすべて、プライマリ ノードで行われるからです。プライマリ ノードに対して行われた設定変更は自動的に、セカンダリ ノードに反映されます。このような理由から、セカンダリ ノードは読み取り専用となっています。

次の図は、アクティブ プライマリとスタンバイ セカンダリのインライン ポスチャ ノードの [フェールオーバー(Failover)] タブの比較です。

図 10-23 インライン ポスチャ アクティブのオプション

 

図 10-24 インライン ポスチャ スタンバイのオプション

 

 


 

次の手順

「RADIUS クライアントとしてのインライン ポスチャの追加」を実行します。

トラブルシューティング項目

「プライマリとセカンダリの Inline Posture ノードのハートビート リンクが機能しない」

インライン ポスチャ ノードの同期

ここで説明する手順は、2 つのインライン ポスチャ ノードがアクティブ/スタンバイ ペアとして設定済みであることを前提としています。この項の目的は、アクティブ/スタンバイ ペアの一方のノードを他方に同期させる方法を説明することです。

前提条件

「ブリッジまたはルーテッド モードでのインライン ポスチャの設定」の説明に従って 2 つのインライン ポスチャ ノードが正常に設定済みであることが必要です。

「ハイ アベイラビリティ ペアの設定」の説明に従って 2 つのノード間の関係が正常に確立済みであることが必要です。

プライマリ管理 ISE ノードに対する管理権限が必要です。

一方のインライン ポスチャ ノードを他方に同期させるには、次の手順を実行します。


ステップ 1 プライマリ管理 ISE ノードで、[管理(Administration)] > [システム(System)] > [展開(Deployment)] を選択します。

ステップ 2 [展開(Deployment)] ナビゲーション ペインの [展開(Deployment)] リンクをクリックします。

ステップ 3 [展開ノード(Deployment Nodes)] ページで、どのインライン ポスチャ ノードに他方のノードを同期させるかを選択して(通常はアクティブ ノード)その横のチェックボックスをオンにし、[編集(Edit)] アイコンをクリックします。

ステップ 4 [フェールオーバー(Failover)] タブをクリックします。

ステップ 5 [ピア ノードを同期(Sync Peer Node)] をクリックします。

選択したノードからのデータが自動的に、ピア ノードに転送されます。

図 10-25 ピア ノードを同期

 

 


 

トラブルシューティング項目

「プライマリとセカンダリの Inline Posture ノードのハートビート リンクが機能しない」

RADIUS クライアントとしてのインライン ポスチャの追加

スタンドアロン インライン ポスチャ ノードの場合は、信頼 IP アドレスを RADIUS クライアントとして追加する必要があります。ハイ アベイラビリティ ペアの場合は、信頼インターフェイスのサービス IP アドレスを RADIUS クライアントとして追加する必要があります。ここでは、この作業の基本的な手順を説明します。詳細については、「ネットワーク デバイスの管理」を参照してください。

前提条件

該当する項の作業が完了している必要があります。

「インライン ポスチャ ノードの展開」

「ハイ アベイラビリティを実現するためのインライン ポスチャの設定」

インライン ポスチャを RADIUS クライアントとして追加するには、次の手順を実行します。


ステップ 1 [管理(Administration)] > [ネットワーク リソース(Network Resources)] > [ネットワーク デバイス(Network Devices)] を選択します。

ステップ 2 [ネットワーク デバイス(Network Devices)] ナビゲーション パネルの [ネットワーク デバイス(Network Devices)] を選択します。

ステップ 3 デバイスの名前と説明を入力します。

ステップ 4 次のいずれかを実行します。

スタンドアロン インライン ポスチャ ノードの場合は、信頼インターフェイスの IP アドレスを入力します。

ハイ アベイラビリティ ペアの場合は、信頼インターフェイスのサービス IP アドレスを入力します。

ステップ 5 必要に応じて [モデル名(Model Name)] と [ソフトウェア バージョン(Software Version)] に入力します。

ステップ 6 [ネットワーク デバイス グループ(Network Device Group)] では、[場所(Location)] と [デバイス タイプ(Device Type)] を必要に応じて指定します。

ステップ 7 [認証設定(Authentication Settings)] チェックボックスをオンにして、共有秘密を入力します。

ステップ 8 [保存(Save)] をクリックします。


 

次の手順

「インライン ポスチャ ノードのモニタリング」

インライン ポスチャ ノードのモニタリング

展開済みのインライン ポスチャ ノードの健全性のモニタリングは、管理 ISE ノードで実行されている Cisco ISE ダッシュボードから行うことができます。インライン ポスチャ ノードは、[システム概要(System Summary)] ダッシュレットに表示されます。チェック マーク付きの緑色のアイコンは、システムが正常に動作していることを示します。黄色のアイコンは警告を示し、赤色のアイコンは深刻なシステム障害を示します。スパークラインは、CPU とメモリの使用率および遅延の経時変化を示します。データ表示範囲は、過去 24 時間と過去 60 分から選択できます。

健全性のアイコンにマウス カーソルを合わせると、クイック ビュー ダイアログに、システム健全性の詳細情報が表示されます。

図 10-26 システム概要のステータス クイック ビュー

 

 

詳細については、「Cisco ISE ダッシュボードのモニタリング」を参照してください。

展開からのインライン ポスチャ ノードの削除

インライン ポスチャ ノードを展開から削除するには、初めにそのノードをメンテナンス モードに変更する必要があります。これで、登録を解除できます。メンテナンス モードとはニュートラル状態であり、そのノードをスムーズにネットワークに、または展開から移動することができます。

前提条件

プライマリ管理 ISE ノードに対する管理権限が必要です。

特定のノードを展開から削除するには、次の手順を実行します。


ステップ 1 プライマリ管理 ISE ノードで、[管理(Administration)] > [システム(System)] > [展開(Deployment)] を選択します。

ステップ 2 左側のペインの [展開(Deployment)] をクリックし、展開から削除するインライン ポスチャ ノードの横のチェックボックスをオンにして [編集(Edit)] をクリックします。

ステップ 3 [展開モード(Deployment Modes)] タブをクリックします。

ステップ 4 [メンテナンス モード(Maintenance Mode)] オプション ボタンをクリックしてから [保存(Save)] をクリックします。

ステップ 5 左側のペインの [展開(Deployment)] をクリックし、展開から削除するインライン ポスチャ ノードの横のチェックボックスをオンにして [登録解除(Deregister)] をクリックします。

「選択されているアイテムを登録解除しますか?(Are you sure you want to deregister the selected items?)」というメッセージが表示されます。

ステップ 6 [OK] をクリックすると、そのノードが展開から削除されます。


 

トラブルシューティング項目

「プライマリとセカンダリの Inline Posture ノードのハートビート リンクが機能しない」

リモート アクセス VPN の使用例

ここでは、インライン ポスチャ ノードを Cisco ISE ネットワーク内の VPN デバイス(たとえば ASA)とともに使用する方法を説明します。図 10-27 に、インライン ポスチャ ノードをリモート VPN アクセス用に使用する Cisco ISE 展開を示します。この図の iPEP という用語はインライン ポスチャ ノードを指し、PDP はポリシー サービス ノードを指します。VPN ゲートウェイからのトラフィックはすべて、インライン ポスチャ ノードを通過する必要があります。確実に Cisco ISE によってポリシーを適用し、ネットワークのセキュリティを保護するためです。

図 10-27 インライン ポスチャ ノードを使用する Cisco ISE 展開

 

プロセス フロー

1. リモート ユーザは VPN ゲートウェイ(ASA)に対する認証を、RADIUS プロトコルを使用して行います。

2. RADIUS クライアントである ASA は、認証リクエストを AAA サーバ(インライン ポスチャ ノード)に送信します。

3. RADIUS プロキシであるインライン ポスチャ ノードは、この RADIUS 認証リクエストを、RADIUS サーバの役割を持つ Cisco ISE ノード(ポリシー サービス ノード)にリレーします。

4. Cisco ISE ポリシー サービス ノードは、設定済みの ID ストアを使用してリモート ユーザの認証を行い、RADIUS 応答をインライン ポスチャ ノードに返します。この応答は、ASA(ネットワーク アクセス デバイス(NAD))にリレーされます。

5. ユーザに適用される許可ポリシーに基づいて、ポリシー サービス ノードは該当する属性をインライン ポスチャ ノードに返します。さらに、ASA に返すこともできます。

6. インライン ポスチャ ノード プロファイルと NAD(標準許可プロファイル)のどちらについても、許可ポリシー ルール エントリごとに別の許可プロファイルを参照することができます。

a. インライン ポスチャ ノード プロファイル:インライン ポスチャ ノードに適用される RADIUS 属性を指定します。たとえば、クライアント プロビジョニング サービスへのリダイレクト用の URL や、インライン ポスチャ ノードによるポリシー適用のためのダウンロード可能 ACL(dACL)です。

b. 標準許可プロファイル:NAD(この例では ASA)のための任意の RADIUS 属性を指定します。

7. 許可ポリシーによる判定の結果、エンドポイントがポスチャ ポリシーに「非準拠」である場合や、ポスチャ ステータスが「不明」の場合は、ポリシー サービス ノードから URL リダイレクト属性値がインライン ポスチャ ノードに返されます。このときに、許可されるトラフィックを指定する dACL も返されます。dACL によって拒否された HTTP/HTTPS トラフィックはすべて、指定の URL にリダイレクトされます。

8. ポスチャが「準拠」になると、再許可が行われてポリシー サービス ノードから新しい dACL がインライン ポスチャ ノードに送信されます。これで、内部ネットワークへのユーザ特権アクセスができるようになります。

インライン ポスチャ ノードを使用する Cisco ISE 展開の設定

前提条件

インライン ポスチャ ノードやそのダウンストリーム ネットワークとの間で送受信されるトラフィックが正しくルーティングまたはスイッチングされるように、ネットワーク インフラストラクチャが設定されていることを確認します。

リモート VPN アクセス用にインライン ポスチャ ノードを使用する Cisco ISE 展開を設定するには、次の手順を実行します。


ステップ 1 スタンドアロンの Cisco ISE ノードを設定します。詳細については、「Cisco ISE ノードの設定」を参照してください。

ステップ 2 このスタンドアロン Cisco ISE ノードをインライン ポスチャ ノードとして、既存のプライマリ管理 ISE ノードに登録し、インライン ポスチャ ノードの設定をプライマリ管理 ISE ノードから行います。詳細については、「インライン ポスチャ ノードの展開」を参照してください。

ステップ 3 必要に応じて、もう 1 つのインライン ポスチャ ノードを設定し、アクティブ/スタンバイ ペアを設定します。詳細については、「ハイ アベイラビリティを実現するためのインライン ポスチャの設定」を参照してください。

ステップ 4 ポリシー サービス ISE ノード(PDP)がインライン ポスチャ ノードの RADIUS サーバとなるように設定します。インライン ポスチャ ノードで設定されているものと同一の RADIUS 共有秘密を、ポリシー サービス ISE ノードでも設定します。

ステップ 5 インライン ポスチャ ノードによって使用される許可プロファイル(インライン ポスチャ ノード プロファイル)を設定します。NAD に使用するための標準許可プロファイルを設定することもできます。詳細については、「インライン ポスチャ ノード プロファイルの作成」および「インライン ポスチャのダウンロード可能アクセス コントロール リストの作成」を参照してください。

ステップ 6 アイデンティティとポスチャ ステータスに基づいてインライン ポスチャ ノード プロファイルをリモート VPN ユーザに適用するための許可ポリシーを設定します。詳細については、「インライン ポスチャ許可ポリシーの作成」を参照してください。

ステップ 7 VPN ゲートウェイの内部 IP アドレスを RADIUS クライアントとして、インライン ポスチャ ノードの RADIUS 設定に、NAD(この例では ASA)の RADIUS 共有秘密とともに追加します。

ステップ 8 RADIUS サーバとして設定済みのインライン ポスチャ ノードとの間で RADIUS 認証および許可を行うための、VPN ゲートウェイ(ASA)を設定します。手順は次のとおりです。

a. [ポリシー(Policy)] > [認証(Authentication)] を選択します。

b. ユーザ レコードに記録されている ID ソースに対してユーザを認証するように、デフォルト ルールが設定されていることを確認します。

c. [保存(Save)] をクリックします。