Red y cortafuegos

Configuración del cortafuegos

Si el appliance se ejecuta en una red local restringida, permite el acceso saliente a los siguientes endpoints de IronFlock para que pueda alcanzar la nube. Todas las conexiones las inicia el appliance — no es necesario abrir ningún puerto entrante en tu cortafuegos.

instance-registry.ironflock.com:443   # descarga y actualización del software de IronFlock y los agentes; el asistente de IA y las notificaciones por SMS
cbw.ironflock.com:443                 # gestión remota del appliance desde la nube
web.ironflock.com:443                 # activación y validación de la licencia
registry.ironflock.com:443            # descarga de imágenes de apps al sincronizar desde la IronFlock Store pública
regauth.ironflock.com:443             # autenticación de esas descargas de imágenes de la Store pública
app.ironflock.com:443                 # apertura de las interfaces de usuario de apps y dispositivos desde la nube (opcional)
smtp-proxy.ironflock.com:2525         # envío de correos de cuenta y notificaciones (opcional)

Las entradas registry.ironflock.com y regauth.ironflock.com son necesarias para sincronizar apps desde la IronFlock Store pública hacia la App Store local. registry.ironflock.com sirve las imágenes de las apps y regauth.ironflock.com emite el token que autoriza cada descarga — ambas deben ser accesibles, o la sincronización (y la exploración/instalación remota de apps) falla. Si tu appliance solo sirve apps que compilas localmente, puedes omitirlas. Una app cuyas imágenes proceden de un registro público como Docker Hub se copia desde ese registro durante la sincronización, así que el appliance también necesita poder alcanzarlo.

La entrada app.ironflock.com transporta el túnel de acceso remoto que hace accesibles las interfaces de usuario de apps y dispositivos mientras trabajas en la instancia desde ironflock.com. Funciona por el puerto 443 como todo lo demás, directamente o a través de un proxy corporativo; solo un appliance instalado con IRONFLOCK_CLOUD_TUNNEL_TCP=1 usa en su lugar el puerto 7000. Si la entrada está bloqueada, nada falla de forma visible — esas interfaces simplemente no se abren desde la nube, aunque siguen funcionando en la red local. Omítela si solo usas el appliance en local.

La entrada smtp-proxy.ironflock.com solo es necesaria si usas el relay de correo integrado de IronFlock. Si configuras tu propio servidor SMTP, puedes omitirla.

Destinos opcionales. El asistente de IA actualiza los metadatos de modelos y widgets desde raw.githubusercontent.com y cdn.jsdelivr.net, y la búsqueda de direcciones para la ubicación de los dispositivos usa nominatim.openstreetmap.org. Los tres son opcionales: si están bloqueados, el asistente recurre a sus datos integrados y la búsqueda de direcciones deja de estar disponible.

La sincronización horaria no está en esta lista porque no va hacia IronFlock: aun así, el appliance necesita una fuente de tiempo que funcione. Permite el UDP 123 saliente hacia tus servidores de tiempo, o configura tu servidor de tiempo interno en el host — consulta Sincronización horaria (NTP).

Si tu red solo alcanza internet a través de un proxy HTTP corporativo, consulta Detrás de un proxy corporativo — el instalador puede apuntar el demonio de Docker a tu proxy automáticamente.

Dispositivos que se conectan al appliance

Los dispositivos de borde se conectan al appliance, no a la nube. Si los dispositivos están en un segmento de red distinto al del appliance, permite que las redes de los dispositivos alcancen el host del appliance en estos puertos:

<APPLIANCE_HOST>:18080   # enlace del dispositivo (WebSocket) — obligatorio
<APPLIANCE_HOST>:15001   # registro local de la App Store (descarga de imágenes de apps) — obligatorio
<APPLIANCE_HOST>:15002   # autenticación del registro (tokens de descarga de imágenes), actualizaciones del agente de dispositivo e instalador de dispositivos — obligatorio
<APPLIANCE_HOST>:7000    # acceso remoto a las UI de los dispositivos (función de túnel opcional)

Estas son conexiones directas — no deben enrutarse a través de un proxy HTTP corporativo. Si la red de un dispositivo fuerza todo el tráfico a través de un proxy, o bien exime al host del appliance del proxy en el dispositivo, o bien cambia el appliance a HTTPS con tu certificado corporativo: en ese modo todo el tráfico de los dispositivos — el enlace del dispositivo, las descargas de imágenes, las actualizaciones del agente y el túnel de acceso remoto — pasa a un único puerto compatible con proxy: el 443 de tu dominio, y funciona a través de proxies corporativos y cortafuegos estrictos sin excepciones por puerto.

