Windows Update KB5072033 後の WSL VPN 接続性の復元
- Aisha Washington
- 6月6日
- 読了時間: 9分
更新日：6月17日
今月、開発ワークフローが突然停止した場合、それはあなただけではありません。Windows Subsystem for Linux (WSL) に依存している多くの開発者が、エンタープライズ VPN に接続した際にネットワークアクセスが完全に失われると報告しています。原因は、最近の Windows アップデート内の競合であり、特に「WSL VPN connectivity」との相互作用を標的としています。と、最新のMirrored Networkingモード。
この問題は、あいまいな「遅延」ではありません。これは完全な停止です。WSL 2経由で内部リソースに接続しようとしたユーザーは、「ホストへのルートがありません」というエラーに遭遇し、Linuxサブシステムと社内ネットワーク間のリンクが事実上切断されます。この問題は直接、Windows Update KB5072033（および以前のプレビュー KB5067036）では、仮想ネットワークインターフェイスがアドレス解決を処理する方法にリグレッションが導入されました。
WSL VPN 接続の実際的な修正
更新が失敗したアーキテクチャ上の理由を詳しく説明する前に、まず緊急の必要性に対処する必要があります。影響を受けたエンジニアのコミュニティは、特定の、検証可能な方法を特定しました。これにより、Windows Update KB5072033 バグ。
これらの解決策は、構成の変更から手動のネットワークオーバーライドまで多岐にわたります。
解決策 1: NATネットワーキングモードへのロールバック
最も信頼性の高い修正は、「ミラーリング」ネットワーキングモードを無効にすることです。ミラーリングモードは互換性を向上させるために導入されましたが、現在のアップデートで破損しているのはこの特定の機能です。古いネットワークアドレス変換（NAT）アーキテクチャにロールバックすると、基本的な WSL VPN接続が復元されますが、IPv6サポートやシームレスなLANアクセスのような新しい機能の一部は失われます。
手順:
実行中のすべてのWSLターミナルを閉じます。
特定の .wslconfig ファイルを開きます。これは通常、Windowsユーザープロファイルディレクトリ（C:\Users\%USERNAME%\.wslconfig）にあります。
ファイルが存在しない場合は、標準のテキストエディタを使用して作成してください。
[wsl2] というラベルのセクションを見つけます。
networkingMode=mirrored という行を見つけます。
この値を networkingMode=nat に変更します。行が存在しない場合は、デフォルトの動作が他の場所で上書きされていないことを確認するか、明示的に NAT に設定してください。
ファイルを保存します。
PowerShell を管理者として開き、wsl --shutdown を実行してサブシステムの再起動を強制します。
Linux ディストリビューションを再起動すると、トラフィックはホストインターフェイスを直接ミラーリングするのではなく、ホストの NAT を介してルーティングされます。これにより、障害を引き起こしている ARP 障害が回避されます。
解決策 2: ARP 静的エントリーの回避策
ワークフローで Mirrored Networking が必須である場合（特定の IPv6 要件やマルチキャストサポートなど）、NAT への切り替えは選択肢になりません。この場合、ユーザーは Address Resolution Protocol (ARP) を含む手動修復を検証しています。
の根本的な問題Windows Update KB5072033仮想インターフェイスがARPリクエストに応答しなくなり、システムがIPアドレスとMACアドレスをマッピングできなくなることです。Cisco Secure ClientまたはOpenVPNインターフェイスを使用して、このギャップを手動で埋めることができます。
技術的な手順:
インターフェイスインデックスを特定し、トラフィックを手動でルーティングする必要があります。これには通常、起動時または接続時に実行されるスクリプトによる修正が含まれます:
Windowsホスト上のVPNインターフェイスのMACアドレスを特定します。
WSL内で、ゲートウェイIPをその特定のMACアドレスにマッピングするARPエントリを強制します。
この方法はNATに切り替えるよりも壊れやすいです。VPNセッションが再接続されるたびに再適用が必要になるため、スクリプトを介してプロセスを自動化できる上級ユーザーにのみ適しています。
解決策 3: "最終手段" (WSL 1)
WSL 2の繰り返し発生する安定性の問題に不満を感じた一部のユーザーは、インスタンスをWSL 1にダウングレードすることを選択しました。WSL 1は、Hyper-Vネットワーキングスタックに同じように依存しない、異なる変換レイヤーを使用します。
ディストリビューション（例: Ubuntu）をバージョン1に変換するには:wsl --set-version Ubuntu 1
警告:これは大幅なダウングレードです。実際のLinuxカーネルが失われ、Dockerのパフォーマンスが大幅に低下し、ファイルシステムのパフォーマンスが変化します。しかし、単純なSSHトンネリングやテキスト編集の場合は、これは完全にWSL VPN接続の失敗を回避します。
技術分析：KB5072033がネットワークを壊す理由
この問題が発生した理由を理解するには、Windows Update KB5072033がHyper-Vネットワークスタックに関して何を変更したかを見る必要があります。
ミラーリングネットワークの失敗
ミラーリングネットワークは、2023年末に追加されたフラッグシップ機能でした。WindowsとLinux間のネットワークエクスペリエンスを調和させることを約束しました。このモードでは、WSL 2はWindowsと全く同じネットワークインターフェイスを見ます。WindowsがVPNに接続されている場合、WSLもVPNに接続されています。
最近のアップデートにより、VPNクライアントの仮想アダプターがWSL環境からのARPリクエストを認識しないバグが導入されました。WSLが社内サーバーにパケットを送信しようとすると、「このIPは誰が持っていますか？」と尋ねます。バグによって目が見えなくなったWindowsホストインターフェイスは沈黙します。結果として「ホストへのルートがありません」というエラーが発生します。理論上はルートは存在しますが、ローカライズされた物理アドレス解決が無効になっています。
影響を受けるソフトウェアスタック
これは普遍的な障害ではありません。サードパーティのエンタープライズVPNクライアントが特にターゲットになっています。確認されたレポートによると、この問題は以下で最も一般的です：
Cisco Secure Client (AnyConnect)
OpenVPN
DirectAccess
複雑なトンネリングなしで標準のWi-Fiまたはイーサネット接続を実行しているホームユーザーは、一般的にこのバグをトリガーしません。 WSL VPN接続のコードパスは十分に区別されているため、標準のウェブブラウジングは影響を受けません。
接続危機に対するMicrosoftの対応
Microsoftは公式に問題を認めました。同社は、2024年後半にリリースされたアップデート、10月の非セキュリティプレビュー（KB5067036）から始まり、11月のパッチチューズデー（KB5072033）で確定したが根本原因であると確認しました。
企業の姿勢
Microsoftのアドバイザリでは、この問題は「エンタープライズシナリオ」にのみ影響するため、限定的であるように見える可能性があると指摘しています。しかし、この表現は批判を招いています。主にエンタープライズ開発者によって使用されるWSLのようなツールにとって、「エンタープライズシナリオ」は主要なユースケースです。ホームユーザーは影響を受けないことを示唆しても、ターゲット層にとっての深刻さを軽減するにはほとんど役立ちません。
現在、この動作を元に戻すための自動パッチはWindows Update経由では展開されていません。エンジニアリングチームはARPリクエストの失敗を調査中ですが、新しい累積アップデートがプッシュされるまで、上記にリストされた手動での修復手順が唯一の解決策となります。
公式パッチの監視
ネイティブな修正を待っているユーザーは、Windows Release Health Dashboardを監視する必要があります。修正は、将来の累積アップデートまたはWSLカーネル自体の帯域外パッチで提供される可能性が高いです。WSLカーネルは、コアOSアップデートとは独立してMicrosoft Store経由で更新されることがよくあります。
WSL開発への長期的な影響
の再発WSL VPN接続の問題は、現在のWSL 2アーキテクチャにおける脆弱性を浮き彫りにしています。ネットワークは、サブシステムの安定化において最も困難なコンポーネントであることが古くから知られています。
エンタープライズQAのギャップ
Cisco AnyConnectのような主要なエンタープライズクライアントが互換性を失ったという事実は、これらの特定のアップデートにおける品質保証（QA）パイプラインのギャップを示唆しています。Dockerコンテナ、バックエンド開発、サーバー管理のためにWSLに依存している組織にとって、安定性は新機能よりも価値があります。
このインシデントは、開発チームがWindowsアップデートを遅らせるという傾向を強化します。多くのユーザーが、「パッチチューズデーの宝くじ」を避けるために、特にアップデートを一時停止したと報告しています。ここでWindows Update KB5072033または同様のリリースが、一晩で開発環境を破壊します。
ミラーリングモード：まだベータ版？
ミラーリングモードは正式にリリースされましたが、今回のインシデントにより、ミッションクリティカルな本番環境での準備状況を再評価する必要が生じました。ARP処理ロジックがOSレベルのアップデートに対して堅牢になるまで、ネットワーク管理者は、制限があるにもかかわらず、従来のNATモードの使用を推奨する可能性があります。NATモードは、シームレスなエクスペリエンスは劣りますが、パケットが確実に流れることを保証します。
FAQ：WSL VPN接続のトラブルシューティング
Q：WSL VPN接続の失敗を引き起こした特定のWindowsアップデートは何ですか？
A：問題は2024年10月のオプションアップデートKB5067036から始まり、広範囲に及んだ2024年11月の必須セキュリティ更新プログラムを適用すると KB5072033。
Q: Wi-FiではWSLが正常に動作するのに、Cisco AnyConnectをオンにすると失敗するのはなぜですか？
A: このバグは、Mirrored NetworkingモードでVPN仮想アダプターのARPリクエストを解決できないようにします。物理Wi-Fiアダプターはこれらのリクエストを異なる方法で処理し、バグのあるコードパスをバイパスします。
Q: KB5072033 をアンインストールすると問題は解決しますか？
A: はい、アップデートをロールバックすると機能が復元されます。ただし、これは重要なセキュリティパッチが削除されるため推奨されません。.wslconfig で NAT の回避策を使用する方が安全な代替手段です。
Q: この問題は WSL 1 に影響しますか？
A: いいえ。WSL 1 は、Hyper-V 仮想スイッチなしで Windows IP スタックを直接共有する異なるネットワークアーキテクチャを使用しています。この特定の WSL VPN 接続 バグの影響を受けません。
Q: Microsoft はいつ恒久的な修正をリリースしますか？
A: Microsoft は調査中ですが、リリース日は確認されていません。「Windows Subsystem for Linux」アプリのアップデートについては Microsoft Store を確認するか、次の累積的な Windows アップデートをお待ちください。
