4-3 802.1X — ポートベース認証とEAP / RADIUS

1. 前節の振り返りと本節の内容

前節 4-2 AAA では、ルータやスイッチに SSH / コンソールでログインしてくる管理者を、外部の RADIUS / TACACS+ サーバで認証・認可する AAA (Authentication, Authorization, Accounting) を扱いました。AAA が制御する対象は「機器そのものへのログイン」であり、認証されるのはネットワーク機器を操作する管理者でした。

本節で扱う IEEE 802.1X は、同じ「認証」の枠組みを スイッチのアクセスポートに接続した端末 へ向けます。AAA が機器の vty にログインする管理者を認証していたのに対し、802.1X はスイッチのポートに繋いだ PC・プリンタ・IP 電話などを、ネットワークへ通す前に 認証する仕組みです。認証が済むまでポートは閉じられ、正規の端末だと確認できて初めてポートが開きます。

本節では 802.1X の 3 者構成 (サプリカント / オーセンティケータ / 認証サーバ)、端末とスイッチの間で使う EAPOL とスイッチと認証サーバの間で使う EAP over RADIUS の往復を整理します。CML 上で Catalyst 9000v をオーセンティケータ、Alpine Linux 上の wpa_supplicant をサプリカント、外部 FreeRADIUS を認証サーバとして、未認証ポートの遮断・EAP-MD5 認証成功でのポート authorized 化・MAB フォールバックまでを実機検証します。

2. 802.1X とは — サプリカント・オーセンティケータ・認証サーバ

IEEE 802.1X は、スイッチのポートに接続した端末を認証し、認証が済むまでそのポートを通る通信を遮断する ポートベース認証 (Port-Based Network Access Control) の標準です。認証を通った端末だけがネットワークに参加でき、認証に失敗した端末や未認証の端末はポートで止められます。

802.1X は 3 つの役割で構成されます。役割は以下のとおりです。

• サプリカント (Supplicant) — 認証を受ける 端末 側のソフトウェア。スイッチのポートに接続し、自身の資格情報 (ユーザ名・パスワードや証明書) を提示して認証を求めます。PC の OS 標準機能や本ラボの wpa_supplicant が該当します。
• オーセンティケータ (Authenticator) — 端末が接続する スイッチ (アクセスポート)。ポートの開閉を物理的に制御する装置ですが、認証の可否そのものは判断しません。端末と認証サーバの間で認証メッセージを 中継 する役に徹します。
• 認証サーバ (Authentication Server) — 可否を判定する RADIUS サーバ。オーセンティケータから転送されてきた資格情報を照合し、許可 (Access-Accept) または拒否 (Access-Reject) を返します。

ここで重要なのは、オーセンティケータ (スイッチ) が認証の可否を判断しない 点です。スイッチは端末から受け取った認証メッセージをそのまま認証サーバへ転送し、認証サーバの判定を受けてポートを開閉するだけです。「誰を通すか」を決めるのは認証サーバ、「ポートを開けるか閉じるか」を実行するのがスイッチ、という役割分担になります。前節 4-2 の用語で言えば、スイッチが NAS (Network Access Server)、RADIUS サーバが AAA サーバにあたります。

ポートには認証の状態として unauthorized (未認証) と authorized (認証済み) の 2 つがあります。端末を接続した直後のポートは unauthorized であり、認証用の EAPOL を扱う一方で、端末の通常のデータ通信は遮断します (CDP や STP など一部の制御フレームは実装上ポートを通りますが、利用者のデータ通信は通しません)。認証サーバが許可を返すと、スイッチはポートを authorized へ遷移させ、ここで初めて端末の通常の通信がポートを通れるようになります。

3. EAPOL と EAP over RADIUS — 端末↔スイッチと スイッチ↔サーバ

802.1X の認証メッセージは、端末とスイッチの区間 と スイッチと認証サーバの区間 で、別々の運び方をします。区間ごとに使うプロトコルが異なる点が 802.1X の構造の核心です。

