Ports et chemins réseau

Le responsable de la plateforme définit le placement et les adresses de service, le responsable du réseau approuve les chemins, et les responsables des services décident des points de terminaison publics dont leurs applications ont besoin. Les pare-feu des hôtes restent de votre ressort : Opfield ne les ouvre pas et ne fournit pas de traversée du NAT.

L’objectif par défaut est simple : les utilisateurs joignent Opfield et l’Ingress public en HTTPS ; les nœuds gérés initient des connexions sortantes authentifiées vers Relay ; les bases de données internes et les interfaces de contrôle restent privées. N’ajoutez d’exposition que pour un chemin produit documenté.

Résumé de la connectivité

Chemin	Objectif
Client -> HTTPS d’Opfield	Console, REST, OAuth, MCP, WebSockets, proxy d’inférence
Démon géré -> Relay 9443/tcp	Contrôle sortant authentifié et trafic de tunnel pris en charge
Internet -> nginx 80/tcp	HTTP et ACME HTTP-01 lorsqu’ils sont utilisés
Internet -> nginx 443/tcp	Routes HTTPS publiques et Pages
Opfield/démon -> fournisseurs externes	DNS, OIDC, e-mail, Git, registres, mises à jour, ACME, fournisseurs d’IA
Services internes d’Opfield	PostgreSQL, Redis, gRPC interne, rappels du cœur d’inférence

C’est Relay — et non l’application Opfield — qui est le détenteur public de 9443/tcp. Les workers Relay distants doivent annoncer des points de terminaison de données joignables depuis les hôtes gérés qui leur sont affectés.

Gardez privés PostgreSQL, Redis, le gRPC interne, le cœur d’inférence, les ports du propriétaire des bases de données, les interfaces de contrôle des démons et les réseaux Docker propres aux liaisons.

Sens de la connectivité

Les démons gérés initient des connexions sortantes authentifiées vers Relay. Les opérateurs n’exposent normalement pas les ports de contrôle des démons à Opfield. Les workers Relay distants font exception : leur point de terminaison 9443/tcp annoncé doit être joignable depuis les hôtes gérés qui leur sont affectés.

Les nœuds ingress reçoivent le trafic applicatif public sur les ports 80 et 443 selon les exigences des Routes et d’ACME. Les nœuds Docker et Storage n’ont besoin ni de ports publics de charges de travail ni de ports de propriétaire pour les Secure Links. Un point de terminaison de base de données managée publié est une option explicite et doit être restreint indépendamment.

Planification des pare-feu

Source	Destination	Nécessaire lorsque
Utilisateur/navigateur	HTTPS d’Opfield	Console, REST, OAuth, MCP, WebSockets, Inference
Nœud géré	Relay affecté 9443/tcp	Toujours, pour le contrôle géré et les tunnels pris en charge
Nœud Docker d’une politique Availability en mode bail, et nœud Ingress de ses Routes	chaque relais du pool, 9443/tcp par défaut	Basculement du plan de données : le trafic de bail et les Secure Links des membres utilisent chaque relais
Internet/client	Ingress 80/tcp	Route HTTP ou ACME HTTP-01
Internet/client	Ingress 443/tcp	Routes HTTPS et Pages
Opfield/nœud	Points de terminaison DNS et de mise à jour	Résolution de noms et téléchargement des mises à jour signées
Opfield/Build Worker	Fournisseurs Git et registres	Découverte des sources, entrée de build, envoi/récupération
Opfield	Fournisseurs OIDC, SMTP, DNS, webhook, SIEM, IA	Intégration activée uniquement
Client applicatif	port TLS publié de la base de données	Uniquement lorsque l’accès direct est délibérément activé
Opfield	Service de licences en HTTPS : license.opfield.dev, ou l’adresse définie dans LICENSE_SERVICE_URL	Enregistrement et signaux de présence ; activation d’une clé payante ; mises à jour d’Opfield d’une installation qui détient ou a détenu un plan payant (les installations Community sans clé se mettent aussi à jour lorsque le service est injoignable).
Opfield	Service de mise à jour get.opfield.dev en HTTPS	Vérification des versions et téléchargements signés
Opfield	Compte cloud account.opfield.dev en HTTPS	Uniquement tant qu’Opfield Cloud est connecté ; une connexion sortante
Client de stockage	port S3 du stockage managé (9000 par défaut)	Uniquement lorsque la publication est délibérément activée
Nœud Storage	ghcr.io, puis Docker Hub en secours	Récupération des images des bases de données et du stockage managés ; l’exécuteur de sauvegardes provient uniquement de ghcr.io
Nœud Docker	ghcr.io, puis Docker Hub en secours	Récupération de l’environnement d’exécution Compose épinglé
Nœud Storage exécuteur de sauvegardes	bases de données externes, points de terminaison de stockage et ghcr.io	Sauvegardes et restaurations des bases de données
Cible de restauration clé-valeur externe	IP de service de l’exécuteur, TCP 20000–39999	Uniquement pendant une restauration vers un stockage clé-valeur externe
Serveur ClickHouse externe	point de terminaison S3 de transit	Sauvegardes et restaurations d’un ClickHouse externe

