実際にWSL2側へのアクセスを試す
実際に、Win32からlocalhostを指定してWSL2側のネットワークサービスをアクセスしてみよう。ここでは、簡単にするため、WSL2側でnode.jsを動かし、httpサーバーを作った。といっても、リクエストに対して文字列を返すだけの機能しかない。
var http = require('http');
var port = 3000;
http.createServer(function (req, result) {
console.log('Connect:' + result.connection.remoteAddress);
result.writeHead(200, {'Content-Type': 'text/plain'});
var now = new Date;
result.end('This is WSL2.\n'+now.toISOString()+'\n');
}).listen(port,'0.0.0.0');
console.log('Server running at http://localhost:'+port+'/');
node.jsが何なのか、どうやって使うのかは、本記事の目的ではないので、簡単に、スクリプトでhttpサーバーを作ったとだけ理解いただきたい。これをポート番号3000で動作させる。WSL2側では、ポート3000がListen Portとなる。これは、netstatコマンドで確認できる。この状態で、Win32側のnetstat.exeを使ってListen Portを調べると、wslhost.exeがポート3000で待ち受けしている状態であることがわかる。
その後、Edgeを使って、http://localhost:3000/をアクセスさせる。すると、WSL2側のnode.jsスクリプトが動作して文字列を返す。
このとき、WSL2側のnetstatコマンドでは、ポート3000に対して、127.0.0.1からアクセスされているようにみえる。実際、node.jsのスクリプトが受け取っているリクエスト情報では、127.0.0.1からのアクセスがなされているように見える。
この改良により、Win32側からは、WSL2側のネットワークサービスを常にlocalhostでアクセス可能になる。では、両方で同じポートを待ち受けに使ったらどうなるのかなのだが、TCP/IPでは、先に待ち受けを開始したほうが優先される。
こうしたネットワークサービスは、Win32側では、サービスとして起動されることがほとんどなので、たとえば、IISや付属のFTPサーバーなどは、Windowsの起動時に動作してしまい、あとからwslhost.exeが待ち受けに使うことができない。ただし、WSL2の仮想ネットインターフェース側での待ち受けは有効なので、WSL2側はエラーにはならない。
要は、Win32側のlocalhostをどっちが使うのかということであり、WSL2側のlocalhostはWSL2側からはそのまま利用できる。なお、マイクロソフトによれば、ウェブサーバなどを使った開発のことを考慮して、WSL2へlocalhostでアクセスできるようにする機能を優先して実装したとのことである。可能性としては、WSL2側でも同じようにlocalhostでWin32側のサービスにアクセスする機能が実装されるかもしれない。
この連載の記事
-
第458回
PC
Windows上でhostsファイルを活用する -
第457回
PC
IPv6アドレスは先頭を見ればどんな種類かわかる -
第456回
PC
あらためてIPv6基本のキ -
第455回
PC
Windowsで現在どのネットワークアダプタがインターネット接続に使われているかを調べる方法 -
第454回
PC
Windows 11 24H2では「デバイスの暗号化」の条件が変わり、より多くのPCでドライブが暗号化される -
第453回
PC
Windows 11 24H2の配布開始後もすぐにはやってこない Windows UpdateとSafeguard Holds -
第452回
PC
Windows 11 Ver.24H2が登場 Copilot+ PCとそうでないPCで実質Windowsが2つに分かれる -
第451回
PC
新しいWindowsサンドボックスではコマンドラインからの制御が可能に -
第450回
PC
ユニコードで文字数を数える方法 -
第449回
PC
WSLはプレビュー版でGUIでの設定が加わった! リリース2.3.xの新機能を見る -
第448回
PC
PowerShellで面倒なオブジェクトはPSCustomObjectに変換するのが早道 - この連載の一覧へ