MENU

Windows Serverのホストルートが効かずデフォルトゲートウェイに流れる原因と対処｜ESXi VLAN設定の落とし穴

ネットワーク

Windows ServerでNICを2枚挿し、特定ホスト宛に/32の静的ルート（ホストルート）を入れているのに、なぜかデフォルトゲートウェイ側へ出てしまう――。この手の現象は「ルート表の見た目」と「実際に成立している経路」がズレると起きます。本記事では、原因がWindowsではなくESXiのVLAN設定だったケースを、確認コマンドと切り分け手順付きで解説します。

目次

結論：Windowsがルートを無視したのではなく、上位のVLAN不整合で“そのルートが成立していなかった”

最初に結論です。今回の症状はWindows Serverのルーティング選択（最長一致・メトリック）そのものが壊れていたわけではありません。上位の仮想化基盤（ESXi）側で、対象NICがぶら下がるPort GroupのVLAN IDが誤っていたため、Windowsから見ると一見「ゲートウェイへは届く」ように見えても、実際にはゲートウェイが目的ネットワークへパケットを転送できない状態になっていました。

その結果、検証やログの見え方として「より具体的なホストルートがあるのに、デフォルトゲートウェイへ流れている（ように見える）」状態になっていた、という整理です。

前提構成：2つのNICを持つWindows Server（マルチホーム）

問題の構成を、今回のケースに沿って整理します。ポイントはNICが2つあり、片方にデフォルトゲートウェイ、もう片方に特定ホスト向けのより具体的な経路があるという点です。

項目NIC1NIC2
IPアドレス/プレフィックス192.168.101.19/24192.168.151.253/24
デフォルトGW192.168.101.1（設定なし、または別GW）
想定する役割通常のインターネット/社内向け出口特定ネットワーク/特定ホスト宛の専用経路
期待する通信一般宛先はNIC1へ192.168.126.14宛はNIC2へ

そして、NIC2側には「目的ホスト 192.168.126.14 宛のより具体的な経路（ホストルート）」がある前提です。例として、ルート表は次のようなイメージになります（実際のゲートウェイIPは環境に合わせて読み替えてください）。

宛先ネットマスク次ホップ（ゲートウェイ）インターフェースメトリック意味
192.168.126.14255.255.255.255（NIC2側GW）NIC2低いホストルート（最優先にしたい）
0.0.0.00.0.0.0192.168.101.1NIC1高いデフォルトルート

本来の動作：Windowsのルーティングは「最長一致 → メトリック」の順に決まる

まず大前提として、Windows ServerのIPv4ルーティングは原則として次の順番で送信先を決めます。

優先順位判定要素見るポイントこのケースでの意味
1最長一致（Longest Prefix Match）/32が最強、次に/24…、最後に/0192.168.126.14/32はデフォルト(0.0.0.0/0)より必ず優先
2メトリック（小さいほど優先）ルートメトリック + インターフェースメトリック同じプレフィックス長の候補が複数あるときに効く
3同値の場合の細かい規則ECMP、到達性、実装依存の最終選択ここに入る前に通常は決着する

つまり、ホストルート（/32）が存在する限り、デフォルトルートに“負ける”ことは基本的にありません。メトリックがどうこう以前に、プレフィックス長が違うからです。

「メトリックが低いのに負ける」のではなく、「その経路が使える前提が崩れている」ケースがある

それでも現場では「/32があるのにデフォルトへ行く」ような挙動に遭遇します。こういうとき、実は次のどれかに該当していることが多いです。

  • ホストルートが思ったルート表に載っていない（ActiveStoreにいない／永続ルートが反映されていない）
  • ホストルートの次ホップが間違っている、または到達できない
  • NICやVLANなどL2の不整合で、ホストルートに使う“出口”が実質的に通信できていない
  • 観測方法（tracertやログの取り方）が原因で、実際の出口と違うように見えている

今回の結論は3つ目、つまりOSの設定ではなく、仮想化基盤側のL2（VLAN）不備でした。

症状の具体像：「ゲートウェイへpingは通る」でも「ゲートウェイ経由で先へ届かない」

