0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@555hamano(Akr)

第17回 ネットワーク分離： VLANとWindowsの「IPSec接続規則」

0
Posted at

はじめに

本連載では、Linux環境でインフラやセキュリティを構築してきたエンジニアに向けて、Windowsの内部構造やセキュリティ機能を「Linuxの概念に翻訳して」徹底解説していきます。

第17回のテーマは「ネットワーク分離」です。

インフラエンジニアが「ネットワーク分離」と聞くと、まず頭に浮かぶのはスイッチやルーターによる VLAN（Virtual LAN） やサブネット分割、あるいはL3ファイアウォールによるアクセス制御でしょう。しかし、現代の「ゼロトラスト」アプローチや、クラウドとオンプレミスが混在するハイブリッド環境では、ネットワーク機器だけに頼る境界型防御には限界があります。

Windowsには、OSレベルで「パケットの暗号化」と「ホスト間の認証」を動的に行い、物理・論理ネットワークのトポロジーに依存しない強力なネットワーク分離（マイクロセグメンテーション）を実現する機能があります。それが 「IPsec接続セキュリティ規則（Connection Security Rule）」 です。

今回は、VLANとのアプローチの違いを整理し、Windows内部でこれがどう処理されているのか、そしてPowerShellからどう制御するのかを解説します。

対象環境

  • Windows Server 2019 / 2022、Windows 10 / 11（Active Directoryドメイン参加済み）
  • 各コマンドは管理者権限のPowerShellで実行してください。

1. VLANによる分離 vs Windows IPsecによる分離

まず、ネットワーク機器ベースの分離（VLAN）と、Windows IPsec接続セキュリティ規則による分離の哲学的な違いを整理します。

比較項目 VLAN / L3ファイアウォール（境界型） Windows IPsec接続セキュリティ規則（ホスト型）
制御レイヤー L2（タグVLAN）/ L3（サブネット） L3 / L4（パケット単位の認証・暗号化）
信頼の根拠 「どのポート/スイッチに繋がっているか」 「どのコンピューター/ユーザーか（AD認証等）」
ネットワーク依存性 強い（ルーター/スイッチの構成変更が必要） なし（同一セグメント内でも通信を強制分離可能）
Linuxでの対応技術 8021q モジュール, iptables/nftables strongSwan / Libreswan + xfrm

VLANの限界とIPsecが解決する課題

VLANやサブネットによる分離は、「同じセグメントにいるホスト同士は互いに信頼する」という前提（境界防御）になりがちです。1台のホストがマルウェアに感染した場合、同一VLAN内の他のホストへの横展開（ラテラルムーブメント）を防ぐのが難しくなります。

WindowsのIPsec接続セキュリティ規則を使用すると、「たとえ同じL2スイッチ（同じVLAN）に接続されていても、ADのコンピューターアカウントで認証し、暗号化（ESP）が成功しない限り通信を拒否する」 というOSレベルでの「論理的な孤立（ドメイン分離）」が実現できます。

2. Windows IPsecの内部構造（アーキテクチャ）

WindowsのIPsecは、サードパーティVPNクライアントのようなアプリケーション層の実装ではありません。カーネルレベルでWindows Defenderファイアウォール（WFP: Windows Filtering Platform）と完全に統合されています。

内部処理の流れ

[アウトバウンドパケット発生]
         |
         v
 ┌──────────────────────────────┐
 │  WFP（Windows Filtering Platform）  │  ← Linuxの netfilter に相当
 │  カーネルモード               │
 │  ・接続セキュリティ規則に合致するか判定  │
 └─────────────┬────────────────┘
               |（IPsec対象と判定）
               v
 ┌──────────────────────────────┐
 │  IKEEXT サービス（ユーザーモード）    │  ← Linuxの strongSwan charon に相当
 │  ・IKEv1/IKEv2 / AuthIP による鍵交換  │
 │  ・相手ホストとのSAネゴシエーション   │
 └─────────────┬────────────────┘
               |（SA確立）
               v
 ┌──────────────────────────────┐
 │  IPsecドライバー（ipsec.sys）        │  ← Linuxカーネルの xfrm に相当
 │  カーネルモード               │
 │  ・ESP/AHによるパケット暗号化/復号   │
 └──────────────────────────────┘
         |
         v
  [暗号化されたパケットを送信]

