WSL2のミラーモードって何？

Windows側のipアドレスと、WSL2側のipアドレスを一致させることのようです。

なんで、ミラーモードにするの？

してなかったら、デフォルトでは、
WSL2のところだけ、別枠の仮想ネットワークで、NAT接続になってるようです。

つまりは、
Windowsをルーターみたいにして、その下に、WSL2がぶら下がってるような構成になってる
という意味なのかな。

そのデフォルトの構成だと、
WSL2が外部と通信時につながらないなど
不都合がおきることがあるらしい

たとえば、Windows側がVPN接続でインターネット通信ができてる状況なのに、
WSL2側が通信ができないなど
そういう問題点が、あるらしい。

ミラーモードにしておけば、
Windows側が外部と通信できる／できない
と、
WSL2側が外部と通信できる／できない
を一致させることができるらしい。
( そうなる可能性が高い状態にするということで、必ずとは言えんです )

補足）
Windowsで起動中の「SQL Server」のプロセスに接続時に、
Windowsのクライアントから接続時は、localhostで接続できる状況で、
WSL2からlocalhostで、接続しようとして、つながらなかったことがあった。
127.0.0.1にしてみるとうまく接続できた。
たとえ、ミラーモードにしてても、localhostだと、
WSL2自身みたいな意味になってしまうことがあるらしい。( 状況にもよる )
ミラーモードは、ipアドレスの共有みたいだから、127.0.0.1だといけるかな。
と、おもってやってみたら、うまくいったことがあった。
ですので、ミラーモードにしてるのに、うまくいかないよって時には、
設定値の中で、localhostになってるものがあれば、127.0.0.1を試してみる
ということだけ、覚えておくことにした。

なので、さっそく、その設定にしておくべきかな。と思いました。

一個一個、書いていくと、

Windows 10
は、公式にはWSL2のミラーモードのサポートがない
が、しかし、

↑の、wsl-vpnkitを使用する非公式なやり方で、
ミラーモードのような状況にできるらしいとのこと。

Windows 11
は、
WSL2ミラーモードの公式サポートがあります。
手順は、下記のとおりで簡単です。

手順は、これだけ

Windows側で
C:\Users\＜windowsユーザ名＞
のフォルダに、
.wslconfig
のファイルを作って、中身を

[wsl2]
networkingMode=mirrored

にしておく
このファイルの改行コードは、CRLFで問題ありません
というか、むしろCRLFにしておくべきかと、思います。
なぜなら、
そもそも、Windows側に置くことが前提の設定ファイルだからです。

wsl --shutdown
をしてから、再度
wsl
で、入った後に、後続の方法で、ミラーモードになってるか確認する。

WSL2ミラーモードになっているかの確認方法

Windows側でのipアドレスと、ubuntu(WSL2)のipアドレスが一致していることを確認する。

Windows側でのipアドレスは、
Ctrl-Alt-Deleteで起動するタスクマネージャーの「パフォーマンス」の
「Wifi」を押したら(Wifiで通信してる場合の話です)
そこに、IPv4アドレス、IPv6アドレス
が表示されているので、それを見るのが簡単です。
コマンドプロンプトでipconfigとか他にもやり方あるでしょうけど
上記のように、タスクマネージャ見るのが簡単です

Ubuntu側のipアドレスは、
Ubuntu側のターミナルで、
ip addr
を打ち込むと、ネットワークのインターフェースのようなものの
情報が一覧表示されます。
それらは、
lo
eth0
loopback0
eth1
などの名前がついてます。

それらのリストの各々に、IPv4アドレス、IPv6アドレス
が表示されます。

その中に、
Windows側のIPv4アドレス、IPv6アドレスと同じ値になってるものがあれば
ミラーモードになっていると確認できる。

同じ値になってるものがあるとすれば、
おそらく、eth1などが該当するかと思います。(環境によって若干違うかも)

副作用はあるかと思いますが、理解すれば問題なし

つまりは、こういうことではないか

通常、同じホスト内では同じポート番号でサーバーソケットを複数起動することはできない。
（サーバーソケットを起動するというのは、特定のポートをリッスンするという意味で言ってます)

WSL2のミラーモードでは、WindowsとWSL2が同じipアドレスを共有するため、ポート番号が重複したサーバーソケットを両方で起動できない状況になると思うです。

例えば、
Windows側で8080を使っている場合、
WSL2側では8080を使えない（逆も同様）

そんなところだと思います。

.wslconfig
に、ignoredPortsの記述をして、
例えば、下記のような状況にすると。

