VPNログインがRADIUSとIDプロバイダーに届くまで

先週、あるユーザーはVPNにサインインできたのに、何も名前解決できないネットワークに着地しました。クライアントは接続済みと言い、ゲートウェイのログはAccess-Acceptと言い、IDチームはアカウントは正常だと言いました。ログインは成功していましたが、その背後の認可は成功していませんでした。VPNサインインが失敗したとき、私は要求が実際にたどる経路——クライアント、ゲートウェイ、RADIUSサーバー、IDプロバイダー——をたどり、応答が次のホップと食い違う最初の地点で止まります。

クライアントはRADIUSを話さない

ノートPC上のアプリが何を示していても、最初のホップはVPNプロトコルで、IKEv2、OpenVPN、WireGuard、またはTLSベースのクライアントです。RADIUSはそのやり取りに現れません。クライアントは証明書、ユーザー名とパスワード、またはトンネル設定の中で運ばれるEAP方式によってゲートウェイに認証します。

これはログを読むときに重要です。ユーザーが見る一般的な認証エラーは、ゲートウェイがすでに何か別のものと話した後に生成するからです。クライアントがゲートウェイにまったく届かなければ、デバッグすべきRADIUS要求は存在せず、RADIUSサーバーに費やす一時間は無駄になるので、バックエンドに触れる前に、トンネルがそもそも上がったかを確認してください。

ゲートウェイがRADIUSクライアントである

トンネル設定が資格情報を確認すべき地点に達すると、ゲートウェイはネットワークアクセスサーバーになります。Access-Requestを組み立て、User-Name、パスワードまたはEAPペイロード、NAS-IP-AddressまたはNAS-Identifier、方式が要求する場合はMessage-Authenticatorを含めます。要求は既定でUDP 1812へ、アカウンティングは1813へ送られます。古い配備は今も1645と1646を使うため、片方の組だけを想定したファイアウォール規則が多くの沈黙の失敗を説明します。

両側は秘密を共有しており、それはユーザー資格情報ではありません。やり取りに署名し、すべての応答がそれに対して検証されます。両側で秘密を違えて設定すると、サーバーは「秘密が違う」とは答えません——要求を捨てるか応答が検証に失敗し、ゲートウェイはタイムアウトを報告します。間違った秘密と死んだサーバーはゲートウェイから見て同じに見えるので、ディレクトリを責める前に、クライアントツールでこのホップを試します。

プロトコルは小さく古いものですが——RFC 2865が認証のやり取りを定義しています——それが運ぶ属性こそ、ほとんどのVPNポリシーの土台です。

# ask the RADIUS server directly, from the gateway host
radtest alice 'test-password' 127.0.0.1 0 testing123

# watch the exchange the gateway actually sends
tcpdump -ni any -c 20 'udp port 1812'

RADIUSサーバーはIDプロバイダーの前面にすぎないことがある

人々はRADIUSとIDプロバイダーを同じ箱のように語ります。多くの場合、そうではありません。RADIUSサーバーはAccess-Requestを受け取り、応答する前に何か別のもの——LDAPやKerberos経由のActive Directory、ローカルのユーザーファイル、外部サービス——に問い合わせます。LDAPまたはkrb5モジュール付きのFreeRADIUS、Windows NPS、Cisco ISEはすべてこの位置にあります。

この区別が、どこを見るべきかを決めます。拒否されたパスワードは、RADIUSが中継するIDプロバイダーの答えです。タイムアウトは通常、RADIUSからディレクトリまでの区間で、期限切れのバインドアカウント、到達できないディレクトリ、誤ったバックエンドへ振られた要求です。ユーザー名にドメイン接尾辞があれば、サーバーはそれで振り分けることがあり、CORP\aliceと[email protected]として送られた同じアカウントが別の場所に着くことがあります。Windows NPSでは、Securityログが許可に6272、拒否に6273を記録するので、判断がそもそもNPSから来たかが分かります。

失敗を生んだホップで読む

「接続できない」という一つのメッセージが四つの異なる失敗を覆っています。何かを変える前に、症状をそれを生んだホップに突き合わせてください。

人を間違ったチームへ送るのは最後の行です。Access-Acceptは資格情報が受け入れられたことを意味しますが、ゲートウェイがユーザーを正しいプールに置いたことやルートを押し込んだことは意味しません。グループ属性は、ゲートウェイのポリシーがそれを読む場合にだけ意味を持ちます。正しいログインがゲストプールに落ちたのを見たことがありますが、それはグループのマッピングが、ゲートウェイが見る属性とは別の属性に対してRADIUS側で設定されていたからです。

一つのログインを最初から最後まで追う

テストアカウントを一つ、ゲートウェイを一つ選び、同じ試行を四つの地点で観察します。RADIUS側でデバッグ実行を開始し——freeradius -Xは要求と触れたすべてのモジュールを出力します——ゲートウェイの認証ログを追い、UDPのやり取りにtcpdumpを実行します。一度接続して、四つのトレースを順に読みます。

見たいのは、ゲートウェイが期待したユーザーについて問い合わせ、RADIUSサーバーが期待したバックエンドを選び、そのバックエンドが判断を返し、応答の属性がゲートウェイの適用するポリシーと一致しているという一致です。トレースが最初に食い違う場所が、あなたの障害線です。応答にグループ属性がなければ問題はVPNプロファイルではなくRADIUS側にあり、属性があってゲートウェイが無視するなら問題はゲートウェイのポリシーです。

そこにいる間のセキュリティ上の注意が一つ。共有秘密はやり取りを守りますが、ほとんどの属性は暗号化しません。ゲートウェイとRADIUSサーバーが別セグメントにあるなら、そのホップをTLS上のRADIUSかプライベート経路に置いてください。暗号化されたユーザートンネルは、バックエンドのリンクについて何も語りません。

チケットを閉じる前に四つを確認してください。ゲートウェイが実際に設定されたポートでRADIUSサーバーに到達できること。共有秘密が両側で一致すること。RADIUSサーバーがゲートウェイの送る正確なユーザー名の形を解決できること。acceptがゲートウェイのポリシーに必要な属性を運んでいること。四つすべてが成り立てば、それでも失敗するログインは認証ではなくゲートウェイのポリシーの問題です。