https://error-daizenn.hatenablog.com/entry/2025/12/16/223734

2025年12月16日ごろから、「Windowsの更新を入れたら、WSL（Windows Subsystem for Linux／Windows上でLinuxを動かす仕組み）だけVPNの社内リソースに届かない」という声が一気に増えています。仕事でWSLを使い、Cisco Secure Client（旧AnyConnect）やOpenVPN（オープンブイピーエヌ）など“企業VPN”を噛ませている人ほど直撃しやすいタイプ。Windows本体は繋がるのに、WSL内だけが詰まる……これ、地味にキツいです。 (bleepingcomputer.com)

何が起きてる？「WindowsはOK、WSLだけNG」という分断

WSLの中からだけ社内ネットワークへ到達できず、エラーが「No route to host（ホストへの経路がありません）」になりがちです。 (bleepingcomputer.com)

ポイントは“VPN自体が死んだ”というより、“WSLのネットワーク方式とVPNの相性が、特定の更新以降で崩れた”ニュアンス。Windowsホスト側（普段のEdgeやPowerShell）では同じ宛先にアクセスできるのに、WSL（Ubuntuなど）からだけ届かない、という報告が典型です。 (bleepingcomputer.com)

発生時期と影響する更新プログラム

起点として名指しされているのは、2025年10月28日公開のプレビュー更新「KB5067036（OS Builds 26200.7019 / 26100.7019）」以降です。 (マイクロソフトサポート)

Microsoftのサポート文書では、Windows 11 25H2/24H2向けのKB5067036（Preview／プレビュー）を入れた後、または“それ以降の更新”で、WSLのmirrored networking mode（ミラード・ネットワーキング・モード）が一部サードパーティVPNで問題を起こす、と明記されています。 (マイクロソフトサポート)

実際、GitHubのWSL公式リポジトリでは、2025年11月のセキュリティ更新「KB5068861」で壊れた、という形の報告も出ています（ただし根っこは「KB5067036以降の系統」で語られがち）。 (GitHub)

典型症状：エラー表記と、地味に刺さるログ

画面上の決定打は「No route to host」ですが、ログは「connect() failed: 101」などLinuxっぽい失敗が混ざります。 (GitHub)

WSL側で社内ホストへpingやsshを投げた瞬間に落ちる、あるいは名前解決から不穏になる、という報告もあります。WSL GitHub Issueでは、getaddrinfo() failed: -5 や connect() failed: 101 が並んでいた例が出ています（数字だけ見ると「何それ…」ですが、要は“繋げに行く道が作れてない”方向の失敗）。 (GitHub)

原因：Microsoftが挙げた「ARP不応答」がかなり核心

原因は「VPNの仮想インターフェースがARP（Address Resolution Protocol／アドレス解決プロトコル）要求に応答しない」ことだと説明されています。 (マイクロソフトサポート)

ARPはざっくり言うと「このIPアドレスの相手って、どのMACアドレス（機器の識別子）？」を問い合わせる仕組みです。mirrored modeは“Windows側のネットワークインターフェースをLinux側へミラーする”新しい構造で、VPN互換性の改善もメリットとして掲げられていました。なのに今回、その“ミラー”と“VPN仮想NIC”の会話が噛み合わず、WSL側だけが経路を作れない……という絵です。 (Microsoft Learn)

どのVPN/ユーザーが刺さりやすい？対象ユーザー層を整理

影響が濃いのは「企業VPN＋WSL2＋mirrored mode有効」の組み合わせで、家庭のWindows Home/Pro単体利用は当たりにくいとされています。 (マイクロソフトサポート)

Microsoftは、Cisco Secure Client（旧Cisco AnyConnect）とOpenVPNが影響例として挙がっている、と書いています。さらに「DirectAccess（ダイレクトアクセス：企業向けのリモートアクセス機構）」など“企業リソースへの到達”が主戦場で問題になる、とも。 (マイクロソフトサポート)

逆に言うと、「WSLは入ってるけどmirrored modeは使ってない（デフォルトのNAT）」とか、「VPNは使うがWSLから社内へは繋いでない」なら、気づかずにスルーしてる人も多いはずです。ここ、落とし穴。

公式対応状況：修正は？回避策は？

現時点で公式は“調査中（under investigation）”で、修正時期も具体的な回避策も未提示です。 (マイクロソフトサポート)

