2025年12月に入ってから急に増えたのが、「Windowsは社内VPNでつながるのに、WSL（Windows Subsystem for Linux／Windows上でLinuxを動かす仕組み）の中だけVPSや社内リソースへ行けない」という報告です。エラーはだいたい同じで、WSL側で通信すると 「No route to host（ホストへの経路がありません）」。開発だけじゃなく、セキュリティ運用やインフラ運用で“WSLから社内に入る”人ほど直撃します。 (マイクロソフトサポート)
- 何が起きてる？いちばん厄介なのは「WindowsはOK、WSLだけNG」
- 発生日時と影響する更新プログラム（KB番号・ビルド）
- 影響範囲：誰が刺さりやすい？（企業VPN＋mirroredが条件）
- 原因：推定じゃなく“Microsoftが書いた”核心
- 公式対応状況：いま直ってる？回避策は？
- まず切り分け：あなたが“この不具合”か、3分で当てる
- 暫定対処：mirrored networkingを外してNATへ戻す（いま一番効きやすい）
- もう一段の対処：更新プログラムのアンインストールはアリ？ナシ？
- 企業IT・情シス向けの現実論：ロールアウト前提を変えるべき？
- みんなの報告スレ：あなたの環境、書き残して（コメント欄テンプレ）
- 考察：VPN互換性のためのmirroredが、なぜVPNで倒れたのか
- まとめ：今日の結論は「mirroredを外して、まず仕事を通す」
何が起きてる？いちばん厄介なのは「WindowsはOK、WSLだけNG」
Windowsホストは同じ宛先へ到達できるのに、WSL（特にmirrored networking）だけがVPN越しに詰まります。 (マイクロソフトサポート)
体感としては「社内のGit、社内DNS、踏み台VPS、社内Kubernetes、全部WSLだけ死ぬ」。Windows側のPowerShellからSSHすると通るのに、WSLのsshだけ落ちる…この分断が精神にきます。
発生日時と影響する更新プログラム（KB番号・ビルド）
起点として名指しされているのは、2025年10月28日公開のKB5067036（OS Builds 26200.7019 / 26100.7019）で、それ以降の更新でも起こり得ます。 (マイクロソフトサポート)
時系列で並べると、ざっくりこうです。
2025年10月28日：Windows 11 24H2/25H2向け 非セキュリティ更新（プレビュー）KB5067036 公開 (マイクロソフトサポート)
2025年11月11日：KB5068861あたりで「mirrored＋VPNが死んだ」という個別報告も登場 (GitHub)
2025年12月9日：累積更新KB5072033の既知の問題（Known issues）に、このWSL障害が明記される (マイクロソフトサポート)
つまり、「10月のプレビューを入れてから潜在的に壊れ、12月の累積で表面化した」パターンも普通にありえます。(マイクロソフトサポート)
影響範囲：誰が刺さりやすい？（企業VPN＋mirroredが条件）
条件がそろうと再現しやすいのは、WSL 2でmirrored networking（ミラード ネットワーキング）を有効にし、第三者製VPNで社内へ入っているケースです。 (マイクロソフトサポート)
Microsoft側の説明でも「Windows Home/Proの一般ユーザーは遭遇しにくい」「企業リソース、DirectAccess（ダイレクトアクセス）などが主戦場」とされています。(マイクロソフトサポート)
逆に言うと、情シス配布のCisco Secure Client（旧Cisco AnyConnect）やOpenVPN、ここを使ってる人は要警戒。(マイクロソフトサポート)
原因：推定じゃなく“Microsoftが書いた”核心
原因は「VPNアプリの仮想インターフェイスがARP（Address Resolution Protocol／アドレス解決プロトコル）要求に応答しない」こと、と明記されています。 (マイクロソフトサポート)
ARPって地味だけど超重要で、ざっくり言えば「IPアドレスからMACアドレスを引くための近所づきあい」です。mirrored networkingは、Windows側のネットワークをWSLへ“ミラー”する新アーキテクチャなので、ここでARPがコケるとLinux側は「次にどこへ投げればいいか分からん…」となり、結果として「No route to host」になりがち、という流れ。(マイクロソフトサポート)
公式対応状況：いま直ってる？回避策は？
2025年12月17日（日本時間）時点で、Microsoftは“調査中（under investigation）”で、公式の確定回避策は提示していません。 (マイクロソフトサポート)
これがつらいところで、「直るまで待つ」以外の公式ルートが薄い。だから現場では、次の“現実的な一手”に流れています。
まず切り分け：あなたが“この不具合”か、3分で当てる
「mirroredが有効」「KB5067036以降が入った」「VPN越しだけWSLが死ぬ」この3点セットなら、かなり当たりです。 (マイクロソフトサポート)
(1) Windowsの「更新履歴」でKB番号を確認します（KB5067036/KB5072033/KB5068861など）。 (マイクロソフトサポート)
(2) %UserProfile%\.wslconfig に networkingMode=mirrored があるか確認します（Windows 11 22H2以降で使われがち）。 (Microsoft Learn)
(3) Windowsホスト（PowerShellのcurlやssh）は通るのに、WSL（Ubuntu等）から同じ宛先へ行くと「No route to host」になるか見ます。 (マイクロソフトサポート)
GitHubの報告例だと、Windows 11 24H2、WSL 2.6.2.0、Ubuntu 24.04、.wslconfigでmirrored＋dnsTunnelingが有効、そして「VPN向こうだけ落ちる」という条件が並んでいました。(GitHub)
暫定対処：mirrored networkingを外してNATへ戻す（いま一番効きやすい）
応急処置としては、WSLをNAT（Network Address Translation／ネットワークアドレス変換）へ戻すのが“被害を止める”近道です。 (Microsoft Learn)
やることはシンプルですが、職場PCだとポリシーが絡むので、慎重にいきます。
(1) Windowsのユーザーフォルダにある .wslconfig を見つけます（例：C:\Users\<ユーザー名>\.wslconfig）。 (Microsoft Learn)
(2) 念のためバックアップを作ります（例：.wslconfig.bak）。
(3) いまこうなっていたら、networkingMode=mirrored を削除するか、NATへ変更します。
例（NATへ戻す書き方の一例）
[wsl2]
networkingMode=nat
(4) PowerShellで wsl --shutdown を実行してWSLを完全停止します（再起動だけだと残ることがあるので、ここはちゃんと）。
(5) VPNをいったん切断→再接続してから、WSLを起動し直して疎通確認します。
mirroredを捨てると、LANからWSLへ直接到達しづらくなるなど“うれしさ”も失います。だけど今は、仕事を進めるほうが大事…って人がほとんどでしょう。don’t worry、戻せます。
もう一段の対処：更新プログラムのアンインストールはアリ？ナシ？
アンインストールは効くケースがありますが、セキュリティ運用と衝突しやすいので、企業では判断が分かれます。 (GitHub)
GitHubの報告では「該当KBを外すと復旧した」という声があります。(GitHub)
ただし、12月の累積更新（KB5072033）を外す判断は、組織のルール次第でかなり重いです。ここはコメント欄でも「外した／外せなかった」体験談が集まると助かるやつ。
企業IT・情シス向けの現実論：ロールアウト前提を変えるべき？
WSLを業務導線に組み込んでいる組織ほど、「Windows更新＝即展開」から「検証リング」を強制したほうが安全です。 (マイクロソフトサポート)
今回のポイントは、OSのネットワークとVPNクライアントとWSLの三者が絡むこと。しかもmirroredは新しめの仕組みで、VPN側の仮想NIC実装差がモロに出ます。
「同じCiscoでもバージョン違いで出る／出ない」「OpenVPNでもTUN/TAPで違う」みたいな話が出てくるの、たぶんこれからです（体感ね）。(SparkLabs)
みんなの報告スレ：あなたの環境、書き残して（コメント欄テンプレ）
再現条件の“地図”を作るのが一番早いので、よければこの形で置いていってください。
テンプレ：
発生したKB番号（例：KB5067036 / KB5072033 / KB5068861）
Windows 11のバージョン（24H2/25H2）とOS Build（分かれば）
VPNクライアント名（Cisco Secure Client / OpenVPN など）
WSLのバージョン（例：2.6.2.0）とディストリビューション（Ubuntu 24.04等）
.wslconfig のネットワーク設定（mirrored / nat、dnsTunnelingの有無）
症状（ping/ssh/curlのどれが死ぬ？「No route to host」以外のログは？） (GitHub)
「うちはmirroredでも平気」「Ciscoはダメだけど別VPNはいけた」みたいな“ズレ”こそ、価値があります。
考察：VPN互換性のためのmirroredが、なぜVPNで倒れたのか
mirroredは“WSLがWindowsと同じネットワークにいる前提”で賢くなる分、VPN仮想NICの癖を正面から食らいます。 (Microsoft Learn)
NATだと、WSLは基本「Windowsが代理で外に出す」形なので、VPNの内側へ行く通信も“Windows発”として処理されやすい。ところがmirroredは、WSLがより直接にネットワークへ参加する設計で、ARPみたいな低レイヤが急に表舞台へ出てくる。そこに更新で何かが変わり、VPNの仮想インターフェイスが応答しなくなった（あるいは応答できない条件が増えた）。
結果、Windowsアプリは通るのにWSLだけ落ちる…この気持ち悪い分断が完成、というわけです。うーん、しんど。(マイクロソフトサポート)
まとめ：今日の結論は「mirroredを外して、まず仕事を通す」
公式修正が出るまでの暫定策としては、mirrored networkingを解除してNATへ戻すのが最も再現性が高い対処です。 (マイクロソフトサポート)
もしあなたが「No route to host」で詰まってるなら、まずはKB番号と.wslconfigを見てください。で、直った／直らないをコメントに残してほしい。次に刺さる人の“助け舟”になります。 (GitHub)