端末とスイッチの間では EAPOL (EAP over LAN) を使います。EAPOL は EAP (Extensible Authentication Protocol) のメッセージを LAN の L2 フレームに載せて運ぶ方式で、IP アドレスを必要としません。未認証の段階ではポートが通常の通信を遮断しており、IP による通信を認証手段として前提にできないため、L2 フレームで認証を進める必要があるからです。EAPOL フレームの宛先には、802.1X 用に予約されたマルチキャスト MAC アドレス 0180.c200.0003 を使います。本ラボの wpa_supplicant のログにも、この宛先 MAC へ EAPOL を送出する様子が現れます。

TX EAPOL: dst=01:80:c2:00:00:03

dst=01:80:c2:00:00:03 が、802.1X 用の予約マルチキャスト MAC 0180.c200.0003 です。端末はこの宛先へ EAPOL フレームを送ることで、スイッチに認証の開始を伝えます。

スイッチと認証サーバの間では、EAP のメッセージを RADIUS の EAP-Message 属性に包んで 運びます。これを EAP over RADIUS と呼びます。スイッチは端末から EAPOL で受け取った EAP メッセージを取り出し、それを RADIUS の Access-Request に詰めて認証サーバへ転送します。逆に認証サーバから返ってきた EAP メッセージは、スイッチが EAPOL に載せ直して端末へ返します。スイッチは EAP の中身を解釈せず、EAPOL と RADIUS の間で EAP メッセージを橋渡しするだけ であり、これが §2 で述べた「スイッチは認証の可否を判断しない」ことの具体的な動作です。

EAP は認証方式そのものではなく、認証方式を運ぶ 枠組み です。実際の認証方式は EAP の上で選択され、本ラボでは EAP-MD5 を使います。EAP-MD5 は、認証サーバが送るチャレンジ (乱数) と端末のパスワード、それに EAP の識別子 (Identifier) を入力として端末が MD5 ハッシュを計算して返し、サーバが同じ計算と照合する チャレンジ＆レスポンス方式 です (PPP CHAP の MD5 と同じ計算で、RFC 3748 が規定します)。パスワードそのものを線上に流さない利点がありますが、サーバ証明書を使わず、端末がサーバを検証する相互認証も行いません。より安全な方式として、サーバ証明書で TLS トンネルを張ってからその中で認証する PEAP や、端末・サーバ双方が証明書を持つ EAP-TLS があり、実運用ではこれらが推奨されます (相互認証の限界は §12 で補足します)。本節は 802.1X の動作原理を最小構成で示すため、証明書を必要としない EAP-MD5 を選んでいます。

4. ラボトポロジ — 端末・スイッチ・RADIUS の 3 者構成

本ラボは、サプリカント (端末)・オーセンティケータ (スイッチ)・認証サーバ (RADIUS) を 1 つずつ並べた最小構成です。Catalyst 9000v をオーセンティケータとし、その 802.1X アクセスポート Gi1/0/1 に、Alpine Linux + wpa_supplicant のサプリカントを直結します。

• SUP (サプリカント / 端末) — Alpine Linux 上の wpa_supplicant を使う本物の端末です。データ用インターフェース eth1 (MAC 5254.006c.bd2d) をスイッチの Gi1/0/1 に直結し、identity に dot1xuser、認証方式に EAP-MD5 を設定して認証を求めます。
• SW (オーセンティケータ / スイッチ) — Catalyst 9000v (IOS-XE 17.15) です。Gi1/0/1 を 802.1X アクセスポート (port-control auto) として設定し、RADIUS への問い合わせは Gi1/0/2 (172.16.1.233) を source として送出します。
• RADIUS (認証サーバ) — 外部の FreeRADIUS (172.16.1.130) です。UDP の認証ポート 1812・課金ポート 1813 で待ち受け、EAP-MD5 の利用者 dot1xuser を登録してあります。

スイッチが RADIUS へ到達できることを、各フェーズに入る前に確認します。スイッチは RADIUS source に指定した Gi1/0/2 (172.16.1.233) を送信元として、RADIUS サーバ (172.16.1.130) へ ping します。