3コンポーネントの役割

  1. WFP（Windows Filtering Platform）： ネットワークスタックを監視するカーネルモードのフレームワークで、パケットが接続セキュリティ規則に合致するかを判定します。Linuxでいう netfilter のフック機構に近い存在です。

  2. IKEEXT サービス： svchost.exe によりホストされるユーザーモードのサービスで、鍵交換プロトコル（IKEv2推奨）およびマイクロソフト独自の拡張プロトコルである AuthIP を制御します。Linuxの charon（strongSwanのデーモン）に相当します。

  3. IPsecドライバー（ipsec.sys）： 実際のパケットの暗号化（ESP/AH）やカプセル化解除をカーネルモードで高速に処理します。Linuxカーネルの xfrm サブシステムに相当します。

💡 AuthIPとは？
標準のIKEに加えて、Windows同士の通信で「コンピューター認証（Kerberos/証明書）」と「ユーザー認証（Kerberos）」の2段階認証をワンシーケンスで行えるマイクロソフトの拡張仕様です。「ADに参加している特定のPCから、かつ特定のユーザーがログインしている時だけ通信を許可する」という極めてタイトな制御が可能になります。

⚠ AuthIPのユーザー認証にNTLMを使うことも技術的には可能ですが、NTLMはリレー攻撃（Pass-the-Hash / NTLM Relay）に対して脆弱です。Kerberos認証または証明書認証を使用し、NTLMへのフォールバックを禁止する構成を強く推奨します。

3. PowerShellで理解する「接続セキュリティ規則」の操作

LinuxでIPsecを組む場合、swanctl.conf を書き、ip xfrm コマンドでSAを確認するはずです。Windowsでは PowerShell（NetSecurityモジュール） で一元管理します。

接続セキュリティ規則の正しい作成手順

Windowsで接続セキュリティ規則（IPsecポリシー）を作成するには、認証の「提案（Proposal）」を定義した認証セットを先に作り、それを規則に紐付けます。

# ① Phase 1（メインモード）認証提案の作成
#    コンピューターのKerberos認証を使用
$phase1Auth = New-NetIPsecAuthProposal -Machine -Kerberos

# ② Phase 1 認証セットの作成
$phase1AuthSet = New-NetIPsecPhase1AuthSet `
    -DisplayName "Kerberos Machine Auth - Phase1" `
    -Proposal $phase1Auth

# ③ Phase 2（クイックモード）認証提案の作成（任意：ユーザー認証を追加する場合）
$phase2Auth = New-NetIPsecAuthProposal -User -Kerberos

# ④ Phase 2 認証セットの作成
$phase2AuthSet = New-NetIPsecPhase2AuthSet `
    -DisplayName "Kerberos User Auth - Phase2" `
    -Proposal $phase2Auth

# ⑤ 接続セキュリティ規則の作成
#    「192.168.10.0/24 との通信にIPsec認証を必須とする」規則
New-NetIPsecRule `
    -DisplayName "Secure Internal Network" `
    -LocalAddress Any `
    -RemoteAddress 192.168.10.0/24 `
    -InboundSecurity Require `
    -OutboundSecurity Require `
    -Phase1AuthSet $phase1AuthSet.Name `
    -Phase2AuthSet $phase2AuthSet.Name `
    -Enabled True

-OutboundSecurity Request（フォールバック）は本番環境では使わない

Request はIPsec非対応の相手に対して平文通信にフォールバックします。これは移行期のテスト用途には便利ですが、本番環境では「意図せず平文で通信してしまう」という重大なリスクがあります。本番環境では必ず Require に設定してください。

# ✅ 本番環境：双方向でIPsecを必須化
-InboundSecurity Require -OutboundSecurity Require

# ⚠ テスト・移行期のみ：送信側フォールバック許容
-InboundSecurity Require -OutboundSecurity Request

設定された規則の確認

# 接続セキュリティ規則の一覧を確認
Get-NetIPsecRule | Select-Object DisplayName, Enabled, InboundSecurity, OutboundSecurity

# 特定の規則の詳細を確認
Get-NetIPsecRule -DisplayName "Secure Internal Network" | Format-List

動的なセキュリティアソシエーション（SA）の確認

Linuxでいう ip xfrm state や swanctl --list-sas に相当するコマンドです。

# メインモード（IKE/AuthIPのネゴシエーション段階）のSA確認
Get-NetIPsecMainModeSA

# クイックモード（実際のデータ転送用暗号化）のSA確認
Get-NetIPsecQuickModeSA

