CGNAT およびモバイル回線での EAP-TLS 認証失敗
ネットワークセキュリティにおいて、Maximum Transmission Unit（MTU）は、断片化されずにネットワークリンク上で送信できる最大のパケットサイズを定義する重要なネットワークパラメータです。ほとんどのユーザーはMTUを意識する必要はありませんが、特定のシナリオ、特にRADIUSおよびEAP-TLS認証では重要なトラブルシューティング要因になります。典型的な症状としては、認証がメインのインターネット接続では動作するのに、携帯回線や衛星のバックアップ回線では失敗する、というものです。この記事では、MTUがRADIUSにどう影響するか、特にEAP-TLS証明書のような大きなペイロードが関わる場合に、なぜ認証失敗につながるのか、そしてRADIUSaaSでそれを回避する方法を説明します。
MTUと断片化の概要
MTUは、ネットワークがそれをより小さな断片に分けずに処理できる最大のパケットサイズです。ほとんどのEthernetネットワークの標準MTUは1500バイトです。パケットがネットワークリンクに対して大きすぎる場合、破棄されるか、より小さな断片に分割される必要があります。これはIP断片化と呼ばれます。宛先ホストは、すべての断片を再結合して元のパケットに戻す責任を負います。
4G/5Gや衛星接続のようなリンクは、事業者が独自のトンネリングのオーバーヘッドを追加するため、一般的な固定回線接続よりも実効MTUが小さいことがよくあります。そのため、固定回線ではそのまま通るパケットでも、これらのリンクでは断片化されることがあります。
EAPとIP断片化：この違いが重要な理由
EAP断片化とIP断片化の違いを理解することは、認証の問題を把握するうえで非常に重要です。
IP断片化はネットワーク層で発生します。ルーターまたはホストが1つのUDPデータグラムを複数の小さなIPパケットに分割します。これはRADIUSアプリケーションより下の層で起こるため、RADIUS側は自分のパケットが断片化されたことを認識していません。
EAP断片化はアプリケーション層で発生します。EAPプロトコル自体は断片化をサポートしていませんが、EAP-TLSのような個々のEAPメソッドが独自に実装しています。証明書のような大きなEAP-TLSメッセージが大きすぎる場合、それは複数のEAPフラグメントに分割され、それぞれのフラグメントが個別のRADIUSパケットで運ばれます。
重要な違いは、IP断片化ではパケットを再構成するためにネットワークがすべての断片を届けることに依存しており、これがしばしば失敗することです。EAP断片化は、クライアントとRADIUSサーバーという2つのEAPエンドポイントによって処理されるため、そうしたネットワーク層の問題を回避できます。
Framed-MTUとEAP断片化サイズ
Framed-MTU属性は、2つの異なる使われ方があるため、EAP断片化と混同されることがよくあります。
Access-Acceptでは、Framed-MTUは、認証後にユーザーのセッション用としてどのMTUを設定すべきかをRADIUSクライアントに通知します。これは認証ハンドシェイク自体には影響しません。
Access-Requestでは、EAPに対して重要です。RFC 3579の2.4節では、RADIUSサーバーはMTUディスカバリーを使ってリンクMTUを把握できないため、認証装置がEAPを含むAccess-RequestにFramed-MTUを含めてサーバーにこの情報を与えることができると説明しています。これを受け取ったサーバーは、リンク種別を考慮したうえで、連結されたEAP-Message属性が通知されたサイズを超えるような「このEAP会話における以後のパケットを送ってはならない」です。たとえばIEEE 802.11では、サーバーはFramed-MTUから4オクテットを差し引いたサイズまでのEAPパケットを送信でき、802.1Xのヘッダーフィールド分を確保できます。
したがって、Access-Request内のFramed-MTUは、認証装置がサーバーから送られるEAPパケットのサイズを制限するための標準的な方法です。ただし、これは認証装置とクライアントの間のリンクを示すものであり、認証装置とRADIUSサーバーの間のネットワーク経路を示すものではありません。副次的にはその経路上のRADIUSパケットサイズを小さくできますが、MTUが低下したリンクでIP断片化を防ぐ保証にはなりません。
EAP断片化だけでは不十分な理由
理論上、EAP断片化は各RADIUSパケットを、IP断片化されずにネットワークを越えられる程度に十分小さく保ちます。そのため、EAPフラグメントサイズを小さくすることは、自前運用のRADIUSサーバーに対する一般的な推奨事項です。
実際には、各方向のフラグメントサイズは2つのEAPエンドポイント、つまりクライアント側のサプリカントともう一方のRADIUSサーバーによって決まります。認証装置はパススルーとして動作し、EAP-TLSメッセージを再断片化しません。Cisco、Aruba、Juniperなどが提供するスイッチやアクセスポイントのEAP設定は、主に認証装置とクライアントの間のリンクを管理します。RADIUSサーバーが返すパケットサイズを直接制御するわけではありません。Merakiのように、この設定をまったく公開していないプラットフォームもあります。
EAP-TLS交換における最も大きなメッセージは、通常、サーバーから認証装置へ流れるものです。つまり、サーバー証明書チェーンを運ぶAccess-Challengeです。そのため、サーバー側のフラグメントサイズが決定要因になります。RADIUSaaSではこの値はサービス側で管理され、顧客ごとに調整することはできないため、デバイス側でEAP断片化を調整するだけでは、MTUが低下したリンクでのIP断片化を確実に防ぐことはできません。
WANインターフェース全体のMTUを下げることも、良い解決策ではありません。そのリンク上のすべてのトラフィックに影響し、単独ではUDP RADIUSパケットの断片化を止めることはできません。より堅牢な方法は、以下に示すようにRADIUSトラフィックの運び方を変更することです。
CGNATで断片化が失敗する理由
IP断片化は認証失敗の一般的な原因であり、特に多くの4G/5G接続やStarlinkのようなCarrier-Grade NAT（CGNAT）を使用するネットワークで顕著です。
多くのファイアウォールやCGNAT装置は、断片化されたパケットを扱うようには設計されていません。NATが接続を追跡するために使うUDPポート番号を含むのは最初の断片だけなので、残りの断片は、セキュリティ上の理由で意図的に、あるいは装置がセッションに対応付けられないために、しばしば破棄されます。
1つでも断片が失われると、元のUDPデータグラムは再構成できません。UDPには失われた部分を再送する仕組みがないため、パケット全体が失われ、最終的に認証はタイムアウトします。
これは両方向に影響しますが、EAP-TLSではサーバー応答で最もよく発生します。サーバー証明書チェーンを運ぶAccess-Challengeは、通常、交換中で最も大きいパケットです。その断片が破棄されると、認証装置はチャレンジを受信できず、認証は失敗します。
解決策：RadSecを使うか、UDP RADIUSをCGNAT経路から外す
RADIUSaaSでは、サーバー側のEAPフラグメントサイズは当社で管理しており、顧客ごとに変更することはできません。したがって、最も信頼性の高い対処法は、断片を扱えない経路上で大きな認証パケットがIP断片化されないようにすることです。
推奨される選択肢は、従来のUDP上のRADIUSではなく、RadSecを使って認証装置をRADIUSaaSに接続することです。RadSecはTCPポート2083上でTLSを使ってRADIUSを運ぶため、サーバー証明書チェーンのような大きなパケットはIP断片ではなく、その経路に適したサイズのTCPセグメントに分割されます。ファイアウォールやCGNAT装置は、これらを他のTCPトラフィックと同様に処理するため、問題は解消されます。現在の多くのプラットフォームはRadSecをネイティブにサポートしています。携帯回線や衛星バックアップのようなMTUが小さいリンク経由でデバイスが接続している場合は、TCP MSSが実際のパスMTUに一致していることも確認してください。WANインターフェースのMTUを低く設定することでこれを行えます。そうすれば、大きなTLSセグメントが静かに破棄されることを防げます。
認証装置がRadSecをサポートしていない場合は、4G/5GやStarlinkのようなCGNATリンクを越えてUDP RADIUSを直接送信しないでください。1つの方法は、RADIUSトラフィックを既存のサイト間VPNを通して固定インターネット接続のある場所へルーティングし、そこからRADIUSaaSプロキシへ送ることです。VPNトンネル内では、断片はカプセル化されるため、キャリアのNATによって破棄されなくなります。もう1つの方法は、現地に小さなRadSecプロキシを置くことです。これはローカルネットワーク上のデバイスからUDP RADIUSを受け取り、RadSecでRADIUSaaSへ転送します。
結論
大きなEAP-TLSメッセージ、特にハンドシェイク中に送られるRADIUSサーバーの証明書チェーンは、一部のネットワーク経路のMTUを超えることがあります。そのような場合、UDPではパケットはIP断片化されます。ファイアウォールやCGNAT装置はしばしばそれらの断片を破棄するため、通常は携帯バックアップ接続のような特定のリンクでのみ発生する認証タイムアウトを引き起こします。RADIUSaaSのサーバー側フラグメントサイズは顧客ごとに調整できないため、最も堅牢な解決策は、可能な限りRadSecを使用してIP断片化を完全になくすことです。RadSecが利用できない場合は、トンネリングするかローカルのRadSecプロキシを使うことで、UDP RADIUSをCGNAT経路から外してください。
最終更新
役に立ちましたか？