NPS の RADIUS クライアントとして登録するのはどのアドレスか

Windows NPS に認証を委ねる VPN ゲートウェイは、ユーザー ポリシーが動く前に NPS 側でゲートウェイ用の RADIUS クライアント エントリという一つのオブジェクトを必要とします。失敗する試行の多くは誤ったアドレスを登録しますが、重要なのはゲートウェイがバックエンド経路で使うアドレスであり、職員が VPN アプリに入力するホスト名ではありません。この値を誤ると NPS は要求を黙って破棄し、クライアント側からはパスワード誤りに見えます。どのアドレスを欄に入れるかは三つの条件で決まるので、コンソールを開く前に整理してください。

登録するのはゲートウェイであり、ノート PC やプールではない

RADIUS クライアント オブジェクトは、認証要求を送るネットワーク アクセス装置を表します。それは VPN ゲートウェイであり、クライアントを動かす各ノート PC でも、トンネル内で配られるアドレス範囲でもありません。

そのトンネル アドレスが RADIUS 要求の送信元になることはなく、要求はゲートウェイ自身のネットワーク経路を通ります。クライアント プールのエントリを登録すると決して一致しないポリシーができあがり、実際の要求は NPS が聞いたことのないアドレスから届きます。同じ混同から職員ごとの自宅 IP を追加する人が出ますが、これは保守できず、誤りでもあります。

入力するアドレスは三つの条件で決まる

まず、ゲートウェイが NPS に向けて実際に使う送信元アドレスを特定します。複数インターフェイスのゲートウェイは、公開 VPN リスナーではなく管理用やバックエンドのインターフェイスから送ることがよくあります。次に、両者の間に NAT があるか確認し、要求が変換されるなら NPS が見る変換後のアドレスを登録します。三つ目に、二台のゲートウェイが役割を共有する場合は要求の送信元ごとにクライアント エントリが必要で、一つのアドレスを持つ一つのオブジェクトはそのうち一台しか覆いません。

両端をそろえた記録が対応関係を保ちます。下の表は説明のためにプライベート アドレスを使っているので、実際の経路が使う値に置き換えてください。

推測せずに送信元を確認します。試行を一度行いながら NPS またはファイアウォールのログを見るか、NPS ホストで sudo tcpdump -ni any udp port 1812 を使って取得します。その取得結果のアドレスが、クライアント エントリに対して唯一弁明できる答えです。ゲートウェイに複数の候補がある場合は、それぞれを独自のわかりやすい名前で登録します。

共有シークレットはゲートウェイと NPS の間の値

共有シークレットは装置間の関係を認証します。ユーザーのパスワードではなく、職員に配られることもクライアント プロファイルに埋め込まれることもありません。

値を一つ選び、両方の場所に入力し、ゲートウェイの構成バックアップがある場所に保管します。一致しないと NPS は有用なエラーなしに要求を捨て、ゲートウェイのログでは到達不能なサーバーと区別できません。保守時間帯に切り替え、同じ変更で両端を更新します。

許可された一度の要求で確認する

制御されたアカウントを使い、両側で一つの試行を突き合わせます。ゲートウェイ側では要求が想定したサーバーへ出たことを、NPS 側では登録済みクライアントから届き、想定した接続要求ポリシーに一致したことを確認します。タイムアウトと拒否は別の意味を持ち、どちらも資格情報の問題として扱うと次の一時間を無駄にします。続いて、有効だが対象外のアカウントと誤ったパスワードも試しますが、すべてを受け入れるポリシーは最初の試験を通ってしまうからです。

最後に、返された承認をゲートウェイがどう扱うかを確認します。RADIUS クライアントの登録は装置の参加を許すだけで、その結果生じる各セッションに LAN へのアクセスを与えるものではありません。

診断出力は範囲を限定し、共有シークレット、ユーザーのパスワード、完全なパケット ペイロードをサポート チケットに含めないでください。設計上 NPS サーバーがディレクトリ属性を読む必要がある場合、その許可はクライアント登録とは別の管理作業であり、欠けているときは別の形で失敗します。