WSL2: ネットワーク構成と NAT およびミラー モードの高度なガイド

インフォマテックデジタル » Recursos » WSL2: ネットワーク構成と NAT およびミラー モードの高度なガイド

WSL2はLinuxとWindowsの統合方法を完全に変えた特にネットワーク関連のあらゆる面で、独自のネットワークスタック、IPアドレス、そして個別のアクセスルールを備えた軽量な仮想マシンが利用可能になりました。これにより、開発、テスト、コンテナ、そしてセルフホスティング環境において多くの可能性が開かれますが、WSL1で発生したように、サービスにアクセスできなくなるという懸念も生じます。

WSL2 ネットワーク構成、NAT およびミラーリング モード、.wslconfig および wsl.conf の使用、およびそれらがファイアウォール、VPN、Docker、Tailscale などのツールとどのように連携するかを理解する これが頭痛の種を避ける鍵です。このセットアップ全体がどのように機能するか、WindowsとLANにサービスを公開する方法、正しいIPアドレスを取得するためのコマンド、そして環境を微調整して安定性とセキュリティを確保するための高度な設定オプションについて、ステップバイステップで見ていきましょう。

WSL2でネットワークが実際にどのように動作するか

WSL2はWSL1のようにホストネットワークスタックを共有しなくなりました代わりに、各LinuxディストリビューションはHyper-Vによって管理される小さな仮想マシン内で実行されます。その仮想マシンには独自の仮想アダプタ（通常は eth0) および内部仮想スイッチによって割り当てられたプライベート IP アドレスです。

デフォルトモードでは、WSL2はNATベースのアーキテクチャを使用します。 (ネットワーク アドレス変換)。Windows はルーター/ホストとして機能し、Linux ディストリビューションは、通常は範囲内のプライベート サブネット上に存在します。 172.16.0.0/12このサブネットは、再起動または WSL の再起動後に変更される可能性があり、静的ファイアウォール ルールを構成するときに複数の人が困惑しています。

実用的な観点から言えば、これはWSL2ディストリビューションのIPアドレスが安定しておらず、LANから直接アクセスできないことを意味します。 WSL1 と同様に、デフォルトでは、Windows と WSL2 間の接続はリダイレクト ルールと NAT を通じてのみ確立され、ローカル ネットワークへの公開には追加の手順またはミラー モードの使用が必要になります。

この基本アーキテクチャに加えて、Windows 11 22H2以降のバージョンでは新しいネットワーク機能が追加されています。 （ミラーモード、dnsTunneling、autoProxy、Hyper-Vファイアウォールなど）グローバルファイルから制御される .wslconfigLinux内の特定のオプションは、 /etc/wsl.conf.

WSL2でIPアドレスを識別する

WSL2 を使用するには、2 つの IP シナリオを明確に区別する必要があります。: LinuxディストリビューションのIPアドレスが必要な場合と、Linuxから見たWindowsホストのIPアドレスが必要な場合。それぞれ異なるコマンドで解決します。

シナリオ1: WindowsからWSL2ディストリビューションのIPアドレスを知りたい ホスト上のアプリケーション（クライアント、ブラウザ、テストツールなど）がLinux内で実行されているサービスに接続できるようにします。これを行うには、Windowsで以下のコマンドを実行します（CMDまたはPowerShellを使用）。

wsl.exe --distribution <DistroName> hostname -i

デフォルトのディストリビューションを使用する場合は、ディストリビューション パラメータを省略できます。 そして電話するだけ wsl.exe hostname -iバックグラウンドでは、このコマンドはLinuxで起動します hostname --ip-addresses インスタンスのIPアドレスを返します。典型的な結果は次のようになります。

172.30.98.229

シナリオ2: LinuxディストリビューションからWindowsホストのIPアドレスを知る必要がある例えば、WSL2アプリケーションをWindowsネイティブサーバー（Node.js、SQL Server、Caddyなど）に接続するには、Linuxシェル内で以下を使用します。

ip route show | grep -i default | awk '{ print $3 }'

出力はWSL2 VMのデフォルトゲートウェイになりますこれは、Linux から見た Windows ホストの IP アドレスに対応し、次のようになります。