今回のケースをややこしくしたのは、Windows側から見るとNIC2側のゲートウェイにpingが通るように見えていた点です。すると人間はこう考えがちです。

  • 「ゲートウェイに届くなら、L2はOK」
  • 「あとはルーティング（L3）の問題だろう」
  • 「でもルート表では/32が勝ってるはず…なぜ？」

しかし現実には、ゲートウェイへの到達（ICMP Echoが返る）と、ゲートウェイが目的ネットワークへ転送できるは別物です。特に仮想環境では、Port GroupのVLAN設定ひとつで「同一セグメントの一部だけ通る」「同じESXi内の通信は通るが外へ出ない」といった中途半端な状態が起きえます。

ESXiのPort Group VLAN IDが間違うと何が起きるのか

ESXiでは、仮想NICが接続されるPort GroupにVLAN IDを設定できます。ここが誤っていると、VMから出るフレームのタグ付けが意図と変わり、結果として物理スイッチ側のVLAN設計と食い違います。

  • Port GroupにVLAN IDが未設定（0 / None相当）なのに、物理側はタグ付きVLANを期待している
  • Port GroupのVLAN IDが別番号になっていて、意図しないVLANへ収容されている
  • Port Groupが「4095（VLAN trunking）」なのに、ゲストOS側でVLANタグを付けていない（VGTの前提が崩れている）

この状態だと、Windowsからは「リンクはUp」「IPも付いている」「同一セグメントの特定機器には届く」ように見えても、ルータでの転送や、物理ネットワークの先までを含めた通信が成立しないことがあります。

なぜ「デフォルトへ流れた」と見えるのか：観測と挙動のズレを理解する

今回の結論は「ESXi側のVLAN不備」ですが、現場で混乱が起きるのは、原因がL2にあるのにL3（ルーティング）の問題に見えるからです。ここでは、実務でよく起こる“見え方の罠”を整理します。

罠1：アプリやOSの再試行で「別経路に見える」

通信が失敗すると、アプリケーションやOSスタックが再試行を行うことがあります。例えばDNS名に複数のAレコードがあり別IPへ再接続したり、TCPの到達性の都合で別ゲートウェイを選び直したり（環境によってはDead Gateway Detectionが働く場面もあります）すると、結果として別NICから出たように見えることがあります。

重要なのは、「ルート表上で/32が優先される」は正しい一方で、通信が成功しているかどうかは経路全体（L2/VLAN〜ゲートウェイ〜その先）で決まる、という点です。

罠2：「ゲートウェイまでの疎通」しか確認していない

ゲートウェイへpingが通ると安心しがちですが、今回のようにゲートウェイは応答するが転送できない状況は珍しくありません。切り分けでは、少なくとも次の2段階を意識すると迷子になりにくいです。

  • 段階A：ゲートウェイ自身に到達できるか（同一セグメントのL2疎通）
  • 段階B：ゲートウェイ経由で目的ホストへ到達できるか（L3転送が成立）

罠3：送信元IPが意図と違い、ログが“別出口”に見せる

マルチホーム環境では、アプリがどのIPで通信を開始したか（送信元IP）が重要です。例えばアプリがNIC1側のIPにバインドしていると、相手側のファイアウォールやルータの制御で、意図しない経路（あるいは片方向）になり得ます。切り分けの段階では、送信元を固定した検証が必須です。

まずWindows側でやるべき確認：ルート表・メトリック・出口インターフェースの見える化

原因が上位ネットワークであっても、最初にWindows側の状態を整理しておくと、後工程（ESXi/物理スイッチ）の確認が一気に楽になります。ここでは、実際に使える確認コマンドをまとめます。

目的コマンド例見たいポイント
ルート表の全体像route print192.168.126.14/32が存在するか、どのIF/メトリックか
PowerShellでルート確認Get-NetRoute -AddressFamily IPv4 | Sort-Object DestinationPrefix, RouteMetricDestinationPrefix/NextHop/InterfaceIndexの整合
永続ルートとアクティブルートの差分確認Get-NetRoute -AddressFamily IPv4 -PolicyStore PersistentStore Get-NetRoute -AddressFamily IPv4 -PolicyStore ActiveStore「入れたはずのルート」がActiveStoreに載っているか
IFメトリック確認Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetricInterfaceMetricが自動で想定外になっていないか
ARP/近傍確認arp -aNIC2側GWのMACが解決できているか

