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 le fichier de configuration central de l’appliance, /opt/ironflock/.env, et la plateforme l’utilise automatiquement — ce fichier reste la source faisant autorité à chaque mise à jour ultérieure (voir Modifier ou supprimer le proxy ultérieurement). 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:[email protected]:3128 — voir Authentification auprès du proxy pour savoir quel compte utiliser.

Drapeaux de proxy de l’installateur :

Drapeau	Rôle
`--http-proxy <url>`	Proxy pour le trafic HTTP en clair depuis le démon Docker.
`--https-proxy <url>`	Proxy pour le trafic HTTPS (celui qui importe pour la récupération des images).
`--no-proxy <list>`	Hôtes supplémentaires séparés par des virgules qui doivent contourner le proxy.

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. Les variables d’environnement du shell ne servent qu’à amorcer la première installation : une fois l’appliance installée, c’est sa configuration enregistrée qui prévaut (voir Modifier ou supprimer le proxy ultérieurement).

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.

Authentification auprès du proxy

Si votre proxy exige une authentification, attribuez à l’appliance son propre compte de service plutôt que le compte d’une personne. Son trafic apparaît alors dans les journaux du proxy sous un nom que votre équipe réseau maîtrise : elle peut restreindre les destinations autorisées pour ce compte, le désactiver ou en changer le mot de passe sans toucher aux identifiants personnels de qui que ce soit. C’est le pendant côté proxy de la section Identité réseau des hôtes IronFlock.

Pris en charge : l’authentification Basic. Indiquez le compte dans l’URL du proxy — http://user:[email protected]:3128 — dans la commande d’installation, ou dans /opt/ironflock/.env suivi de sudo ironflock-update. Encodez en URL les caractères spéciaux du mot de passe (par exemple @ → %40).
Pas encore pris en charge : l’authentification intégrée Windows (Kerberos, NTLM). Si votre proxy n’accepte rien d’autre, demandez à votre équipe réseau d’autoriser le compte de service avec l’authentification Basic, ou d’admettre l’adresse de l’appliance sans authentification en tant qu’hôte nommé.

Ce qu’il faut indiquer à votre équipe réseau au sujet de ce trafic :

Il se limite aux points de terminaison de la liste Configuration du pare-feu, en HTTPS sur le port 443. Le relais d’e-mails sur le port 2525 n’utilise jamais le proxy.
L’uplink de gestion à distance vers cbw.ironflock.com est une connexion WebSocket de longue durée, avec un trafic keep-alive toutes les quelques secondes. Si le proxy coupe les connexions de longue durée au bout d’un délai fixe, l’appliance se reconnecte d’elle-même en quelques secondes, mais les utilisateurs distants peuvent remarquer une brève interruption à chaque fois — dans la mesure du possible, exemptez cette connexion des limites de durée de vie des connexions.

Modifier ou supprimer le proxy ultérieurement

Le proxy est enregistré dans le fichier de configuration central de l’appliance, /opt/ironflock/.env. Ce fichier est la source faisant autorité : ce qu’il contient est ce que chaque mise à jour applique. Reconfigurer le proxy sur une appliance installée se fait donc en deux étapes :

Modifiez les entrées HTTP_PROXY, HTTPS_PROXY et NO_PROXY dans /opt/ironflock/.env.
Exécutez sudo ironflock-update.

La mise à jour réapplique les paramètres partout en une seule passe — le démon Docker, les services de la plateforme, l’agent de l’appareil et le tunnel d’accès à distance — en ne redémarrant que ce qui a réellement changé.

Vous pouvez aussi passer les nouvelles valeurs sous forme de drapeaux — ils priment sur le fichier et y sont réenregistrés :


sudo ironflock-update --https-proxy "http://user:[email protected]:3128"

Chaque paramètre est indépendant : passer uniquement --https-proxy laisse votre liste NO_PROXY existante intacte (le schéma HTTP manquant est automatiquement repris en miroir).

Pour supprimer le proxy — par exemple après avoir déplacé l’appliance vers un réseau avec accès internet direct — videz les entrées dans /opt/ironflock/.env (HTTP_PROXY=, HTTPS_PROXY=), ou passez des drapeaux explicitement vides, puis mettez à jour :


sudo ironflock-update --http-proxy "" --https-proxy ""

La configuration du proxy est de nouveau retirée du démon Docker et de l’agent de l’appareil, et l’appliance revient à des connexions directes. Votre liste NO_PROXY est conservée en vue d’une réactivation ultérieure.

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 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"

Quels hôtes contournent le proxy