SW#ping 172.16.1.130 source GigabitEthernet1/0/2 repeat 3
...
Packet sent with a source address of 172.16.1.233 
Success rate is 100 percent (3/3), round-trip min/avg/max = 18/21/25 ms

Packet sent with a source address of 172.16.1.233 のとおり、スイッチが Gi1/0/2 を送信元に RADIUS へ 100% 到達できています。この source インターフェースを Gi1/0/2 に固定する理由は本ラボ固有の事情によるもので、§12 で詳述します。

5. 認証フロー — EAPOL-Start から EAP-Success・ポート authorized へ

802.1X の認証は、端末がポートに接続してから authorized になるまで、複数のメッセージを往復します。全体の流れを時間で追うと、次のようになります。

流れを段階で整理します。

1. 未認証ポート — port-control auto を設定したポートは、認証が済むまで unauthorized 状態にあります。この間ポートは利用者の通常のデータフレームを遮断し、認証のための EAPOL フレームを扱います。
2. EAPOL-Start — 端末がスイッチへ EAPOL-Start を送り、認証を開始します。
3. EAP-Request/Identity — スイッチが端末へ識別子を尋ねます。
4. EAP-Response/Identity — 端末が自身の識別子 (dot1xuser) を返します。
5. Access-Request (EAP) — スイッチが端末の EAP メッセージを RADIUS の Access-Request に包んで認証サーバへ中継します。ここから EAP over RADIUS に切り替わります。
6. Access-Challenge (MD5) — RADIUS が EAP-MD5 のチャレンジを返し、スイッチがそれを端末へ中継します。
7. EAP-Response/MD5 → Access-Request — 端末がチャレンジ・パスワード・識別子から計算した MD5 ハッシュを返し、スイッチが再び Access-Request で RADIUS へ中継します。
8. Access-Accept (EAP-Success) — RADIUS がハッシュを照合し、一致すれば Access-Accept に EAP-Success を載せて返します。
9. ポート authorized 化 — スイッチが EAP-Success を受けてポートを authorized へ遷移させ、端末の通信が通り始めます。

このうち、EAPOL の区間 (②③④⑥後半⑦前半) と EAP over RADIUS の区間 (⑤⑥前半⑦後半⑧) を、以降の節でそれぞれ実機の出力で確認します。

6. 802.1X の有効化と未認証ポート

802.1X を有効化したポートが、認証前に端末を遮断する様子を確認します。802.1X はグローバルの dot1x system-auth-control で機能全体を有効化し、アクセスポートごとに認証を有効化します。AAA とオーセンティケータの設定は以下のとおりです。

aaa new-model
aaa authentication dot1x default group RAD-GRP
aaa authorization network default group RAD-GRP
!
radius server RAD1
 address ipv4 172.16.1.130 auth-port 1812 acct-port 1813
 key radlab123
!
aaa group server radius RAD-GRP
 server name RAD1
!
ip radius source-interface GigabitEthernet1/0/2
!
dot1x system-auth-control
!
interface GigabitEthernet1/0/1
 switchport mode access
 authentication port-control auto
 dot1x pae authenticator

設定の要点は以下のとおりです。

• aaa authentication dot1x default group RAD-GRP — 802.1X 認証の問い合わせ先を RADIUS サーバグループ (RAD-GRP) に向けます。前節 4-2 のログイン認証と同じく、認証先を method-list で指定します。
• ip radius source-interface GigabitEthernet1/0/2 — RADIUS パケットの送信元を Gi1/0/2 に固定します。
• dot1x system-auth-control — 機器全体で 802.1X 機能を有効化するグローバルスイッチです。
• authentication port-control auto — アクセスポートを 802.1X 認証の対象にします。auto は「認証結果に従ってポートを開閉する」モードで、認証が済むまで unauthorized です。
• dot1x pae authenticator — このポートのロールをオーセンティケータ (PAE = Port Access Entity) に設定します。

この設定を入れた直後、まだ端末が認証を済ませていない状態でポートの 802.1X 情報を見ると、認証済みクライアントが存在しないことが確認できます。

