SMB ファイアウォール規則の LocalSubnet は VPN クライアントを対象にしない
LocalSubnet の許可規則が対象とするのはサーバー自身のサブネットであり、ルーティングされた VPN プールではない。範囲を広げる前に、サーバーが見る送信元アドレスを比較する。
オフィスのデスクトップは共有に到達するが、VPN ユーザーはタイムアウトし、同じアカウントはスマートフォンのテザリングからは機能する。違いは共有のアクセス許可であることはまれで、通常はファイルサーバーに届くアドレスが違いである。LocalSubnet に限定した規則は、サーバー自身が接続しているサブネットを許可するのであり、別途ルーティングされた VPN プールはその一つではない。二つの設計がこの隙間を埋めるが、残される記録は大きく異なる。
二つの設計、一つの症状
第一の設計は、規則のリモート アドレス条件に VPN プールを追加する。サーバーは各クライアントのトンネル アドレスを見るため、ログで一人のリモート ユーザーを別のユーザーと区別できる。第二の設計は、VPN トラフィックをゲートウェイ経由でルーティングし、サーバーが見る前に LAN アドレスへ変換する。これにより接続は回復するが、同じ手順で区別も失われる。
この表はアドレスではなく役割を説明しており、どの行が当てはまるかは自分のプレフィックスで決まる。ブログ記事の例をコピーするのではなく、サーバーの実際の値を出力すること。
Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixLengthこの表は判断の補助であり、すべての配備についての主張ではない。追加のインターフェース、第二の拠点リンク、異なるマスクを持つホストではローカル集合が異なる。
| Path the packet takes | Address the server records | Filter scope that admits it | What the log can still tell you |
|---|---|---|---|
| Desktop on the server LAN | Its own LAN address | LocalSubnet or the LAN prefix | Which workstation connected |
| Client on the routed VPN pool | Its tunnel address | The VPN pool as a remote address | Which VPN account connected, if the pool is logged |
| Client behind source NAT at the gateway | The gateway's LAN address | The gateway address | Only that some VPN user connected |
| Site-to-site gateway | The remote gateway's tunnel address | The remote site's prefix | Which site connected, not which user |
Microsoft の New-NetFirewallRule のリファレンスは、リモート アドレス条件と LocalSubnet キーワードを説明している。このキーワードがすべてのプライベート アドレスを意味すると判断する前に読むこと。実際にはそうではない。
サーバーが実際に受け取るものを比較する
誰かが作成したと記憶している規則ではなく、有効な規則を読むこと。有効になっているか、アクティブなプロファイルに適用されているか、リモート アドレス条件がサーバーの見る送信元と一致しているかを確認する。Domain プロファイルでのみ有効な規則は、ネットワーク変更後にアダプターが Public に移ると何もしない。
Get-NetFirewallRule -DisplayGroup 'File and Printer Sharing' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction最初のコマンドはファイル共有規則に付随するアドレス フィルターを出力し、二番目はどのプロファイルがアクティブか、一致しない受信トラフィックがどう扱われるかを示す。ブロック規則と中央管理ポリシーも確認すること。ブロック規則は許可規則より優先され、ローカル規則の結合を無効にするポリシーは新しいローカル例外を無効化しうる。
コンソールでは規則が正しく見えるのにトラフィックに効果がないのは、この場合である。同時にプロファイルの割り当てを確認すること。別のネットワークに参加したノート PC は、誰もファイアウォールに触れなくても Public プロファイルへ移ることがある。
ログインの前にトランスポートをテストする
到達可能性と認証を分けて考える。TCP 445 のリスナーはサービスがポートにバインドされていることを示すが、リモートのパケットが到達できることは示さない。逆に、完了した TCP 接続は SMB セッションの確立や共有のアクセス許可についてまだ何も語らない。規則を編集する前に、両側からハンドシェイクをテストすること。
Test-NetConnection -ComputerName files.corp.example -Port 445
Test-NetConnection -ComputerName files.corp.example -Port 445 -InformationLevel Detailed最初のコマンドは実行したマシンから TCP ハンドシェイクが成功するかを報告し、二番目は解決されたアドレスとインターフェースの詳細を追加する。VPN クライアントとオフィスのデスクトップの両方から実行して比較すること。Ping はどちらの問いにも答えない。SMB が開いていても ICMP がブロックされることがあり、ファイアウォールが 445 を破棄していても許可されることがあるためである。
VPN からのみハンドシェイクが失敗する場合、送信元の範囲が第一の容疑者である。成功しても共有が拒否する場合は、ファイアウォール規則を編集するのではなく、SMB セッションとアクセス許可の診断に進むこと。
送信元 NAT が区別を失わせるとき
経路に変換があると、サーバーは個々の VPN クライアントをアドレスで区別できない。すべてのリモート ユーザーがゲートウェイとして到着する。それらを区別することに依存する認可は、身元がまだ見える場所、通常は VPN コンセントレーターまたは認証プロキシで適用する必要がある。ファイアウォール規則はトラフィックを許可できるが、変換が失わせた区別を回復することはできない。
そのゲートウェイ アドレスを許可すると、すべてのリモート ユーザーが単一のアドレスで記録されるため、規則はゲートウェイに到達できる誰にでもプール全体を許可することになる。ユーザーごとの判断が重要なら、元のアドレスを見えるままにするか、ユーザーをまだ知っている層へ判断を移すこと。そうしなければ、すべてのリモート ユーザーがサーバーの見える一つのアドレスのアクセス許可を継承し、監査証跡では後から区別できなくなる。これは設計上の判断であり、ファイアウォールの細部ではない。
二つの設計のどちらかを意図的に選ぶこと。接続したのが誰かを見る必要がある場合は規則を実際の VPN プールに限定し、サーバーがその情報を本当に必要としない場合にのみ変換された経路を受け入れる。選んだ送信元範囲は規則のそばに記録すること。次にこれをデバッグする人は、まずアドレス表を見るからである。