Documentation
Publier un service : HTTP et TCP
Un mesh VIGIL-MESH garde par défaut ses services entre ses membres : rien n'est joignable depuis l'internet public tant que vous ne l'avez pas décidé. Publier, c'est ouvrir une porte précise vers un seul service — une application web interne, une API, un flux — sans exposer pour autant le reste du réseau. Cette page explique le principe d'une publication, la différence entre une publication HTTP (avec reverse-proxy et certificats automatiques) et une publication TCP, et les cas où l'une ou l'autre convient.
Le principe : sortir un service sans exposer l'infra
À l'intérieur du mesh, vos machines se joignent par des adresses stables et des noms internes, et rien de tout cela n'est visible depuis l'extérieur. Une publication ajoute un point d'entrée public unique qui pointe vers un seul service interne. Le trafic entrant est reçu par la plateforme, puis relayé jusqu'au service à travers le mesh chiffré. Le visiteur ne voit qu'une URL ou un port ; il n'apprend rien de la topologie, des autres machines ou des services restés privés.
Ce découplage est l'intérêt principal : le service publié n'a pas besoin d'être exposé directement sur l'internet, n'ouvre aucun port entrant sur sa propre machine, et reste joignable même s'il vit derrière un NAT domestique ou sur un lien mobile. C'est la plateforme, et elle seule, qui présente une surface publique.
Une porte par service
Chaque publication vise un seul service interne. Ce qui n'est pas explicitement publié reste inaccessible depuis l'extérieur, sans configuration supplémentaire.
Aucun port à ouvrir côté service
La machine qui héberge le service n'expose rien : elle joint le mesh en sortie. C'est la plateforme qui reçoit le trafic public et le relaie.
La topologie reste privée
Adresses internes, noms de machines, services non publiés : rien n'est révélé au visiteur. La publication ne fuit que ce que vous avez choisi de montrer.
Publication HTTP : reverse-proxy et certificats automatiques
La publication HTTP convient aux services qui parlent le web : une application interne, un tableau de bord, une API REST. La plateforme agit en reverse-proxy : elle termine la connexion TLS côté public, puis transporte la requête jusqu'au service interne à travers le mesh. Le service reçoit une requête HTTP ordinaire et n'a rien à savoir du chiffrement public ni du domaine par lequel on l'atteint.
- 1Désigner le service interne à publierLa machine du mesh et le port sur lequel écoute l'application web à exposer. Le service continue de tourner exactement comme avant, sans modification.
- 2Choisir le nom publicLe domaine ou sous-domaine par lequel les visiteurs atteindront le service. Sa gestion (propriété, DNS, activation) est décrite dans la documentation des domaines, à /docs/plateforme-domaines.
- 3Laisser la plateforme obtenir le certificatLe certificat TLS est demandé et renouvelé automatiquement pour le nom public. Vous n'avez pas de fichier à installer ni d'échéance à surveiller.
- 4Le reverse-proxy relaie vers le serviceUne fois le nom actif, le trafic entrant est terminé côté public puis transporté jusqu'au service interne par le mesh chiffré.
Publication TCP
Tous les services ne parlent pas HTTP. Pour une base de données, un service SSH, un protocole métier ou tout ce qui n'est pas du web, la publication TCP expose un port de transport brut. La plateforme accepte les connexions entrantes sur ce port et les relaie vers le service interne, sans interpréter le contenu du flux et donc sans terminer de TLS applicatif.
| Aspect | Publication HTTP | Publication TCP |
|---|---|---|
| Nature du service | Application web, API, tableau de bord | Flux TCP brut : base, SSH, protocole métier |
| Point d'entrée public | Nom de domaine | Port de transport |
| Terminaison TLS par la plateforme | Oui, avec certificat automatique | Non : le flux est relayé tel quel |
| Chiffrement de bout en bout | À la charge de l'application interne | À la charge du protocole publié lui-même |
Réservez la publication TCP aux cas où le web ne s'applique pas. Pour une application web, la voie HTTP offre les certificats automatiques et une surface publique mieux maîtrisée.
Cas d'usage
La publication répond à un besoin récurrent : rendre atteignable, depuis l'extérieur, une ressource qui vit à l'intérieur du mesh, sans déménager cette ressource ni ouvrir son site. Quelques situations typiques :
- Exposer une application interne (outil métier, tableau de bord) à des utilisateurs distants via un nom de domaine, en HTTP avec certificat automatique.
- Ouvrir un accès contrôlé à un flux de caméras hébergé sur un site distant : le détail de ce scénario est traité dans /docs/cas-cameras.
- Donner un point d'entrée TCP à un service non web (base, protocole métier) hébergé derrière un NAT, sans ouvrir de port sur la machine hôte.
- Publier une API consommée par des partenaires externes, tout en gardant le reste de l'infrastructure invisible.
Publier ouvre-t-il l'accès au reste du réseau ?
Dois-je ouvrir un port sur la machine qui héberge le service ?
Quand choisir TCP plutôt que HTTP ?
In English
By default a VIGIL-MESH mesh keeps its services private among its members. Publishing opens a single, precise entry point to one internal service — over HTTP with a reverse-proxy and automatic certificates, or as a raw TCP port — while the rest of the infrastructure stays invisible.
The hosting machine opens no inbound port: the platform receives public traffic and relays it through the encrypted mesh. Prefer HTTP whenever the service is web-based; use TCP only for non-web protocols, keeping in mind the platform then relays the stream without terminating TLS itself.