Windows Server 2019をドメインコントローラーとして構築した直後、ホストから仮想マシンへの通信が途切れるという状況が発生することがあります。今回、Hyper-V上のWindows Server 2019で実際に起きた問題と、その対処策を解説します。ぜひ参考にしてみてください。
Windows Server 2019のネットワークが遮断される背景
Windows 10 Pro環境のHyper-V上に構築したWindows Server 2019のVMが、ホストからの通信を受け付けなくなるトラブルは意外と多く報告されています。特にドメインコントローラーとしてサーバーを昇格させた後に、ファイアウォールのルールや仮想スイッチの設定が原因で問題が起きやすいのが特徴です。ここでは、実際に想定される原因を具体的に見ていきます。
発生環境の概要
- ホストOS：Windows 10 Pro
- Hyper-V：Windows 10 Proに標準搭載されているHyper-V機能
- ゲストOS：Windows Server 2019（ドメインコントローラーとして昇格済み）
- 仮想スイッチ：外部接続の仮想スイッチを利用
この環境で、再起動前はホストからVMへ問題なくpingやRDP接続ができたものの、再起動後に突然ホストからVMへの通信が途絶える事象が確認されています。一方で、VMから外部サイトや別のネットワーク機器、さらには別のVM（RHELなど）への通信は可能です。
想定される原因
再起動前との大きな違いとして、Windows Server 2019がドメインコントローラーに昇格されている点があります。ドメインコントローラーになると、Windows Server上のドメインファイアウォールが強化され、ドメインネットワーク内の通信や認証を厳密に制御し始めます。この段階で外部（ドメイン外）の端末からのpingやRDP接続をブロックするケースが生じます。また、Hyper-V固有の仮想スイッチ設定や、RDPやICMP（ping）が許可されるためのポート開放の有無も影響します。
ドメインファイアウォールのポリシー強化
ドメインコントローラーとして昇格すると、既定のドメインファイアウォールポリシーが適用され、外部のクライアントやドメイン外マシンからの接続を制限するルールが自動で有効になる場合があります。特に、ICMPやRDPに関する受信規則が無効になると、ホストからのpingやRDP接続が通らなくなります。
仮想スイッチ設定の不備
Hyper-Vマネージャーで外部仮想スイッチを作成する際、「管理OSがこのネットワークアダプターを共有する」にチェックを入れていないと、ホスト側がネットワークを正しく共有できない可能性があります。これが原因でホストからゲストOSへの通信経路が確立しない場合があります。
RDPおよびICMP許可の問題
ドメインファイアウォールの規則やグループポリシーにより、特定のプロトコルやポートがブロックされると、リモートデスクトップ(RDP)やping(ICMP Echo Request)が通りにくくなります。特にサーバー再起動後やポリシー更新後に設定がリセットされたり強化されたりすることで、突然通信不可になることがあります。
ドメイン参加と認証
サーバー側がドメインコントローラーとして機能すると、基本的に同じドメイン内のクライアントとの通信を前提とした設定が推奨されます。ホスト側がドメインに参加していない場合は、認証が適切に行われず、ファイアウォールで通信がブロックされるリスクが高まります。
具体的な対処方法
これらの原因を踏まえて、実際にはどのように設定やトラブルシュートを行えばよいのでしょうか。以下に主な対処策をいくつか紹介します。
ドメインファイアウォールの設定を見直す
まずはWindows Server 2019側でドメインファイアウォールのルールを確認します。Server Managerから「Windows Defender ファイアウォール」「詳細設定」の画面に進み、受信の規則をチェックしましょう。
RDPやICMP(Echo Request)などのプロトコルがブロックされていないかを確認し、必要に応じて規則を有効にします。また、ドメインネットワーク用とプライベートネットワーク用・パブリックネットワーク用それぞれにルールが存在しますので、ドメインファイアウォールだけでなく、他のプロファイルも適切に許可設定を行いましょう。
| ルール名 | プロトコル / ポート | 役割 |
|---|---|---|
| リモートデスクトップ(UDP-In) | UDP / 3389 | RDP接続の許可(一部の高パフォーマンス機能) |
| リモートデスクトップ(TCP-In) | TCP / 3389 | RDP接続の許可 |
| ファイルとプリンターの共有 (Echo Request – ICMPv4-In) | ICMP | pingを許可 |
DNSやLDAPなど、ドメインコントローラーに必要なポートも忘れずに開放しておくと、トラブルシューティングが進めやすくなります。以下は代表的なポート一覧です。
| ポート番号 | プロトコル | 用途 |
|---|---|---|
| 53 | TCP/UDP | DNSサーバー |
| 88 | TCP/UDP | Kerberos認証 |
| 135 | TCP | RPCサービス |
| 389 | TCP/UDP | LDAP |
| 443 | TCP | HTTPS |
| 445 | TCP | ファイル共有 (SMB) |
| 636 | TCP | LDAP over SSL |
| 3268 | TCP | グローバルカタログ (LDAP) |
| 3269 | TCP | グローバルカタログ (LDAP over SSL) |
仮想スイッチの構成を正しくする
Hyper-Vマネージャーで外部仮想スイッチを作成する場合、以下の手順を見直します。
- Hyper-Vマネージャーを起動
- 「仮想スイッチ マネージャー」を開く
- 「外部ネットワーク」を選択し、対象のネットワークアダプターを指定
- 「管理OSがこのネットワークアダプターを共有する」にチェックを入れる
このチェックが入っていないと、ホスト側がネットワークアダプターを正しく共有できず、VMとの通信に支障をきたす場合があります。また、ホストOSが複数の物理NICを持っている場合は、どのNICを外部仮想スイッチとして利用しているか、重複していないかを確認することも重要です。
RDPとICMPを許可する
ドメインコントローラーとしてWindows Server 2019を運用する際に、外部（ホスト側など）からの管理を行う必要がある場合は、RDPとICMPによる疎通確認を許可する設定を行いましょう。以下にPowerShellでの例を示します。
# RDPの許可ルールを確認（状態を確認する例）
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Format-Table Name, Enabled, Profile
# RDPのルールを有効化する（必要に応じて）
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"
# ping(ICMPv4)を許可する（Echo Request - ICMPv4-In）
Enable-NetFirewallRule -DisplayName "ファイルとプリンターの共有 (Echo Request - ICMPv4-In)"これらのルールが有効になっていれば、ホストからのpingやRDP接続が可能になります。ただし、ドメインファイアウォールのプロファイルやグループポリシーが絡んでくる場合は、それぞれのプロファイル（ドメイン、プライベート、パブリック）に対して同様の設定が必要になる可能性があります。
ホストをドメインに参加させる
ホストマシンを同じドメインに参加させることができるなら、ドメインコントローラーのポリシーと整合性が取れるため、通信がスムーズになります。ドメインに参加することで、認証の問題やファイアウォールの制限が大幅に緩和されるケースが多いです。
もしセキュリティポリシーや運用上の理由でホストをドメインに参加させられない場合は、ホストを「ワークグループ」環境のまま運用するため、ドメインファイアウォールの受信規則を個別に構成し、必要な通信を許可することが求められます。
実践例 : PowerShellによる設定
ドメインコントローラーとして昇格した直後にファイアウォールを一時的に無効化し、通信が通るか確認する方法はトラブルシュートの第一歩として有効です。ただし、本番環境でファイアウォールを無効化する行為は推奨されませんので、テスト環境やクローズドな環境でのみ行いましょう。
# ドメインプロファイルのファイアウォールを無効化する（テスト目的）
Set-NetFirewallProfile -Profile Domain -Enabled False
# 一時的に無効にして通信を確認した後は、必ず有効に戻す
Set-NetFirewallProfile -Profile Domain -Enabled Trueこの操作によってホストからのpingやRDP接続が復活する場合は、やはりファイアウォールの受信規則が原因である可能性が高いと考えられます。その後、必要なルールだけを有効化し、不要なルールを絞り込むことでセキュリティと利便性のバランスを取ることが重要です。
トラブルシューティングのポイント
ドメイン環境やHyper-Vなど、複数の要素が絡み合うネットワークトラブルは、一つずつ切り分けて考える必要があります。以下にいくつかのトラブルシューティングポイントを示します。
1. ネットワークアダプターの役割確認
Windows Server 2019の「ネットワークと共有センター」や「ipconfig /all」コマンドを使い、どのNICがどのIPアドレスを取得しているかを把握します。特に、仮想スイッチと紐づく仮想NICの設定が意図どおりになっているか、ゲートウェイやDNSは正しく設定されているかを確認しましょう。
2. ファイアウォールログやイベントビューアを活用
Windows Firewall with Advanced Securityには、トラフィックを記録する機能が備わっています。イベントビューアの「セキュリティ」ログや「ファイアウォール」ログを有効化しておくと、どのルールによって通信がブロックされているかがわかる場合があります。
3. DNSの設定
ドメインコントローラーは通常、DNSサーバーも兼任します。ホストがこのDNSサーバーを参照していない場合、名前解決がうまくいかずに通信が失敗しているケースがあります。ホスト側のDNS設定にドメインコントローラーのIPアドレスを指定し、ドメインを解決できるようにしておくとトラブルシュートがしやすくなります。
4. ネットワークキャプチャツール
問題がさらに複雑な場合は、WiresharkやMicrosoft Message Analyzerなどのネットワークキャプチャツールを使って、ICMPやRDPトラフィックがどこでブロックされているかを調べるのも有効です。
ホストとサーバーの両側でパケットキャプチャを実行し、送信したパケットがサーバーに到達しているか、サーバーから応答が返っているかを比較することで、ブロックの原因や場所を特定できます。
まとめ
ドメインコントローラーとして設定したWindows Server 2019のVMが突然ホストからの通信を受け付けなくなる場合、主に以下のポイントをチェックすると解決につながりやすいです。
- ドメインファイアウォールの受信規則を再確認し、RDPやICMPが許可されているか
- Hyper-Vの外部仮想スイッチ設定で「管理OSとの共有」が正しく行われているか
- サーバー再起動やグループポリシー更新でファイアウォールの設定が上書きされていないか
- ホストをドメインに参加させることでポリシーや認証の整合性を取れるか
- DNS設定やイベントログ、ネットワークキャプチャツールを活用して詳細を調査
最終的には、ドメインファイアウォールのルールを必要最低限にカスタマイズするか、ホストマシンをドメインに参加させてポリシーの整合性を確保するといったアプローチが有効です。運用する環境やセキュリティポリシーに合わせて設定を最適化し、スムーズで安心できるサーバー管理を実現しましょう。
コメント