トレーニング
認定資格
Microsoft Certified: Azure Network Engineer Associate - Certifications
Azure ネットワーク インフラストラクチャ、負荷分散トラフィック、ネットワーク ルーティングなどの設計、実装、メンテナンスのデモを行います。
このブラウザーはサポートされなくなりました。
Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。
ネットワーク アプリと WSL を使用する場合に注意すべき考慮事項がいくつかあります。 既定では、WSL は NAT ベースのアーキテクチャを使用します。最新の機能と改善点を取得するには、新しいミラー化されたネットワーク モードを試してみることをお勧めします。
WSL を介して実行される Linux ディストリビューションの実行に使用される IP アドレスを特定する場合に、考慮すべき次の 2 つのシナリオがあります。
シナリオ1: Windows ホストの視点から、WSL2 経由で動作している Linux ディストリビューションの IP アドレスにクエリを実行し、Windows ホスト上のプログラムがディストリビューション (インスタンス) 内部で動作しているサーバー プログラムに接続できるようにする。
Windows ホストでは次のコマンドを使用できます。
wsl -d <DistributionName> hostname -I
既定のディストリビューションにクエリを実行する場合、ディストリビューションを指定するコマンドの次の部分は省略できます: -d <DistributionName>
。 小文字の -i
ではなく、大文字の -I
フラグを使用するようにしてください。
そのしくみとして、ホスト コマンド wsl.exe
でターゲット インスタンスが起動し、Linux コマンド hostname -I
を実行します。 このコマンドは、WSL インスタンスの IP アドレスを STDOUT
に出力します。 その後、STDOUT
テキスト コンテンツは wsl.exe にリレーを返します。 最後に、wsl.exe でその出力がコマンド ラインに表示されます。
一般的な出力は次のようになります。
172.30.98.229
シナリオ2:WSL2 (インスタンス) を介して Linux ディストリビューション内で実行されているプログラムで、Linux プログラムが Windows ホスト サーバー プログラムに接続できるように、Windows ホストの IP アドレスを把握できるようにする。
WSL2 Linux ユーザーは、次のコマンドを使用できます。
ip route show | grep -i default | awk '{ print $3}'
一般的な出力は次のようになります。
172.30.96.1
172.30.96.1
は、この例では Windows のホスト IP アドレスです。
注意
WSL2 を既定の NAT ネットワーク モードで実行している場合、通常は上記のような IP アドレスのクエリを実行する必要があります。
WSL2 を新しいミラー モードで実行している場合、Windows ホストと WSL2 VM は localhost
(127.0.0.1) を送信先アドレスとして互いに接続できるため、クエリ ピアの IP アドレスを使用するのにこつは必要ありません。
既定では、WSL はネットワークに NAT (ネットワーク アドレス変換) ベースのアーキテクチャを使用します。 NAT ベースのネットワーク アーキテクチャを使用する場合は、次の考慮事項に注意してください。
Linux ディストリビューションでネットワーク アプリ (たとえば、Node.js または SQL Server で実行されるアプリ) を構築する場合、(通常の場合と同様に) localhost
を使用して (Microsoft Edge または Chrome インターネット ブラウザーなどの) Windows アプリからアクセスすることができます。
Linux ディストリビューション (つまり、Ubuntu) から Windows 上で実行されているネットワーク アプリ (たとえば、Node.js または SQL Server で実行されるアプリ) にアクセスする場合は、ホスト マシンの IP アドレスを使用する必要があります。 これは一般的なシナリオではありませんが、次の手順に従ってこれを実現できます。
ip route show | grep -i default | awk '{ print $3}'
次の図は、これを実行するために、curl を介して Windows で実行されている Node.js サーバーに接続する例です。
リモート IP アドレスを使用してアプリケーションに接続すると、ローカル エリア ネットワーク (LAN) からの接続として扱われます。 これは、アプリケーションで LAN 接続を受け入れることができるようにする必要があることを意味します。
たとえば、場合によっては、127.0.0.1
ではなく 0.0.0.0
にアプリケーションをバインドする必要があります。 Flask を使用する Python アプリの例では、次のコマンドを使用してこれを実行できます: app.run(host='0.0.0.0')
。 これらの変更を行うと、LAN からの接続が許可されるため、セキュリティに注意してください。
WSL 1 ディストリビューションを使用している場合、LAN からアクセスできるようにコンピューターが設定されていれば、WSL で実行されているアプリケーションに LAN からもアクセスできます。
WSL 2 では、これは既定の動作ではありません。 WSL 2 には、独自の一意の IP アドレスを持つ仮想化されたイーサネット アダプターがあります。 現在、このワークフローを有効にするには、通常の仮想マシンの場合と同じ手順を実行する必要があります。 (Microsoft は、このエクスペリエンスを改善する方法を検討しています)。
Netsh インターフェイス portproxy Windows コマンドを使用して、ホスト ポートをリッスンし、そのポート プロキシを WSL 2 VM の IP アドレスに接続するポート プロキシを追加する例を次に示します。
netsh interface portproxy add v4tov4 listenport=<yourPortToForward> listenaddress=0.0.0.0 connectport=<yourPortToConnectToInWSL> connectaddress=(wsl hostname -I)
この例では、<yourPortToForward>
をポート番号 (listenport=4000
など) に更新する必要があります。 listenaddress=0.0.0.0
は、任意の IP アドレスからの受信要求が受け入れられることを意味します。 リッスン アドレスは、リッスンする IPv4 アドレスを指定します。これは、IP アドレス、コンピューターの NetBIOS 名、またはコンピューターの DNS 名を含む値に変更できます。 アドレスが指定されない場合、既定値はローカル コンピューターです。 <yourPortToConnectToInWSL>
値を、WSL が接続するポート番号 (例: connectport=4000
) に更新する必要があります。 最後に、connectaddress
値は、WSL 2 経由でインストールされた Linux ディストリビューションの IP アドレス (WSL 2 VM アドレス) である必要があります。これは、wsl.exe hostname -I
コマンドを入力することで確認できます。
したがって、このコマンドは次のようになります。
netsh interface portproxy add v4tov4 listenport=4000 listenaddress=0.0.0.0 connectport=4000 connectaddress=192.168.101.100
IP アドレスを取得するには、次を使用します。
wsl hostname -I
。WSL 2 経由でインストールされた Linux ディストリビューションの IP アドレスの場合 (WSL 2 VM アドレス)cat /etc/resolv.conf
。WSL 2 から見た Windows マシンの IP アドレスの場合 (WSL 2 VM)listenaddress=0.0.0.0
を使用すると、すべての IPv4 ポートでリッスンします。
注意
hostname コマンドで小文字の "i" を使用すると、大文字の "I" を使用する場合とは異なる結果が生成されます。 wsl hostname -i
はローカル コンピューターです (127.0.1.1 はプレースホルダー診断アドレスです)。一方、wsl hostname -I
では、他のマシンから見たローカル コンピューターの IP アドレスが返されるため、WSL 2 を介して実行されている Linux ディストリビューションの connectaddress
を識別するために使用する必要があります。
wsl hostname -i
。WSL 2 経由でインストールされた Linux ディストリビューションの IP アドレスの場合 (WSL 2 VM アドレス)ip route show | grep -i default | awk '{ print $3}'
。WSL 2 から見た Windows マシンの IP アドレスの場合 (WSL 2 VM)listenaddress=0.0.0.0
を使用すると、すべての IPv4 ポートでリッスンします。
Windows 11 22H2 以降を実行しているマシンでは、ミラー モードのネットワークを有効にするために、.wslconfig
ファイルの [wsl2]
の下に networkingMode=mirrored
を設定できます。 これを有効にすると、新しいネットワーク機能を追加し、互換性を改善するために、Windows 上にあるネットワーク インターフェイスを Linux に "ミラーリング" することを目標とする、まったく新しいネットワーク アーキテクチャに WSL が変更されます。
このモードを有効にするための現在の利点を次に示します。
127.0.0.1
を使用して Linux 内から Windows サーバーに接続する。 IPv6 localhost アドレス ::1
はサポートされていません注意
管理者特権を使用して PowerShell ウィンドウで次のコマンドを実行し、受信接続: Set-NetFirewallHyperVVMSetting -Name '{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}' -DefaultInboundAction Allow
または New-NetFirewallHyperVRule -Name "MyWebServer" -DisplayName "My Web Server" -Direction Inbound -VMCreatorId '{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}' -Protocol TCP -LocalPorts 80
を許可するように Hyper-V ファイアウォール設定を構成します。
この新しいモードは、NAT (ネットワーク アドレス変換) ベースのアーキテクチャの使用に関して見られるネットワークの問題に対処します。 GitHub の WSL 製品リポジトリで特定されたバグに関する既知の問題またはファイル フィードバックを確認します。
Windows 11 22H2 以降を実行しているマシンでは、.wslconfig
ファイルの [wsl2]
の下に dnsTunneling=true
を設定すると、WSL では WSL 内から DNS 要求に応答する仮想化機能が使用され、ネットワーク パケット経由でそれらが要求されることはありません。 この機能は、VPN やその他の複雑なネットワーク設定との互換性を向上させることを目的としています。
Windows 11 22H2 以降を実行しているマシンでは、.wslconfig
ファイルの [wsl2]
の下に autoProxy=true
を設定すると、WSL に Windows の HTTP プロキシ情報の使用が適用されます。 Windows でプロキシが既に設定されている場合、この機能を有効にすると、そのプロキシが WSL でも自動的に設定されます。
Windows 11 22H2 以降を実行しているコンピューター (WSL 2.0.9 以降) では、Hyper-V ファイアウォール機能が既定でオンになります。 これにより、次のことが保証されます。
Windows Subsystem for Linux に関するフィードバック
Windows Subsystem for Linux はオープンソース プロジェクトです。 フィードバックを提供するにはリンクを選択します。
トレーニング
認定資格
Microsoft Certified: Azure Network Engineer Associate - Certifications
Azure ネットワーク インフラストラクチャ、負荷分散トラフィック、ネットワーク ルーティングなどの設計、実装、メンテナンスのデモを行います。