MENU

WSLのmirrored networkingをVPN接続中に改善する方法｜KB5101681の適用・確認手順

Windows11

VPNへ接続したときだけ、WSL 2から社内Git、プライベートAPI、開発サーバーなどへ接続できなくなる場合は、Windows 11 26H1にKB5101681、またはそれ以降の累積更新プログラムを適用するのが最初の対処です。

2026年7月28日に公開されたKB5101681では、VPN利用時におけるWSLのmirrored networkingモードの使いやすさが改善されました。適用後のOSビルドは「28000.2608」です。Microsoftは、現時点でこの更新プログラムの既知の問題を認識していないと案内しています。(マイクロソフトサポート)

ただし、KB5101681の公式説明では、修正対象となった具体的なVPN製品、エラーコード、根本原因までは明らかにされていません。更新後も接続できない場合は、DNSトンネリング、プロキシ、Hyper-Vファイアウォール、VPNクライアント固有の設定を順番に切り分ける必要があります。

目次

VPN接続時のWSL mirrored networking問題はKB5101681で改善

KB5101681の概要は次のとおりです。

項目内容
対象OSWindows 11 バージョン26H1の全エディション
公開日2026年7月28日
更新プログラムKB5101681
適用後のOSビルド28000.2608
更新の種類非セキュリティのプレビュー累積更新
WSLの変更点VPN利用時におけるmirrored networkingモードの利用性を改善
公式な対応KB5101681またはそれ以降のビルドを適用
既知の問題Microsoftは現時点で認識していない
入手方法Windows UpdateまたはMicrosoft Update Catalog

Microsoft Update Catalogには、x64ベースとArm64ベースのWindows 11 26H1向けパッケージが登録されています。手動で入手する場合は、端末のアーキテクチャに合ったものを選択する必要があります。(マイクロソフトサポート)

KB5101681はプレビュー更新であり、セキュリティ更新ではありません。VPN経由でWSLを利用できず業務に影響している場合は早めの適用を検討できます。一方、問題が発生していない端末では、後続の累積更新に修正が含まれるのを待つ運用も可能です。

WSLのmirrored networkingとは

WSL 2では、Linux環境をWindows上の軽量な仮想マシンとして動かします。標準的なNATモードでは、WSL側にWindowsとは別の仮想ネットワークが作成されます。

mirrored networkingモードは、Windowsが持つネットワークインターフェースをLinux側へミラーリングする方式です。Windows 11 22H2以降で利用でき、VPNや複雑なネットワーク環境との互換性向上を目的としています。

Microsoftが案内している主な利点は次のとおりです。

  • VPNとのネットワーク互換性向上
  • IPv6のサポート
  • WSLからWindows上のサービスへ127.0.0.1で接続
  • マルチキャストのサポート
  • LAN上の端末からWSLへ直接接続

(Microsoft Learn)

NATモードとmirrored networkingモードの違いを整理すると、次のようになります。

比較項目NATモードmirrored networkingモード
ネットワーク構成WSL専用の仮想ネットワークWindowsのインターフェースをLinuxへ反映
既定値既定のネットワークモード利用者が設定
VPNとの互換性VPN製品やルート設定の影響を受けやすいVPN互換性の向上を目的としている
Windowsへのlocalhost接続構成によってホストIPの確認が必要127.0.0.1を利用可能
IPv6環境依存公式にサポート
LANからWSLへの接続ポート転送などが必要になる場合がある直接接続に対応。ただしファイアウォール規則が必要

mirrored networkingはVPN問題を減らすための有力な設定ですが、すべてのVPN製品やセキュリティ構成で接続を保証するものではありません。

KB5101681の対象になりやすい症状

MicrosoftはKB5101681で改善された具体的なエラー内容を公開していません。そのため、次の症状は「この更新で改善する可能性がある目安」として判断してください。

  • VPNを切断するとWSLから通信できる
  • VPNへ接続した直後からWSLの通信だけ失敗する
  • Windows側では社内サイトを開けるが、WSL側のcurlでは接続できない
  • 社内ドメインの名前解決だけ失敗する
  • VPNへ再接続したあと、WSLの通信が復旧しない
  • 社内Git、プライベートパッケージリポジトリ、データベースへ接続できない
  • WSL上の開発ツールだけプロキシを経由できない
  • Windowsでは正常なVPN経路がWSL側へ反映されていないように見える

