网络与防火墙

防火墙配置

如果 Appliance 运行在受限的本地网络中，请放行对以下 IronFlock 端点的出站访问，以便它能够连接云端。所有连接均由 Appliance 主动发起——您的防火墙无需开放任何入站端口。

instance-registry.ironflock.com:443   # 下载和更新 IronFlock 软件和代理；AI 助手和短信通知
cbw.ironflock.com:443                 # 从云端远程管理 Appliance
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 中的应用同步到本地 App Store。registry.ironflock.com 提供应用镜像，regauth.ironflock.com 颁发授权每次拉取的令牌——两者都必须可达，否则同步（以及远程应用浏览/安装）将失败。如果您的 appliance 始终只提供您本地构建的应用，则可以将它们省略。如果某个应用的镜像来自 Docker Hub 等公共镜像仓库，同步时会直接从该镜像仓库复制，因此 Appliance 也必须能够访问它。

app.ironflock.com 一项承载远程访问隧道：当您通过 ironflock.com 使用实例时，应用和设备的用户界面正是经由它才能访问。它与其他所有连接一样通过端口 443 运行，无论是直接连接还是经由企业代理；只有使用 IRONFLOCK_CLOUD_TUNNEL_TCP=1 安装的 Appliance 才会改用端口 7000。如果该项被拦截，不会出现明显的报错——这些界面只是无法从云端打开，在本地网络中仍可正常使用。如果您只在本地使用 Appliance，可以将其省略。

smtp-proxy.ironflock.com 一项仅在您使用内置的 IronFlock 邮件中继时才需要。如果您配置了自己的 SMTP 服务器，则可以将其省略。

可选目标地址。 AI 助手会从 raw.githubusercontent.com 和 cdn.jsdelivr.net 刷新模型和小部件的元数据，为设备位置查询地址则会用到 nominatim.openstreetmap.org。这三项均为可选：如果它们被拦截，AI 助手会改用其内置数据，地址查询功能则不可用。

时间同步不在此列表中，因为它并非发往 IronFlock：但 Appliance 仍然需要一个可用的时间源。请放行发往你的时间服务器的出站 UDP 123，或在主机上配置内部时间服务器——参见时间同步 (NTP)。

如果您的网络只能通过企业 HTTP 代理访问互联网，请参阅位于企业代理之后——安装程序可以自动将 Docker 守护进程指向您的代理。

连接到 Appliance 的设备

边缘设备连接到 Appliance，而不是连接到云端。如果设备所在的网段与 Appliance 不同，请放行设备网络在以下端口上访问 Appliance 主机：

<APPLIANCE_HOST>:18080   # 设备链路（WebSocket）——必需
<APPLIANCE_HOST>:15001   # 本地 App Store 镜像仓库（拉取应用镜像）——必需
<APPLIANCE_HOST>:15002   # 镜像仓库身份验证（镜像拉取令牌）、设备代理程序更新及设备安装程序——必需
<APPLIANCE_HOST>:7000    # 远程访问设备 UI（可选的隧道功能）

这些是直接连接——它们不得通过企业 HTTP 代理路由。如果设备所在的网络强制所有流量都经过代理，请在设备侧将 Appliance 主机从代理中排除，或将 Appliance 切换到使用您的企业证书的 HTTPS：在该模式下，所有设备流量——设备链路、镜像拉取、代理程序更新以及远程访问隧道——都会迁移到您域名上单一的、对代理友好的端口：443，无需逐端口开放例外即可穿越企业代理和严格的防火墙。

端口 15002 也用于设备代理程序更新和设备安装程序：连接到 Appliance 的设备从 Appliance 自身下载代理程序更新（新设备则下载安装程序），而不是从互联网下载——在域名模式下则改为通过端口 443 从 https://registry.<APPLIANCE_DOMAIN>/dl 获取。参见设备代理程序更新和注册无法访问互联网的设备。

设备在正常运行时无需访问互联网。 连接到 Appliance 的设备所做的一切——设备链路、应用镜像、代理程序更新、远程访问——都发往 Appliance。设备只有在以下情况下才会访问互联网：从 Dockerfile 构建应用、且其基础镜像位于公共镜像仓库时；您发布使用公共镜像的应用时；仍需安装 Docker 本身时；以及在运行 FlockOS 的设备上，向 instance-registry.ironflock.com 检查操作系统更新时。您部署的应用本身可能还有各自的网络需求。

IronFlock 主机的网络身份

Appliance 和每一台边缘设备都以无人值守的系统服务形式运行 IronFlock：它随系统启动，并全天候保持连接，无论是否有人登录。因此，针对这些主机的防火墙和代理规则必须绑定到机器——而绝不能绑定到恰好在该机器上登录的人员。对于边缘设备，无论它们连接到哪个平台，这一点都同样适用；设备指南在身份感知防火墙与代理中对此有详细说明。

这一点在部署了身份感知防火墙或代理（identity-aware firewall / proxy）的网络中尤为重要：这类产品按目录身份而非地址授予访问权限。如果放行某台 IronFlock 主机的规则绑定到某个用户，那么一旦该用户的会话失效，该主机就会失去访问权限。已经建立的连接会继续运行，而每个新连接都会被静默丢弃，因此主机在下一次需要建立连接之前看起来一切正常；到那时，应用安装、代理程序更新或重新连接就会失败，而设备在下一次重启后将一直处于离线状态。

无需为这些主机豁免身份策略。请让您的网络团队按照每台主机实际具有的身份来识别它：

在常见产品中的对应做法：

• Check Point Identity Awareness： 在 Access Role 中选择机器（计算机对象或组），而不是用户。机器身份依靠计算机自身的域活动来刷新；如果在您的网关上机器身份可能失效，请改用网络对象。
• Palo Alto Networks User-ID： 计算机账户不会产生 IP 到用户的映射，因此请使用地址对象、标签（tag）或 Device-ID。
• Fortinet FSSO 及类似的基于目录的防火墙： 为该主机使用地址对象，或使用您的网络准入控制分配的动态地址。
• Zscaler、Prisma Access 及其他云安全网关： 将 Appliance 的地址注册为服务器或 IoT 位置（受信任的来源），使其流量按位置而非按用户来识别。

如何识别这类故障。 如果设备保持在线，但每个新连接——镜像拉取、镜像仓库登录、重新连接——都失败，而 ping 和其现有会话仍然正常，那么问题出在已过期的身份规则上，而不在设备本身。在设备重新能够成功建立新连接之前，请不要重启代理程序：仍然保持打开的那个会话是当前唯一可用的连接。

通过 ironflock.com 访问您的实例

尽管 Appliance 是一个完全本地的平台，您不必待在工厂网络内也能使用它。 只要 Appliance 有互联网连接，且您的 appliance 账户已连接到您的 ironflock.com 账户（参见账户关联）， 您就可以直接从 IronFlock 云端 UI 切换到您的实例——无需 VPN，无需端口转发，无需任何额外工具。

这意味着：

• 统一的 UI — 在同一个浏览器标签页中并排管理您的云端项目和 appliance 实例。
• 随处办公 — 操作员、开发者和支持人员可以通过互联网访问 Appliance，而所有生产数据和工作负载始终保留在 Appliance 本地。
• 多站点轻松管理 — 如果您在不同工厂运营多台 Appliance，每一台都会出现在您的 ironflock.com 账户中，只需一键即可访问。

当 Appliance 失去互联网连接时，它会继续在本地运行，并仍然可以通过 http://<appliance-host> 在工厂网络内访问——只有远程访问通道会暂停，直到连接恢复。