IEEE 802.1Xの深淵：なぜ「繋ぐだけ」でネットワークに入れないのか？
「LANケーブルを挿せば通信できる」。そんな時代はもう遠い昔の話です。現代のエンタープライズネットワークにおいて、物理ポートは単なる接続口ではなく、信頼のゲートウェイです。
今回は、ネットワークエンジニアなら避けて通れない「IEEE 802.1X」について、その泥臭い仕組みと、トラブルシューティングの勘所を紐解いていきましょう。
—
1. 3つの登場人物：役割分担の妙
IEEE 802.1Xを理解する上で、まずは役割分担を明確にしましょう。教科書的な用語を、現場の感覚で翻訳します。
- Supplicant（サプリカント）: クライアントPCやIoTデバイスのこと。自分の身分を証明し、「ネットワークに入れてくれ」と懇願する立場です。Windowsのネイティブ機能や、Linuxの
wpa_supplicantがこれに当たります。 - Authenticator（オーセンティケーター）: 現場の門番、すなわちスイッチ（L2/L3）です。サプリカントと認証サーバーの間に立ち、EAPメッセージを右から左へ、あるいは左から右へ「運ぶ」役割（EAPOLフレームの終端）を担います。
- Authentication Server（認証サーバー）: 最終的な裁定者です。RADIUSサーバーがこれに当たります。ユーザーIDやパスワード、証明書が正しいかを判定し、スイッチに対して「通してよし（Accept）」または「拒否（Reject）」を伝えます。
—
2. 通信の解像度を上げる：EAPのシーケンス
802.1Xの本質は、「認証が完了するまで、スイッチのポートは遮断されている」という点にあります。この時、ポートは EAPOL（EAP over LAN）という特殊なフレームしか通しません。
認証シーケンスのリアルな流れは以下の通りです。
1. EAP-Request/Identity: スイッチが「お前は何者だ？」と問います。
2. EAP-Response/Identity: クライアントがIDを返します。
3. RADIUS Access-Request: スイッチは受け取ったIDをRADIUSサーバーに転送します。
4. EAP-Challenge: サーバーは「ならばパスワードや証明書で証明せよ」という課題を出します。
5. EAP-Success: 認証成功。ここで初めてスイッチがポートを authorized 状態にし、通常のイーサネットフレーム（IPトラフィック）の転送を開始します。
ここで重要なのは、「スイッチは中身を解釈していない」という点です。スイッチにとって、EAPは単なるカプセル。中身の暗号化方式（EAP-TLSなど）が何であれ、スイッチには関係ありません。これが802.1Xの柔軟性であり、同時にトラブル時に「どこでパケットが止まっているのか」を切り分ける難しさでもあります。
—
3. 実践：Cisco Catalystでの構成例
現場で最も遭遇するCisco IOS環境での設定例です。これを設定する際は、必ず vty からのアクセスや、認証失敗時の guest-vlan の設計を忘れないでください。
# 1. AAAの有効化
aaa new-model
aaa authentication dot1x default group radius
# 2. RADIUSサーバーの定義
radius-server host 192.168.10.50 key 0 MySecretPassword123
# 3. インターフェースへの適用
interface GigabitEthernet0/1
switchport mode access
dot1x pae authenticator # このポートを門番にする
spanning-tree portfast # 認証待ちでリンクがダウンしないよう設定
authentication port-control auto # 認証を強制する—
4. トラブルシューティングの極意
「認証が通らない」というヘルプデスクへの電話は、ネットワークエンジニアにとって日常茶飯事です。まずは以下の順序で確認します。
Step 1: パケットの到達確認
スイッチ上で debug dot1x all を打つ前に、まずは show dot1x interface <int> details で状態を確認します。Status が unauthorized で止まっているなら、EAPOLフレームがサプリカントからスイッチに届いていない可能性が高いです。
Step 2: RADIUSのログを確認
スイッチまでパケットが来ているなら、次に疑うのはスイッチとRADIUSサーバー間の通信です。
# RADIUSサーバーとの通信統計を確認
show radius statisticsここで Access-Request は出ているのに Access-Accept が返ってこない場合、共有鍵（Shared Secret）の不一致か、RADIUSサーバー側での認証ポリシーの不備が確定します。
—
5. 最後に：インフラエンジニアとしての視点
Web API開発者の方々にも意識してほしいのは、「ネットワークの認証もAPIの認可も、根本は同じ」ということです。
クライアントが提示したトークン（EAPでは証明書や認証情報）を、信頼されたオーソリティ（RADIUSサーバー）が検証し、ゲートウェイ（スイッチ）がアクセスを許可する。このアーキテクチャは、OAuth2.0やOpenID Connectと構造的には変わりません。
インフラは「繋がって当たり前」と思われる職種ですが、その裏側ではこうした無数のハンドシェイクが静かに行われています。次にLANケーブルを挿すとき、その先に広がる802.1Xの厳かなプロセスに、少しだけ想いを馳せてみてください。
—
*「ネットワークは正直だ。設定した通りに動き、嘘をつかない。だからこそ、設計者の思想がそのまま性能として現れる。」* — 現場の先輩より
コメント