反対に、Windows側でも同じ接続先へアクセスできない場合は、WSLではなくVPN接続、認証、社内ネットワーク、接続先サービス側の問題である可能性が高くなります。

KB5101681を適用する前の確認

Windows 11 26H1であることを確認する

Windowsキー + Rを押し、次のコマンドを実行します。

winver

表示された画面で、WindowsのバージョンとOSビルドを確認してください。

KB5101681の対象はWindows 11 26H1です。Windows 11 24H2や25H2にKB5101681を無理に適用することはできません。別のバージョンを使用している場合は、そのバージョン向けに提供されている最新の累積更新を確認します。

KB5101681適用後は、次のビルドになります。

28000.2608

すでに28000.2608より新しいビルドであれば、後続の累積更新によって修正が取り込まれている可能性があります。

使用中のLinuxがWSL 2であることを確認する

PowerShellまたはコマンドプロンプトで、次のコマンドを実行します。

wsl --list --verbose

実行例は次のとおりです。

  NAME      STATE           VERSION
* Ubuntu    Running         2

VERSIONが2であることを確認します。

.wslconfigによるmirrored networking設定はWSL 2に適用されます。WSL 1のディストリビューションには適用されません。(Microsoft Learn)

mirrored networkingが有効か確認する

PowerShellで次のコマンドを実行します。

Get-Content "$env:USERPROFILE\.wslconfig" -ErrorAction SilentlyContinue

次の設定が含まれていれば、mirrored networkingが指定されています。

[wsl2]
networkingMode=mirrored

.wslconfigが存在しない場合や、networkingMode=mirroredが記載されていない場合は、通常は既定のNATモードです。

設定ファイルを開くには、PowerShellで次のコマンドを実行します。

notepad "$env:USERPROFILE\.wslconfig"

すでに[wsl2]セクションがある場合は、新しい[wsl2]を重複して作らず、既存セクションへ設定を追加してください。

KB5101681を適用する手順

Windows Updateから適用する

個人端末や、利用者によるオプション更新のインストールが許可されている端末では、次の手順で適用します。

  1. 「設定」を開く
  2. 「Windows Update」を選択する
  3. 「詳細オプション」を開く
  4. 「オプションの更新プログラム」を選択する
  5. KB5101681を選択する
  6. ダウンロードとインストールを実行する
  7. Windowsを再起動する

KB5101681は非セキュリティのプレビュー更新であるため、通常のセキュリティ更新とは別に表示される場合があります。Microsoftの案内でも、Windows Updateの「オプションの更新プログラム」からインストールする手順が示されています。(マイクロソフトサポート)

KB5101681が表示されない場合は、次の可能性を確認してください。

  • Windows 11 26H1ではない
  • すでに後続の累積更新が適用されている
  • 組織のWindows Updateポリシーでプレビュー更新が制限されている
  • 更新プログラムの提供対象になっていない
  • 再起動待ちの更新が残っている
  • 段階的ロールアウトのため、対象機能の有効化時期が端末ごとに異なる

Microsoftは、KB5101681の一部を段階的ロールアウトで提供すると説明しています。段階的ロールアウト対象の機能は、同じ更新プログラムを適用した端末でも利用可能になる時期が異なる場合があります。(マイクロソフトサポート)

Microsoft Update Catalogから適用する

Windows Updateに表示されない場合は、Microsoft Update Catalogから手動で入手できます。

Catalogには次のパッケージが用意されています。

  • x64ベースシステム用
  • Arm64ベースシステム用

端末のアーキテクチャは、「設定」から「システム」「バージョン情報」の順に開き、「システムの種類」で確認できます。

Microsoftの案内では、KB5101681に複数のMSUファイルや前提パッケージが含まれる可能性があり、所定の順序でインストールする必要があるとされています。そのため、通常はWindows Updateを優先し、Catalogを使用する場合は公式のインストール手順に従ってください。(マイクロソフトサポート)

企業管理端末では、利用者が個別にCatalogから更新するのではなく、管理者がWindows Update for Business、WSUS、Intuneなどの更新方針に沿って展開するのが安全です。

WSL本体も最新化する

KB5101681はWindows側の更新プログラムです。一方、WSL本体はMicrosoft Storeなどを通じてWindowsとは別に更新されることがあります。

PowerShellで次のコマンドを実行してください。

wsl --version
wsl --update