SW#show dot1x interface GigabitEthernet1/0/1 details
Dot1x Info for GigabitEthernet1/0/1
--------------------------------------------
PAE                       = AUTHENTICATOR
QuietPeriod               = 60
ServerTimeout             = 0
SuppTimeout               = 30
ReAuthMax                 = 2
MaxReq                    = 2
TxPeriod                  = 30

Dot1x Authenticator Client List Empty

SW#show authentication sessions interface GigabitEthernet1/0/1 details
No sessions match supplied criteria.

PAE = AUTHENTICATOR で、このポートがオーセンティケータとして動作していることが分かります。注目箇所は Dot1x Authenticator Client List Empty で、認証を済ませたクライアントが 1 台も存在しないことを示します。続く show authentication sessions も No sessions match supplied criteria. で、このポートに認証セッションがまだ確立していません。この状態のポートは unauthorized であり、端末が EAPOL で認証を進めない限り、通常のデータ通信は遮断されます。

7. 認証成功の実機検証 — EAP-MD5 でポートを authorized 化する

サプリカント (wpa_supplicant) が EAP-MD5 で認証を行い、ポートが authorized になる様子を確認します。wpa_supplicant には identity に dot1xuser、eap に MD5 を設定してあり、起動すると EAPOL で認証を開始します。サプリカント側のログには、EAPOL の送出から EAP-Success の受信までが記録されます。

TX EAPOL: dst=01:80:c2:00:00:03
eth1: RX EAPOL from 52:54:00:27:56:ee
EAP: Received EAP-Success
eth1: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
EAPOL: Supplicant port status: Authorized
EAPOL authentication completed - result=SUCCESS

TX EAPOL: dst=01:80:c2:00:00:03 で端末が予約マルチキャスト MAC へ EAPOL を送出し、RX EAPOL from 52:54:00:27:56:ee でスイッチ (オーセンティケータ) から EAPOL を受信しています。EAP: Received EAP-Success で認証サーバの認証成功 (EAP-Success) を受け取り、EAPOL: Supplicant port status: Authorized でサプリカント側もポートを authorized と認識し、最終的に EAPOL authentication completed - result=SUCCESS で認証が成功で完了しています。

スイッチ側では、このポートに認証セッションが確立し、Status が Authorized になります。

SW#show authentication sessions interface GigabitEthernet1/0/1 details
            Interface:  GigabitEthernet1/0/1
          MAC Address:  5254.006c.bd2d
            User-Name:  dot1xuser
               Status:  Authorized
               Domain:  DATA
       Oper host mode:  single-host
    Common Session ID:  E90110AC0000000E0A85C4C5
       Current Policy:  POLICY_Gi1/0/1

      Security Policy:  Should Secure
      Security Status:  Link Unsecured

       Method           State
        dot1x           Authc Success

MAC Address: 5254.006c.bd2d が認証された端末 (サプリカントの eth1) です。User-Name: dot1xuser で、認証に使われた識別子が記録され、Status: Authorized でポートが認証済みになっています。最下部の dot1x Authc Success は、認証メソッドが dot1x (802.1X) であり、その結果が Authc Success (認証成功) であることを示します。§6 で Dot1x Authenticator Client List Empty だったポートに、認証成功した端末のセッションが確立しています。

オーセンティケータ視点の 802.1X 情報でも、認証成功が確認できます。

SW#show dot1x interface GigabitEthernet1/0/1 details
...
EAP Method                = MD5
Supplicant                = 5254.006c.bd2d
    Auth SM State         = AUTHENTICATED

EAP Method = MD5 で、この認証に使われた EAP の方式が EAP-MD5 であることが分かります。Supplicant = 5254.006c.bd2d が認証された端末の MAC で、Auth SM State = AUTHENTICATED は認証ステートマシン (State Machine) が認証済み状態にあることを示します。ポート単位のサマリでも、ステータスが AUTHORIZED です。