El puerto 15002 también sirve las actualizaciones del agente de dispositivo y el instalador de dispositivos: los dispositivos conectados al appliance descargan las actualizaciones del agente — y los dispositivos nuevos, el instalador — desde el propio appliance, nunca desde internet; en modo dominio, en su lugar, desde https://registry.<APPLIANCE_DOMAIN>/dl por el puerto 443. Consulta Actualizaciones del agente de dispositivo y Dar de alta dispositivos sin acceso a internet.

Los dispositivos no necesitan acceso a internet para el funcionamiento normal. Todo lo que hace un dispositivo conectado al appliance — el enlace del dispositivo, las imágenes de apps, las actualizaciones del agente, el acceso remoto — va al appliance. Un dispositivo solo sale a internet cuando compila una app a partir de un Dockerfile cuya imagen base está en un registro público, cuando publicas una app que usa imágenes públicas, cuando todavía hay que instalar el propio Docker y — en dispositivos con FlockOS — para buscar actualizaciones del sistema operativo en instance-registry.ironflock.com. Las apps que despliegues pueden tener sus propias necesidades de red.

Identidad de red de los hosts de IronFlock

El appliance y cada dispositivo de borde ejecutan IronFlock como un servicio del sistema desatendido: arranca con el sistema y permanece conectado a todas horas, haya o no alguien con la sesión iniciada. Por eso, las reglas de cortafuegos y de proxy para estos hosts deben vincularse a la máquina — nunca a la persona que tenga la sesión iniciada en ella en ese momento. Para los dispositivos de borde esto se aplica sea cual sea la plataforma a la que se conecten; la guía de dispositivos lo trata en Cortafuegos y proxies con reconocimiento de identidad.

Esto importa sobre todo en redes con un cortafuegos o proxy con reconocimiento de identidad (identity-aware), que concede el acceso según la identidad del directorio en lugar de según la dirección. Si la regla que admite a un host de IronFlock está ligada a un usuario, el host pierde el acceso en cuanto caduca la sesión de ese usuario. Las conexiones ya abiertas siguen funcionando mientras cada conexión nueva se descarta en silencio, así que el host parece estar bien hasta que necesita volver a conectarse — entonces falla la instalación de una app, una actualización del agente o una reconexión, y tras su siguiente reinicio el dispositivo sigue desconectado.

No hace falta ninguna exención de la aplicación de políticas por identidad. Pide a tu equipo de red que identifique cada host por la identidad que realmente tiene:

Cómo se traslada esto a los productos más habituales:

• Check Point Identity Awareness: en el Access Role, selecciona la máquina (objeto de equipo o grupo) en lugar de usuarios. Las identidades de máquina se renuevan con la propia actividad del equipo en el dominio; si en tu gateway pueden caducar, usa en su lugar un objeto de red.
• Palo Alto Networks User-ID: las cuentas de equipo no generan asignaciones de IP a usuario, así que usa un objeto de dirección, una etiqueta o Device-ID.
• Fortinet FSSO y cortafuegos similares basados en directorio: usa un objeto de dirección para el host, o la dirección dinámica que asigna tu control de acceso a la red.
• Zscaler, Prisma Access y otros gateways de seguridad en la nube: registra la dirección del appliance como servidor o como ubicación de IoT (un origen de confianza), de modo que su tráfico se identifique por ubicación y no por usuario.

Cómo reconocer el fallo. Un dispositivo que sigue en línea pero falla en cada conexión nueva — descargas de imágenes, inicios de sesión en el registro, reconexiones — mientras los pings y su sesión existente siguen funcionando apunta a una regla de identidad caducada, no al dispositivo. No reinicies el agente hasta que una conexión nueva desde el dispositivo vuelva a tener éxito: la sesión que sigue abierta es la única que funciona.

Accede a tu instancia desde ironflock.com

Aunque el appliance es una plataforma completamente local, no hace falta estar en la red de la fábrica para usarlo. Mientras el appliance tenga conexión a internet y tu cuenta del appliance esté conectada a tu cuenta de ironflock.com (consulta Vincular cuentas), puedes saltar a tu instancia directamente desde la UI cloud de IronFlock — sin VPN, sin reenvío de puertos, sin herramientas adicionales.

Esto significa:

• Una UI unificada — gestiona tus proyectos en la nube y tus instancias de appliance lado a lado desde una única pestaña del navegador.
• Trabaja desde cualquier sitio — operadores, desarrolladores y personal de soporte pueden alcanzar el appliance por internet, mientras que todos los datos de producción y cargas de trabajo permanecen locales en el appliance.
• Supervisión multisede sencilla — si operas varios appliances en distintas fábricas, cada uno aparece en tu cuenta de ironflock.com y está a un clic de distancia.

Cuando el appliance pierde la conexión a internet, sigue ejecutándose localmente y permanece accesible desde dentro de la red de la fábrica en http://<appliance-host> — solo el acceso remoto queda en pausa hasta que vuelva la conectividad.