Detrás de un proxy corporativo

Muchas redes de fábrica y empresariales solo alcanzan internet a través de un proxy HTTP corporativo (por ejemplo, un proxy Squid en el puerto 3128). El IronFlock Appliance se instala y funciona sin problemas en esta configuración — tú proporcionas tu proxy en el comando de instalación y el instalador configura todo lo demás por ti.

Esta página asume que el host del appliance no tiene definidas variables de entorno de proxy — tú proporcionas el proxy de forma explícita. Explica lo que el instalador gestiona automáticamente y el único paso adicional necesario para los proxies que interceptan TLS.

Este es el complemento sobre proxies de la sección Configuración del cortafuegos de la guía del Appliance. Deben ser alcanzables los mismos endpoints de IronFlock — la diferencia es que aquí se alcanzan a través de tu proxy.

Por qué un proxy requiere atención

Las imágenes de la plataforma IronFlock las descarga el demonio de Docker — un servicio en segundo plano con su propia configuración de red, separada de tu shell. Incluso en un host que por lo demás puede alcanzar internet a través del proxy, el demonio no lo conoce a menos que se le indique explícitamente. Si se deja sin configurar, intenta conectarse directamente, la red lo bloquea y la instalación se detiene en el paso de inicio de sesión con un timeout:


Error response from daemon: Get "https://instance-registry.ironflock.com/v2/":
net/http: request canceled while waiting for connection (Client.Timeout exceeded)

Qué gestiona el instalador por ti

Cuando proporcionas un proxy en el comando de instalación, el instalador configura el demonio de Docker por ti — escribe un fragmento de configuración de proxy en /etc/systemd/system/docker.service.d/http-proxy.conf y reinicia Docker una vez para que pueda alcanzar el registro de IronFlock. Este paso es:

Sin intervención — proporcionas el proxy una vez (ver más abajo); el instalador escribe la configuración y reinicia Docker por ti, sin configuración manual del demonio.
Idempotente — en actualizaciones posteriores solo reinicia Docker si el proxy cambió realmente, de modo que tus apps en ejecución no se ven afectadas.
Omitido por completo cuando no se proporciona ningún proxy — las instalaciones con internet directo no se ven afectadas.

El instalador también enruta la propia conexión del appliance a la nube a través del proxy — la validación de la licencia y el enlace de gestión remota que te permite alcanzar tu instancia desde ironflock.com. Registra tu proxy en la configuración del appliance y la plataforma lo usa automáticamente. No se necesita ninguna configuración adicional para que el appliance se conecte.

Ejecutar el instalador detrás de un proxy

El proxy se necesita en dos lugares: curl lo necesita para descargar el instalador, y el instalador lo necesita para configurar Docker. Proporciónalo a ambos en un solo comando — define la URL del proxy una vez, pásala a curl con --proxy y al instalador con --http-proxy / --https-proxy:


# Tu proxy corporativo — edita esta línea
PROXY="http://proxy.your-company.com:3128"
 
curl -fsSL --proxy "$PROXY" \
  https://instance-registry.ironflock.com/dl/appliance/install_ironflock.sh \
  | sudo bash -s -- <your-instance-key> --http-proxy "$PROXY" --https-proxy "$PROXY"

Sustituye la URL del proxy y <your-instance-key> por tus propios valores. Si tu proxy requiere autenticación, incluye las credenciales en la URL: http://user:password@proxy.your-company.com:3128.

Flags de proxy del instalador:

Flag	Propósito
`--http-proxy <url>`	Proxy para el tráfico HTTP simple del demonio de Docker.
`--https-proxy <url>`	Proxy para el tráfico HTTPS (el que importa para la descarga de imágenes).
`--no-proxy <list>`	Hosts adicionales, separados por comas, que deben omitir el proxy.

Los mismos valores pueden proporcionarse como variables de entorno IRONFLOCK_HTTP_PROXY, IRONFLOCK_HTTPS_PROXY e IRONFLOCK_NO_PROXY.

Si el host ya exporta HTTP_PROXY / HTTPS_PROXY, puedes ejecutar en su lugar sudo -E bash (sin los flags) y el instalador las detectará automáticamente — pero en un appliance recién instalado normalmente no están definidas, así que pasarlas explícitamente como se muestra arriba es la vía fiable.

El tráfico local siempre omite el proxy

No necesitas gestionar NO_PROXY a mano. El instalador siempre mantiene localhost, 127.0.0.1 y la propia dirección del host del appliance fuera del proxy (todo lo que pases con --no-proxy se conserva y se fusiona). Esto garantiza que la app store local y el registro del appliance se alcancen directamente, sin enrutarse hacia fuera a través del proxy corporativo.

Dispositivos de borde

Todo lo anterior se aplica igualmente a los dispositivos de borde configurados con la herramienta de configuración de dispositivos (ironflock-init). Acepta los mismos flags de proxy y se configura de la misma forma — pasa el proxy cuando la ejecutes y enrutará sus descargas (gestor de paquetes, instalación de Docker, descarga del agente) y el demonio de Docker a través del proxy por ti:


