EAP 断片化の解決：信頼できる RADIUS 認証の鍵
ネットワークセキュリティにおいて、 最大伝送単位（MTU） は、ネットワークリンク上で断片化されることなく送信できる最大のパケットサイズを定義する重要なネットワーキングパラメータです。ほとんどのユーザーはMTUを意識する必要はありませんが、特定のシナリオ、特にRADIUSやEAP-TLS認証においてトラブルシューティングで重要な要素になります。本記事では、MTUがRADIUSプロトコルにどのように影響するか、特にEAP-TLSで使用される証明書のような大きなペイロードを扱う場合にどのように認証失敗につながるかを探ります。
MTUと断片化の概要
この MTU は、ネットワークがパケットをより小さな断片に分割することなく処理できる最大のパケットサイズです。ほとんどのイーサネットネットワークの標準MTUは1500バイトです。パケットがネットワークリンクに対して大きすぎる場合、それは破棄されるか、受け入れ可能なより小さな断片に分割される必要があり、このプロセスを IP断片化と呼びます。宛先ホストは、すべての断片を元のパケットに再構成する責任を負います。
EAPとIP断片化の違い：なぜこの区別が重要か
EAPとIP断片化の区別は、認証問題を理解するうえで決定的に重要です。
IP断片化（ネットワーク層）：これはルーターが単一のUDPデータグラムを複数のより小さなIPパケットに分割する場合です。これはRADIUSアプリケーションの下位で発生し、RADIUS自体は自分のパケットが断片化されたことを認識しません。
EAP断片化（アプリケーション層）：EAPプロトコル自体は断片化をサポートしていませんが、EAP-TLSのような個々のEAPメソッドが独自の断片化メカニズムを実装できるフレームワークを提供します。大きなEAP-TLSメッセージ（例：証明書）がMTUに対して大きすぎる場合、それは複数のEAP断片に分割されることがあります。各断片はそれぞれ独自のRADIUSパケットにカプセル化され、個別に送信されます。
重要な違いは、 IP断片化 がパケットを再構成するためにネットワークに依存するのに対し、このプロセスはしばしば失敗するという点です。 EAP断片化 はクライアントとサーバーが再構成を処理することに依存しており、ネットワークレベルの問題を回避するより堅牢なプロセスです。
断片化における認証器（Authenticator）の役割
RADIUSクライアント、すなわちAuthenticatorはこのプロセスにおける重要な役者です。プロキシとして機能しながら、IP断片化を避けるためにEAPメッセージを断片化するよう設定できます。これは大きなペイロードを扱う際の推奨方法です。例えば、Authenticatorはサプリカントから受信した大きなEAPメッセージをRADIUSパケットにカプセル化してサーバーに送信する前に分割するよう設定できます。これによりパケットがネットワーク経路に適したサイズになることが保証されます。
Framed-MTUとEAP断片化サイズの違い
Framed-MTUはしばしばEAP断片化と混同されます。Framed-MTUは通常、RADIUSサーバーからRADIUSクライアントへの Access-Accept メッセージで送られる属性で、ユーザーが正常に認証された後のデータセッションのIP MTUを設定することが目的です。これは認証ハンドシェイク自体の間に発生する断片化問題を解決することはできず、その場合にはEAP断片化が必要になります。
より稀なシナリオでは、Framed-MTU属性がRADIUSクライアントからサーバーへ Access-Request メッセージで送信され、クライアントがサポートできる、あるいは使用したいと希望するMTUを示す場合があります。これはヒントや提案であって命令ではありません。RADIUSサーバーはこの値を無視するか、セッションのMTUを決定する際の考慮要素として使用する自由がありますが、これはEAP断片サイズを交渉する標準的な仕組みではありません。
なぜEAP断片化がより良い解決策なのか
EAP断片化は、信頼性のあるEAP-TLS認証を確実にするためにAuthenticatorとRADIUSサーバーの両方で設定される必要があります。EAP-TLSプロセスは双方向のやり取りであるため、両側が大きなペイロードを断片化できることが必要です。また、一貫性を保ち認証失敗を防ぐために、両側で同じEAP断片サイズを設定するのがベストプラクティスです。
この必要性を踏まえると、大きな証明書が原因で認証が失敗する場合、それはしばしばIP断片化が原因です。ファイアウォールやCGNATデバイスは断片化されたパケットを破棄することがあり、認証がタイムアウトする原因になります。すべてのネットワークトラフィックに対してMTUを一律に下げる代わりに、最善の方法は AuthenticatorおよびRADIUSサーバーでのEAP断片化を設定することです。
このアプローチはいくつかの重要な利点を提供します：
標的を絞った修正：AuthenticatorまたはRADIUSサーバーで特定のEAP断片サイズを設定することで、問題の根本で直接解決できます。大きな認証パケットがネットワーク上で送信される前に小さな許容できる断片に分割されることを保証し、他のトラフィックに影響を与えることなくIP断片化を防ぎます。
ネットワーク全体への大きな性能影響がない：インターフェースのグローバルMTUを下げるとすべてのネットワークトラフィックに影響を与え、オーバーヘッドの増加やネットワーク効率の低下を招く可能性があります。EAP断片化を使用することで、ネットワークの他のトラフィックは標準MTUを引き続き使用し、最適なパフォーマンスが維持されます。EAP断片化は同じペイロードに対してより多くの小さなパケットを作成し、往復回数が増えるためわずかな遅延を生む可能性がありますが、全体のネットワークへの性能影響はほとんど無視できるものであり、認証成功のために必要なトレードオフです。
プロトコル固有の設計：断片化をサポートするEAPメソッドは大きなペイロードを処理するように設計されています。この組み込み機能に依存することは、ネットワーク層の回避策に頼るよりも信頼性が高く標準に基づいたアプローチです。
Cisco、Aruba、JuniperなどのスイッチやアクセスポイントのようなRADIUSクライアント機能を持つ一般的な機器には、EAP断片化を設定する機能があります。同様に、FreeRADIUSのようなRADIUSサーバーには fragment_size という設定があり、最大EAP断片サイズを制御できます。
すべてのベンダーがこの機能を提供しているわけではないことに注意することが重要です。例えば、Merakiはダッシュボードでユーザーが設定可能なEAP断片化設定を提供しておらず、これは重要な制限となる可能性があります。
なぜCGNATで断片化が失敗するのか
IP断片化は認証失敗の一般的な原因であり、StarlinkのようなキャリアグレードNAT（CGNAT）を使用するネットワークでは特に問題になります。
断片の破棄：多くのファイアウォールやCGNATデバイスは断片化されたパケットを効率的に処理するよう設計されていません。セキュリティやパフォーマンスの理由で断片を破棄したり、正しく再構成できないことがあります。
パケット損失：転送中にたった一つの断片でも失われると、サーバーは元のUDPデータグラム全体を再構成できません。UDPはコネクションレスで再送機構がないため、RADIUSサーバーは完全な
Access-Requestを受け取ることがなく、認証は失敗します。
断片化されたUDPトラフィックに再送機構がないことが、IP断片化が認証に対して信頼できない解決策である核心的な理由です。だからこそEAP断片化の設定が正しい解決策となります。EAPメッセージがあらかじめ小さな断片になっていることを保証することで、IPレイヤーで断片化されるのを防ぎ、断片化されたトラフィックを破棄するファイアウォールやCGNATデバイスによる問題を回避します。
結論
大きなEAP-TLS証明書のペイロードとネットワークのMTUとの相互作用は、認証失敗の隠れた原因になり得ます。RADIUSプロトコルは断片化をネットワークに委ねますが、ファイアウォールやCGNATデバイスはしばしば断片化されたパケットを破棄します。EAPとIP断片化の区別を理解し、AuthenticatorとRADIUSサーバーでEAP断片化を設定するというベストプラクティスを実施することで、認証パケットがネットワークを通過する際に完全な状態を維持できるようになります。このアプリケーション層での意図的なアプローチは、一般的で苛立たしい接続問題を防ぐ堅牢で信頼性の高い解決策を提供します。
最終更新
役に立ちましたか？