# 確立中のSAで使用されている暗号アルゴリズムを確認
Get-NetIPsecQuickModeSA | Select-Object `
    LocalAddress, RemoteAddress, CipherAlgorithm, AuthenticationMethod

これらを叩くと、CipherAlgorithm: AES256 や HashAlgorithm: SHA256 といった、Linuxでも見慣れたパラメーターが並んでいるのを確認できます。

4. ドメイン環境：GPOによる一括展開

PowerShellコマンドで個別設定するのは検証・小規模環境向けです。ドメイン環境では GPO（グループポリシー） で全サーバー・クライアントに一括展開するのが正しい運用です。

コンピューターの構成
  → Windowsの設定
    → セキュリティの設定
      → セキュリティが強化されたWindows Defenderファイアウォール
        → 接続セキュリティの規則
          → 新しい規則（分離、サーバー間、トンネル、カスタムから選択）

GPOで配布する利点は、AD参加時に自動的にIPsecポリシーが適用されることです。新規サーバーをドメインに参加させるだけで、管理者の手作業なしにセキュアな通信セグメントへ自動参加させられます。

5. Linuxエンジニアがハマりやすい注意点

①「ファイアウォール規則」と「接続セキュリティ規則」は別物

Windows Defenderファイアウォールには独立した2種類の規則があります。

  • 接続セキュリティ規則： パケットをどう認証・暗号化するか（「トンネルをどう掘るか」）を決める。
  • 受信/送信の規則： そのパケットを通過させるか（ALLOW/DENY） を決める。

Linuxでいえば、xfrm/strongSwan でSAを設定する層と、nftables でフィルタリングする層が独立しているイメージです。接続セキュリティ規則を作っただけではポートは開きません。 暗号化された上で、さらにファイアウォール規則でそのポートの通過が許可されている必要があります。

② ポート500 / 4500 の解放

IPsecのネゴシエーションには以下のポートが必要です。VLAN間のルーターACLを忘れずに確認してください。

  • UDP 500： IKEネゴシエーション
  • UDP 4500： NAT越え（NAT-T）/ AuthIP
# IPsecネゴシエーション用のファイアウォール規則を確認
Get-NetFirewallRule | Where-Object {$_.DisplayName -like "*IPsec*"} | `
    Select-Object DisplayName, Enabled, Direction

③ トランスポートモードとトンネルモード

接続セキュリティ規則は、デフォルトでは トランスポートモード（ペイロードのみ暗号化、IPヘッダーはそのまま）で動作します。拠点間VPN（Site-to-Site）で使われるトンネルモード（IPパケット丸ごとカプセル化）が必要な場合は、-Mode Tunnel パラメーターを使用し、エンドポイントを明示的に指定します。

# トンネルモードで接続セキュリティ規則を作成する場合
New-NetIPsecRule `
    -DisplayName "Site-to-Site Tunnel" `
    -Mode Tunnel `
    -LocalTunnelEndpoint "203.0.113.1" `
    -RemoteTunnelEndpoint "198.51.100.1" `
    -LocalAddress 192.168.1.0/24 `
    -RemoteAddress 192.168.2.0/24 `
    -InboundSecurity Require `
    -OutboundSecurity Require `
    -Phase1AuthSet $phase1AuthSet.Name

まとめ

ネットワークの「分離」を物理スイッチやVLANタグ（802.1Q）のレイヤーだけで考えていると、クラウドシフトやリモートワーク環境に対応できなくなります。

WindowsのIPsec接続セキュリティ規則は、strongSwan + netfilter が極めて高度にOSカーネルへ組み込まれた機能であり、ネットワークトポロジーに依存しない動的なセグメンテーションを可能にします。GPOとの組み合わせで、「ADドメイン参加PC以外からの通信を一切拒否するセグメント」をコードで宣言的にデプロイできます。

今すぐ実行すべき確認コマンド

# 現在の接続セキュリティ規則を一括確認
Get-NetIPsecRule | Select-Object DisplayName, Enabled, InboundSecurity, OutboundSecurity | Format-Table -AutoSize

# 確立中のSAを確認（空であればIPsecは現在使われていない）
Get-NetIPsecQuickModeSA | Select-Object LocalAddress, RemoteAddress, CipherAlgorithm

# IKEEXT サービスが稼働しているか確認
Get-Service -Name IKEEXT | Select-Object Name, Status, StartType

参考

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?