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