sudo ./ironflock-init -c mydevice.flock \
  --http-proxy "$PROXY" --https-proxy "$PROXY"

El script de bootstrap que descarga la herramienta de configuración se ejecuta antes que ella, así que proporciona también el proxy a ese paso — expórtalo primero en el shell para que su descarga funcione:


export HTTP_PROXY="$PROXY"
export HTTPS_PROXY="$PROXY"
curl -sSL --proxy "$PROXY" https://instance-registry.ironflock.com/dl/reswarmify/install.sh | bash

Si el dispositivo descarga las imágenes de apps desde una app store local de un appliance en lugar de la nube, añade el host de ese registro con --no-proxy para que esas descargas permanezcan en la red local.

En los dispositivos Windows el agente se ejecuta como servicio de Windows; pase el proxy al instalador del servicio — se guarda en el entorno del servicio y cubre la conexión con la plataforma y las autoactualizaciones del agente:


reagent.exe service install -config path\to\config.flock -proxy "http://proxy.example.com:3128"

Docker Desktop no lee esta configuración: configure su proxy por separado en Settings → Resources → Proxies para que también funcionen las descargas de imágenes.

Proxies que interceptan TLS (CA corporativa)

Muchos proxies corporativos inspeccionan el tráfico HTTPS volviéndolo a firmar con una autoridad de certificación (CA) de la empresa. Para estos, configurar el proxy es necesario pero no suficiente — el host del appliance también debe confiar en esa CA, o se rechazará cada conexión a la nube (descargas de imágenes, validación de licencia, el enlace de gestión).

Instala la CA una sola vez, en el almacén de confianza del sistema del host. El appliance monta ese almacén de confianza en todos sus contenedores, de modo que Docker y todos los servicios de IronFlock toman la CA — no hay nada que configurar por contenedor ni por servicio. Como los contenedores la leen al arrancar, reinicia el stack tras añadir o cambiar la CA (paso 3 más abajo).

1. Obtén la CA corporativa

Pide a tu equipo de red la CA raíz de “inspección SSL” / “interceptación TLS” del proxy — el mismo certificado ya desplegado en las máquinas corporativas gestionadas — como un archivo .crt. Esa es la fuente más limpia.

Instala la CA emisora, no el certificado de un único host. El error habitual es guardar el certificado refirmado por el proxy para un nombre de host (por ejemplo, solo instance-registry.ironflock.com). Eso hace que únicamente ese host funcione y deja fallando a todos los demás hosts de la nube. Necesitas la CA que firma esos certificados.

Si no puedes obtener el archivo directamente pero el proxy presenta su cadena completa, puedes extraer la CA desde la conexión — sustituye <PROXY_HOST>:<PROXY_PORT> por tu proxy:


# Captura la cadena, un PEM por certificado. c1 es la hoja por host (omítela);
# c2..cN son la cadena de CA corporativa en la que confiar.
echo quit | openssl s_client -connect instance-registry.ironflock.com:443 \
  -proxy <PROXY_HOST>:<PROXY_PORT> -showcerts 2>/dev/null \
  | awk '/BEGIN CERTIFICATE/{n++; c=1} c{print > ("/tmp/proxy-c" n ".pem")} /END CERTIFICATE/{c=0}'
 
# Opcional — inspecciona lo que se obtuvo:
for f in /tmp/proxy-c*.pem; do echo "== $f =="; openssl x509 -in "$f" -noout -subject -issuer; done

2. Instálala y reconstruye el almacén de confianza

Si tu equipo de IT te dio el .crt directamente:


sudo cp corporate-root-ca.crt /usr/local/share/ca-certificates/corporate-proxy-ca.crt
sudo update-ca-certificates

Si la extrajiste de la cadena anterior, confía en cada certificado excepto la hoja (c1):


i=0; for f in $(ls -v /tmp/proxy-c*.pem | tail -n +2); do
  i=$((i+1)); sudo cp "$f" "/usr/local/share/ca-certificates/corporate-proxy-ca-$i.crt"
done
sudo update-ca-certificates

3. Verifica

Cada host de la nube de IronFlock debe validarse ahora a través del proxy — un estado HTTP, no un error de TLS:


for H in instance-registry.ironflock.com web.ironflock.com cbw.ironflock.com \
         registry.ironflock.com regauth.ironflock.com; do
  curl -x http://<PROXY_HOST>:<PROXY_PORT> -sS -o /dev/null -w "$H -> %{http_code}\n" "https://$H/"
done

Un código como 200, 401 o 404 para los cinco significa que la CA es correcta. Luego reinicia el stack para que los servicios la tomen (o vuelve a ejecutar el instalador):


sudo systemctl restart ironflock.service

Acceso remoto a las interfaces de usuario de los dispositivos