続けて、WSLを完全に終了します。

wsl --shutdown

wsl --shutdownを実行すると、起動中のすべてのWSLディストリビューションが停止します。エディター、データベース、コンテナー、開発サーバーなどを終了し、作業中のファイルを保存してから実行してください。

.wslconfigの変更は、WSL仮想マシンが終了して再起動されたときに反映されます。単にLinuxのターミナル画面を閉じただけでは、WSLがバックグラウンドで動き続けている場合があります。(Microsoft Learn)

なお、wsl --updateだけではKB5101681の代わりにはなりません。今回のVPN改善を取り込むには、Windows 11側も28000.2608またはそれ以降へ更新する必要があります。

VPN接続前後で通信テストを行う

更新を適用したら、「VPN切断時」と「VPN接続時」の両方で同じテストを実行します。

Windows側のテスト

PowerShellで名前解決を確認します。

Resolve-DnsName internal.example.com

続けて、HTTPSポートへ接続できるか確認します。

Test-NetConnection internal.example.com -Port 443

internal.example.comは、実際に利用している社内サーバーのFQDNへ置き換えてください。

WSL側のテスト

WSL内で名前解決を確認します。

getent hosts internal.example.com

HTTPS接続を確認します。

curl -I --connect-timeout 10 https://internal.example.com/

ルーティング情報も確認します。

ip route

DNS構成を確認します。

cat /etc/resolv.conf

プロキシの環境変数を確認します。

env | grep -iE '^(http|https|no)_proxy='

結果の見方は次のとおりです。

Windows側WSL側疑うべき箇所
接続不可接続不可VPN接続、認証、社内ネットワーク、接続先サービス
接続可能名前解決不可DNSトンネリング、resolv.conf、DNSサフィックス
接続可能名前解決可能だがTCP接続不可ルート、VPNクライアント、ファイアウォール
接続可能curlは成功するが特定アプリだけ失敗アプリ固有のプロキシ、証明書、認証設定
WSLは成功Dockerコンテナーだけ失敗Docker Desktop側のDNSやネットワーク設定

pingだけで正常・異常を判断しないようにしてください。社内ネットワークではICMPを拒否していても、HTTPSやSSHなど必要な通信は許可されている場合があります。

VPN環境で確認したい.wslconfigの設定

mirrored networkingを有効にするだけなら、最小構成は次のとおりです。

[wsl2]
networkingMode=mirrored

VPN、DNS、プロキシを含めて設定を明示する場合は、次のように記載できます。

[wsl2]
networkingMode=mirrored
dnsTunneling=true
autoProxy=true
firewall=true

現在のMicrosoft Learnでは、dnsTunneling、autoProxy、firewallの既定値はいずれもtrueとされています。そのため、通常はすべてを明示する必要はありません。

重要なのは、過去のトラブル対処でfalseに変更していないかを確認することです。(Microsoft Learn)

dnsTunnelingを確認する

DNSトンネリングは、WSLからのDNS要求をWindows経由で処理する仕組みです。VPNがWindowsのNRPTポリシーや社内DNSサフィックスを利用している場合、WSL側にもその設定を反映しやすくなります。

Microsoftは、VPNとWSLを併用する場合にDNSトンネリングを有効にすることを案内しています。(Microsoft Learn)

ただし、Linux側の/etc/wsl.confに次の設定が残っていると、DNSトンネリングが正常に機能しません。

[network]
generateResolvConf=false

確認するにはWSL内で次のコマンドを実行します。

grep -n "generateResolvConf" /etc/wsl.conf 2>/dev/null

過去にVPN問題の回避策として/etc/resolv.confを手動編集していた場合は、この設定が残っていることがあります。

変更前にバックアップを作成します。

sudo cp /etc/wsl.conf /etc/wsl.conf.bak
sudo nano /etc/wsl.conf

手動DNS設定が不要であることを確認したうえで、generateResolvConf=falseを削除するか、次のように変更します。

[network]
generateResolvConf=true

変更後はWindows側のPowerShellで次を実行します。

wsl --shutdown

社内ネットワークの運用上、固定DNSサーバーを指定している場合は、設定を削除する前にネットワーク管理者へ確認してください。

autoProxyを確認する

autoProxy=trueにすると、Windows側のHTTPプロキシ情報をWSLへ反映できます。

