RADIUS の VLAN 応答が VPN ユーザーに何ももたらさない理由

NPS ポリシーに VLAN 属性を追加し、VPN ユーザーが接続しても、ノート PC は既定のプールに着地したままです。RADIUS サーバーは要求どおりの値を返しているため、障害はキャッシュの問題に見えます。通常はそうではありません。Access-Accept は認可のヒントを運び、それを受け取ったネットワークアクセスサーバーだけが、一つをネットワーク割り当てに変換できます。

ポリシーではなくゲートウェイから始める

何かを変更する前に、クライアントから内側へ連鎖をたどってください。クライアントはゲートウェイにセッションを要求し、ゲートウェイは RADIUS にユーザーが取得してよいか問い合わせ、RADIUS は結果と属性の集合で応答します。その後、ゲートウェイは適用できるものを適用します。

あなたの確認は四番目の手順から始まるため、最初の三つは健全に見えます。やり取りの中の何も、受け取った属性の実装をゲートウェイに義務づけてはいません。応答はゲートウェイへの要求であり、クライアントに関する事実ではありません。

スイッチができて VPN にできないこと

802.1X アクセススイッチはポートを持つ認証者であり、動的 VLAN 割り当てはそのポートの一つを、スイッチがすでに運んでいる VLAN へ移します。RADIUS トンネル属性は、その意図をスイッチが理解できる形式で記述します。ルーティングされた VPN はトンネルを終端し、スイッチポートを終端せず、そのクライアントは通常、ブロードキャストドメインへの所属ではなく、アドレスとルートを受け取ります。移すべきポートがないため、同じ属性に作用する対象はありません。

これはベンダーの不具合ではなく、モデルの違いです。一部のゲートウェイは、スクリーンショットでは似て見える独自のグループポリシー、プール選択、フィルタの仕組みを追加します。何も実装しないものもあり、属性は記録されて無視されます。実際に有効にしたリモートアクセスモードのドキュメントを読み、スクリーンショットのモードを読まないでください。

サーバーが実際に送った応答を読む

ポリシーエディターの表示ではなく、RADIUS が返した内容を確認してください。同じユーザー名と既知のパスワードによるテスト要求は、応答属性を読める形で出力するため、一つの手順で疑問が解けます。

radtest alice secret 10.0.0.10 0 testing123

その応答に VLAN 属性がない場合は、まずポリシーの一致を修正してください。存在する場合、サーバーは役割を果たしており、欠落は下流にあります。

まずセッションポリシーを、次に到達性を証明する

次に、ゲートウェイが構築したセッションを見てください。アクティブセッションの一覧には、プール、割り当てられたアドレス、ゲートウェイが付加したグループポリシーが表示され、適用のために重要な証拠はこれだけです。ポリシーが意図したものではなく、ユーザーが到達できるものと比較してください。

swanctl --list-sas

正しいプールのアドレスが分離を証明しないため、続いてクライアントから許可されるリソースと拒否されるリソースを一つずつ試してください。希望する割り当ての仕組みがゲートウェイにない場合、属性のコピーを増やしても作られません。期待するプールのアドレスは、他のすべてのプールへの完全なアクセスと共存し得ます。サポートされるポリシーの仕組みを選ぶか、意図的にネットワーク設計を変えてください。