サポート文書の「Workaround（回避策）」欄が、事実上「調査して後で共有するね」で止まっています。だからこそ、現場では“mirrored modeを一旦やめる”が最も現実的な暫定策として流通しています（公式が言い切ってはいないけど、症状の構造的に効きやすい）。 (マイクロソフトサポート)

いま取れる現実的な対処：mirrored modeをいったん外す

応急処置としては「WSLをNAT（Network Address Translation／ネットワークアドレス変換）に戻す」が一番手堅いです。 (Microsoft Learn)

手順はやること自体は単純です。怖いのは“どこを触ったか分からなくなる”ことなので、バックアップだけ丁寧に。

(1) Windowsのユーザーフォルダにある「.wslconfig」を探します（例：C:\Users\<ユーザー名>\.wslconfig）。
(2) 念のため、同じ場所にコピーを作って退避します（ファイル名を.wslconfig.bakなどに）。
(3) .wslconfigを開き、networkingMode=mirrored が書いてある場合は削除するか、いったん記述を外します（＝デフォルトのNAT動作に戻す狙い）。
(4) PowerShellで wsl --shutdown を実行してWSLを完全停止します。
(5) VPNをいったん切断→再接続してから、WSLを起動し直して疎通確認します。

mirrored modeのメリット（IPv6対応やLANからWSLへ直接到達など）が必要で有効化していた人ほど、ここは悩ましいはず。なのでコメント欄で「mirroredを捨てたら何が困ったか」もぜひ共有してほしい。あなたの詰まりポイント、同じ人が絶対いる。

切り分けチェック：自分が“この不具合”に当たってるか？

見分け方は「Windowsホストは届くのに、WSLだけ届かない」＋「mirrored modeが有効」＋「KB5067036以降」が揃うかです。 (マイクロソフトサポート)

確認するときは、OSビルド（例：26200系/26100系）と、入っているKB、WSLのバージョン、VPNクライアント名の4点が揃うと判断が速いです。WSL GitHubの報告例だと、Windows 11 24H2/25H2、WSL 2.6.x、Kernel 6.6.87.2-1、Cisco AnyConnect系、そして .wslconfig に networkingMode=mirrored が書いてある、みたいな並びが見えます。 (GitHub)

ついでに：VPN絡みの混乱、実は他でも起きてる（SoundCloud 403）

SoundCloudでもVPN利用者が403（Forbidden／アクセス拒否）になる障害が続き、設定変更が原因で復旧対応中と説明されています。 (bleepingcomputer.com)

「VPNって便利ツールでしょ？」で済まない国・地域や事情もあるので、この手の障害は感情面でも燃えやすい。Redditでは「VPNが唯一の手段なのに遮断された」という切実な投稿も出ています。 (Reddit)

朗報：白フラッシュ（白い点滅）は直ったケースもある

別件ですが、KB5070311で起きたエクスプローラーの白フラッシュは、KB5072033で修正されたと案内されています。 (マイクロソフトサポート)

最近の更新は「直る話」も「壊れる話」も同時に流れてくるので、情緒が追いつかないんですよね…。でも少なくとも、白フラッシュは“Known issue（既知の問題）→修正”の流れがはっきりしていました。 (マイクロソフトサポート)

コメント欄をフォーラム化したい：あなたの環境、教えて

同じ「No route to host」でも条件が微妙に違うので、再現条件を集めると次の一手が見えます。 (マイクロソフトサポート)

書ける範囲でいいので、こんな順で置いていってください。文章のままでもOK、短くてもOK。
まずWindowsのバージョンとOSビルド（例：Windows 11 25H2 / 26200.x）。次に問題が出たKB（例：KB5067036、KB5068861、KB5072033など）。次にWSLのバージョン（例：2.6.1.0 / 2.6.2.0）。次にVPN（Cisco Secure Client、OpenVPNなど）。最後に .wslconfig で mirrored modeを使っているか、そして出たエラー文（No route to host、connect failed 101…みたいなやつ）。 (マイクロソフトサポート)

まとめ：当面の結論は「mirroredを外して耐える」が強い

企業VPN＋WSL mirroring運用の人は、修正が来るまでNATへ戻すのが一番安全寄りの暫定策です。 (マイクロソフトサポート)

あなたはどっち派ですか？「mirroredの恩恵が大きいから死守したい」か、「仕事が止まるから一旦オフ」か。あと、Cisco系とOpenVPN系で体感差があるのかも気になります。コメント欄で、遠慮なく“生の環境”を投げてください。