はじめに

Windows Server (ドメインコントローラ兼DNSサーバ) で複数NICを有効にした環境において、

「あるNIC (LAN2) 上で確立していた通信が、別のNIC (LAN3) にケーブルを挿すと切断される」
アプリケーション側では WSAECONNABORTED (10053) エラーが発生する
Windowsイベントビューアには通信断が記録されない
といった問題が起こることがあります。
今回の事例では、実際のパケットキャプチャを解析した結果、「NetLogon再バインド」と呼ばれる Active Directory 特有の挙動が通信切断の主原因と推測されました。

本記事では、このトラブルシュートの過程と原因の考察、そして再発防止策について整理します。

現象の概要

ドメインコントローラ (AD + DNSサーバ) を稼働する Windows Server 2022 マシンがある
このマシンは複数のNIC (LANポート) を有効にしており、OSからは LAN1 / LAN2 / LAN3 / LAN4 として見える
LAN2 で確立していた通信(アプリのTCPセッション)が、LAN3 や他のLANポートにケーブルを挿すと突然切断される
アプリ側ログには WSAECONNABORTED (10053) が出力され、サーバ側では TCP RST が返されている形跡
Windows イベントログには特に「リンク断」などは残っていない

このように、一見すると「物理層の混線」や「NICドライバの不具合」を疑いたくなる挙動ですが、実際にパケットキャプチャ（Wireshark など）を取ってみると、次のようなパターンが見えました。

パケットキャプチャで判明した挙動

LAN2キャプチャ

TCPセッションが再送 (Retransmission) を繰り返し、最終的にサーバから RST が返る
その間に IGMPv3 / LLMNR / mDNS など、複数NICが起動した際のマルチキャスト・名前解決関連パケットが大量に見える

LAN3キャプチャ

ケーブル挿入直後に ARP Probe, NBNS, LLMNR, mDNS, IGMPv3 Join など、Windows が「NICを新たに有効化した直後」に行う典型的なマルチキャスト探索が多発
「LAN2の通信を意図的に切断する」ような直接的パケットは見えない

これらを総合すると、「LAN3 をリンクアップする → OSがマルチホーミング環境を再評価 → NetLogonや
DNS関連サービスが再バインド → 既存TCPセッションを強制RST」という流れが疑われます。

「NetLogon再バインド」とは何か？

ドメインコントローラ＋複数NICの難しさ

ドメインコントローラ(DC)は、起動やNIC状態変化のたびに DNS動的登録 (Dynamic Update) や NetLogonサービスの再初期化を行う場合があります。
マルチホーミング構成（複数NICが有効）だと、DCが自身のホスト名を複数アドレスでDNSに登録しようと試みるなど、思わぬ再初期化が起こりがちです。

再バインドの結果

Windows Server は「NICが増えた（ケーブル挿した）」タイミングでルーティングやDNS設定を再評価し、NetLogonが再バインド(再起動)されることがあります。
その過程で既存のTCPセッションが RST で切断され、アプリケーション側から見ると「突然回線断 → WSAECONNABORTED (10053)」が発生するというわけです。

よくある他の原因

NIC省電力機能 (EEE, Link State Power Management, WoL)
- 短時間のリンクダウンを起こす可能性がある
- ただし、本件では無効化しても改善しなかった
NICドライバの不具合
- 最新版を入れても再現する場合、ハード的な問題よりは OS レイヤの再初期化が本質的な原因のことが多い
ルーティング競合・複数ゲートウェイ設定
- 同一サブネットに複数NICが存在する、複数GWが設定されている… などで OS が経路を再計算し、セッション断が発生することも

解決策・回避策

ドメインコントローラを「シングルNIC」で運用

もっともシンプルかつ確実なのは、ドメインコントローラ上のNICを1本に絞ることです。

他NICを使わないのであれば、デバイスマネージャやBIOSで無効化
ADのマルチホーミングは、Microsoftでも推奨されていないケースが多く、シングルNICが原則

どうしても複数NICが必要なら…

1つのNIC(メインNIC) だけ「DNSに登録する」「デフォルトゲートウェイを設定する」
他のNICは

「この接続のアドレスをDNSに登録する」をオフ
デフォルトゲートウェイは未設定
必要があれば、静的ルートを個別に設定

省電力機能 (EEE, Link State Power Management) は無効が安定
ケーブルを抜き差しする場合は極力サーバの運用時間外に行う（物理リンク変化を避ける）

こうすることで、AD や NetLogon が「メインNIC以外のIPを DNS 登録しよう」としなくなるため、不要な再バインドが減って既存通信への影響も最小限になります。

レジストリ設定で DNS動的更新を無効化？

DisableDynamicUpdate=1 や RegisterDnsARecords=0 (NetLogonパラメータ) を使えば、動的DNS登録をグローバルに無効化できますが、DCとしてのSRVレコード登録などまで止まるため要注意。
原則的には NICごとに「DNS登録するかどうか」を制御する方法がベストプラクティスです。

パケットキャプチャの観点

もし「物理的にLAN2のTCPパケットがLAN3へ混線しているのでは？」と疑うなら、リングバッファ(物理ポートごとの送受信バッファ)は独立しており、混線はまず起きないことを理解しましょう。
実際は OSのネットワークスタックが「LAN3を有効化」→「NetLogon再バインド」→「LAN2の既存接続を RST」としているだけです。
パケットキャプチャで “RST を投げている側” を見ると、サーバが明確に「切る意思」で TCP RST を送っているのが分かります。

まとめ

Windows Server のドメインコントローラに複数NICを有効化すると、ケーブルの挿抜やOS起動時に NetLogonサービスが再バインドを引き起こし、既存セッションが強制的に切断される事象が起こりやすいです。
パケットキャプチャで IGMP/LLMNR/mDNS/NBNS が急増しているタイミングで TCP RST が見られる場合、マルチホーミング構成×AD特有の再初期化を疑ってください。
ベストプラクティス：シングルNIC運用。もし複数NICが必要なら、メインNIC以外のDNS登録をオフにし、ゲートウェイを設定しないなどでトリガーを最小化すると安定します。