Utilisez des listes d’autorisation des fournisseurs et une politique de trafic sortant lorsque c’est possible, mais incluez la validation des certificats, les redirections, le DNS et les points de terminaison de paquets et de registres requis par la fonctionnalité choisie. N’utilisez pas de règle large « tout autoriser » pour masquer une dépendance non résolue.

Choix des adresses

Opfield enregistre les adresses locales et publiques signalées ainsi que les adresses de service propres à chaque rôle. Choisissez les adresses selon le chemin réel des pairs : les clients publics vers l’Ingress, les hôtes gérés vers Relay, les opérations Docker entre nœuds vers des adresses de service joignables, et les certificats des bases de données vers les IP de service publiées.

Changer une adresse peut nécessiter des mises à jour DNS, une rotation de certificats, une migration de Routes ou un rééquilibrage de Relay. Vérifiez chaque pair avant de retirer l’ancien chemin.

Vérification

Testez depuis le réseau source réel, et pas seulement depuis l’hôte de destination. Confirmez le DNS, la joignabilité TCP, l’identité TLS, le comportement du protocole HTTP ou gRPC et la santé signalée par Opfield. Une connexion TCP réussie ne prouve à elle seule ni l’authentification ni la disponibilité de l’application.

Procédure de modification et de retour arrière

Avant de modifier une adresse publique, un point de terminaison Relay, une règle de pare-feu, un enregistrement DNS ou une identité de certificat, listez chaque pair qui utilise le chemin et définissez une période de coexistence de l’ancien et du nouveau chemin. N’abaissez le TTL DNS que lorsque le DNS fait partie du changement, et faites-le suffisamment tôt pour qu’il prenne effet. Gardez l’ancienne route disponible jusqu’à ce que la vérification externe et les reconnexions des nœuds gérés prouvent le nouveau chemin.

Revenez en arrière en rétablissant l’adresse, la valeur DNS, le certificat ou l’affectation précédents en un seul changement coordonné. Évitez d’alterner entre les configurations tant que les caches et les connexions de longue durée sont encore actifs. Après le retour arrière, vérifiez les sessions Relay, la fraîcheur des nœuds, les Routes, Pages, les liaisons de bases de données, les webhooks et le trafic sortant vers les sources et fournisseurs utilisés par l’installation.

Diagnostics pour l’opérateur

Utilisez une vérification par couches depuis la source réelle :

1. Le DNS renvoie l’adresse prévue.
2. Le chemin réseau et le pare-feu autorisent le port de destination documenté.
3. TLS présente l’identité attendue et une chaîne de confiance.
4. Le protocole applicatif termine l’authentification ou les vérifications de santé.
5. Opfield reçoit un état récent signalé par le propriétaire.

Consignez la couche qui échoue. Ouvrir davantage de ports ne corrige pas un problème de certificat, d’autorisation, de politique ou de disponibilité applicative.