Azure IoT Edge を施設ネットワークへ設置したところ、

開発環境では Azure IoT Hub に接続できるのに、病院など一部の施設では接続できない

という問題が発生しました。

PC自体は Internet に接続できます。

Web Browser から Web Site も開けます。

それでも Azure IoT Edge から Azure IoT Hub への通信だけが通りません。

今回の原因は、

Azure IoT Edge
↓
AMQP
↓
TCP 5671
↓
施設 Firewall
↓
Block

という、施設側の Network Policy でした。

そこで、

AMQP
↓
AMQP over WebSocket

へ変更し、

TCP 5671
↓
TCP 443

を利用する構成に変更しました。

この記事では、

Internet は使えるのに Azure IoT Hub へ接続できない理由
AMQP と AMQP over WebSocket の違い
なぜ TCP 443 を使うと改善することがあるのか
Azure IoT Edge で変更するときの考え方
変更後も確認すべき Network 設定

を整理します。

結論

今回のポイントはこれです。

変更前

Azure IoT Edge
↓
AMQP
↓
TCP 5671
↓
施設 Firewall
↓
施設によって OK / NG

これを、

変更後

Azure IoT Edge
↓
AMQP over WebSocket
↓
TCP 443
↓
施設 Firewall
↓
Azure IoT Hub

へ変更しました。

AMQP自体に問題があったわけではありません。

問題だったのは、

AMQP
↓
TCP 5671

という通信経路が、一部施設の Network Policy と合わなかったことです。

症状：Internetには接続できるのにAzure IoT Hubへ接続できない

今回の構成を単純化すると、次のようになります。

接続機器
↓
Edge PC
（Azure IoT Edge）
↓
Azure IoT Hub
↓
Cloud

Edge PC 上では、

接続機器からDataを受信
↓
Edge PC上で処理
↓
必要なDataをCloudへ送信

という処理を行っています。

開発環境では正常に通信できていました。

しかし、実際に複数の施設へ設置すると、

施設A
↓
Cloud接続 OK

施設B
↓
Cloud接続 NG

という違いが発生しました。

しかも施設Bでも、

Web Browser
↓
Internet
↓
OK

です。

ここで最初に注意したいのが、

Internetへ接続できることと、すべてのOutbound Portが利用できることは別

という点です。

原因：通常のAMQPはTCP 5671を使用する

Azure IoT Hub との主な通信では、Protocolによって使用するPortが異なります。

Protocol	Outbound TCP Port
AMQP	5671
MQTT	8883
AMQP over WebSocket	443
MQTT over WebSocket	443
HTTPS	443

通常の AMQP では、

Azure IoT Edge
↓
AMQP
↓
TCP 5671
↓
Azure IoT Hub

という通信になります。

Outbound通信の制限が少ないNetworkであれば、

TCP 5671
↓
許可
↓
Azure IoT Hub

となるため問題ありません。

しかし、病院や企業Networkなどでは、外部への通信Portが制限されていることがあります。

例えば、

TCP 443
↓
許可

TCP 5671
↓
Block

という環境です。

この場合、

HTTPS
↓
TCP 443
↓
Internet
↓
OK

でも、

Azure IoT Edge
↓
AMQP
↓
TCP 5671
↓
Facility Firewall
↓
Block

となります。

その結果、

PCはInternetへ接続できるのにAzure IoT Hubへは接続できない

という、一見分かりにくい状態になります。

なぜ施設によって接続できたりできなかったりするのか

Network Policy は施設ごとに異なります。

例えば、

施設A

TCP 5671
↓
許可
↓
AMQP通信 OK

という環境もあれば、

施設B

TCP 443
↓
許可

TCP 5671
↓
制限
↓
AMQP通信 NG

という環境もあります。

つまり、

同じEdge PC
同じApplication
同じAzure IoT Edge
同じAzure IoT Hub

であっても、

設置するNetworkによって結果が変わります。

これは、Edge PC内部だけを調査していると見落としやすいポイントです。

