IoT Edge for Linux on Windows ネットワークのトラブルシューティング
適用対象: IoT Edge 1.4
重要
サポートされているリリースは、Azure IoT Edge 1.5 LTS と IoT Edge 1.4 です。 IoT Edge 1.4 LTS は、2024 年 11 月 12 日にサービス終了になります。 以前のリリースの場合は、「IoT Edge を更新する」を参照してください。
お使いの環境で Azure IoT Edge for Linux on Windows (EFLOW) の使用中にネットワークの問題が発生した場合は、この記事を参考にしてトラブルシューティングと診断を行ってください。 EFLOW 仮想マシンのトラブルシューティングに関するヘルプがさらに必要な場合は、「IoT Edge for Linux on Windows デバイスのトラブルシューティング」も参照してください。
問題を切り分ける
IoT Edge for Linux on Windows ネットワークのトラブルシューティングを行う場合、次の 4 つのネットワーク機能が原因で問題が発生している可能性があります。
- IP アドレスの構成
- ドメイン ネーム システム (DNS) の構成
- ファイアウォールとポートの構成
- その他のコンポーネント
EFLOW ネットワークの概念の詳細については、「Windows ネットワーク上の Linux のIoT Edge」を参照してください。 また、EFLOW ネットワーク構成の詳細については、「Azure IoT Edge for Linux on Windows のネットワーク構成」を参照してください。
IP アドレスを確認する
IoT Edge for Linux on Windows ネットワークをトラブルシューティングする際の最初の手順は、VM の IP アドレス構成を確認することです。 IP 通信が正しく構成されていない場合、すべての受信および送信接続は失敗します。
- [管理者として実行] を使用して、管理者特権の PowerShell セッションを開始します。
- VM ライフサイクル エージェントによって返された IP アドレスを確認します。 IP アドレスをメモし、後の手順で VM 内から取得したものと比較します。
Get-EflowVmAddr
- EFLOW 仮想マシンに接続します。
Connect-EflowVm
- eth0 VM ネットワーク インターフェイス構成を確認します。
出力に、eth0 の構成情報が表示されているはずです。 inet アドレスが正しく設定されていることを確認します。ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 172.31.100.171 netmask 255.255.240.0 broadcast 172.31.111.255 inet6 fe80::215:5dff:fe2a:2f62 prefixlen 64 scopeid 0x20<link> ether 00:15:5d:2a:2f:62 txqueuelen 1000 (Ethernet) RX packets 115746 bytes 11579209 (11.0 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 976 bytes 154184 (150.5 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
inet IP アドレスが空白であるか、Get-EflowVmAddr
コマンドレットを使用して指定されたものと異なる場合は、EFLOW VM に無効な IP アドレスが割り当てられている理由、または IP アドレスが割り当てられていない理由をトラブルシューティングする必要があります。 次の表を使用して、問題をトラブルシューティングします。
仮想スイッチ | IP アドレスの割り当て | トラブルシューティング |
---|---|---|
外部 | [静的 IP] | IP 構成が正しく設定されていることを確認します。 3 つのパラメーター ip4Address、ip4GateWayAddress、および ip4PrefixLength をすべて使用する必要があります。 VM に割り当てられた IP アドレスは有効である必要があり、外部ネットワーク上の他のデバイスで使用されていてはなりません。 EFLOW VM インターフェイスの構成を確認するには、/etc/systemd/network/ にあるファイルを調べます。 |
外部 | [DHCP] | 外部ネットワークに DHCP サーバーがあることを確認します。 使用可能な DHCP サーバーがない場合は、静的 IP 構成を使用します。 また、DHCP サーバーに MAC アドレスに関するファイアウォール ポリシーがないことを確認します。 ある場合は、Get-EflowVmAddr コマンドレットを使用して、EFLOW MAC アドレスを取得できます。 |
既定のスイッチ | [DHCP] | 通常、この問題は既定のスイッチの誤動作に関連しています。 Windows ホスト OS を再起動してみてください。 問題が解決しない場合は、Hyper-V を無効にしてから有効にしてみてください |
Internal | [静的 IP] | IP 構成が正しく設定されていることを確認します。 3 つのパラメーター ip4Address、ip4GateWayAddress、および ip4PrefixLength をすべて使用する必要があります。 VM に割り当てられた IP アドレスは有効である必要があり、内部ネットワーク上の他のデバイスで使用されていてはなりません。 また、インターネットに接続するには、NAT テーブルを設定する必要があります。 「Azure IoT Edge for Linux on Windows 仮想スイッチの作成」の NAT の構成手順に従います。 |
Internal | [DHCP] | 内部ネットワークに DHCP サーバーがあることを確認します。 Windows Server で DHCP サーバーと NAT テーブルを設定するには、「Azure IoT Edge for Linux on Windows の仮想スイッチの作成」の手順に従います。 使用可能な DHCP サーバーがない場合は、静的 IP 構成を使用します。 |
警告
場合によっては、Windows Server またはクライアント VM で外部仮想スイッチを使用しているときに、追加の構成が必要になることがあります。 入れ子になった仮想化の構成に関する詳細については、「Azure IoT Edge for Linux on Windows の入れ子になった仮想化」を参照してください。
IP アドレスの割り当てに関する問題が解決しない場合は、別の Windows または Linux 仮想マシンを設定し、同じスイッチと IP 構成を割り当ててみてください。 新しい EFLOW 以外の VM で同じ問題が発生している場合、その問題は仮想スイッチまたは IP 構成に関連している可能性があり、EFLOW に固有のものではありません。
ドメイン ネーム システム (DNS) の構成を確認する
IoT Edge for Linux on Windows ネットワークをトラブルシューティングする際の 2 番目の手順は、EFLOW VM に割り当てられている DNS サーバーを確認することです。 EFLOW VM DNS の構成を確認するには、「Azure IoT Edge for Linux on Windows のネットワーク構成」を参照してください。 アドレス解決が機能している場合、問題はネットワーク上のファイアウォールまたはセキュリティ構成に関連している可能性があります。
EFLOW VM は、systemd-resolved サービスを使用して DNS 解決を管理します。 このサービスの詳細については、「Systemd-resolved」を参照してください。 特定の DNS サーバー アドレスを設定するには、Set-EflowVmDnsServers
コマンドレットを使用します。 DNS 構成に関する詳細情報が必要な場合は、/etc/systemd/resolved.conf、および sudo systemctl status systemd-resolved
コマンドを使用した system-resolved サービスを確認してください。 また、モジュール構成の一部として特定の DNS サーバーを設定することもできます。「オプション 2: モジュールごとに IoT Edge のデプロイで DNS サーバーを設定します」を参照してください。
アドレス解決は、複数の理由で失敗する可能性があります。 最初に、DNS サーバーは正しく構成できたが、EFLOW VM からアクセスできない場合があります。 DNS サーバーが ICMP ping トラフィックに応答する場合は、DNS サーバーに ping を実行して、ネットワーク接続を確認できます。
- [管理者として実行] を使用して、管理者特権の PowerShell セッションを開始します。
- EFLOW 仮想マシンに接続します。
Connect-EflowVm
- DNS サーバー アドレスに ping を実行し、応答を確認します。
ping <DNS-Server-IP-Address>
ヒント
サーバーに到達できる場合は、応答を受け取るはずであるため、問題は他の DNS サーバー構成に関連している可能性があります。 応答がない場合は、サーバーへの接続に問題が発生している可能性があります。
2 番目に、一部のネットワーク環境では、DNS サーバーのアクセスが特定の許可リスト アドレスに制限されます。 その場合は、まず Windows ホスト OS から DNS サーバーにアクセスできることを確認してから、EFLOW IP アドレスを許可リストに追加する必要があるかどうかをネットワーク チームに確認してください。
最後に、一部のネットワーク環境では、Google DNS (8.8.8.8 や 8.8.4.4) などのパブリック DNS サーバーがブロックされます。 その場合は、ネットワーク環境チームと話し合って有効な DNS サーバーを定義し、Set-EflowVmDnsServers
コマンドレットを使用して設定します。
ファイアウォール規則とポート構成規則を確認する
Azure IoT Edge for Linux on Windows では、サポートされている Azure IoT Hub プロトコルを使用した、オンプレミス サーバーから Azure クラウドへの通信が許可されます。 IoT Hub プロトコルの詳細については、「通信プロトコルの選択」を参照してください。 IoT Hub ファイアウォールとポートの構成の詳細については、「IoT Edge デバイスのトラブルシューティング」を参照してください。
IoT Edge for Linux on Windows は、基になる Windows ホスト OS とネットワーク構成に引き続き依存しています。 そのため、エッジからクラウドへの安全な通信を実現するための適切なネットワーク規則およびファイアウォール規則が設定されていることを確認することが不可欠です。 Azure IoT Edge for Linux on Windows ランタイムがホストされている基になるサーバー用にファイアウォール規則を構成するときは、以下の表をガイドラインとして使用できます。
プロトコル | [ポート] | 着信 | 送信 | ガイダンス |
---|---|---|---|---|
MQTT | 8883 | ブロック (既定値) | ブロック (既定値) | 通信プロトコルとして MQTT を使用する場合は、"送信 (アウトバウンド)" を "オープン" になるように構成します。 MQTT での 1883 は、IoT Edge ではサポートされていません。 - 受信 (インバウンド) 接続はブロックする必要があります。 |
AMQP | 5671 | ブロック (既定値) | オープン (既定値) | IoT Edge の既定の通信プロトコル。 Azure IoT Edge が他のサポートされているプロトコル用に構成されていない場合、または AMQP が望ましい通信プロトコルである場合は、"オープン" になるように構成する必要があります。 AMQP での 5672 は、IoT Edge ではサポートされていません。 Azure IoT Edge が、IoT Hub でサポートされているのとは異なるプロトコルを使用する場合は、このポートをブロックします。 受信 (インバウンド) 接続はブロックする必要があります。 |
HTTPS | 443 | ブロック (既定値) | オープン (既定値) | IoT Edge のプロビジョニングのために、"送信 (アウトバウンド)" をポート 443 で "オープン" になるように構成します。 この構成は、手動スクリプトや Azure IoT Device Provisioning Service (DPS) を使用する場合に必要です。 "受信 (インバウンド) 接続" が、以下の 2 つの特定のシナリオだけで "オープン" になるようにする必要があります。 1. メソッド要求を送信することがあるダウンストリーム デバイスを備えた透過的なゲートウェイがある場合。 この場合、ポート 443 は、IoT Hub に接続したり Azure IoT Edge を通じて IoT Hub サービスを提供したりするために、外部ネットワークに対してオープンにする必要はありません。 そのため、受信規則は内部ネットワークからのオープンな "受信 (インバウンド)" だけに制限することができます。 2. クライアントからデバイス (C2D) のシナリオの場合。 HTTP での 80 は、IoT Edge ではサポートされていません。 企業内で非 HTTP プロトコル (AMQP や MQTT など) を構成できない場合は、メッセージを WebSockets 経由で送信できます。 その場合、ポート 443 は WebSocket 通信のために使用されます。 |
Note
外部仮想スイッチを使用している場合は、EFLOW 仮想マシン内で使用しているモジュール ポート マッピングに適切なファイアウォール規則を必ず追加してください。
EFLOW VM ファイアウォールの詳細については、IoT Edge for Linux on Windows のセキュリティに関する記事を参照してください。 EFLOW 仮想マシンの規則を確認するには、次の手順に従います。
- [管理者として実行] を使用して、管理者特権の PowerShell セッションを開始します。
- EFLOW 仮想マシンに接続します。
Connect-EflowVm
- iptables ファイアウォール規則を一覧表示します。
sudo iptables -L
EFLOW VM にファイアウォール規則を追加するには、EFLOW Util - Firewall Rules のサンプル PowerShell コマンドレットを使用できます。 また、次の手順に従って、同じ規則を適用することもできます。
- [管理者として実行] を使用して、管理者特権の PowerShell セッションを開始します。
- EFLOW 仮想マシンに接続します
Connect-EflowVm
- "<プロトコル>" (udp または tcp) トラフィックの "<ポート>" への着信トラフィックを受け入れるファイアウォール規則を追加します。
sudo iptables -A INPUT -p <protocol> --dport <port> -j ACCEPT
- 最後に、VM が起動されるたびに再作成されるように規則を保持します
sudo iptables-save | sudo tee /etc/systemd/scripts/ip4save
その他の構成を確認する
ネットワーク通信が失敗する理由は、他にも複数あります。 次のセクションでは、ユーザーが過去に遭遇したいくつかの問題を一覧で紹介します。
EFLOW 仮想マシンが ping (ICMP トラフィック) 要求に応答しない。
既定では、ICMP ping トラフィック応答は EFLOW VM ファイアウォールで無効になっています。 ping 要求に応答するには、次の PowerShell コマンドレットを使用して ICMP トラフィックを許可します。
Invoke-EflowVmCommand "sudo iptables -A INPUT -p icmp --icmp-type 8 -s 0/0 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT"
マルチキャスト トラフィックを使用したデバイスの検出に失敗する。
まず、マルチキャストによるデバイスの検出を許可するには、Hyper-V VM が外部スイッチを使用するように構成されている必要があります。 次に、コンテナーの作成オプションを使用して、ホスト ネットワークを使用するように IoT Edge カスタム モジュールを構成する必要があります。
{ "HostConfig": { "NetworkMode": "host" }, "NetworkingConfig": { "EndpointsConfig": { "host": {} } } }
ファイアウォール規則が追加されたが、トラフィックが IoT Edge モジュールにまだ到達できない。
適切なファイアウォール規則を追加しても通信が依然として機能しない場合は、ファイアウォールを完全に無効にしてトラブルシューティングしてみてください。
sudo iptables -F sudo iptables -X sudo iptables -P INPUT ACCEPT sudo iptables -P OUTPUT ACCEPT sudo iptables -P FORWARD ACCEPT
完了したら、VM (
Stop-EflowVm
とStart-EflowVm
) を再起動して、EFLOW VM ファイアウォールを通常の状態に戻します。複数の NIC を使用しているときにインターネットに接続できない。
一般に、この問題はルーティングの問題に関連しています。 「Azure IoT Edge for Linux on Windows の産業用 IoT および DMZ 構成を構成する方法」を参照して、静的ルートを設定します。
次のステップ
IoT Edge プラットフォームのバグを発見したと思われる場合は、 改善を続けられるように問題を報告してください。
その他に質問がある場合は、サポート リクエストを作成して対応を要請してください。