WSLには、環境に応じて次の変数が設定されます。

  • HTTP_PROXY
  • HTTPS_PROXY
  • NO_PROXY
  • それぞれの小文字版

ただし、WindowsがPACファイルを使用している場合、WSLにはWSL_PAC_URLが設定されます。一般的なLinuxコマンドやアプリケーションはPACをそのまま解釈できない場合があるため、autoProxy=trueだけで通信できるとは限りません。(Microsoft Learn)

curlは動作するのに、npm、pip、apt、Gitなど特定のツールだけ失敗する場合は、各ツールのプロキシ設定も確認してください。

firewallを安易に無効化しない

mirrored networkingでは、WSLの通信にWindowsファイアウォールとHyper-Vファイアウォールの規則が適用されます。

WSL上でWebサーバーを起動し、WindowsやLANから接続する場合は、受信規則の追加が必要になることがあります。一方、WSLから社内サーバーへ接続する問題は送信方向の通信であるため、受信規則を開放しても改善しない場合があります。

原因確認のためであっても、.wslconfigでfirewall=falseにすることを最初の対処にしないでください。必要なポートと通信方向を特定し、最小限の規則を追加する方法が安全です。mirrored networkingではHyper-Vファイアウォールが関係することをMicrosoftも案内しています。(Microsoft Learn)

更新後も改善しない場合の切り分け

一時的にNATモードと比較する

問題がmirrored networking固有か確認するため、一時的にNATモードへ戻して比較できます。

[wsl2]
networkingMode=nat
dnsTunneling=true

設定後に次を実行します。

wsl --shutdown

NATモードでは接続でき、mirrored networkingでは接続できない場合は、VPNクライアントとミラー化されたインターフェース、ルーティング、Hyper-Vファイアウォールの組み合わせを重点的に確認します。

ただし、NATモードもVPN製品によってはルーティングの影響を受けます。NATへ戻すことは恒久対策ではなく、原因を切り分けるための比較テストとして使用してください。

VPNクライアントの情報を確認する

一部のVPN製品やバージョンでは、WSLとの互換性問題が発生することがあります。MicrosoftのWSLトラブルシューティングにも、mirrored networkingと一部VPNの組み合わせに関する注意事項があります。(Microsoft Learn)

管理者やベンダーへ問い合わせる際は、次の情報を揃えておくと調査しやすくなります。

  • WindowsのバージョンとOSビルド
  • KB5101681の適用有無
  • wsl --versionの結果
  • wsl --list --verboseの結果
  • 使用しているLinuxディストリビューション
  • .wslconfigの内容
  • /etc/wsl.confの内容
  • VPN製品名とバージョン
  • スプリットトンネルかフルトンネルか
  • VPN接続前後のip route
  • VPN接続前後の/etc/resolv.conf
  • Windowsでは接続でき、WSLだけ失敗するか
  • FQDNでは失敗し、IPアドレスでは接続できるか
  • エラーがDNS、タイムアウト、接続拒否のどれか

Dockerコンテナーだけ失敗する場合は別に確認する

Docker Desktopが管理するコンテナーのDNS要求は、WSLのDNSトンネリングをそのまま利用しない場合があります。

そのため、WSLディストリビューション上のcurlは成功するのに、Dockerコンテナー内だけ名前解決に失敗する場合は、Docker Desktop側のDNS、プロキシ、VPN統合を確認してください。Microsoftも、Docker Desktop管理下のコンテナーはWSLのDNSトンネリングとは異なる仕組みでDNS設定を処理すると説明しています。(Microsoft Learn)

KB5101681適用時に失敗しやすいポイント

失敗しやすい対応問題点適切な対応
24H2や25H2へKB5101681を適用しようとするKB5101681は26H1向け使用中のWindowsバージョン向け更新を確認する
wsl --updateだけ実行するWindows側の修正が入らないWindowsを28000.2608以降へ更新する
.wslconfigを変更してすぐ再接続するWSL VMに設定が反映されていないwsl --shutdown後に再起動する
古い手動DNS設定を残すDNSトンネリングを妨げる場合があるgenerateResolvConfとresolv.confを確認する
pingだけで判断するICMPが禁止されている可能性があるDNSと実際のTCPポートをテストする
ファイアウォールをすべて無効化するセキュリティリスクが大きい通信方向と必要ポートを特定する
Catalogで異なるアーキテクチャを選ぶ更新を適用できないx64またはArm64を確認する
「既知の問題なし」を完全な安全保証と考えるVPNや業務アプリ固有の問題は残り得る検証端末でVPN接続テストを行う