[wsl2]
networkingMode=mirrored

[experimental]
ignoredPorts=5000,6000

WindowsとWSL2で別々に5000,6000のポートでリッスンするサービスを起動できるらしい

たとえば、WSL2で4000でサービスを起動したら
Windows側からブラウザとかでlocalhost:4000でそこに接続できたりする
これは、デフォルトでは、WSL2からWindowsへポートフォワーディングしてるから。

ignoredPortsのignoreの無視は何を無視するかというと
ポートフォワーディングを無視するという意味かと

[experimental]
ignoredPorts=5000,6000
であれば、WSL2からWindowsに5000,6000の
フォワーディングを無視する（フォワーディングしない）から
Windows側で、localhost:5000でアクセスしても、WSL2の5000のサービスにはつながらない
その状況ならば、別枠で、Windowsで5000ポートのサービスを起動しておれば
localhost:5000でアクセスしたら、Windowsで5000ポートのサービスにつながればよい

だから、5000,6000については、WindowsとWSL2の両方で別のサービスを起動してても
問題なし、という意味ではないか

一方、ignoredPortsで指定していない4000番の場合は、
もし、WindowsとWSL2の両方で別のサービスを4000で起動することを許してしまったら、
Windowsからlocalhost:4000でつないだときに、
どっちにつなげばよいのか、わからなくなってしまう。

なので、Windowsか、WSL2のいずれか一方でしか、サービス起動できない制約が
あるのではないか

WSL2からのWindowsへのポートフォワーディングを無視（フォワーディングしない）のは、
これらですよ
ということで、
[experimental]
ignoredPorts=5000,6000
を設定しておけば、
そのポートで、WSL2でのサービス起動したものに、Windows側からの接続はできなくなりますが
それを受け入れれば
この5000,6000に関しては、WindowsとWSL2で競合せず、別々にサービス起動可能になりますから
その必要性があれば、ignoredPortsを利用して
環境構築の問題を解決できる場合があるかもねー。

って、そんな意味かなって思ってる次第であります。

ちょっと、わかりにくく、間違ってたら、ここの記述は修正します。

このignoredPortsをうまく活用して、環境構築で混乱がおきないようには
対処できるかもしれないということだけ、覚えておくことにした。

WSL2のミラーモードは過去にdockerでトラブルがあったらしいが今は大丈夫らしい

にて、

[2024.9.22]Docker 27.3.0 に WSL用の特別ルールが入りました。これによりWindowsホストからの127.0.0.1へのアクセスはコンテナでポートマップしたサービスへアクセスできるようになりました。

https://github.com/moby/moby/releases/tag/v27.3.0

ということで、この記事に書いた内容はすでに昔話です。安心してミラーモードをご利用ください。

と書いてる
詳しく、わからないが
たとえば、ホストの8080にアクセスしたらコンテナの80につなげる
みたいな事柄がうまくできない問題が過去にあったということだろうか・・・。

上記に「Docker 27.3.0 に WSL用の特別ルールが入りました」とありますが

前述の、

＜引用＞
WSL2のミラーモードでは、WindowsとWSL2が同じipアドレスを共有するため、ポート番号が重複したサーバーソケットを両方で起動できない状況になると思うです。

この部分を実現する技術がマイクロソフト特有のものであり、Dockerがうまく理解できず
誤作動があったのではないかと、思いました。
それを、WSL用の特別ルールをDocker側が対応してくれたので、
問題がなくなった。
そんな意味ではないかと、想像してます。

まぁ、
今は、大丈夫なようなので、これ以上は、深追いしないことにしました。

WSL2のよいところは、DockerもUbuntuなどのディストリビューションも
共通のLinuxカーネル上で動作するため、高速である
安価なPCでも、メモリが十分あれば(WSL2はそれなりにメモリを食う)
軽快に動いてくれる

WSL2の悪いところは、VMでカーネルが動いてるところで、
Windowsの下に、NATでぶら下がってたが、ゆえに、外部との通信で難があったこと。

それをミラーモードで解消し、そして、
それによってDockerとの間で不具合があったが
そこは、Docker側が、対応してくれた

そういう流れだろう。

他にもWSL2はいろいろ進化していた・・。

ところで、今回の話題とは直接関係ないが、
WSL2は、昔はHyper-Vで動作していて、Hyper-Vを有効にする必要があった
でも、今は、Hyper-Vを有効にせず、WSL2が動作する。( Windows 11の場合かな )

