はじめに
第2部「ネットワーク・通信制御編」のスタートです。第11回は、Linuxエンジニアにとっての「壁」であるWindows Defender ファイアウォールを攻略します。
Linuxで iptables や nftables（あるいは firewalld）を触ってきた人にとって、Windowsのファイアウォールは「通知がうるさいGUIツール」に見えがちです。しかし、その実体は非常に強力なステートフル・パケット・インスペクション（SPI）エンジンです。
Linuxサーバーを立てたらまず ss -tulpn でポートを確認し、iptables で穴を開ける。これがエンジニアの流儀です。Windowsでもやることは同じですが、Windowsファイアウォールには 「プロファイル」 という独特の概念があり、ここを理解していないと「設定したはずなのに通信が通らない」という迷宮に迷い込みます。
今回は、GUIの奥に隠された「詳細設定」と、エンジニアが大好きな「CLIでの制御」をマスターしましょう。
1. 「プロファイル」：接続先でルールを切り替える
Linuxの iptables は通常、どのインターフェースでも同じルールセット（Chain）が適用されます。対してWindowsは、接続しているネットワークの性質に応じて3つの 「プロファイル」 を自動で使い分けます。
| プロファイル | 適用条件 | 信頼レベル |
|---|---|---|
| ドメイン (Domain) | ドメインコントローラー（DC）への認証に成功している状態 | 最高 |
| プライベート (Private) | ユーザーが「プライベート」と手動指定した家庭・社内LAN | 中 |
| パブリック (Public) | 未指定のネットワーク（カフェのWi-Fiなど） | 最低。多くのインバウンドをデフォルトでブロック |
重要：NICがDCを検出できない場合はドメインプロファイルに切り替わらない
サーバー用途であれば通常「ドメイン」または「プライベート」が適用されますが、NICがDCへの通信に失敗した場合、「ドメイン」ではなく「パブリック」プロファイルが自動適用されることがあります。この場合、RDP（3389）やWinRM（5985/5986）などの管理通信がブロックされ、突然リモート接続できなくなる原因になります。
適用中のプロファイルは以下で確認できます。
Get-NetConnectionProfile
2. 概念の「翻訳」：iptables vs Windows Firewall
| 比較項目 | Linux (iptables) | Windows Firewall |
|---|---|---|
| 受信トラフィック | INPUT チェーン | 受信の規則 (Inbound Rules) |
| 送信トラフィック | OUTPUT チェーン | 送信の規則 (Outbound Rules) |
| 動作 (Target) | ACCEPT / DROP / REJECT | 許可 (Allow) / ブロック (Block) |
| 条件の指定 | ポート, IP, プロトコル, インターフェース | ポート, IP, プロトコル, プログラム (.exe), サービス |
| デフォルトポリシー | iptables -P INPUT DROP |
各プロファイルの「プロパティ」で設定 |
| ステートフル追跡 | -m state --state ESTABLISHED |
デフォルトで有効（戻りパケットは自動許可） |
Windowsファイアウォールの最大の特徴は、「特定の実行ファイル（.exe）だけ通信を許可する」 という設定が容易な点です。ポート番号が動的に変わるアプリケーションや、同じポートを使う複数のアプリを区別して制御したい場合に非常に有効です。
DROPとREJECTに相当する動作
WindowsのFirewallにはLinuxのDROP（無応答廃棄）とREJECT（ICMPエラー返却）の明示的な区別はなく、「ブロック」はデフォルトで応答なしの廃棄（DROP相当）になります。
3. 設定の優先順位：どちらが勝つか？
Linuxの iptables は「上から順番に評価してマッチしたら終了（First Match）」ですが、Windowsは異なるロジックで動作します。
優先順位のルール（重要度順）
-
「ブロック（上書き不可）」ルールが最強
New-NetFirewallRuleの-Action Block -OverrideBlockRulesオプションに相当。通常の許可ルールより優先されます。 -
「ブロック」ルールが「許可」ルールより優先
同じ条件で「許可」と「ブロック」が競合した場合、常に「ブロック」が勝ちます。iptablesの「先に書いたものが勝つ」とは逆の挙動なので要注意です。 -
精度の高い（より具体的な）ルールが優先
「すべてのIPからのTCP通信をブロック」より「192.168.1.0/24からポート80を許可」のような個別ルールが優先されます。「ルールの順序」ではなく「ルールの特定性」で勝負が決まります。
実務的な注意：
「許可ルールを追加したのに通信が通らない」という場合、競合するブロックルールが存在している可能性があります。以下で確認しましょう。# 特定ポートに関連するルールをすべて表示（許可・ブロック両方） Get-NetFirewallRule | Where-Object { $_ | Get-NetFirewallPortFilter | Where-Object { $_.LocalPort -eq 80 } }
4. 実践：PowerShellで「黒い画面」から操作する
GUIでポチポチするのはエンジニアの仕事ではありません。NetSecurity モジュールを使って、コマンドラインから制御しましょう。
ルールの確認（iptables -L に相当）
# 有効になっている受信ルールを一覧表示
Get-NetFirewallRule -Enabled True -Direction Inbound |
Select-Object DisplayName, Action, Direction, Profile
ポートの開放
80番ポート（HTTP）を許可するルールを追加します。
# iptables -A INPUT -p tcp --dport 80 -j ACCEPT に相当
New-NetFirewallRule `
-DisplayName "Allow HTTP Inbound" `
-Direction Inbound `
-LocalPort 80 `
-Protocol TCP `
-Action Allow `
-Profile Domain,Private # ← プロファイルを明示するのがベストプラクティス
-Profileを省略しない理由：
デフォルトではAny（3プロファイルすべて）に適用されます。PublicプロファイルにHTTPを開放するのは意図しない動作になる場合があるため、Domain,Privateと明示的に絞り込みましょう。
プログラム指定での許可（Windowsならではの設定）
# 特定の .exe だけ通信を許可する（ポート番号に依存しない）
New-NetFirewallRule `
-DisplayName "Allow MyApp" `
-Direction Inbound `
-Program "C:\MyApp\myapp.exe" `
-Action Allow `
-Profile Domain,Private
ファイアウォールの状態確認（systemctl status firewalld に相当）
# 3つのプロファイルがすべて有効（True）か確認
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction
特定ルールの削除
# iptables -D に相当
Remove-NetFirewallRule -DisplayName "Allow HTTP Inbound"
おわりに
Windowsファイアウォールは、ただの「パケットフィルタ」ではなく、アプリケーションと密接に連携した高度なガードマンです。特に「プログラム指定での許可」と「プロファイルの明示指定」を使いこなせば、Linuxよりも柔軟に「必要な通信だけを通す」要塞化が可能になります。
今回の「エンジニアの知恵」
RDP（3389）がつながらない時、ファイアウォールを「無効」にするのは最悪の選択です。まず以下で切り分けましょう。
# 対象ポートへの疎通確認（iptables + nc に相当）
Test-NetConnection -ComputerName <サーバー名> -Port 3389
# どのプロファイルが適用されているかを確認
Get-NetConnectionProfile
# RDP関連のファイアウォールルールを確認
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Select-Object DisplayName, Enabled, Profile, Action
「プロファイルが意図せずPublicになっていないか」を確認するのが、プロのトラブルシューティングの第一歩です。