172.30.96.1

その値（例えば、 172.30.96.1）はLinuxクライアントが指すべきアドレスです クラシック NAT モードで Windows ホスト上で実行されているサービスにアクセスする場合。

NATモード: WSL2ネットワークのデフォルトの動作

WSL2 はそのままでは NAT モードで動作し、多くのシンプルな開発環境ではこれで十分です。重要なのは、幽霊を追いかけて時間を無駄にしないために、何が「単独で」機能し、何が機能しないかを理解することです。

localhost を使用して Windows から Linux サービスにアクセスするWSL2ディストリビューションでネットワークアプリケーション（Node.jsサーバー、Flaskサーバー、Linux上のSQL Serverなど）を実行する場合、Windowsから次のようにアクセスできます。 localhost:puertoWindows は、着信接続を WSL2 VM の内部 IP アドレスに自動的に転送します。

LinuxからWindows上で実行されているサービスにアクセスするここで状況が変わります。WSL2からホスト上のネットワークアプリケーション（Node.jsサーバー、SQL Server、Windows上のCaddyなど）にアクセスするには、Linuxから見たホストのIPアドレスを使用する必要があります。このIPアドレスは、default routeコマンドで取得します。

ip route show | grep -i default | awk '{ print $3 }'

そのIPアドレスを使用すると、Linuxからホスト上の任意のサービスに接続できます。例えば http://172.30.96.1:3000 Windows サーバーがすべてのインターフェースでポート 3000 をリッスンしている場合。

リモート IP (ローカルホストではない) を使用して接続すると、アプリケーションはそれを LAN 接続として認識します。これは、多くのサーバーがリッスンするように設定する必要があることを意味します 0.0.0.0 代わりに 127.0.0.1たとえば、Flask を使用すると次のように起動できます。

app.run(host='0.0.0.0')

この変更によりアクセシビリティは向上しますが、セキュリティに重点を置く必要があります。コンピュータ自体からだけでなく、ローカル ネットワークからの接続も許可しているためです。

NAT を使用してローカル ネットワーク (LAN) から WSL2 にアクセスする

WSL1からWSL2に移行する際の最も厄介な変更点の1つは、ディストリビューションがLANから直接アクセスできなくなったことです。WSL1 では、Windows がネットワーク上で表示可能であれば、ディストリビューションのサービスはほとんど苦労せずにその公開を継承しました。

WSL2 では、VM には独自のプライベート IP アドレスがあり、LAN 上で自動的にアドバタイズされません。以前の動作と同様の動作を実現するには、NAT モードで、他の Hyper-V 仮想マシンの場合と同様に、Windows でポート プロキシを作成する必要があります。

Windows には、このための古典的なツールが含まれています。 netsh interface portproxyホスト ポートを WSL2 IP/ポートにリダイレクトする一般的なコマンドは次のようになります。

netsh interface portproxy add v4tov4 listenport=<puertoHost> listenaddress=0.0.0.0 connectport=<puertoWSL> connectaddress=(wsl hostname -I)

実際には、マーカーを特定の値に置き換えます。たとえば、次のようになり

netsh interface portproxy add v4tov4 listenport=4000 listenaddress=0.0.0.0 connectport=4000 connectaddress=192.168.101.100

ここで listenaddress=0.0.0.0 これは、Windows がホストのすべての IPv4 アドレスをリッスンすることを示します。ポート4000経由で受信したものを転送します 192.168.101.100:4000これは次のようにして取得される WSL2 IP アドレスになります。

• wsl hostname -I WSL2 VM内のLinuxディストリビューションのIPアドレスがわかります
• cat /etc/resolv.conf WSL2 から Windows Vista ホストの IP アドレスを明らかにします。

この技術により、WSL2で実行されているサービスをLAN上のどのコンピュータからでもアクセスできるようになります。ただし、Windows ファイアウォールが許可しており、ホストを直接公開するのではなく、VM のサービスを公開していることが明確である場合に限ります。

IPv6と最新のネットワーク機能

