Derrière un proxy d’entreprise

De nombreux réseaux d’usine et d’entreprise n’atteignent internet qu’à travers un proxy HTTP d’entreprise (par exemple un proxy Squid sur le port 3128). L’IronFlock Appliance s’installe et fonctionne sans accroc dans cette configuration — vous fournissez votre proxy dans la commande d’installation, et l’installateur configure tout le reste à votre place.

Cette page suppose que l’hôte de l’appliance n’a aucune variable d’environnement de proxy définie — vous fournissez le proxy explicitement. Elle explique ce que l’installateur gère automatiquement et l’étape supplémentaire nécessaire pour les proxys qui interceptent le TLS.

Ceci est le complément « proxy » de la section Configuration du pare-feu du guide Appliance. Les mêmes points de terminaison IronFlock doivent être accessibles — la différence est qu’ici ils sont atteints à travers votre proxy.

Pourquoi un proxy demande de l’attention

Les images de la plateforme IronFlock sont récupérées par le démon Docker — un service en arrière-plan avec sa propre configuration réseau, distincte de votre shell. Même sur un hôte qui peut par ailleurs atteindre internet à travers le proxy, le démon ne le connaît pas tant qu’on ne le lui indique pas explicitement. Laissé non configuré, il tente de se connecter directement, le réseau le bloque, et l’installation s’arrête à l’étape de connexion avec un délai d’attente dépassé :

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

Ce que l’installateur gère pour vous

Lorsque vous fournissez un proxy dans la commande d’installation, l’installateur configure le démon Docker à votre place — il écrit un fichier drop-in de proxy dans /etc/systemd/system/docker.service.d/http-proxy.conf et redémarre Docker une fois afin qu’il puisse atteindre le registre IronFlock. Cette étape est :

• Sans intervention — vous fournissez le proxy une seule fois (voir ci-dessous) ; l’installateur écrit la configuration et redémarre Docker pour vous, aucune configuration manuelle du démon.
• Idempotente — lors des mises à jour ultérieures, il ne redémarre Docker que si le proxy a réellement changé, afin que vos apps en cours d’exécution ne soient pas perturbées.
• Entièrement ignorée lorsqu’aucun proxy n’est fourni — les installations en accès internet direct ne sont pas affectées.

L’installateur achemine également la propre connexion de l’appliance vers le cloud à travers le proxy — la validation de la licence et l’uplink de gestion à distance qui vous permet d’atteindre votre instance depuis ironflock.com. Il enregistre votre proxy dans la configuration de l’appliance, et la plateforme l’utilise automatiquement. Aucune configuration distincte n’est nécessaire pour que l’appliance se mette en ligne.

Lancer l’installateur derrière un proxy

Le proxy est nécessaire à deux endroits : curl en a besoin pour télécharger l’installateur, et l’installateur en a besoin pour configurer Docker. Fournissez-le aux deux en une seule commande — définissez l’URL du proxy une fois, passez-la à curl avec --proxy, et à l’installateur avec --http-proxy / --https-proxy :

# Votre proxy d'entreprise — modifiez cette ligne
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"

Remplacez l’URL du proxy et <your-instance-key> par vos propres valeurs. Si votre proxy nécessite une authentification, incluez les identifiants dans l’URL : http://user:password@proxy.your-company.com:3128.

Drapeaux de proxy de l’installateur :

Les mêmes valeurs peuvent être fournies via les variables d’environnement IRONFLOCK_HTTP_PROXY, IRONFLOCK_HTTPS_PROXY et IRONFLOCK_NO_PROXY.

Si l’hôte exporte déjà HTTP_PROXY / HTTPS_PROXY, vous pouvez à la place exécuter sudo -E bash (sans les drapeaux) et l’installateur les détectera automatiquement — mais sur une appliance fraîche, elles ne sont généralement pas définies, donc les passer explicitement comme ci-dessus est la voie fiable.

Le trafic local contourne toujours le proxy

Vous n’avez pas besoin de gérer NO_PROXY à la main. L’installateur garde toujours localhost, 127.0.0.1 et la propre adresse d’hôte de l’appliance en dehors du proxy (tout ce que vous passez avec --no-proxy est conservé et fusionné). Cela garantit que l’app store local et le registre de l’appliance sont atteints directement, jamais acheminés vers l’extérieur à travers le proxy d’entreprise.

Appareils Edge

