ネットワークとファイアウォール

ファイアウォールの設定

アプライアンスを制限されたローカルネットワーク内で運用する場合は、クラウドに到達できるよう、以下の IronFlock エンドポイントへのアウトバウンドアクセスを許可してください。すべての接続はアプライアンス側から開始されるため、ファイアウォールでインバウンドポートを開放する必要はありません。

instance-registry.ironflock.com:443   # IronFlock ソフトウェアとエージェントのダウンロードと更新、AI アシスタントと SMS 通知
cbw.ironflock.com:443                 # クラウドからのアプライアンスのリモート管理
web.ironflock.com:443                 # ライセンスの有効化と検証
registry.ironflock.com:443            # パブリックの IronFlock Store から同期する際のアプリイメージのプル
regauth.ironflock.com:443             # パブリック Store からのイメージプルの認証
app.ironflock.com:443                 # クラウドからアプリおよびデバイスのユーザーインターフェースを開く（任意）
smtp-proxy.ironflock.com:2525         # アカウントメールおよび通知メールの送信（任意）

registry.ironflock.com と regauth.ironflock.com のエントリは、パブリックの IronFlock Store から local App Store へアプリを同期するために必要です。registry.ironflock.com がアプリイメージを提供し、regauth.ironflock.com が各プルを認可するトークンを発行します — 両方に到達できなければ、同期（およびリモートのアプリ閲覧・インストール）は失敗します。アプライアンスがローカルでビルドしたアプリのみを提供する場合は、省略できます。Docker Hub などのパブリックレジストリのイメージを使うアプリは、同期時にそのレジストリからコピーされるため、アプライアンスはそのレジストリにも到達できる必要があります。

app.ironflock.com のエントリは、ironflock.com からインスタンスで作業する際に、アプリやデバイスのユーザーインターフェースへ到達できるようにするリモートアクセストンネルを通します。このトンネルは他のすべての通信と同様にポート 443 を使用し、直接接続でも企業プロキシ経由でも動作します。IRONFLOCK_CLOUD_TUNNEL_TCP=1 を指定してインストールしたアプライアンスのみ、代わりにポート 7000 を使用します。このエントリがブロックされていても、目立ったエラーは発生しません — これらのインターフェースがクラウドから開けなくなるだけで、ローカルネットワーク上では引き続き動作します。アプライアンスをローカルでのみ使用する場合は、省略できます。

smtp-proxy.ironflock.com のエントリは、組み込みの IronFlock メールリレーを使用する場合にのみ必要です。独自の SMTP サーバー を設定する場合は、省略できます。

任意の接続先。 AI アシスタントはモデルとウィジェットのメタデータを raw.githubusercontent.com と cdn.jsdelivr.net から更新し、デバイスの設置場所の住所検索には nominatim.openstreetmap.org を使用します。3 つはいずれも任意です。ブロックされている場合、AI アシスタントは組み込みのデータで動作し、住所検索は利用できなくなります。

時刻同期は IronFlock 宛ての通信ではないため、この一覧には含まれていません。それでもアプライアンスには機能する時刻ソースが必要です。時刻サーバー宛ての外向き UDP 123 を許可するか、ホストに社内の時刻サーバーを設定してください — 時刻同期（NTP） を参照してください。

ネットワークが企業の HTTP プロキシ経由でしかインターネットに到達できない場合は、企業プロキシの背後で を参照してください — インストーラが Docker デーモンを自動的にプロキシへ向けるよう設定できます。

アプライアンスに接続するデバイス

エッジデバイスは、クラウドではなくアプライアンスに接続します。デバイスがアプライアンスとは異なるネットワークセグメントに存在する場合は、デバイスネットワークが以下のポートでアプライアンスホストに到達できるよう許可してください。

<APPLIANCE_HOST>:18080   # デバイスリンク（WebSocket）— 必須
<APPLIANCE_HOST>:15001   # local App Store レジストリ（アプリイメージのプル）— 必須
<APPLIANCE_HOST>:15002   # レジストリ認証（イメージプルトークン）、デバイスエージェントの更新およびデバイスインストーラー — 必須
<APPLIANCE_HOST>:7000    # デバイス UI へのリモートアクセス（任意のトンネル機能）

これらは直接接続であり、企業の HTTP プロキシ経由でルーティングしてはいけません。デバイスのネットワークがすべてのトラフィックをプロキシ経由に強制する場合は、デバイス側でアプライアンスホストをプロキシの対象外にするか、アプライアンスを 企業証明書による HTTPS に切り替えてください。このモードでは、すべてのデバイストラフィック — デバイスリンク、イメージのプル、エージェントの更新、およびリモートアクセストンネル — が、自社ドメイン上の単一のプロキシフレンドリーなポート：443 に集約され、ポートごとの例外設定なしで企業プロキシや厳格なファイアウォールを通過して動作します。