設定例：/32（ホストルート）を正しく追加・永続化する

「ホストルートを入れているつもりだったが、実はマスク違いだった」「再起動で消えていた」といった事故もよくあります。/32の静的ルートを入れる代表例を載せます（ゲートウェイとIF番号は環境に合わせて置き換えてください）。

route print

まずはIF番号（Interface Listの番号）を確認します。そのうえで、永続（-p）かつIF指定で追加すると、意図がブレにくくなります。

route -p add 192.168.126.14 mask 255.255.255.255 192.168.151.1 metric 5 if 12

PowerShell派なら、次のように追加・削除できます。

New-NetRoute -DestinationPrefix "192.168.126.14/32" -InterfaceIndex 12 -NextHop "192.168.151.1" -RouteMetric 5
Remove-NetRoute -DestinationPrefix "192.168.126.14/32" -InterfaceIndex 12 -NextHop "192.168.151.1"

送信元を固定して「どのNICから出たか」を確認する

マルチホームの切り分けで強力なのが、送信元を固定した疎通です。Windowsのpingは送信元IPを指定できます。

ping -S 192.168.151.253 192.168.126.14
ping -S 192.168.101.19  192.168.126.14

これで「NIC2から出したい通信が本当にNIC2から出ているのか」「送信元を変えると挙動が変わるか」が分かります。tracertも送信元指定が可能です。

tracert -d -S 192.168.151.253 192.168.126.14

デフォルトゲートウェイは原則“1つ”に寄せる

Windows ServerでNICが複数あるとき、設計としておすすめなのはデフォルトゲートウェイは基本的に1つにし、他の経路は静的ルートで明示することです。複数NICにデフォルトGWが入っていると、メトリックや到達性の変化で出口が揺れ、切り分けが難しくなります。

例外として冗長化目的で複数デフォルトGWを持つ設計もありますが、その場合でも「どういう条件で切り替わるか（監視・再送・DGDの影響）」を理解したうえで運用するのが安全です。

パケットで確認する（Windows標準のpktmonでもOK）

「ルート表は正しそうなのに結果が変」というとき、パケットを見ると一気に真相に近づけます。Wiresharkが入れにくいサーバーでも、Windowsにはpktmonが標準搭載されています（OSバージョンによって差はあります）。

pktmon filter remove
pktmon filter add -i <NIC2のIfIndex>
pktmon start --etw -m real-time

ETW形式で取得して解析する流れもありますが、まずは「NIC2から出ていない」「出ているが応答がない」などの一次情報が取れれば十分です。

ここで詰まったら疑うべき：仮想環境（ESXi）のPort Group/VLAN設定

Windows側のルートやメトリックが整っているのに、特定NIC経由の通信だけ“先へ進まない”場合、仮想基盤のL2設定を疑う価値が急上昇します。特にESXiでは、Port GroupのVLAN設定が原因のことがよくあります。

確認ポイントありがちな誤り起きる症状チェック方法の例
Port GroupのVLAN IDVLAN IDが未設定／別番号同一セグメントの一部は通るが、ルータ転送が通らないvSphereでPort Group設定を確認（VLAN ID）
VLAN 4095（トランク）利用ゲストOS側でタグ付けしていない通信が不安定／想定VLANに乗らないVGT前提かVST前提かを設計書で再確認
vSwitch/Distributed Switchのuplink物理NICの接続先ポートがAccessになっているVLANタグが落ちる／別VLANに混入物理スイッチ側のtrunk/allowed VLAN確認
物理スイッチのトランク許可VLANから抜けている／native VLAN不一致ゲートウェイだけ通る/通らないなど不可解な挙動トランク許可リスト、native VLAN、STP等の確認