SW#show dot1x all summary
Interface                PAE     Client          Status           
------------------------------------------------------------------
GigabitEthernet1/0/1     AUTH    5254.006c.bd2d  AUTHORIZED

GigabitEthernet1/0/1 AUTH 5254.006c.bd2d AUTHORIZED で、Gi1/0/1 がオーセンティケータ (AUTH) として、端末 5254.006c.bd2d を AUTHORIZED の状態で収容していることが一覧で確認できます。

8. EAP over RADIUS の中身 — スイッチが中継する EAP メッセージ

§7 で端末とスイッチの間の EAPOL を確認しました。本節では、スイッチと認証サーバの間の EAP over RADIUS を、認証サーバ (FreeRADIUS) 側のログで確認します。FreeRADIUS を debug モードで動かすと、スイッチから受け取った Access-Request と、それに返す Access-Challenge / Access-Accept の往復が見えます。

(0) Received Access-Request Id 15 from 172.16.1.233:56971 to 172.16.1.130:1812
(0)   User-Name = "dot1xuser"
(0)   EAP-Message = 0x0201000e01646f74317875736572
(0) eap_md5: Issuing MD5 Challenge
(0) Sent Access-Challenge Id 15 from 172.16.1.130:1812 to 172.16.1.233:56971
(0)   EAP-Message = 0x010200160410ab2afabb18f8d5e56161cc3dc8520279
(1) Received Access-Request Id 16 from 172.16.1.233:56971 to 172.16.1.130:1812
(1)   EAP-Message = 0x020200160410e29f4124153614e633784a64a05d1558
(1) eap: Peer sent packet with method EAP MD5 (4)
(1) Sent Access-Accept Id 16 from 172.16.1.130:1812 to 172.16.1.233:56971
(1)   EAP-Message = 0x03020004
(1)   User-Name = "dot1xuser"

往復が 2 つのトランザクション (0) と (1) に分かれています。流れを読み解きます。

第一に、(0) Received Access-Request ... from 172.16.1.233 で、スイッチ (RADIUS source 172.16.1.233) からの Access-Request を受信しています。この中の EAP-Message = 0x0201000e01646f74317875736572 が、端末の EAP メッセージをそのまま包んだものです。末尾の 646f74317875736572 は ASCII の dot1xuser であり、端末の識別子が EAP-Message 属性として運ばれていることが分かります (先頭の 0201000e が EAP のヘッダで、02=Code(Response) / 01=Identifier / 000e=Length、続く 5 バイト目の 01 が Type=Identity を表します)。

第二に、認証サーバは eap_md5: Issuing MD5 Challenge で MD5 チャレンジを生成し、Sent Access-Challenge でスイッチへ返します。Access-Challenge の EAP-Message (0x0102...) が EAP-MD5 のチャレンジ本体で、これがスイッチ経由で端末へ届きます。

第三に、(1) Received Access-Request で端末が計算した MD5 レスポンスを含む Access-Request を受信し、eap: Peer sent packet with method EAP MD5 (4) で EAP の方式が MD5 (種別番号 4) であることをサーバが認識しています。照合の結果、認証サーバは Sent Access-Accept を返し、その中の EAP-Message = 0x03020004 が EAP-Success です (03 が EAP-Success のコード)。この Access-Accept をスイッチが受けてポートを authorized 化し、§7 でサプリカントが受け取った EAP: Received EAP-Success に対応します。

ここで確認できるのは、スイッチが EAP の中身を作らず、端末の EAP メッセージを RADIUS の EAP-Message 属性に包んで中継しているだけ という構造です。dot1xuser という識別子も MD5 のチャレンジ＆レスポンスも、すべて端末と認証サーバの間の EAP 対話であり、スイッチはその橋渡しに徹しています。これが §2・§3 で述べた「スイッチは認証の可否を判断しない中継役」の実機での裏付けです。

9. 認証失敗の実機検証 — 誤クレデンシャルでポートは unauthorized のまま

認証に失敗したとき、ポートが authorized にならないことを確認します。サプリカントのパスワードを誤った値に変えて認証を試みると、EAP は失敗で終わります。サプリカント側のログは以下のとおりです。