Tout ce qui précède s’applique de la même manière aux appareils edge configurés avec l’outil de configuration d’appareil (ironflock-init). Il prend les mêmes drapeaux de proxy et se configure de la même façon — passez le proxy lorsque vous l’exécutez, et il achemine ses téléchargements (gestionnaire de paquets, installation de Docker, téléchargement de l’agent) et le démon Docker à travers le proxy pour vous :

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

Le script d’amorçage qui télécharge l’outil de configuration s’exécute avant lui, donnez donc le proxy à cette étape aussi — exportez-le d’abord dans le shell pour que son téléchargement aboutisse :

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

Si l’appareil récupère les images d’apps depuis un app store d’appliance local plutôt que depuis le cloud, ajoutez l’hôte de ce registre avec --no-proxy pour que ces récupérations restent sur le réseau local.

Sur les appareils Windows, l’agent s’exécute en tant que service Windows ; transmettez le proxy à l’installateur du service — il est enregistré dans l’environnement du service et couvre la connexion à la plateforme ainsi que les mises à jour automatiques de l’agent :

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

Docker Desktop ne lit pas ce paramètre : configurez son proxy séparément sous Settings → Resources → Proxies pour que les téléchargements d’images fonctionnent également.

Proxys interceptant le TLS (CA d’entreprise)

De nombreux proxys d’entreprise inspectent le trafic HTTPS en le re-signant avec une autorité de certification (CA) de l’entreprise. Pour ceux-ci, configurer le proxy est nécessaire mais pas suffisant — l’hôte de l’appliance doit également faire confiance à cette CA, sinon chaque connexion vers le cloud (récupération des images, validation de la licence, uplink de gestion) est rejetée.

Installez la CA une seule fois, dans le magasin de confiance du système de l’hôte. L’appliance monte ce magasin de confiance dans tous ses conteneurs, de sorte que Docker et chaque service IronFlock prennent en compte la CA — il n’y a rien à configurer par conteneur ou par service. Comme les conteneurs la lisent au démarrage, redémarrez la stack après avoir ajouté ou modifié la CA (étape 3 ci-dessous).

1. Obtenir la CA d’entreprise

Demandez à votre équipe réseau la CA racine d’« inspection SSL » / d’« interception TLS » du proxy — le même certificat déjà déployé sur les machines d’entreprise gérées — sous forme de fichier .crt. C’est la source la plus propre.

Installez la CA émettrice, pas le certificat d’un seul hôte. L’erreur courante est d’enregistrer le certificat re-signé par le proxy pour un nom d’hôte (par exemple uniquement instance-registry.ironflock.com). Cela ne fait fonctionner que cet hôte et laisse échouer tous les autres hôtes du cloud. Vous avez besoin de la CA qui signe ces certificats.

Si vous ne pouvez pas obtenir le fichier directement mais que le proxy présente sa chaîne complète, vous pouvez extraire la CA depuis le réseau — remplacez <PROXY_HOST>:<PROXY_PORT> par votre proxy :

# Capture la chaîne, un PEM par certificat. c1 est la feuille propre à l'hôte (à ignorer) ;
# c2..cN sont la chaîne de CA d'entreprise à approuver.
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}'
 
# Facultatif — inspectez ce qui est revenu :
for f in /tmp/proxy-c*.pem; do echo "== $f =="; openssl x509 -in "$f" -noout -subject -issuer; done

2. L’installer et reconstruire le magasin de confiance

Si votre équipe IT vous a fourni le .crt directement :

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