WSL2 は IPv6 でも動作できるため、特に最新の環境、VPN、企業ネットワークに適しています。アドレスを処理するための Linux の基本コマンドは IPv4 のコマンドと同等です。

• wsl hostname -i WindowsからWSL2ディストリビューションのIPアドレスを確認する
• ip route show | grep -i default | awk '{ print $3 }' LinuxからWindowsホストのIPアドレスを取得する

IPv6とVPNサポートの品質の飛躍的向上が特に顕著に表れるのは、ミラーリングされたネットワークモードです。Windows 11 22H2 以降のバージョンで利用可能で、これについては後ほど詳しく説明します。

ミラーリングされたネットワークモード: Linux で Windows インターフェースをミラーリングする

Windows 11 22H2 以降を搭載したコンピューターでは、「ミラーリング」ネットワーク モードを有効にできます。 WSL2 では、モデルが完全に変更され、従来の NAT の代わりに、Linux は反映された Windows ネットワーク インターフェイスを「認識」します。

有効にするには、ファイルを編集する必要があります .wslconfig ユーザーの、にあります %UserProfile%\.wslconfig管理者権限を持つ PowerShell からは、次のコマンドで開くことができます。

notepad $env:USERPROFILE\.wslconfig

内部で[wsl2]セクションを追加（または変更）してミラーモードを有効にします。:

[wsl2]
networkingMode=mirrored

ファイルを保存したら、変更を有効にするために WSL2 を再起動する必要があります。たとえば、次のようになります。

wsl --shutdown

再起動すると、WSL は新しいミラーリングされたネットワーク アーキテクチャを使用します。これにはいくつかの非常に強力な利点があります:

• ネイティブ IPv6 サポートと企業ネットワークおよび VPN との統合の改善
• LinuxからWindowsサービスに接続する機能 127.0.0.1 directamente （許可されていないが） ::1 （IPv6ループバックなど）
• Windows-Linux統合におけるマルチキャストサポートの改善
• netsh portproxy を必要とせずに LAN から WSL に直接アクセスするWindowsマシン自体のIPアドレスを使用する

このモードを有効にすると、従来のWSL2 NATの問題の多くが解決されます。 これは、Windows 11 の更新バージョンを使用できるほとんどの最新の開発環境およびセルフホスティング環境で推奨されるオプションです。

WSL2 での DNS トンネリングとプロキシの使用

Windows 11 22H2 以降のバージョンでは、WSL2 からの名前解決も大幅に改良されました。鍵となるのは、 .wslconfig: dnsTunneling y autoProxy.

選択 dnsTunneling [wsl2] セクションではデフォルトで有効になっています。 これにより、LinuxのDNSリクエストは通常​​のネットワークパケットとして送信されるのではなく、仮想化機能を介して処理されるようになります。これにより、VPNやホスト上の複雑なネットワーク構成との互換性が大幅に向上します。

その部分については、 autoProxy=true WSLにWindows HTTPプロキシ設定を使用するように強制しますホストが企業プロキシまたはセキュリティ プロキシの背後にある場合、WSL2 は環境変数を手動で操作しなくてもそれを自動的に継承します。

例えば、次のようなものを .wslconfig:

[wsl2]
dnsTunneling=true
autoProxy=true

これにより、WSL2 ネットワークがホスト構成と一貫して動作することが保証されます。厳格なネットワークおよびフィルタリング ポリシーを持つ企業で特に役立ちます。

Hyper-V ファイアウォールとセキュアサービス公開

最近の環境では、WSL2 ネットワークも専用のファイアウォールを通過します。Windows 11 22H2 上の WSL 2.0.9 以降では、Hyper-V ファイアウォール機能が既定で有効になり、VM トラフィック (WSL2 トラフィックを含む) のフィルタリング レイヤーが追加されます。

ミラーモードで作業していて、WSL2サービスをLANに永続的に公開したい場合 (たとえば、API、ダッシュボード、セルフホスティング サービスなど) を使用する場合は、ファイアウォール ルールで許可されていることを確認する必要があります。

管理者権限を持つPowerShellからの合理的なアプローチは、プライベートネットワーク用のHyper-Vルールを作成することです。:

New-NetFirewallHyperVRule -DisplayName "WSLPrivateInboundRule" -Profiles Private -Direction Inbound -Action Allow -VMCreatorId ((Get-NetFirewallHyperVVMCreator).VMCreatorId)

何らかの理由で特定のHyper-V保護を無効にしたい場合 (あまりお勧めできませんが)、次の方法も使用できます。

Set-NetFirewallHyperVVMSetting -Name ((Get-NetFirewallHyperVVMCreator).VMCreatorId) -Enabled False

可能な限りファイアウォールをアクティブにしておくことが重要です。ルールをプライベート ネットワークと本当に必要なポートのみに制限し、大量の非アクティブ化は最後の手段として残し、すべてが機能し始めたらすぐに構成を再び強化することを常に念頭に置いてください。

WSL2 ネットワーク アーキテクチャ、X11、172.16.0.0/12 の範囲

WSL2ネットワークの詳細を明らかにする典型的な例は、X11経由のグラフィカルアプリケーションの使用である。たとえば、Windows で Xming を起動し、DISPLAY 経由で Linux アプリケーションを送信します。

WSL1 から WSL2 にアップグレードすると、多くのユーザーは X が動作しなくなることに気づきます。 ネットワークは「共有」されなくなり、次のような範囲を持つ仮想NATネットワークになるからです。 172.16.0.0/12これは、Windows または WSL を再起動するたびに変更されることもあります。

WSL2 から Xming を使用して X を再び動作させるには、通常、Linux が認識する Windows IP アドレスを取得します。 使用：

ENS

DISPLAY=$(grep nameserver /etc/resolv.conf | cut -d' ' -f2):0

並行して、そのNATサブネットからのX11トラフィックを許可するようにWindowsファイアウォールを調整する必要がある。典型的なアプローチは、Xmingルールを編集して範囲を追加することです。 172.16.0.0/12 TCP+UDP 6000で。

多くの人は、オプションでXming認証を無効にすることになります -acこれは事実上、そのネットワークから接続してくるすべてのクライアントXに対して「扉を開く」ことになります。確かに機能しますが、セキュリティの観点からはかなり疑問があるため、より限定的なソリューションを検討するか、Windows 11のWSLg（統合GUIアプリケーション）の使用を検討する価値があります。

wsl.conf と .wslconfig: 高度な WSL2 構成

WSL には、VM の動作と各ディストリビューションの動作の両方を制御する 2 つの主要な構成ファイルが用意されています。: /etc/wsl.conf （ディストリビューションによる）および %UserProfile%\.wslconfig (すべての WSL2 ディストリビューションにグローバル)。

wsl.conf Linuxディストリビューション内では、 /etc/wsl.confこれは、そのディストリビューションのローカルオプションを設定するために使用されます：自動マウント、 hosts y resolv.confWindows、デフォルトユーザー、systemd などとの相互運用性。

.wslconfig Linux 外部の Windows ユーザー プロファイルに保存されます。 (C:\Users\<Usuario>\.wslconfig) であり、WSL2 を動かす VM のグローバル パラメータ (メモリ、CPU、カーネル、ネットワーク モード、ファイアウォール、DNS、仮想ディスク サイズ、GUI サポートなど) を制御します。

興味深い点の 1 つは、設定を変更するときの「8 秒ルール」です。これらのファイルを変更する際は、WSL VMが完全にシャットダウンされていることを確認してください。ディストリビューションウィンドウを閉じても、メモリ内に数秒間残る場合があります。

サブシステムを強制的に再起動するには、:

• wsl --list --running アクティブなディストリビューションがあるかどうかを確認する
• wsl --shutdown すべての配布を一度に終了する
• wsl --terminate <distroName> 特定のディストリビューションを停止する

構成の変更は、WSL がシャットダウンされて再起動されたときにのみ実際に適用されます。多くの人が見落としているのは、調整が「機能しない」と考えていることです。

セクション別の主な wsl.conf オプション

ファイル wsl.conf これは、セクションとキーを備えた古典的な.ini形式に触発されています。主なセクションは [automount], [network], [interop], [user], [boot], [gpu] y [time].

