Réseau et pare-feu

Configuration du pare-feu

Si l’appliance fonctionne dans un réseau local restreint, autorisez l’accès sortant vers les points de terminaison IronFlock suivants afin qu’elle puisse atteindre le cloud. Toutes les connexions sont initiées par l’appliance — aucun port entrant n’a besoin d’être ouvert sur votre pare-feu.

instance-registry.ironflock.com:443   # téléchargement et mise à jour du logiciel IronFlock et des agents ; assistant IA et notifications SMS
cbw.ironflock.com:443                 # gestion de l'appliance à distance depuis le cloud
web.ironflock.com:443                 # activation et validation de la licence
registry.ironflock.com:443            # téléchargement des images d'apps lors de la synchronisation depuis l'IronFlock Store public
regauth.ironflock.com:443             # authentification de ces téléchargements d'images depuis le Store public
app.ironflock.com:443                 # ouverture des UI des apps et des appareils depuis le cloud (optionnel)
smtp-proxy.ironflock.com:2525         # envoi des e-mails de compte et de notification (optionnel)

Les entrées registry.ironflock.com et regauth.ironflock.com sont nécessaires pour synchroniser des apps depuis l’IronFlock Store public vers le local App Store. registry.ironflock.com diffuse les images d’apps et regauth.ironflock.com émet le jeton qui autorise chaque téléchargement — les deux doivent être accessibles, sinon la synchronisation (ainsi que la navigation et l’installation d’apps à distance) échoue. Si votre appliance ne sert que des apps que vous construisez localement, vous pouvez les omettre. Une app dont les images proviennent d’un registre public tel que Docker Hub est copiée depuis ce registre lors de la synchronisation : l’appliance doit donc pouvoir l’atteindre, lui aussi.

L’entrée app.ironflock.com achemine le tunnel d’accès distant qui rend les interfaces utilisateur des apps et des appareils accessibles lorsque vous travaillez sur l’instance depuis ironflock.com. Il passe par le port 443 comme tout le reste, directement ou à travers un proxy d’entreprise ; seule une appliance installée avec IRONFLOCK_CLOUD_TUNNEL_TCP=1 utilise le port 7000 à la place. Si l’entrée est bloquée, rien n’échoue bruyamment : ces interfaces ne s’ouvrent tout simplement pas depuis le cloud, alors qu’elles continuent de fonctionner sur le réseau local. Omettez-la si vous n’utilisez l’appliance qu’en local.

L’entrée smtp-proxy.ironflock.com n’est nécessaire que si vous utilisez le relais d’e-mails IronFlock intégré. Si vous configurez votre propre serveur SMTP, vous pouvez l’omettre.

Destinations optionnelles. L’assistant IA actualise les métadonnées des modèles et des widgets depuis raw.githubusercontent.com et cdn.jsdelivr.net, et la recherche d’adresses pour l’emplacement des appareils utilise nominatim.openstreetmap.org. Ces trois destinations sont optionnelles : si elles sont bloquées, l’assistant se rabat sur ses données intégrées et la recherche d’adresses n’est pas disponible.

La synchronisation horaire ne figure pas dans cette liste car elle ne va pas vers IronFlock : l’appliance a néanmoins besoin d’une source de temps fonctionnelle. Autorisez l’UDP 123 sortant vers vos serveurs de temps, ou configurez votre serveur de temps interne sur l’hôte — voir Synchronisation horaire (NTP).

Si votre réseau n’atteint internet qu’à travers un proxy HTTP d’entreprise, voir Derrière un proxy d’entreprise — l’installateur peut faire pointer automatiquement le démon Docker vers votre proxy.

Appareils se connectant à l’appliance

Les appareils edge se connectent à l’appliance, et non au cloud. Si les appareils se trouvent sur un segment de réseau différent de celui de l’appliance, autorisez les réseaux des appareils à atteindre l’hôte de l’appliance sur ces ports :

<APPLIANCE_HOST>:18080   # liaison de l'appareil (WebSocket) — requise
<APPLIANCE_HOST>:15001   # registre du local App Store (téléchargement des images d'apps) — requis
<APPLIANCE_HOST>:15002   # authentification du registre (jetons de téléchargement d'images), mises à jour de l'agent d'appareil et installateur d'appareil — requis
<APPLIANCE_HOST>:7000    # accès distant aux UI des appareils (fonctionnalité de tunnel optionnelle)

Ce sont des connexions directes — elles ne doivent pas être routées à travers un proxy HTTP d’entreprise. Si le réseau d’un appareil force tout le trafic à passer par un proxy, soit exemptez l’hôte de l’appliance du proxy sur l’appareil, soit basculez l’appliance en HTTPS avec votre certificat d’entreprise : dans ce mode, tout le trafic des appareils — la liaison de l’appareil, les téléchargements d’images, les mises à jour de l’agent et le tunnel d’accès distant — bascule vers un port unique et compatible avec les proxys : 443 sur votre domaine, et fonctionne à travers les proxys d’entreprise et les pare-feu stricts sans exceptions par port.

