はじめに
このドキュメントでは、Cisco Catalyst 9800シリーズワイヤレスコントローラで802.1Xセキュリティを使用してWLANを設定する方法について説明します。
前提条件
要件
次の項目に関する知識があることが推奨されます。
使用するコンポーネント
このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。
- Catalyst 9800ワイヤレスコントローラシリーズ(Catalyst 9800-CL)
- Cisco IOS® XEジブラルタル17.3.x
- Cisco ISE 3.0
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
設定
ネットワーク図
WLC の設定
9800 WLCでのAAAの設定
GUI:
ステップ 1:RADIUSサーバを宣言します。 Configuration > Security > AAA > Servers / Groups > RADIUS > Servers > + Add に移動し、RADIUSサーバ情報を入力します。
今後、中央Web認証(または認可変更[CoA]を必要とするあらゆる種類のセキュリティ)を使用する予定の場合は、CoAのサポートが有効になっていることを確認します。
ステップ 2:RADIUSサーバをRADIUSグループに追加します。[グループに名前を付ける]に移 Configuration > Security > AAA > Servers / Groups > RADIUS > Server Groups > + Add. 動し、以前に作成したサーバーを Assigned Servers.
ステップ 3:認証方式リストを作成します。移動先 Configuration > Security > AAA > AAA Method List > Authentication > + Add.
次の情報を入力します。
CLI:
# config t # aaa new-model # radius server <radius-server-name> # address ipv4 <radius-server-ip> auth-port 1812 acct-port 1813 # timeout 300 # retransmit 3 # key <shared-key> # exit # aaa group server radius <radius-grp-name> # server name <radius-server-name> # exit
# aaa server radius dynamic-author
# client <radius-server-ip> server-key <shared-key>
# aaa authentication dot1x <dot1x-list-name> group <radius-grp-name>
AAAデッドサーバ検出についての注意
RADIUSサーバを設定したら、それが「ALIVE」と見なされるかどうかを確認できます。
#show aaa servers | s WNCD Platform State from WNCD (1) : current UP Platform State from WNCD (2) : current UP Platform State from WNCD (3) : current UP Platform State from WNCD (4) : current UP ...
特に複数のRADIUSサーバを使用する場合、WLCで dead criteria, および deadtime を設定できます。
#radius-server dead-criteria time 5 tries 3 #radius-server deadtime 5
注: dead criteria は、RADIUSサーバをデッドとしてマークするために使用される基準です。構成は次のとおりです。 1.コントローラが最後にRADIUSサーバから有効なパケットを受信してから、サーバが停止したとマークされるまでの経過時間を示すタイムアウト(秒単位)。2.カウンタ。RADIUSサーバが停止とマークされるまでにコントローラで発生する必要がある連続タイムアウトの数を表します。
注: deadtimeは、dead基準によってサーバがdeadとしてマークされた後、サーバがdeadステータスのままになる時間(分単位)を指定します。デッドタイムが経過すると、コントローラはサーバをUP(ALIVE)としてマークし、登録されたクライアントに状態変更を通知します。状態がUPとマークされた後もサーバに到達できず、デッド基準を満たしている場合、サーバはデッドタイムインターバルの間に再びデッドとマークされます。
WLANプロファイルの設定
GUI:
ステップ 1:WLANを作成します。Configuration > Wireless > WLANs > + Addの順に移動し、必要に応じてネットワークを設定します。
ステップ 2:WLAN情報を入力します
ステップ 3: Security
タブに移動し、必要なセキュリティ方式を選択します。この例では、WPA2 + 802.1xです。
ステップ 4: Security > AAA タブで、手順3で作成した認証方式を「9800 WLCでのAAA設定」セクションから選択します。
CLI:
# config t # wlan <profile-name> <wlan-id> <ssid-name> # security dot1x authentication-list <dot1x-list-name> # no shutdown
ポリシープロファイルの設定
ポリシープロファイル内では、他の設定(アクセスコントロールリスト[ACL]、Quality of Service [QoS]、モビリティアンカー、タイマーなど)の中から、クライアントに割り当てるVLANを決定できます。
デフォルトのポリシープロファイルを使用することも、新しいプロファイルを作成することもできます。
GUI:
Configuration > Tags & Profiles > Policy Profile の順に移動し、default-policy-profile を設定するか、新しいプロファイルを作成します。
プロファイルを有効にします。
また、アクセスポイント(AP)がローカルモードの場合、ポリシープロファイルで中央スイッチングと中央認証が有効になっていることを確認します。
Access Policiesタブで、クライアントを割り当てる必要があるVLANを選択します。
VLAN割り当てなどの属性をアクセス承認で返すようにISEを設定する場合は、 Advanced タブでAAA Overrideを有効にしてください。
CLI:
# config # wireless profile policy <policy-profile-name>
# aaa-override # central switching # description "<description>" # vlan <vlanID-or-VLAN_name> # no shutdown
ポリシータグの設定
Policy Tagは、SSIDとポリシープロファイルをリンクするために使用されます。新しいポリシータグを作成するか、default-policy タグを使用します。
注:default-policy-tagは、1 ~ 16のWLAN IDを持つSSIDをdefault-policy-profileに自動的にマッピングします。変更も削除もできません。 ID 17以上のWLANがある場合、default-policy-tagは使用できません。
GUI:
必要に応じて、Configugation > Tags & Profiles > Tags > Policy に移動し、新しいプロファイルを追加します。
WLAN プロファイルを目的のポリシープロファイルにリンクします。
CLI:
# config t # wireless tag policy <policy-tag-name> # wlan <profile-name> policy <policy-profile-name>
ポリシータグの割り当て
必要な AP にポリシータグを割り当てます。
GUI:
タグを1つのAPに割り当てるには、関連するポリシータグを割り Configuration > Wireless > Access Points > AP Name > General Tags, 当てるように移動し、 Update & Apply to Device.
注:APのポリシータグが変更されると、9800 WLCへの関連付けがドロップされ、数分後に元に戻ることに注意してください。
複数のAPに同じポリシータグを割り当てるには、 Configuration > Wireless Setup > Advanced > Start Now > Apply.
タグを割り当てるAPを選択して、 + Tag APs
ポリシー、サイト、およびRFに適用できるタグを選択し、Save およびApply to Deviceを
クリックします
CLI:
# config t # ap <ethernet-mac-addr> # policy-tag <policy-tag-name> # end
ISE 設定
ISEでのWLCの宣言
ステップ 1:ISEコンソールを開き、図に示すように Administration > Network Resources > Network Devices > Add に移動します。
ステップ2.ネットワークデバイスを設定します。
必要に応じて、モデル名、ソフトウェアバージョン、説明を指定し、デバイスタイプ、ロケーション、またはWLCに基づいてネットワークデバイスグループを割り当てることができます。
このIPアドレスは、認証要求を送信するWLCインターフェイスに対応しています。デフォルトでは、次の図に示すように管理インターフェイスになります。
の Network Device Groups 詳細については、『Cisco Identity Services Engine管理者ガイド』の「ネットワークデバイスの管理」の章の「ネットワークデバイスグループ」を参照してください。
ISE での新しいユーザの作成
ステップ 1:図 Administration > Identity Management > Identities > Users > Add に示すように移動します。
ステップ2.ユーザの情報を入力します。この例では、このユーザはALL_ACCOUNTSというグループに属していますが、図に示すように必要に応じて調整できます。
認証プロファイルの作成
Authorization Profile は、条件が一致したときに返される一連の属性で構成されます。許可プロファイルは、クライアントがネットワークにアクセスできるかどうか、アクセスコントロールリスト(ACL)をプッシュするかどうか、VLANオーバーライドなどのパラメータを決定します。次の例に示す認可プロファイルは、クライアントのaccess acceptを送信し、クライアントをVLAN 1416に割り当てます。
ステップ 1:に移動 Policy > Policy Elements > Results > Authorization > Authorization Profiles し、 Add ボタンをクリックします。
ステップ 2:図に示すように、値を入力します。ここでは、VLANなどのAAAオーバーライド属性を例として返すことができます。WLC 9800は、VLAN IDまたは名前を使用するトンネル属性64、65、81を受け入れ、 AirSpace-Interface-Name 属性の使用も受け入れます。
ポリシーセットの作成
ポリシーセットは、認証ルールと許可ルールの集合を定義します。ポリシーを作成するには、 Policy > Policy Setsに移動し、リストの最初のポリシーセットの歯車をクリックして、次の図に示すように Insert new row above を選択します。
名前を設定し、このポリシーセットの条件を作成します。この例では、条件はWLCから到達するトラフィックと一致することを指定します。
Radius:NAS-IP-Address EQUALS X.X.X.X // X.X.X.X is the WLC IP address
Allowed Protocols / Server Sequenceの下で Default Network Access が選択されていることを確認します。
認証ポリシーの作成
認証ポリシーと認可ポリシーを設定するには、ポリシーセットの設定を入力する必要があります。これは、 Policy Set 行の右側にある青い矢印をクリックすると実行できます。
認証ポリシーは、ユーザのクレデンシャルが正しいかどうかを確認(ユーザが本当に本人であることを確認)するために使用されます。認証ポリシーの作 Authenticaton Policy, 成の下で、次の図に示すように設定します。この例で使用するポリシーの条件は次のとおりです。
RADIUS:Called-Station-ID ENDS_WITH <SSID> // <SSID> is the SSID of your WLAN
また、この認証ポリシーの Use タブでInternal Usersを選択します。
許可ポリシーの作成
同じページで、 Authorization Policy に移動
し、新しいページを作成します。この許可ポリシーの条件は次のとおりです。
RADIUS:Called-Station-ID ENDS_WITH <SSID> // <SSID> is the SSID of your WLAN
このポリシーのタ Result > Profiles ブで、以前に作成し Authorization Profile たを選択します。これにより、ユーザが認証されると、ISEは正しい属性をWLCに送信します。
この時点で、WLCとISEのすべての設定が完了したので、クライアントとの接続を試行できます。
ISE許可プロトコルポリシーの詳細については、『Cisco Identity Services Engine Administrator Guide』の「Manage Authentication Policies」の章を参照してください。
ISEアイデンティティソースの詳細については、『Cisco Identity Services Engine Administrator Guide: Identity Sources』の「Manage Users and External Identity Sources」の章を参照してください。
確認
次のコマンドを使用して、現在の設定を確認できます。
# show run wlan // WLAN configuration # show run aaa // AAA configuration (server, server group, methods) # show aaa servers // Configured AAA servers # show ap config general // AP's configurations # show ap name <ap-name> config general // Detailed configuration of specific AP
# show ap tag summary // Tag information for AP'S
# show wlan { summary | id | name | all } // WLAN details
# show wireless tag policy detailed <policy-tag name> // Detailed information on given policy tag
# show wireless profile policy detailed <policy-profile name>// Detailed information on given policy profile
トラブルシュート
注:外部ロードバランサの使用には問題はありません。ただし、calling-station-id RADIUS属性を使用して、ロードバランサがクライアントごとに動作することを確認してください。UDP送信元ポートに依存するメカニズムは、9800からのRADIUS要求のバランシングではサポートされていません。
WLCでのトラブルシューティング
WLC 9800には常時トレース機能があります。これにより、クライアント接続に関連するすべてのエラー、警告、および通知レベルのメッセージが継続的にログに記録され、発生後にインシデントまたは障害状態のログを表示できます。
生成されるログの量によって異なりますが、通常は数時間から数日に戻ることができます。
9800 WLCがデフォルトで収集したトレースを表示するには、SSH/Telnetで9800 WLCに接続し、次の手順を実行します(セッションをテキストファイルに記録していることを確認します)。
ステップ 1:WLCの現在の時刻を確認して、問題が発生した時刻までログを追跡できるようにします。
# show clock
ステップ 2:システム設定に従って、WLCバッファまたは外部syslogからsyslogを収集します。これにより、システムの正常性とエラー(発生している場合)をすぐに確認できます。
# show logging
ステップ 3:デバッグ条件が有効になっているかどうかを確認します。
# show debugging IOSXE Conditional Debug Configs: Conditional Debug Global State: Stop IOSXE Packet Tracing Configs: Packet Infra debugs: Ip Address Port ------------------------------------------------------|----------
注:条件が一覧表示されている場合は、有効な条件(MACアドレス、IPアドレスなど)に遭遇するすべてのプロセスについて、トレースがデバッグレベルで記録されていることを意味します。これにより、ログの量が増加します。そのため、アクティブにデバッグを行っていない場合は、すべての条件をクリアすることを推奨します。
ステップ 4:テスト対象のMACアドレスがステップ3の条件としてリストされていないとすると、特定のMACアドレスのalways-on notice levelトレースを収集します。
# show logging profile wireless filter { mac | ip } { <aaaa.bbbb.cccc> | <a.b.c.d> } to-file always-on-<FILENAME.txt>
セッションの内容を表示するか、ファイルを外部TFTPサーバにコピーできます。
# more bootflash:always-on-<FILENAME.txt>
or
# copy bootflash:always-on-<FILENAME.txt> tftp://a.b.c.d/path/always-on-<FILENAME.txt>
条件付きデバッグとラジオアクティブトレース
常時接続トレースで、調査中の問題のトリガーを判別するのに十分な情報が得られない場合は、条件付きデバッグを有効にして、無線アクティブ(RA)トレースをキャプチャできます。これにより、指定された条件(この場合はクライアントMACアドレス)と対話するすべてのプロセスにデバッグレベルのトレースが提供されます。これは、GUIまたはCLIを使用して実行できます。
CLI:
条件付きデバッグを有効にするには、次の手順を実行します。
ステップ 5:有効なデバッグ条件がないことを確認します。
# clear platform condition all
手順 6:監視するワイヤレスクライアントのMACアドレスのデバッグ条件を有効にします。
このコマンドは、指定されたMACアドレスを30分間(1800秒)モニタし始めます。オプションでこの時間を最大2085978494秒まで増やすことができます。
# debug wireless mac <aaaa.bbbb.cccc> {monitor-time <seconds>}
注:複数のクライアントを同時にモニタするには、MACアドレスごとにdebug wireless mac <aaaa.bbbb.cccc>コマンドを実行します。
注:ターミナルセッションでは、すべてが後で表示できるように内部でバッファされるため、クライアントアクティビティの出力は表示されません。
手順 7:監視する問題または動作を再現します。
ステップ 8:デフォルトまたは設定されたモニタ時間が経過する前に問題が再現した場合は、デバッグを停止します。
# no debug wireless mac <aaaa.bbbb.cccc>
モニター時間が経過するか、debug wireless が停止すると、9800 WLC では次の名前のローカルファイルが生成されます。
ra_trace_MAC_aaaabbbbcccc_HHMMSS.XXX_timezone_DayWeek_Month_Day_year.log
ステップ 9: MAC アドレスアクティビティのファイルを収集します。 ra trace.logを外部サーバにコピーするか、出力を画面に直接表示できます。
RAトレースファイルの名前を確認します。
# dir bootflash: | inc ra_trace
ファイルを外部サーバーにコピーします。
# copy bootflash:ra_trace_MAC_aaaabbbbcccc_HHMMSS.XXX_timezone_DayWeek_Month_Day_year.log tftp://a.b.c.d/ra-FILENAME.txt
内容を表示します。
# more bootflash:ra_trace_MAC_aaaabbbbcccc_HHMMSS.XXX_timezone_DayWeek_Month_Day_year.log
ステップ 10:根本原因がまだ明らかでない場合は、デバッグレベルのログのより詳細なビューである内部ログを収集します。すでに収集されて内部で保存されているデバッグログの詳細を確認するため、クライアントを再度デバッグする必要はありません。
# show logging profile wireless internal filter { mac | ip } { <aaaa.bbbb.cccc> | <a.b.c.d> } to-file ra-internal-<FILENAME>.txt
注:このコマンド出力は、すべてのプロセスのすべてのログレベルのトレースを返し、非常に大量です。これらのトレースを解析する場合は、Cisco TAC にお問い合わせください。
ra-internal-FILENAME.txt を外部サーバーにコピーするか、出力を画面に直接表示できます。
ファイルを外部サーバーにコピーします。
# copy bootflash:ra-internal-<FILENAME>.txt tftp://a.b.c.d/ra-internal-<FILENAME>.txt
内容を表示します。
# more bootflash:ra-internal-<FILENAME>.txt
ステップ 11デバッグ条件を削除します。
# clear platform condition all
注:トラブルシューティングセッションの後は、必ずデバッグ条件を削除してください。
GUI:
ステップ 1: Troubleshooting > Radioactive Trace > + Add に移動して、トラブルシューティングを行うクライアントのMAC/IPアドレスを指定します。
ステップ 2:[Start(スタート)] をクリックします。
ステップ 3:問題を再現します。
ステップ 4: [Stop] をクリックします。
ステップ 5: Generate ボタンをクリックし、ログを取得する時間間隔を選択して、 Apply to Device. In this example, the logs for the last 10 minutes are requested.
手順 6:コンピュータに放射性トレースをダウンロードし、ダウンロードボタンをクリックして検査します。
ISEでのトラブルシューティング
クライアント認証の問題が発生した場合は、ISEサーバでログを確認できます。 Operations > RADIUS > Live Logs に移動すると、認証要求のリスト、一致したポリシーセット、各要求の結果などが表示されます。図に示すように、各行の Details タブの下にある虫眼鏡をクリックすると、詳細が表示されます。