NPS のグループポリシーは VPN リソースの強制ではない

二つのグループ、二つのアクセスプロファイル、一つの VPN ゲートウェイがあり、最終的に両方のグループが同じサーバーに到達します。よくある原因はポリシーの破損ではなく、設計の後半が欠けていることです：NPS は誰がセッションを確立できるかを決め、そのセッションが何に到達できるかは別の何かが決めなければなりません。前半だけが存在する場合、認証するすべての人に対して承認が成功します。ポリシーは役割を果たしており、設計はまだ不完全です。

グループに一致するネットワークポリシーは、受け入れに関する証拠です。パケットに関する証拠ではなく、この二つの記述の間の隔たりこそが、この作業の大部分が起きる場所です。

セッションを実際に受け入れたポリシーを見つける

NPS は順序付けられたネットワークポリシーを評価し、条件が一致する最初の有効な規則が優先されます。条件には、ユーザーまたはコンピューターのグループメンバーシップ、接続の種類、時刻、デバイスの状態を含めることができます。そのため、一覧の前方に置かれた広いポリシーは、下方の狭い規則が検討される前に接続を受け入れます。順序はインターフェイスの細部ではなく、順序こそがポリシーです。

一覧を順に読み、一致したものを持定し、それが返した設定を記録します。エディター上のグループ名は結果ではなく、結果はサーバーが受け取った承認です。展開が両方を使う場合は、トンネルを開けるアカウントが自動的にすべての内部サービスに到達すべきアカウントではないからこそ、ユーザー承認とデバイス承認を分けて扱ってください。

RADIUS の応答は指示であり、フィルターではない

Filter-Id 属性はフィルター一覧の名前を運びます。すべての受信者が理解する可搬なパケットフィルター規則の集合を配布するものではなく、ゲートウェイが定義したことのない名前を送っても何も強制されません。同じ注意は VLAN 属性にも当てはまります：トンネルセッションを VLAN に割り当てることは、それ自体ではそのユーザーに対するルーティングされたアクセス規則ではありません。

ここが、NPS 側では完全に見える設計が静かに何もしない場所です。標準の属性名が標準の動作を意味すると仮定するのではなく、どの承認属性がサポートされ、受信者がそれぞれをどう扱うかをゲートウェイベンダーのドキュメントで確認してください。

強制をトラフィックが通る場所に置く

ユーザーのパケットを処理するゲートウェイは、セッションごとのフィルターを適用し、グループをゲートウェイポリシーにマップし、またはファイアウォールが別扱いする分離プールからアドレスをセッションに渡すことができます。いずれも機能し得ますが、失敗の仕方は異なります。ポリシーを書く前に、ゲートウェイがどの仕組みをサポートするかを特定してください。次に、沈黙が既定である以上、その仕組みがない場合にセッションがどうなるかを書き留めてください。

意図する許可を四つの部分で記述する: 送信元の ID またはグループ、宛先、プロトコル、ポートです。ユーザーが本当に必要とする依存関係、たとえば DNS や認証サービスを追加しないと、制限は誰も検証しようと思わなかったログインフローを壊します。規則は実際にフィルターするインターフェイスに対して書き、エディターでたまたま開いているインターフェイスに対して書かないでください。

アドレス変換も考慮してください。下流のファイアウォールがトンネル利用者ごとに一つの変換済み送信元アドレスを見る場合、そのアドレスだけでは個人を区別できず、区別できるかのように書かれた規則は役に立たないか、広すぎるものになります。

クライアントプロファイルは信頼されない側に住む

管理された VPN プロファイルはルート、分割トンネルの規則、アプリケーションフィルターを配布でき、それらは行儀のよいデバイスの振る舞いを形作ります。それらはサービスの保護ではありません：クライアントこそが制約しようとしている当事者だからです。プロファイル内のルートを削除することも承認ではありません：クライアントは同じ宛先への別の経路を持つ可能性があるからです。

クライアントの設定は利便性、ゲートウェイの設定は制御として扱ってください。両者が食い違う場合、パケットを見るのはゲートウェイなので、ゲートウェイが正しいのです。

二つのアカウントで受け入れ、順に追跡する

意図する権限が異なる二つの通常のテストアカウントを作成し、新しいセッションを確立し、それぞれの実効ゲートウェイポリシーを確認します。次に、無害な許可済み操作と、明示的に拒否されるリソースを一つずつ試します。ping の失敗だけでは、ICMP はフィルターされていてもその背後の TCP サービスが快く応答することがあるため、ほとんど何も証明できません。

両方のアカウントが依然として広いアクセスを得る場合、決まった順序で追跡してください：どのポリシーが一致したか、応答がどの承認を運んだか、ゲートウェイがそれをどう扱ったかです。受信者がそれらを実装すると確認する前に NPS 属性を増やすことが、小さな承認の問題を結果のない変更ウィンドウに変える道です。