Windows Firewallを変更しても解決しないケースがある

通信経路全体を見ると、

Edge PC
↓
Edge PC Firewall
↓
施設Network
↓
施設Firewall / Proxy
↓
Internet
↓
Azure IoT Hub

となります。

例えばEdge PC側で、

TCP 5671
↓
許可

していたとしても、

その先にある施設Firewallで、

TCP 5671
↓
Block

されていれば通信できません。

つまり、

Edge PC側のFirewall Ruleだけを変更し続けても解決しない場合がある

ということです。

Cloudへ接続できない場合は、PC内部だけではなく、

Edge PC
↓
施設Network
↓
Internet
↓
Cloud

という経路全体を見る必要があります。

対応1：施設側にTCP 5671を許可してもらう

一つの方法は、

施設Firewall
↓
TCP 5671 Outbound
↓
許可

してもらうことです。

技術的には、この方法でも通常の AMQP を利用できます。

しかし、複数施設へEdge PCを展開する場合、

施設A
↓
5671許可可能

施設B
↓
Security Policy上許可できない

施設C
↓
Network管理会社への申請が必要

施設D
↓
Firewall変更に時間がかかる

といった差が発生する可能性があります。

これでは、Edge PCを設置するたびに個別調整が必要になります。

長期間・複数拠点で運用するシステムでは、

施設ごとの特別なFirewall設定にできるだけ依存しない

構成の方が運用しやすくなります。

対応2：AMQP over WebSocketへ変更する

そこで採用したのが、

AMQP over WebSocket

です。

通常の AMQP は、

Azure IoT Edge
↓
AMQP
↓
TCP 5671
↓
Azure IoT Hub

ですが、AMQP over WebSocket では、

Azure IoT Edge
↓
AMQP
↓
WebSocket
↓
TLS
↓
TCP 443
↓
Azure IoT Hub

となります。

大きな違いは、

TCP 443を利用できること

です。

AMQPがHTTPSに変わるわけではない

ここは少し分かりにくいポイントです。

AMQP over WebSocket に変更したからといって、

AMQP
↓
HTTPS

という別のMessage Protocolになるわけではありません。

イメージとしては、

┌─────────────────┐
│      AMQP       │
├─────────────────┤
│    WebSocket    │
├─────────────────┤
│      TLS        │
├─────────────────┤
│     TCP 443     │
└─────────────────┘

です。

つまり、

AMQPのMessage通信をWebSocketの通信経路に載せています。

Message通信としては、

AMQP

を利用しながら、Network上では、

TCP 443

を使用できます。

なぜTCP 443だと通りやすいのか

TCP 443 は、

HTTPS
Cloud Service
Web Application

などで広く利用されています。

そのためInternet接続を提供している施設Networkでは、

TCP 443
↓
Outbound許可

となっているケースが比較的多くあります。

今回も、

通常AMQP
↓
TCP 5671
↓
施設Networkで通信できない

という環境に対して、

AMQP over WebSocket
↓
TCP 443
↓
Azure IoT Hub

へ変更することで対応しました。

ここで重要なのは、

施設側のSecurityを弱くしたわけではない

という点です。

新しいPortを施設側に開放してもらうのではなく、

既存のNetwork Policyの中で利用できる通信方式へEdge PC側を合わせた

という考え方です。

Azure IoT EdgeではUpstream Protocolを変更する

Azure IoT Edge では、Cloud側への通信Protocolを、

UpstreamProtocol

で指定できます。

今回の変更を概念的に表すと、

変更前

UpstreamProtocol
↓
AMQP
↓
TCP 5671

から、

変更後

UpstreamProtocol
↓
AmqpWs
↓
TCP 443

への変更です。

edgeAgentとedgeHubの両方を考える

Azure IoT Edge Runtime では、代表的なSystem Moduleとして、

edgeAgent
edgeHub

があります。

役割を単純化すると、

Module	主な役割
edgeAgent	Moduleの配置、起動、監視、状態管理
edgeHub	Module間通信やAzure IoT Hubとの通信