Hyper-Vのサブセットのような別物で動作してるとのこと。
Hyper-Vを有効にすると、他の仮想化技術と競合して、
WSL2か、他の仮想化技術のいずれかしか使えないような問題点があったため、
Hyper-Vなしで、WSL2が動くように改善されたとのことでした。

上記で、「Hyper-Vのサブセットのような別物」言うてるのは、
Windows + R を押し、optionalfeatures.exe と入力して Enter
してでてくる

上の図の画面で赤枠で、囲まれた2つのこと。
これらを有効にしてたら、WSL2が動く

のとおり、Hyper-Vはチェックが外れているが、
この状況で、WSL2が動作してる。

WSL2出てから結構、年数が経過してきたので
いろいろ問題点解消され、前進してるんだな。思った。

★★★★★★★★★★★
★ 2025/10/15追記 ★
★★★★★★★★★★★
仕事でチームメンバーにWSL2の導入方法を教えていた時に、改めて、気が付いたメモ。

上の図の赤枠の「Linux用Windowsサブシステム」はチェックなしでも
WSL2はインストールできます。
どうやら、この「Linux用Windowsサブシステム」は、WSL1のことだと思われて
昔は、この「Linux用Windowsサブシステム」をチェックありでWSL1を有効にしたうえで、
それをWSL2にアップデートする手順だったようですが、
今は、この「Linux用Windowsサブシステム」をチェックなしの状態で、
https://learn.microsoft.com/ja-jp/windows/wsl/install
に乗ってる

wsl --install

をすれば、いきなり、WSL2がインストールされる状況のようである。
インストール後は、

wsl --version

で、WSLのバージョンが2系であるかどうかや、カーネルのバージョンも確認できます。
★★★★★★★★★★★

★★★★★★★★★★★
★ 2025/10/15追記（その2) ★
★★★★★★★★★★★
「Windowsハイパーバイザープラットフォーム」
のチェックは、どうやら、要らなさそう。

wsl --install
を「管理者として起動したpowershell」で実行する場合は、
「Virtual Machine Platform」を事前に「有効：チェックあり」にするのは
不要だったようです。

wsl --install
の中で「Virtual Machine Platform」が「無効：チェックなし」ならば、
「有効：チェックあり」に変更するようですが
それには、管理者としてpowershell起動したうえで「wsl --install」を実行している必要がある
そして、
この「Virtual Machine Platform」を
「無効：チェックなし」→ 「有効：チェックあり」
の変更が伴う形で、wsl --installが実行完了した場合については、
PCの再起動が必要なようである。

既に
「Virtual Machine Platform」を「有効：チェックあり」にしている状況ならば、
その工程が必要ないため
管理者としてpowershell起動してなくても、

「wsl --install」自体は正常に完了するようです。

ですが、

念のため、これからは、
「wsl --install」をするときには、管理者としてpowershellを実行し、
そして、完了後、PCを再起動する手順にしようかと思いました。
理由は、上記は、あくまで、2025/10/15時点の仕様であり、
Microsoftはころころ仕様を変えるため、
管理者としてpowershellを実行が必要な何かが、今後、埋め込まれるかもしれないし
そんな細かいこと覚えられないため。

★★　おぼえること　★★
「管理者としてpowershellを起動し「wsl --install」し、その後、PC再起動の一択でよし！！」
とだけ、記憶しとけばよろしいと、思った

それ以外の詳細のことは、１週間たてば、どうせ、忘却の彼方となるため
上記の、★★　おぼえること　★★　だけにしとく
★★★★★★★★★★★

一応は、わかったことをまとめたが、感想

こういう情報を理解しようとすると、古くて、今となっては意味がない話なども
まじって情報が入ってくるです。
ブリッジモードの話もちょくちょく出てきた
ただミラーモードでのDockerでの不具合が解消された今、
ブリッジモードの話は、もはや、見る必要性がなさそうに思える。

あらかじめ、過去にこういうことがあって、これがこうなって、今はこうなった
そのとき、こういうやり方がでてきたが、ここが改善されたため、
それは使われてなくなって今は、こっちのやり方だ
みたいな、あらすじ　変遷のあらすじ　がわかれば、
情報の取捨選択がしやすいのだが、
★★そういう歴史的経緯を簡単に、ざっくり説明してくれるものが、なかなか、ない★★
★★漫画でいいので、それが先に欲しいな思う★★

これまでの紆余曲折のあらすじ

そしたら、
情報の取捨選択できるから、要る分だけ詳細みたらいいだけになるから、かなり、楽になるんだが。

Discussion