Si vous l’avez extrait de la chaîne ci-dessus, approuvez chaque certificat sauf la feuille (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. Vérifier

Chaque hôte du cloud IronFlock doit désormais se valider à travers le proxy — un statut HTTP, et non une erreur 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 code comme 200, 401 ou 404 pour les cinq signifie que la CA est correcte. Redémarrez ensuite la stack pour que les services la prennent en compte (ou relancez l’installateur) :

sudo systemctl restart ironflock.service

Accès à distance aux interfaces utilisateur des appareils

IronFlock vous permet d’ouvrir une interface utilisateur qui s’exécute sur un appareil ou une machine edge — un IHM de machine, une page d’automate (PLC), un écran de configuration ou de tableau de bord embarqué — directement dans IronFlock, depuis n’importe où. C’est un facilitateur clé pour le service et le support à distance : un technicien peut atteindre l’interface d’une machine sans être sur site ni sur le réseau local. L’accès est toujours médiatisé et protégé par le système de privilèges IronFlock, de sorte que seuls les utilisateurs autorisés atteignent un appareil donné.

Ce tunnel d’accès à distance repose sur frp (Fast Reverse Proxy), une technologie open source mature et largement utilisée. IronFlock l’utilise uniquement pour fournir l’accès aux interfaces des appareils décrit ci-dessus.

Pourquoi un proxy d’entreprise peut faire obstacle

frp possède de puissantes capacités de traversée de réseau, et pour cette raison les produits de sécurité antivirus et proxy le signalent souvent de façon générique comme logiciel à risque (riskware) — même si, en tant que composant open source ayant fait ses preuves, il est sûr et n’est utilisé ici que pour la fonction d’accès à distance autorisée. Lorsque cela se produit, le proxy bloque le téléchargement du composant IronFlock qui contient frp.

Cela ne casse pas votre appliance : le tunnel d’accès à distance est une fonction optionnelle, donc si ce composant est bloqué, la plateforme s’installe et fonctionne normalement et opère simplement sans accès aux interfaces des appareils. Dans le tableau de bord, les commandes d’accès à distance d’un appareil indiquent alors que l’accès à distance n’est pas disponible sur cette appliance.

Ce que le service informatique de l’entreprise doit autoriser

Si votre organisation souhaite bénéficier des fonctions de service à distance d’IronFlock, le composant IronFlock contenant frp doit être autorisé à se télécharger à travers le proxy d’entreprise. Demandez à votre équipe réseau/sécurité de :

• Exempter le trafic de téléchargement d’IronFlock de l’analyse de contenu antivirus / anti-malware et du blocage de téléchargement de fichiers pour le composant frp — l’option la plus propre est d’ajouter les points de terminaison d’IronFlock à la liste ne-pas-déchiffrer (contournement de l’inspection TLS) du proxy.
• Traiter la détection de frp comme une exception approuvée : il s’agit d’un faux positif bien connu pour l’usage légitime de cette bibliothèque open source.

Les mêmes points de terminaison IronFlock déjà listés pour l’appliance s’appliquent — voir Configuration du pare-feu ; il s’agit ici de ne pas analyser/bloquer ce trafic, en plus de simplement l’acheminer.

Une fois frp autorisé à passer, il suffit de relancer la mise à jour — la fonction s’active automatiquement dès que le téléchargement aboutit, sans aucun autre changement :

sudo ironflock-update

Fonctionner sans accès à distance

Si vous n’avez pas besoin de l’accès aux interfaces des appareils — ou si vous voulez une installation propre pendant que l’exception du proxy est mise en place — vous pouvez désactiver le tunnel explicitement. Tout le reste s’installe normalement :

# au moment de l'installation, ajouté à la commande d'installation
... | sudo bash -s -- <your-instance-key> --no-tunnel
 
# ou sur une appliance déjà installée
sudo ironflock-update --no-tunnel

Ce choix est mémorisé d’une mise à jour à l’autre. Réactivez-le plus tard (une fois frp autorisé) avec --tunnel :

sudo ironflock-update --tunnel

Dépannage

L’installation s’arrête à « Logging in to instance-registry.ironflock.com » avec une erreur Client.Timeout. Le démon Docker ne peut pas atteindre le registre. Relancez l’installateur et passez votre proxy avec --http-proxy / --https-proxy, comme montré ci-dessus.

La connexion échoue toujours après avoir configuré le proxy. Votre proxy intercepte très probablement le TLS. Installez la CA d’entreprise comme décrit dans Proxys interceptant le TLS, puis relancez.

Vérifiez que le démon Docker voit le proxy :

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

Si docker login réussit de lui-même, l’installation de l’appliance dépassera l’étape défaillante.

Un seul composant échoue au téléchargement alors que tout le reste s’installe correctement. Il s’agit généralement du composant d’accès à distance basé sur frp qui est bloqué par votre proxy ou votre antivirus en tant que logiciel à risque (riskware). L’installation se termine tout de même — seul l’accès aux interfaces des appareils est indisponible. Pour l’activer, demandez à votre équipe proxy d’autoriser ce trafic comme décrit dans Accès à distance aux interfaces utilisateur des appareils, puis relancez ironflock-update. Pour installer délibérément sans lui, passez --no-tunnel.

Mises à jour

Une fois qu’une appliance est installée derrière un proxy, ses paramètres de proxy sont mémorisés. Les mises à jour manuelles comme les mises à jour automatiques en arrière-plan continuent de fonctionner à travers le proxy sans action supplémentaire — voir Maintenance dans le guide Appliance.

Si l’accès à distance aux interfaces des appareils a été bloqué au moment de l’installation, chaque mise à jour le réessaie automatiquement — ainsi, dès que votre proxy autorise frp, la prochaine mise à jour active la fonction sans aucune étape supplémentaire.