ポート 15002 はデバイスエージェントの更新とデバイスインストーラーにも使われます。アプライアンスに接続されたデバイスはエージェントの更新を、新しいデバイスはインストーラーを、インターネットからではなくアプライアンス自身からダウンロードします — ドメインモードでは代わりに https://registry.<APPLIANCE_DOMAIN>/dl からポート 443 経由で取得します。デバイスエージェントの更新 と インターネットに接続できないデバイスの登録 を参照してください。

通常の運用では、デバイスにインターネットアクセスは必要ありません。 接続されたデバイスが行う通信 — デバイスリンク、アプリイメージ、エージェントの更新、リモートアクセス — はすべてアプライアンス宛てです。デバイスがインターネットに接続するのは、ベースイメージがパブリックレジストリにある Dockerfile からアプリをビルドするとき、パブリックイメージを使用するアプリを公開するとき、Docker 自体をまだインストールする必要があるとき、そして — FlockOS を実行しているデバイスでは — instance-registry.ironflock.com で OS の更新を確認するときだけです。デプロイするアプリには、それぞれ独自のネットワーク要件がある場合があります。

IronFlock ホストのネットワーク ID

アプライアンスとすべてのエッジデバイスは、IronFlock を無人のシステムサービスとして実行します。起動時に開始し、誰かがサインインしているかどうかに関係なく常時接続を維持します。そのため、これらのホストに対するファイアウォールおよびプロキシのルールはマシンに紐づける必要があります — たまたまそのマシンにログインしている人に紐づけてはいけません。エッジデバイスについては、どのプラットフォームに接続する場合でもこれが当てはまります。詳しくはデバイスガイドの ID 認識型ファイアウォールとプロキシ で説明しています。

これが特に重要になるのは、アドレスではなくディレクトリ上の ID に基づいてアクセスを許可する ID 認識型ファイアウォールまたはプロキシ（identity-aware firewall / proxy）を使用しているネットワークです。IronFlock ホストを許可するルールがユーザーに紐づいていると、そのユーザーのセッションが切れた時点でホストはアクセスを失います。すでに開いている接続は動作し続ける一方、新しい接続はすべて通知なく破棄されるため、ホストは次に接続が必要になるまで正常に見えます。そのときにアプリのインストール、エージェントの更新、再接続が失敗し、次に再起動した後はデバイスがオフラインのままになります。

ID による制御の対象外にする必要はありません。各ホストを、そのホストが実際に持っている ID で識別するよう、ネットワークチームに依頼してください。

主な製品では、次のように対応します。

• Check Point Identity Awareness： Access Role で、ユーザーではなくマシン（コンピューターオブジェクトまたはグループ）を選択します。マシン ID はコンピューター自身のドメイン上のアクティビティによって更新されます。ゲートウェイ上でマシン ID が失効する可能性がある場合は、代わりにネットワークオブジェクトを使用してください。
• Palo Alto Networks User-ID： コンピューターアカウントからは IP とユーザーのマッピングが生成されないため、アドレスオブジェクト、タグ、または Device-ID を使用してください。
• Fortinet FSSO および同様のディレクトリベースのファイアウォール： ホストのアドレスオブジェクト、またはネットワークアクセス制御が割り当てるダイナミックアドレスを使用してください。
• Zscaler、Prisma Access などのクラウドセキュリティゲートウェイ： アプライアンスのアドレスをサーバーまたは IoT のロケーション（信頼できる送信元）として登録し、そのトラフィックがユーザーではなくロケーションによって識別されるようにしてください。

障害の見分け方。 デバイスはオンラインのままなのに、新しい接続 — イメージのプル、レジストリへのログイン、再接続 — がすべて失敗し、ping と既存のセッションは動作し続けている場合、原因はデバイスではなく、期限切れになった ID ルールにあります。デバイスからの新しい接続が再び成功するまでは、エージェントを再起動しないでください。まだ開いているセッションが、唯一機能している接続だからです。

ironflock.com からインスタンスにアクセスする

アプライアンスは完全にローカルなプラットフォームですが、利用するために工場ネットワーク内にいる必要はありません。 アプライアンスがインターネットに接続されており、アプライアンスのアカウントが ironflock.com のアカウントと接続されていれば（アカウントの連携 を参照）、IronFlock クラウド UI からインスタンスに直接切り替えることができます — VPN もポートフォワーディングも、追加のツールも不要です。

これにより、次のことが可能になります。

• 統一された UI — クラウドプロジェクトとアプライアンスインスタンスを、1 つのブラウザタブで並べて管理できます。
• どこからでも作業可能 — オペレーター、開発者、サポートスタッフはインターネット経由でアプライアンスに到達できる一方、すべての本番データとワークロードはアプライアンス上にローカルで保持されます。
• マルチサイトの管理が容易 — 複数の工場で複数のアプライアンスを運用している場合、それぞれが ironflock.com アカウントに表示され、ワンクリックでアクセスできます。

アプライアンスがインターネット接続を失っても、ローカルでは引き続き動作し、工場ネットワーク内からは http://<appliance-host> で引き続きアクセスできます — リモートアクセス経路だけが、接続が復旧するまで一時的に停止されます。