となります。

Azureとの通信を一言で、

Edge PC
↓
Azure IoT Hub

と表してしまいがちですが、実際には複数のRuntime Moduleが通信しています。

例えば、

edgeAgent
↓
Deployment情報取得
Module状態報告
↓
Azure IoT Hub

と、

Application Module
↓
edgeHub
↓
Telemetry / Message
↓
Azure IoT Hub

があります。

そのため、

一部
↓
AMQP over WebSocket

一部
↓
AMQP

という構成では、一部通信だけTCP 5671を利用してしまう可能性があります。

今回の方針では、

edgeAgent
↓
AMQP over WebSocket

edgeHub
↓
AMQP over WebSocket

↓
TCP 443
↓
Azure IoT Hub

とし、

Edge PC → Azure IoT Hub のUpstream通信をAMQP over WebSocketへ統一する

形にしました。

TCP 443にすれば必ず通信できるわけではない

ここは重要です。

AMQP over WebSocket
↓
TCP 443

に変更すれば、

すべての施設で必ず通信できるわけではありません。

施設Networkによっては、

Proxy
TLS Inspection
WebSocket制限
接続先FQDN制限
DNS制限

などが存在する可能性があります。

したがって、AMQP over WebSocketへ変更した後も、実際の施設NetworkでAzure IoT Hubまで通信できるか確認する必要があります。

Cloudへ接続できないときの確認ポイント

Azure IoT Edge が施設NetworkからCloudへ接続できない場合、私は次の順番で考えます。

1. Edge PC自体はInternetへ接続できるか
        ↓
2. Azure IoT Hubへの通信だけ失敗していないか
        ↓
3. 使用Protocolは何か
        ↓
4. 使用しているOutbound Portは何か
        ↓
5. 施設Firewallで許可されているか
        ↓
6. Proxyは存在するか
        ↓
7. WebSocketは許可されているか
        ↓
8. TLS Inspectionは存在するか
        ↓
9. DNS名前解決はできるか
        ↓
10. 接続先FQDNに制限がないか

特に、

Internetに接続できる

だけで、

Networkに問題はない

と判断しないことが重要です。

まとめ

今回の問題は、

Azure IoT Edge
↓
AMQP
↓
TCP 5671

という通信が、一部施設のNetwork Policyで許可されていなかったことでした。

そのため、

Azure IoT Edge
↓
AMQP over WebSocket
↓
TCP 443
↓
Azure IoT Hub

へ変更しました。

ポイントを整理すると、

Internet接続ができてもTCP 5671が使えるとは限らない
通常のAMQPではTCP 5671を使用する
AMQP over WebSocketではTCP 443を利用できる
PC側Firewallだけでなく施設Firewallも確認する
edgeAgent / edgeHubを含めUpstream通信全体で考える
TCP 443でもProxyやWebSocket制限によって通信できない場合がある
最終的には実際の施設Networkで確認する

となります。

開発環境で、

Azure IoT Edge
↓
Azure IoT Hub
↓
接続成功

しているだけでは、複数施設への展開では不十分です。

重要なのは、

実際に設置されるNetworkでも通信できる設計になっているか

まで確認することです。

特に病院や企業Networkなど、Security Policyが厳しい環境へEdge PCを展開する場合、

Applicationが正常に動くか

だけではなく、

どのProtocolを使うか
どのPortを使うか
施設Firewallを通過できるか

まで含めて設計しておく必要があります。

補足

本記事は、実際のEdge PC運用・障害対応経験をもとに、機密情報に配慮して一部を一般化・匿名化しています。

特定の組織、施設、製品、システムについて説明するものではありません。

また、

AMQP over WebSocket
TCP 443

を使用すれば、すべてのNetwork環境で通信できることを保証するものではありません。

実際の環境では、

Firewall
Proxy
WebSocket
TLS Inspection
DNS
接続先FQDN
Network Policy

などを確認し、実際の施設NetworkからAzure IoT Hubまで正常に通信できることを確認したうえで展開することが重要です。