企業で展開する場合の確認項目

業務端末へKB5101681または後続更新を展開する場合は、単にWebアクセスできるかだけでなく、実際の開発作業を想定して検証します。

最低限、次の組み合わせを確認してください。

  • VPN接続前と接続後
  • VPNの切断と再接続後
  • スプリットトンネルとフルトンネル
  • 社内DNS名とインターネット上のDNS名
  • GitのHTTPS接続とSSH接続
  • npm、pip、aptなどのパッケージ取得
  • 社内APIやデータベースへの接続
  • Windows上のブラウザーとWSL上のcurl
  • WSLディストリビューションとDockerコンテナー
  • プロキシなし、固定プロキシ、PACプロキシ
  • Windows Defender Firewallと組織配布のHyper-Vファイアウォール規則

プレビュー更新を直接展開しない方針の組織では、後続の通常累積更新に修正が含まれるまで待つ判断もできます。緊急度は、VPN経由のWSL利用が業務を停止させているかどうかで決めるとよいでしょう。

KB5101681に関するよくある疑問

KB5101681は必ずインストールする必要がありますか

必須のセキュリティ更新ではありません。

Windows 11 26H1で、VPN接続時にWSLのmirrored networkingが正常に動作せず、業務や開発に影響している場合は適用を検討してください。問題が発生していない場合は、後続の累積更新を待つ運用も可能です。

NATモードでもKB5101681の効果はありますか

公式に明示されているWSLの改善対象は、mirrored networkingモードとVPNの組み合わせです。

現在NATモードを使用している場合、この改善の直接的な対象ではない可能性があります。ただし、KB5101681は累積更新であり、WSL以外の多数の品質改善も含まれています。

更新後に.wslconfigを変更する必要がありますか

すでに次の設定を使用している場合、mirrored networkingを有効にするための追加変更は不要です。

[wsl2]
networkingMode=mirrored

ただし、dnsTunneling=false、autoProxy=false、firewall=false、generateResolvConf=falseなどを過去に設定している場合は、現在のVPN構成に必要か確認してください。

Windowsを再起動すればwsl –shutdownは不要ですか

Windowsを再起動すればWSLも終了するため、通常は別途wsl --shutdownを実行する必要はありません。

Windowsを再起動せずに.wslconfigやwsl.confだけ変更した場合は、wsl --shutdownを実行して設定を反映します。

MicrosoftはKB5101681の既知の問題を認識していますか

2026年7月28日時点の公式情報では、MicrosoftはKB5101681の既知の問題を認識していないとしています。(マイクロソフトサポート)

ただし、すべてのVPN製品、プロキシ、ファイアウォール、開発ツールとの組み合わせが保証されているという意味ではありません。業務端末へ広く展開する前に、実際のVPNクライアントを使用した検証が必要です。

まずKB5101681以降へ更新し、DNSと経路を分けて確認する

Windows 11 26H1でVPN接続中のWSL mirrored networkingが使いにくい場合は、次の順番で対応してください。

  1. winverでWindows 11 26H1か確認する
  2. wsl --list --verboseでWSL 2か確認する
  3. .wslconfigのnetworkingMode=mirroredを確認する
  4. KB5101681またはそれ以降の累積更新を適用する
  5. Windowsを再起動する
  6. wsl --updateでWSL本体も更新する
  7. VPN接続前後でWindowsとWSLの通信結果を比較する
  8. DNSだけ失敗する場合はdnsTunnelingとgenerateResolvConfを確認する
  9. 特定アプリだけ失敗する場合はプロキシや証明書設定を確認する
  10. mirrored networkingだけ失敗する場合は、NATモードとの比較結果を添えて管理者やVPNベンダーへ問い合わせる

最も重要なのは、Windows側で接続できるか、WSL側で名前解決できるか、名前解決後のTCP接続が成功するかを分けて調べることです。KB5101681を適用したうえでこの順序で確認すれば、Windows更新で改善する問題と、DNS・プロキシ・VPN製品固有の問題を効率よく切り分けられます。

Windows11
VPN WSL Windows 11 26H1 KB5101681 mirrored networking

この記事を書いた人

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

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

関連記事

コメント

コメントする

目次