eth1: CTRL-EVENT-EAP-FAILURE EAP authentication failed
EAPOL authentication completed - result=FAILURE

CTRL-EVENT-EAP-FAILURE EAP authentication failed で EAP の認証が失敗し、EAPOL authentication completed - result=FAILURE で認証が失敗 (FAILURE) として完了しています。§7 の成功時が result=SUCCESS だったのに対し、result=FAILURE で終わっている点が対照的です。

このときスイッチ側のポートは authorized になりません。スイッチで show authentication sessions を確認すると、§7 の成功時と同じ端末 (User-Name は dot1xuser) でありながら、状態が異なります。

SW#show authentication sessions interface GigabitEthernet1/0/1 details
            Interface:  GigabitEthernet1/0/1
          MAC Address:  5254.006c.bd2d
            User-Name:  dot1xuser
               Status:  Unauthorized
       Method           State
        dot1x           Stopped

§7 の成功時は Status: Authorized / dot1x Authc Success だったのに対し、失敗時は Status: Unauthorized のままで、認証メソッド dot1x は Stopped (中断) となります。誤った資格情報を提示した端末は、認証サーバが拒否を返すためポートが開かず、通信できません。802.1X は、正規の資格情報を持つ端末だけを通し、それ以外をポートで止める仕組みであることが、成功・失敗の対照で確認できます。

10. MAB — 802.1X を話せない端末を MAC で認証する

ネットワークには、802.1X のサプリカント機能を持たない端末も存在します。古いプリンタや一部の IP 電話・IoT 機器は EAPOL を送らないため、§7 の認証フローに乗れず、ポートで止められてしまいます。こうした端末を救済する仕組みが MAB (MAC Authentication Bypass) です。

MAB は、端末が一定時間 EAPOL を返さないとき、スイッチが端末の 送信元 MAC アドレスを資格情報 (ユーザ名・パスワード) として RADIUS へ問い合わせ、登録済みの MAC であれば許可する方式です。802.1X の認証フロー (サプリカント主導) と違い、MAB は端末が認証に関与せず、スイッチが端末の MAC を代理で RADIUS に提示します。あらかじめ RADIUS に端末の MAC をユーザとして登録しておく必要があります。

本ラボの Catalyst 9000v (IOS-XE 17.15) は IBNS 2.0 (Identity-Based Networking Services 2.0) が既定の認証フレームワークです。IBNS 2.0 では、認証の振る舞いを policy-map type control subscriber という制御ポリシーで記述します。802.1X が失敗・タイムアウトしたときに MAB へフォールバックする設定は、制御ポリシーの認証失敗イベントに MAB を実行する処理を書きます。設定例は以下のとおりです。

interface GigabitEthernet1/0/1
 switchport mode access
 access-session port-control auto
 mab
 dot1x pae authenticator
 service-policy type control subscriber DOT1X_MAB
!
policy-map type control subscriber DOT1X_MAB
 event session-started match-all
  10 class always do-until-failure
   10 authenticate using dot1x priority 10
 event authentication-failure match-all
  10 class DOT1X_NO_RESP do-until-failure
   10 terminate dot1x
   20 authenticate using mab priority 20

event authentication-failure の中で authenticate using mab を書くことで、802.1X が応答を得られなかったときに MAB を実行します。インターフェースの mab が MAB を有効化し、access-session port-control auto がポートを認証対象にします。MAB が成功すると、ポートが authorized になります。

SW#show authentication sessions interface GigabitEthernet1/0/1 details
          MAC Address:  5254.006c.bd2d
            User-Name:  5254006cbd2d
               Status:  Authorized
               Domain:  DATA
       Method           State
        dot1x           Stopped
          mab           Authc Success

