Microsoft Azure上で動作しているRADIUSサーバーでEAP-TLS認証ができなかった理由と対処方法
概要
2024年1月17日よりIaaS対応のNetAttest EPS仮想アプライアンスがリリースいたしまして、合わせて【EPS技術記事】Microsoft Azure 環境へのNetAttest EPS構築手順を公開しております。
この手順でMicrosoft AzureにNetAttest EPSをデプロイして無線APからの認証を行ってみたところ、EAP-TLS認証だけできない事象がありましたので紹介させていただきます。
なお、本内容はMicrosoft Azureに限らず、ご利用の環境によっては発生する問題であり、かつNetAttest EPS特有の制限事項ではありません。
構成
社内検証環境に仮想VPNルーターを設置して、Microsoft AzureとSite to SiteでIPsec VPN接続しています。
Microsoft AzureのNetAttest EPSで各種認証を試した結果
実際のお客様での利用を想定して、社内検証環境からMicrosoft AzureのNetAttest EPSへ下記の認証をテストしました。
テストの結果は次の通りとなります。
PAP認証
PAP認証は有線スイッチでのMACアドレス認証を行う際に利用されるケースが多いため、有線スイッチにてMACアドレス認証を行う設定にしてテストしました。
問題なく認証できることが確認できました。
PEAP(MS-CHAPv2)認証
PEAP(MS-CHAPv2)認証はユーザー名、パスワードでの認証方式であり、Active Directoryと連携してWindowsアカウント、パスワードを使った認証やコンピューターアカウントを使った認証を行うことができます。
今回はNetAttest EPSのローカルにユーザーを登録して、Windows 10端末でWi-Fi接続時の認証ができるかをテストしました。。
こちらも問題なく認証できることが確認できました。
EAP-TLS認証
EAP-TLS認証はクライアント証明書を使った認証方式であり、主に企業ネットワークにおいてWindowsだけでなくmacOS、スマートフォン、タブレットなどでのWi-Fi接続の認証で多く利用されています。
NetAttest EPSから発行した証明書をWindows 10端末にインポートして、その証明書を使ってWi-Fi接続時の認証ができるかをテストしました。
PAP認証、PEAP(MS-CHAPv2)認証が成功していたので、EAP-TLS認証も問題なく認証できるだろうと考えておりましたが、結果としては不思議なことにEAP-TLS認証だけ「このネットワークに接続できません」と表示され、Wi-Fi接続ができませんでした。
EAP-TLSだけ認証ができなかった理由について
EAP-TLSだけ認証ができないという不思議な状況であったので、NetAttest EPSの認証ログを確認しましたがAccess-Rejectなど認証失敗につながるようなログは出力されていませんでした。
どうやら、無線APもしくはクライアント端末自体が接続できないと判断したようです。
Windows端末でイベントログを確認する
Windows OSではイベントビューアーの[アプリケーションとサービスログ]-[Microsoft]-[Windows]-[WLAN-AutoConfig]-[Operational]にWi-Fi接続のログが記録されるので確認したところ次のようなエラーが記録されていました。
これらのイベントは無線APポイントよりEAPエラーを受信したので、ネットワークが利用できないことを示す内容となっています。
この情報とNetAttest EPSではAccess-Rejectを返したわけではない点をあわせて考えると、端末と無線AP間の電波状況悪い、もしくは無線APが壊れているのでは無いかと考えたのですが、無線APとNetAttest EPSを同セグメントに配置した場合にはEAP-TLSは認証成功となったので、無線APとMicrosoft Azure上のEPS間のネットワークで何かが起こっているように思われます。
パケットキャプチャを取得して状況確認
検証環境とMicrosoft AzureのNetAttest EPSのそれぞれでパケットキャプチャを取得して、RADIUSパケットがどうなっているかを追ってみました。
仮想ルーターのパケットもMicrosoft AzureのNetAttest EPSで取得したパケットもオレンジで囲った部分のNo.1からNo.10までのパケットは共通なので、APとEPS間の通信に問題がない事がわかります。
しかし、仮想ルーターで取得したパケットキャプチャで赤枠で囲ったNo.11からNo.15までのパケット(id=33)は、Microsoft AzureのEPSで取得したパケットキャプチャには存在していません。仮想ルーターからMicrosoft Azureの間のどこかでこのパケットが消失してしまったようです。
ちなみに届いていないフラグメントされたパケットを確認してみました。
赤枠で囲った部分はEAP-TLS認証して使用したクライアント証明書の情報でした。
届いているパケットと届いてないパケットを見比べると、届いていないパケットはサイズが1500バイトを超えていることがわかります。
パケットサイズが大きいのが原因?
マイクロソフト社のドキュメントではSite to SiteのIPsec VPNではMSSを1350するか、MTUを1400バイトにすると記載がありました。こちらもヒントになりそうです。
EAP-TLS認証だけ認証ができなかったのは、クライアント証明書が含まれている大きなサイズのパケットがMicrosoft Azureの仮想ネットワークまで届かない為に、認証が成立しない状況だったと考えられます。
参考までに手元の検証環境での各認証のパケットの最大サイズはおおよそ次の通りでした。
- PAP認証のパケットサイズ Access-Request(AP→EPS)でおおよそ130バイト
- PEAP(MS-CHAPv2)認証のパケットサイズ Access-Challenge(EPS→AP)でおおよそ1200バイト
- EAP-TLS認証のパケットサイズ 赤枠で囲ったフラグメントしたAccess-Request(AP→EPS)パケットを結合するとおおよそ1800バイト(1514バイト+227バイト=1741バイト)でした。
※本検証で使用したCA証明書、EPSのサーバー証明書、クライアント証明書は共にRSA暗号の鍵長2048bit、署名アルゴリズムはSHA256の物を使用しています。
パケットサイズを制限してEAP-TLS認証を行う方法
今回の検証環境では、大きなサイズのUDPパケットが届かないことがわかりましたが、幸いなことにRADIUSパケットのDFビット(Don't Fragment bit)は0が指定されておりパケットの分割ができるようになっていましたので、大きなサイズのパケットをどこかで分割するように制限すれば解決できそうです。
そこで以下を試しましたが、今回の検証環境ではRADIUS認証のUDPパケットは小さくならず、改善には至りませんでした。
- Windows PCの無線インターフェースのMTU変更
- 無線APのLANインターフェースのMTU変更
- VPNルーターのLANインターフェースのMTU変更
さらに調査を進めた結果、UDPパケットを分割する方法をいくつか見つけることが出来ました。
IPsec トンネルインターフェイスでMTUサイズを変更する
VPNルーターのドキュメントを確認したところVPN接続するIPsecトンネルインターフェイス(Virtual Tunnle Interface/VTI)でMTUサイズを制限する方法が案内されていたため、こちらを使ってIPsecトンネルインターフェイスにてMTUを1400に絞ったところ、EAP-TLS認証に成功しました。
認証したときのパケットキャプチャを取得しました。
赤枠で囲ったフラグメントされた部分のパケットサイズが一致していない様に見えますが、足し算してみますと
- 仮想ルーター:1514バイト+227バイト=1741バイト
- Azure上のEPS:1410バイト+331バイト=1741バイト
と同じサイズになっており、無線APとMicrosoft Azure間でパケットが消失されないようにパケットを分割して送っていることがわかります。
Arubaアクセスポイントを利用する
HPE Aruba Networking製アクセスポイントにはEAPパケットを指定サイズにフラグメントするdot1x eap-frag-mtuコマンドがあり、これを設定することでAruba APから発出されるRADIUSパケットのサイズを調整する事ができました。
RADIUS以外のUDPを使うプロトコル
TCPであれば3ウェイ・ハンドシェイクでMSSを調整できたり、PATH MTU Discoveryなどでパケットサイズ調整が行いやすく問題になりにくいのですが、そのような機構がないUDPの場合にはプロトコル自身で配慮しているものもあります。
UDPを使う他のプロトコルとして、有名所ではDNSやQUICなどがありますが、様々な経路を経由してもパケットが消失しないよう配慮したパケットサイズを使うように定められています。
- DNS
RFC791(Internet Protocol)のsection3.1を意識してDNSメッセージサイズを512バイトまで - QUIC
RFC2460(Internet Protocol, Version 6)のsection5を意識してUDPペイロードは1200バイト
ハンドシェイク無しに通信するUDPをインターネット越しに利用することと、通信の効率性を考慮して、1200バイトにすること定められている
これらのプロトコルとは異なり、プロトコルでパケットサイズを配慮していない場合には、ネットワーク機器で配慮した設計が必要になります。
終わりに
本事象の原因であるUDP通信のフラグメントについては、必ずしも発生する現象ではありませんが、VPN機器や無線メーカー側でも考慮・対応されているものがありました。
ただ、機器によって設定や対応方法の違いなどがありますので、NetAttest EPSをMicrosoft Azure上やVPN越しに配置する場合は、ネットワーク機器の仕様もご確認しつつ進めていただければと思います。
なお、仮想アプライアンスの評価版をご用意しておりますので、NetAttest EPSをご購入頂く前に現在ご利用中のネットワーク機器や設定でEAP-TLS認証ができるかの確認にぜひご活用いただければ幸いです。
Pickup ピックアップ
-
イベント報告
【ウェビナー】「医療情報システムの安全管理に関するガイドライン」に基づくランサムウェア等へのセキュリティ対策と導入事例/効果に...
-
インタビュー
「切れない」VPNに認証の側面から安心をプラス|Absolute Secure Access ✕ Soliton OneGat...
-
イベント報告
【ウェビナー】知っておきたい「医療ガイドライン第6.0版」のポイントと、求められるセキュリティ対策とは?|アクシオ×ソリトンシ...
-
インタビュー
フルマネージドの連携ソリューションで快適かつ安全な無線環境を負荷なく実現|Hypersonix × Soliton OneGa...
-
インタビュー
「まずは認証から」現場の課題に寄り添い、実現可能なゼロトラストセキュリティソリューションを提案|萩原テクノソリューションズ×ソ...