IronFlock te permite abrir una interfaz de usuario que se ejecuta en un dispositivo o máquina de borde — un HMI de máquina, una página de PLC, una pantalla de configuración o dashboard en el propio dispositivo — directamente dentro de IronFlock, desde cualquier lugar. Este es un habilitador clave para el servicio y soporte remotos: un ingeniero puede alcanzar la interfaz de una máquina sin estar en las instalaciones ni en la red local. El acceso está siempre mediado y protegido por el sistema de privilegios de IronFlock, de modo que solo los usuarios autorizados alcanzan un dispositivo dado.

Este túnel de acceso remoto está construido sobre frp (Fast Reverse Proxy), una tecnología de código abierto madura y ampliamente utilizada. IronFlock la usa únicamente para proporcionar el acceso a la interfaz de dispositivos descrito arriba.

Por qué un proxy corporativo puede interponerse

frp tiene potentes capacidades de atravesado de red y, por esa razón, los productos de seguridad antivirus y proxy a menudo lo marcan genéricamente como riskware — aunque, como componente de código abierto con una larga trayectoria, es seguro y aquí se usa solo para la función de acceso remoto autorizada. Cuando eso ocurre, el proxy bloquea la descarga del componente de IronFlock que contiene frp.

Esto no rompe tu appliance: el túnel de acceso remoto es una función opcional, así que si ese componente se bloquea, la plataforma se instala y funciona con normalidad y simplemente opera sin acceso a la interfaz de dispositivos. En el dashboard, los controles de acceso remoto de un dispositivo indican entonces que el acceso remoto no está disponible en este appliance.

Qué necesita permitir el IT corporativo

Si tu organización quiere beneficiarse de las funciones de servicio remoto de IronFlock, el componente de IronFlock que contiene frp debe poder descargarse a través del proxy corporativo. Pide a tu equipo de red/seguridad que:

Exima el tráfico de descarga de IronFlock del análisis de contenido antivirus / malware y del bloqueo de descarga de archivos para el componente frp — la opción más limpia es añadir los endpoints de IronFlock a la lista de no descifrar (exclusión de la inspección TLS) del proxy.
Trate la detección de frp como una excepción aprobada: es un conocido falso positivo para el uso legítimo de esta biblioteca de código abierto.

Se aplican los mismos endpoints de IronFlock ya enumerados para el appliance — consulta Configuración del cortafuegos; esto trata de no analizar/bloquear ese tráfico, además de simplemente enrutarlo.

Una vez que frp está permitido, basta con volver a ejecutar la actualización — la función se activa automáticamente en cuanto la descarga funciona, sin ningún otro cambio:


sudo ironflock-update

Funcionar sin acceso remoto

Si no necesitas acceso a la interfaz de dispositivos — o quieres una instalación limpia mientras se gestiona la excepción del proxy — puedes desactivar el túnel explícitamente. Todo lo demás se instala con normalidad:


# en el momento de la instalación, añadido al comando de instalación
... | sudo bash -s -- <your-instance-key> --no-tunnel
 
# o en un appliance ya instalado
sudo ironflock-update --no-tunnel

La elección se recuerda entre actualizaciones. Vuelve a activarlo más tarde (una vez que frp esté permitido) con --tunnel:


sudo ironflock-update --tunnel

Resolución de problemas

La instalación se detiene en “Logging in to instance-registry.ironflock.com” con un error Client.Timeout. El demonio de Docker no puede alcanzar el registro. Vuelve a ejecutar el instalador y pasa tu proxy con --http-proxy / --https-proxy, como se muestra arriba.

El inicio de sesión sigue fallando tras configurar el proxy. Lo más probable es que tu proxy intercepte TLS. Instala la CA corporativa como se describe en Proxies que interceptan TLS, y vuelve a ejecutar.

Comprueba que el demonio de Docker ve el proxy:


sudo systemctl show --property=Environment docker
sudo docker login instance-registry.ironflock.com

Si docker login funciona por sí solo, la instalación del appliance superará el paso que falla.

Un único componente no se descarga mientras todo lo demás se instala correctamente. Normalmente se trata del componente de acceso remoto basado en frp que tu proxy o antivirus bloquea como riskware. La instalación se completa igualmente — solo el acceso a la interfaz de dispositivos queda no disponible. Para habilitarlo, pide a tu equipo de proxy que permita ese tráfico como se describe en Acceso remoto a las interfaces de usuario de los dispositivos, y luego vuelve a ejecutar ironflock-update. Para instalar deliberadamente sin él, pasa --no-tunnel.

Actualizaciones

Una vez que un appliance está instalado detrás de un proxy, su configuración de proxy se recuerda. Tanto las actualizaciones manuales como las actualizaciones automáticas en segundo plano siguen funcionando a través del proxy sin ninguna acción adicional — consulta Mantenimiento en la guía del Appliance.

Si el acceso remoto a las interfaces de dispositivos fue bloqueado en el momento de la instalación, cada actualización lo reintenta automáticamente — así, en cuanto tu proxy permita frp, la siguiente actualización activa la función sin pasos adicionales.