NO_PROXY s’applique au nom d’hôte composé par le client, jamais à l’adresse vers laquelle ce nom est résolu. Une appliance que l’appareil atteint par son nom — toute appliance en mode domaine, voir Interfaces d’applications et HTTPS — doit donc être nommée explicitement, faute de quoi l’agent envoie sa connexion vers l’appliance locale à travers le proxy d’entreprise. La plupart des proxies refusant de router vers le réseau interne, l’appareil ne se connecte jamais.

L’installateur le déduit du .flock de l’appareil lui-même. À côté de localhost et 127.0.0.1, il ajoute le domaine de l’appliance — dans sa forme simple et dans celle avec point initial — ainsi que tout hôte de registre joint sans TLS. Les appareils cloud ne reçoivent rien au-delà des deux entrées de loopback, car leurs points de terminaison sont publics et ont bel et bien besoin du proxy.

Tout le reste dont votre site a besoin passe par -no-proxy, l’équivalent de l’option du même nom d’ironflock-init :


reagent.exe service install -config path\to\config.flock `
  -proxy "http://proxy.example.com:3128" `
  -no-proxy "buildserver.corp.example,10.0.0.0/8"

Modifier les réglages par la suite

Le résultat est écrit dans %ProgramData%\IronFlock\Reagent\proxy.env, et ce fichier fait autorité à partir de là :


HTTP_PROXY=http://proxy.example.com:3128
HTTPS_PROXY=http://proxy.example.com:3128
NO_PROXY=localhost,127.0.0.1,appliance.corp.example,.appliance.corp.example

Modifiez-le puis relancez reagent.exe service install pour appliquer le changement. Une installation ultérieure n’écrase jamais le fichier, et service uninstall conserve le répertoire de l’agent : vos réglages survivent donc au cycle désinstallation/installation qu’impose une réinstallation du service. Utilisez -force-proxy pour remplacer délibérément le fichier à partir des options.

Supprimez une entrée si ce site atteint l’appliance via le proxy. Les deux cas existent réellement : une appliance sur le même réseau local d’usine est jointe directement, tandis qu’une appliance hébergée de façon centralisée peut n’être accessible que par le proxy d’entreprise. L’installateur ne peut pas les distinguer, il écrit donc les hôtes littéralement — retirez ceux qui ne s’appliquent pas à votre réseau.

Docker se configure séparément

Docker Desktop ne lit ni proxy.env ni l’environnement du service. Les images sont téléchargées par le démon Docker, qui dispose de ses propres réglages sous Settings → Resources → Proxies, y compris sa propre liste d’exclusions — laquelle a elle aussi besoin de l’hôte de l’appliance. Un proxy corrigé côté agent ne répare pas docker pull.

Appareils Linux

ironflock-init accepte --no-proxy directement ; l’appliance peut donc être nommée dès l’installation :


sudo ./ironflock-init -c mydevice.flock \
  --http-proxy "$PROXY" --https-proxy "$PROXY" \
  --no-proxy "appliance.corp.example.com"

Cela crée un drop-in systemd dans /etc/systemd/system/reagent.service.d/http-proxy.conf. N’éditez pas ce fichier pour ajuster les réglages par la suite — l’outil d’installation le réécrit. Utilisez plutôt systemctl edit reagent, qui crée un override.conf que systemd applique après le drop-in de l’installateur et auquel IronFlock ne touche jamais :


sudo systemctl edit reagent


[Service]
Environment="NO_PROXY=localhost,127.0.0.1,appliance.corp.example.com"


sudo systemctl restart reagent

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.

Il s’agit ici de la confiance de l’appliance envers votre CA — et non de servir du HTTPS aux navigateurs. Vous faites en sorte que les connexions sortantes de l’appliance vers le cloud aboutissent à travers un proxy qui intercepte le TLS. Servir les interfaces web des applications aux navigateurs de votre réseau est la direction opposée — voir Interfaces d’applications et HTTPS.

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é deux choses précises :

Une exception d’analyse pour les téléchargements d’images depuis instance-registry.ironflock.com, afin que le verdict générique de logiciel à risque (riskware) ne bloque pas le composant du tunnel. C’est plus ciblé que d’exclure tout le trafic IronFlock de l’inspection TLS — le reste du trafic de l’appliance peut continuer d’être inspecté.
L’enregistrement de la détection comme faux positif connu. frp est un reverse proxy open source largement utilisé ; IronFlock l’utilise uniquement pour la fonction d’accès à distance décrite ci-dessus, soumise à un contrôle d’accès.

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 dans /opt/ironflock/.env et réappliqués à chaque mise à jour. 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. Pour faire pointer l’appliance vers un autre proxy — ou la retirer complètement du proxy — voir Modifier ou supprimer le proxy ultérieurement.

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.