Le port 15002 sert aussi aux mises à jour de l’agent d’appareil et à l’installateur d’appareil : les appareils rattachés à l’appliance téléchargent les mises à jour de l’agent — et les nouveaux appareils l’installateur — depuis l’appliance elle-même, jamais depuis internet ; en mode domaine, depuis https://registry.<APPLIANCE_DOMAIN>/dl sur le port 443. Voir Mises à jour de l’agent d’appareil et Enrôler des appareils sans accès internet.

Les appareils n’ont pas besoin d’accès internet en fonctionnement normal. Tout ce que fait un appareil rattaché — la liaison de l’appareil, les images d’apps, les mises à jour de l’agent, l’accès distant — s’adresse à l’appliance. Un appareil n’accède à internet que lorsqu’il construit une app à partir d’un Dockerfile dont l’image de base se trouve sur un registre public, lorsque vous publiez une app qui utilise des images publiques, lorsque Docker lui-même doit encore être installé et — sur les appareils sous FlockOS — pour vérifier les mises à jour du système d’exploitation sur instance-registry.ironflock.com. Les apps que vous déployez peuvent avoir leurs propres besoins réseau.

Identité réseau des hôtes IronFlock

L’appliance et chaque appareil edge exécutent IronFlock en tant que service système sans surveillance : il démarre avec la machine et reste connecté en permanence, qu’une session utilisateur soit ouverte ou non. Les règles de pare-feu et de proxy de ces hôtes doivent donc être liées à la machine — jamais à la personne qui s’y trouve connectée à ce moment-là. Pour les appareils edge, cela vaut quelle que soit la plateforme à laquelle ils se connectent ; le guide des appareils traite ce point dans Pare-feu et proxys sensibles à l’identité.

C’est particulièrement important sur les réseaux dotés d’un pare-feu ou d’un proxy sensible à l’identité (identity-aware), qui accorde l’accès selon l’identité dans l’annuaire plutôt que selon l’adresse. Si la règle qui autorise un hôte IronFlock est liée à un utilisateur, l’hôte perd l’accès dès que la session de cet utilisateur expire. Les connexions déjà ouvertes continuent de fonctionner tandis que chaque nouvelle connexion est abandonnée silencieusement ; l’hôte semble donc en bonne santé jusqu’à ce qu’il doive se reconnecter — c’est alors une installation d’app, une mise à jour de l’agent ou une reconnexion qui échoue, et après son prochain redémarrage l’appareil reste hors ligne.

Aucune exemption de l’application des politiques d’identité n’est nécessaire. Demandez à votre équipe réseau d’identifier chaque hôte par l’identité qu’il possède réellement :

Correspondance avec les produits courants :

• Check Point Identity Awareness : dans l’Access Role, sélectionnez la machine (objet ordinateur ou groupe) au lieu d’utilisateurs. Les identités de machine sont rafraîchies par l’activité de l’ordinateur lui-même sur le domaine ; si elles peuvent expirer sur votre passerelle, utilisez plutôt un objet réseau.
• Palo Alto Networks User-ID : les comptes d’ordinateur ne produisent pas de correspondances IP-utilisateur ; utilisez donc un objet adresse, un tag ou Device-ID.
• Fortinet FSSO et pare-feu similaires basés sur l’annuaire : utilisez un objet adresse pour l’hôte, ou l’adresse dynamique attribuée par votre contrôle d’accès réseau.
• Zscaler, Prisma Access et autres passerelles de sécurité cloud : enregistrez l’adresse de l’appliance comme emplacement serveur ou IoT (une source de confiance), afin que son trafic soit identifié par son emplacement plutôt que par un utilisateur.

Reconnaître la panne. Un appareil qui reste en ligne mais dont chaque nouvelle connexion échoue — téléchargements d’images, connexions au registre, reconnexions — alors que les pings et sa session existante continuent de fonctionner signale une règle d’identité expirée, et non un problème d’appareil. Ne redémarrez pas l’agent tant qu’une nouvelle connexion depuis l’appareil n’aboutit pas à nouveau : la session encore ouverte est la seule qui fonctionne.

Accédez à votre instance depuis ironflock.com

Bien que l’appliance soit une plateforme entièrement locale, vous n’avez pas besoin d’être sur le réseau de l’usine pour l’utiliser. Tant que l’appliance dispose d’une connexion internet et que votre compte appliance est connecté à votre compte ironflock.com (voir Liaison des comptes), vous pouvez basculer vers votre instance directement depuis l’interface cloud IronFlock — sans VPN, sans redirection de port, sans outil supplémentaire.

Cela signifie :

• Une interface unifiée — gérez vos projets cloud et vos instances appliance côte à côte depuis un seul onglet de navigateur.
• Travaillez depuis n’importe où — opérateurs, développeurs et personnel de support peuvent atteindre l’appliance via internet, tandis que toutes les données de production et les workloads restent locaux sur l’appliance.
• Supervision multi-sites simplifiée — si vous exploitez plusieurs appliances dans différentes usines, chacune apparaît dans votre compte ironflock.com et est à un clic de distance.

Quand l’appliance perd l’accès internet, elle continue à fonctionner en local et reste accessible depuis le réseau de l’usine via http://<appliance-host> — seul l’accès distant est en pause jusqu’au retour de la connectivité.