RDP の許可規則を追加しても VPN アクセスは狭まらない

計画はもっともらしく聞こえます：既存のリモート デスクトップの許可はそのままにし、アクセスを与えるべき唯一の VPN クライアント用に小さな許可を追加する、というものです。Windows Firewall はそのようには動きません。規則は最も具体的な項目が勝つ順序付きリストではなく、広い許可の隣に狭い許可を置いても、広い許可がすでに通していた全員を引き続き通すため何も変わりません。サービスを狭めるというのは、すでに仕事をしている許可自体を編集することを意味します。

追加する規則は重要な規則ではない

Windows Firewall は、そのマシンに適用されるポリシー ストア内の該当する受信規則をすべて評価し、そのうえで一致する許可があるか、それを上書きするブロックがあるかを判断します。規則を追加することは許可を追加することであり、すでにある許可を削除したり限定したりはしません。

したがって問いは決して「何を追加したか」ではありません。問いは、ローカル ポリシー、ドメイン ポリシー、プロファイルの既定値が統合された後に 有効なポリシーに何が含まれているか です。ローカル規則が一つだけのワークステーションは考えやすいですが、ドメインに参加したサーバーはそうではありません。

管理者が正しく見える変更を行い、間違ったマシンから試して、うまくいったと結論づけられるのも同じ理由です。除外された送信元は決して試されていません。成功だけを証明するテストは、その変更が何のためのものだったかの半分も証明しません。

サーバーがどのアドレスを見るかを突き止める

何かを絞り込む前に、Windows ホスト上で許可されたセッションを一つ観察し、サーバーが報告する送信元アドレスを記録します。それはクライアントが持っていると思っているアドレスとは限りません。

VPN ゲートウェイがクライアントのアドレスを保持するなら、サーバーはクライアントのトンネル アドレスを見るので、アドレスで絞った規則は意味を持ちます。ゲートウェイが変換するなら、すべてのクライアントがゲートウェイのアドレスとして到着し、そのアドレスに絞ると背後にある全クライアントにアクセスを与えてしまいます。その場合、規則は間違った対象について正確です。

この二つの設計には別の答えが必要です：前者はファイアウォール規則で表現できます。後者は ID がまだ存在する場所、つまり VPN 自体か、サービスの前にある認証済みゲートウェイで強制する必要があります。

ファイアウォール フィルターは、ネットワーク変換が捨てた ID を取り戻せません：アドレスをどれほど丁寧に入力しても同じです。

有効な規則の所有者を変える

有効な受信ポリシーを調べ、現在 RDP トラフィックを許可しているすべての規則を見つけます。表示名にポート 3389 が一度も出てこない規則も含みます：サービスで絞った規則とアプリケーションで絞った規則も数え、一部の RDP 展開が有効にする UDP トランスポートも同様です。

次に、その規則を所有するストアを通じて既存の規則を編集します。ドメイン ポリシーも定義している規則へのローカル編集は、統合されたり、無視されたり、上書きされたりする可能性があり、それに頼る前にどれが起きるかを知っておく価値があります。

次のコマンドは有効な規則を検索し、一つに付随するアドレス フィルターを表示し、範囲変更をプレビューします：

Get-NetFirewallRule -PolicyStore ActiveStore -Direction Inbound | Where-Object DisplayName -match RDP
Get-NetFirewallAddressFilter -AssociatedNetFirewallRule (Get-NetFirewallRule -Name Reviewed-RDP-TCP)
Set-NetFirewallRule -Name Reviewed-RDP-TCP -RemoteAddress 10.63.4.17 -WhatIf

ここでの規則名はレビューが見つけた内容のプレースホルダーであり、プレビュー フラグがあるのは、アドレスの打ち間違いで編集中のサーバーから締め出されないようにするためです。

ブロックしてから許可するのは別のモデル

他のファイアウォールの習慣は、広いブロックを書き、その上に狭い許可を置くことです。Windows では明示的なブロックが一般に許可より優先されるため、その順序は一人のクライアントのための例外ではなく、誰も到達できないサービスを生みます。結果は壊れた RDP サービスのように見える障害です。実際には優先順位の間違いであり、修正は別の許可を追加することではなくブロックを削除することです。

アクティブなプロファイルで既定の受信ブロック動作を維持し、代わりに個別の許可を狭めます。そうすれば、相互作用が優先順位の細部に依存する二つの矛盾した規則ではなく、理解できる一つの姿勢がマシンに残ります。

二つ目の送信元で証明する

許可されたクライアントから、そして今は失敗するはずの送信元から試します。接続が一つ成功しただけでは、許可された経路が機能することを示すだけで、今行った除外については何も語りません。

サーバーで有効なら IPv6 でテストを繰り返します：IPv4 だけを意図していても、誰も見ていない広い IPv6 許可と共存できるからです。

最後に、認証を到達可能性から切り離しておきます。ネットワーク レベル認証、アカウントの権利、ログオン制限は依然として誰がセッションを使えるかを決め、ファイアウォールは誰が問い合わせられるかだけを決めます。後でデバイスを外すときは、その VPN 登録とこのネットワーク許可の両方を外すべきです：そうしないと、絞り込んだアドレスはいつか他人のものになります。