注目箇所は User-Name: 5254006cbd2d です。§7 の 802.1X 認証では User-Name が dot1xuser でしたが、MAB では端末の MAC アドレス (5254.006c.bd2d を区切りなしの小文字で表した 5254006cbd2d) がそのまま User-Name になっています。これが MAB の特徴で、端末ではなくスイッチが端末の MAC を資格情報として RADIUS に提示したことを示します。最下部の Method status list では、dot1x Stopped で 802.1X が中断され、mab Authc Success で MAB が認証成功してポートを開いたことが読み取れます。

MAB は 802.1X を話せない端末を収容できる便利な仕組みですが、認証の根拠が MAC アドレスだけ である点に注意が必要です。MAC アドレスは容易に詐称できるため、登録済み端末の MAC を騙る なりすまし に弱いという弱点があります。MAB はあくまで 802.1X を補完する救済策であり、正規端末には可能な限り 802.1X を使い、MAB は対応できない端末に限定するのが運用の原則です。

11. ゲスト VLAN と制限 VLAN — ポートを閉じずに段階収容する

802.1X や MAB で認証されなかった端末を、ポートを完全に閉じる代わりに、限定的なネットワークへ段階的に収容する 仕組みがあります。代表的なものが 2 つあります。

• ゲスト VLAN (guest-vlan) — 802.1X に 無応答 な端末 (サプリカントを持たず EAPOL を一度も送らない端末) を収容する VLAN。EAPOL 応答待ちがタイムアウトした端末を、認証なしで限定的なネットワーク (例: インターネット接続のみ) に通す用途です。MAB を併用している場合は、MAB の MAC 認証にも失敗した端末の収容先として使う構成もあります (MAB はスイッチが端末の MAC を問い合わせる方式であり、端末が応答する認証ではない点に注意します)。
• 制限 VLAN / auth-fail VLAN (restricted-vlan) — 802.1X を話すが 認証に失敗 した端末 (誤クレデンシャルなど) を収容する VLAN。ポートを閉じる代わりに、復旧手段だけが届く隔離ネットワークへ置く運用です。

ゲスト VLAN が「認証に反応しない端末」を、制限 VLAN が「認証に反応したが失敗した端末」を対象とする点が両者の違いです。IBNS 2.0 では、これらの収容も制御ポリシーのイベントで記述します。認証失敗イベントで、サービステンプレート (service-template) を使って特定の VLAN を端末に割り当てる構成が典型です。設定例は以下のとおりです。

service-template RESTRICTED_VLAN
 vlan 200
!
policy-map type control subscriber DOT1X_MAB
 event authentication-failure match-all
  10 class AAA_SVR_DOWN_AUTHZ_FAIL do-until-failure
   10 activate service-template RESTRICTED_VLAN

service-template RESTRICTED_VLAN で VLAN 200 を割り当てるテンプレートを定義し、認証失敗イベントの中で activate service-template によって端末を制限 VLAN へ収容します。ゲスト VLAN も同様に、無反応イベントに対応するクラスでサービステンプレートを当てる形で構成します。

なお、本ラボの CML 環境では、認証失敗から制限 VLAN への収容について、安定した認証セッションの形成を実機で観測できませんでした。設定としては IBNS 2.0 の制御ポリシーとサービステンプレートを投入できますが、CML 上で auth-fail から制限 VLAN へ遷移するセッションを繰り返し再現することができなかったため、本節ではゲスト VLAN・制限 VLAN を 設定例と動作の説明に留めます。実機で確認した authorized セッションは、§7 の 802.1X 認証成功と §10 の MAB 成功の 2 つです。

12. 落とし穴・補足

実機検証で確認した、教科書の記述と実機挙動の対応や運用上の注意点、本ラボ固有の事情を記録します。

1. EAP-MD5 はサーバ証明書を使わず、相互認証もしない — EAP-MD5 はチャレンジ＆レスポンスでパスワードそのものを線上に流さない一方、サーバ証明書を使わないため 端末が認証サーバを検証しません (§3)。これは、偽の認証サーバに端末がチャレンジ＆レスポンスを返してしまうリスクを意味します。本節は 802.1X の動作原理を証明書なしの最小構成で示すために EAP-MD5 を使いましたが、実運用ではサーバ証明書で TLS トンネルを張る PEAP や、双方が証明書を持つ EAP-TLS が推奨されます。EAP は認証方式を運ぶ枠組みであり、要件に応じて方式を選べる点が EAP の柔軟性です。