En [automount] Linux内でWindowsドライブをマウントする方法を制御できます （通常は低い） /mnt):

• enabled (ブール値、デフォルトはtrue)trueの場合、C:/、D:/などが自動的にマウントされます。 /mnt/c, /mnt/d...
• mountFsTab (ブール): 真の場合、処理されます /etc/fstab ディストリビューションを起動するとき。
• root （鎖）: ドライブがマウントされるルートディレクトリ。例: /windir/ 持っている /windir/c.
• options （カンマ区切りのリスト）: DrvFs固有のパラメータ、例えば metadata, uid, gid, umask, fmask, dmask o case.

DrvFs は、Windows と Linux をつなぐファイル システムです。権限制御、メタデータ、大文字と小文字の区別を備え、WSL から NTFS にアクセスするように設計されています。

セクション内 [network] ネットワークファイルの自動生成を調整します:

• generateHosts: trueの場合、WSLは自動的に生成します /etc/hosts.
• generateResolvConftrueの場合、WSLは /etc/resolv.conf レガシー DNS を使用します。
• hostname: ディストリビューションが使用するホスト名。

セクション [interop] Windowsとの相互運用性を制御:

• enabled: WSL から Windows プロセスを起動する機能を有効または無効にします。
• appendWindowsPath: Windowsパスを追加するかどうかを決定します $PATH Linux。

En [user] ディストリビューションを起動するときにデフォルトで使用されるユーザーを指定できます:

• default: WSL でデフォルトで起動されるユーザー名。

セクション [boot] Windows 11とServer 2022で特に役立ちます WSL 内で Docker などのサービスを自動的に起動するには:

• command: WSL の起動時に実行するコマンド文字列。例: service docker start.
• protectBinfmt: systemd が有効な場合に systemd ユニットの生成を保護します。

次のようなセクションもあります [gpu] （LinuxからWindows GPUへのアクセスを有効にする）、および [time] Windowsとタイムゾーンを同期するこれにより、夏時間への変更時や旅行時の問題を回避できます。

.wslconfig: WSL2 仮想マシン制御

wsl.conf は各ディストリビューションの動作を微調整しますが、.wslconfig を使用すると、すべての WSL2 ディストリビューションで共有される VM を微調整できます。このファイルは、WSL1 ではなく WSL2 として実行されるディストリビューションによってのみ考慮されます。

以内 .wslconfig メインセクションは [wsl2]主要なパラメータを定義する場所:

• kernel y kernelModules: Windows からカスタム Linux カーネルとそのモジュールへの絶対パス。
• memory: VMのメモリ制限（デフォルトはホストRAMの50%） 4GB.
• processors: VM に割り当てられた論理プロセッサの数。
• localhostForwarding: WSL2の開いているポートにWindowsからアクセスできるようにする localhost.
• swap y swapFile: VM のスワップ ファイルのサイズとパス。
• guiApplications: GUI アプリケーション サポート (WSLg) を有効または無効にします。
• dnsProxyNAT モードの場合、Linux DNS サーバーがホストの NAT インスタンスになるか、Windows DNS のコピーになるかを決定します。
• networkingModeここで以下から選択します none, nat, bridged （廃止）、 mirrored o virtioproxy.
• firewall, dnsTunneling y autoProxy: WSL ネットワークを Windows ポリシーとより適切に統合するために説明したオプション。
• defaultVhdSize: ディストリビューションのファイル システムが保存される VHD の最大サイズ (既定値は 1 TB)。

セクションもあります [experimental] テストで機能が有効になる場所 として：

• autoMemoryReclaim: 自動メモリ回復設定 (無効、段階的、dropCache)。
• sparseVhd: スペースを節約するためのスパース仮想ディスクの作成。
• bestEffortDnsParsing y dnsTunnelingIpAddress: DNS トンネリングの微調整。
• ignoredPorts: ミラー モードのときに Windows で使用されていても Linux アプリが使用できるポート。
• hostAddressLoopback: ミラーモードでホストのローカル IP アドレスを使用してホストとコンテナが接続できるようにします。