「Port GroupのVLAN IDが入っていない」だけで起きる典型パターン

例えば、物理スイッチ〜ESXi間がトランクで、VLAN 151をタグ付きで流す設計なのに、Port GroupのVLAN IDが0（タグなし）になっていると、VMのNIC2はVLAN 151に乗りません。結果として、次のような現象が起き得ます。

  • VM内ではIPは設定できる（OSとしては問題に見えない）
  • 同一ESXi内の別VMや、たまたま到達できる範囲には応答がある
  • しかしルータで別セグメントへ転送する通信が成立しない

ここで「ゲートウェイにpingが通る」ケースが混じると、切り分けが一気に難しくなります。だからこそ、ゲートウェイの“その先”まで疎通試験をするのが重要です。

対処：ESXi側でVLAN設定を是正し、経路として成立させる

対処はシンプルです。ESXi側のPort Groupに正しいVLAN IDを設定（または、VLANタグ/トランク設計に合わせて設定を統一）し、NIC2側が本来のVLANに正しく収容される状態に戻します。

  1. 対象VMのNIC2が接続されているPort Groupを特定する
  2. Port GroupのVLAN IDが、設計どおりの番号になっているか確認する
  3. 物理スイッチ側のトランク許可VLANに、その番号が含まれているか確認する
  4. 必要に応じて、VLAN IDの設定を修正する（VST/VGTの方針も含めて整合させる）
  5. 修正後、Windows側で送信元固定ping/tracertを再実行し、期待どおりNIC2経由になることを確認する

この是正により、期待どおり「最も具体的な経路（ホストルート）」が使われ、192.168.126.14宛の通信が安定して成立します。

再発防止：OSのルート表だけ見ないための運用のコツ

同じ症状は、別環境でも繰り返し起こりがちです。特にマルチホーム＋仮想環境では、OSのルーティングと仮想スイッチ/物理スイッチの設定が分業になりやすいため、境界でミスが起きます。再発防止の観点で、効いた工夫をまとめます。

チェックリストを「L3だけ」で作らない

障害対応のチェックリストが「route printを見よう」「メトリックを調整しよう」で止まっていると、今回のようなL2不整合で時間を溶かします。L2まで含めたチェック項目にしておくのが効果的です。

レイヤ最低限の確認項目具体例
L1/L2リンク状態、VLAN整合、MAC学習Port Group VLAN ID、物理スイッチのtrunk/allowed VLAN、ARP
L3ルート表、次ホップ、メトリックGet-NetRoute、Get-NetIPInterface、静的ルートの永続化
L4〜送信元/戻り経路、FW/NAT送信元固定ping、FWログ、非対称ルーティングの有無

Port Group名にVLAN番号を含め、設計と運用を一致させる

地味ですが効きます。Port Group名に「VLAN151_APP」などとVLAN番号を含めておくと、設定ミスの発見が早くなります。VM追加時のレビューもやりやすく、属人性が下がります。

疎通試験は「ゲートウェイまで」と「ゲートウェイの先」をセットで行う

次の2つをワンセットにすると、今回のような“中途半端に通る”状態を早期に見抜けます。

  • NIC2のゲートウェイに送信元固定ping（L2疎通確認）
  • 目的ホスト（または同等の別セグメントホスト）に送信元固定ping/tracert（転送確認）

まとめ

「最も具体的な経路（ホストルート）があるのにデフォルトルートへ流れる」現象は、Windows Serverのルーティング選択が壊れているとは限りません。今回のように、仮想化基盤（ESXi）のPort Group VLAN IDの不整合によって、そのルートで使うゲートウェイが“到達はできても転送できない”状態になると、OSのルート表だけを見ても原因に到達しにくくなります。

マルチNIC環境で迷ったら、送信元固定の疎通と、ゲートウェイの先まで届くか、そしてVLAN/トランクの整合まで含めて確認してください。そうすれば「Windowsがルートを無視した」のではなく「経路として成立していなかった」ことを、短時間で切り分けられます。

ネットワーク
Windows Server デフォルトゲートウェイ VLAN ルーティング ESXi ホストルート

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次