2. MAB は MAC だけが根拠でなりすましに弱い — MAB は端末の MAC アドレスを資格情報として RADIUS に問い合わせる方式です (§10)。MAC アドレスは詐称が容易なため、登録済み端末の MAC を騙るなりすましを防げません。MAB は 802.1X を話せない端末の救済策であり、正規端末には 802.1X を使い、MAB は対応できない端末に限定するのが原則です。

3. Catalyst 9000v (IOS-XE 17.15) は IBNS 2.0 が既定 — 本ラボの Catalyst 9000v では、認証の振る舞いを policy-map type control subscriber という制御ポリシーで記述する IBNS 2.0 が既定です (§10・§11)。古い記述方式 (legacy) の authentication order dot1x mab だけでは MAB へのフォールバックが期待どおりに動かず、制御ポリシーの event authentication-failure で authenticate using mab を明示することで MAB に落ちました。また、access-session port-control auto を投入すると確認プロンプトが表示されるため、自動化の文脈では legacy 互換の authentication port-control auto を併用する場面があります。MAB やフォールバックを設計する際は、対象機器の認証フレームワークが legacy か IBNS 2.0 かを確認します。

4. 802.1X の EAP は RADIUS source インターフェースと VRF に注意 — 本ラボの Catalyst 9000v では、管理用の Gi0/0 が専用の管理 VRF に固定されており、その管理 VRF 経由では 802.1X の EAP が RADIUS へ到達できませんでした。前節 4-2 で使った test aaa (PAP) は VRF のサーバグループ経由で通るのに、802.1X の EAP だけが通らないという食い違いが発生しました。これは、802.1X の EAP が test aaa とは別のコード経路を通り、管理 VRF を使えなかったためです。解決として、グローバルテーブル上のルーテッドインターフェース (Gi1/0/2 / 172.16.1.233) を RADIUS source として別途用意し、ip radius source-interface GigabitEthernet1/0/2 で VRF を使わずに RADIUS へ到達させました (§4)。test aaa は通るのに 802.1X の認証だけが AAA Server Down で失敗する場合は、RADIUS source インターフェースが管理 VRF 上にないかを疑います。

5. 未認証ポートでも EAPOL は扱う — port-control auto のポートは、認証が済むまで利用者の通常のデータフレームを遮断しますが、認証用の EAPOL フレームは扱います (§6)。「ポートを完全に閉じる」のではなく「認証メッセージは通す」という挙動であり、これがあるからこそ未認証の端末でも EAPOL で認証を進められます。なお、実装によっては未認証ポートでも CDP / STP などの制御フレームは通る点に注意します (利用者のデータ通信が遮断される、というのが本質です)。

13. 次節

本節では、IEEE 802.1X のポートベース認証を、サプリカント (端末) / オーセンティケータ (スイッチ) / 認証サーバ (RADIUS) の 3 者構成で整理しました。端末とスイッチの間は EAPOL、スイッチと認証サーバの間は EAP over RADIUS で EAP メッセージを運び、スイッチは認証の可否を判断せず中継に徹することを実機で確認しました。EAP-MD5 認証成功でポートが authorized になること、誤クレデンシャルではポートが unauthorized のまま残ること、802.1X を話せない端末を MAC で認証する MAB のフォールバックまでを、show 出力と RADIUS のログで対照しました。

802.1X が「ポートに接続した端末を認証してからネットワークへ通す」仕組みであったのに対し、次節 4-4 L2 セキュリティ では、L2 で発生する不正そのものを防ぐ仕組みを扱います。ポートに接続できる MAC アドレスを制限するポートセキュリティ、不正な DHCP サーバを排除する DHCP スヌーピング、ARP の偽装を防ぐ DAI (Dynamic ARP Inspection) など、スイッチが L2 レベルで備える防御機能を見ていきます。