.wslconfig を適切に構成すると、リソースを大量に消費する VM と、Windows システムおよびネットワークで適切に動作する最適化された環境との違いが生じます。特に、負荷の高いワークロード、コンテナ、または複数のディストリビューションを同時に扱う場合には重要です。

Tailscale を使用したセルフホスティングのための WSL2、Docker、ネットワーク

非常に実用的な例としては、Windowsサーバー（Windows Server 2025でも）でWSL2をセルフホスティングプラットフォームとして使用することが挙げられます。WSL2 上の Ubuntu、Docker Engine (Docker Desktop なし)、Tailscale、Caddy などのリバース プロキシを組み合わせて、n8n や Supabase などのサービスを公開します。

WSL2内で安定したDocker環境を構築し、サーバー上のDocker Desktopの問題を回避することが目的です。Docker Engine を Ubuntu (WSL2) に直接インストールする場合、コンテナー ネットワークは WSL2 ネットワークに依存し、WSL2 ネットワークは .wslconfig で定義されている NAT またはミラー モードに依存します。

WSL2 に Tailscale をインストールすると、メッシュ VPN でサービスを公開できます。 ルーターのポートを開かずに、Caddy をリバース プロキシとして使用して、TLS 証明書、ルート、およびコンテナー間の軽量負荷分散を一元管理します。

クリーンで予測可能で安全なネットワークを維持するためには、:

• 単一の一貫したネットワークモード（NATまたはミラーリング）を選択し、それを文書化する
• WindowsとWSL2間のポート競合を回避する、頼りに ignoredPorts ミラーリングを使用する場合
• TailscaleまたはCaddy経由でのみサービス公開を制御ファイアウォールで「デフォルトで」ポートを開く代わりに
• Docker、Tailscale、Caddyの起動を自動化 [boot] wsl.conf内 より生産に近い環境を実現する

このアーキテクチャにより、WSL2 は単なる開発ツールではなくなり、かなり本格的なセルフホスティング プラットフォームになることができます。ただし、その制限事項 (Hyper-V による仮想化、追加のネットワーク層など) を受け入れ、慎重に構成する必要があります。

開発とテストのための WSL2 ネットワークのベスト プラクティス

微調整以外にも、WSL2ネットワークを快適に操作するのに役立つガイドラインがいくつかあります。 IP、ポート、ファイアウォールと常に格闘する必要はありません。

開発サービスの場合は、高ポート（1024以上）を使用してください。 特権ポートや頻繁に使用されるポートを避けてください。これにより競合が最小限に抑えられ、追加の特権が必要なくなります。

コードとデータが Linux ファイル システム内に存在していることを確認します。 （あなた ~/ または内部ルート）に直接作業するのではなく、 /mnt/cWSL から NTFS にアクセスすると速度が遅くなり、I/O を集中的に使用するサービスに悪影響を与える可能性があるためです。

スクリプトを使用してネットワーク設定とリダイレクトルールを自動化する PowerShell および Bash の場合: たとえば、WSL2 の起動時にそれを構成するスクリプト。 netsh portproxy (NAT を続行する場合) またはミラーリングを使用するときにファイアウォール ルールを確認します。

IPの変更に頼らない 内部仮想スイッチによって生成される。可能な限り、 localhost、ホスト名またはエントリ /etc/hosts サービスの IP を変更してもテスト インフラストラクチャの半分が壊れることがないようにします。

プロフェッショナル環境または準本番環境では、WSL の自動転送に盲目的に依存しないことが最善です。ポート、プロキシ、ファイアウォール ルールを明示的に構成して、公開されている内容と場所を正確に把握します。

適切に構成された WSL2 は、高度な開発、API テスト、コンテナーの操作、分散環境のシミュレーションに最適な、分離された柔軟なネットワークを提供します。重要なのは、ネットワーク モード (NAT とミラーリング)、wsl.conf ファイルと .wslconfig ファイル、ファイアウォールやスタック内のツール (Docker、Tailscale、リバース プロキシ) とのやり取りをマスターすることです。そうすることで、ポートが重複したりセキュリティが損なわれたりすることなく、Windows と Linux を同じマシン上で実行できるようになります。