VIGIL MESH

Documentation

Référence : ports et protocoles

Cette page recense, de façon factuelle, les ports réseau et les protocoles employés par VIGIL-MESH. La règle tient en une phrase : un nœud ordinaire n'ouvre aucun port entrant — il n'émet que des connexions sortantes — tandis qu'une vigie, qui doit être joignable pour relayer et coordonner la traversée NAT, ouvre trois ports entrants publics. Le transport est QUIC sur UDP, chiffré par TLS 1.3, avec des clés publiques brutes Ed25519 et un échange de clés hybride post-quantique.

Ports par rôle

Le modèle d'exposition dépend entièrement du rôle. Un nœud n'accepte jamais de connexion entrante : il se connecte vers les vigies et vers le contrôleur, puis établit ses chemins directs par traversée NAT. Une vigie, à l'inverse, est un service public joignable de l'extérieur ; c'est elle qui porte les trois ports entrants.

RôlePorts entrantsSens du trafic
NœudAucunSortant uniquement : le nœud initie ses connexions vers les vigies et le contrôleur ; aucun listener public n'est ouvert.
Vigieudp/443, udp/4433, tcp/443Entrant : la vigie est un service joignable de l'extérieur pour relayer le trafic chiffré et coordonner la traversée NAT.
Port entrant (vigie)Rôle
udp/443Transport QUIC principal des sessions relayées.
udp/4433Coordination de la traversée NAT (miroir d'adresse publique, mise en relation des nœuds).
tcp/443Qualification et joignabilité de la vigie depuis l'extérieur.

Protocoles et cryptographie

Une session entre deux machines est une connexion QUIC de bout en bout : il n'y a pas de tunnel superposé à un autre tunnel. Le tableau ci-dessous récapitule les briques de transport et de chiffrement.

ÉlémentValeurPrécision
TransportQUIC sur UDPLe trafic circule en UDP ; QUIC porte le multiplexage, la fiabilité et la migration de session.
ChiffrementTLS 1.3 uniquementAucune version antérieure de TLS n'est acceptée.
ALPNvigil-e2e/1Identifiant de protocole applicatif négocié au handshake.
Authentification des pairsClés publiques brutes Ed25519 (RPK, RFC 7250)Pas de chaîne de certificats X.509 à gérer : la clé publique brute identifie le pair.
Suites de chiffrementChaCha20-Poly1305 / AES-256-GCMChiffrement authentifié (AEAD).
Échange de clésHybride X25519 + ML-KEM768La clé de session dépend des deux mécanismes à la fois ; elle tient tant que l'un des deux résiste — défense contre « harvest now, decrypt later ».

Pare-feu et ouverture des ports

Côté nœud, aucune règle entrante n'est à créer : il suffit d'autoriser le trafic sortant (ce qui est le comportement par défaut de la plupart des pare-feu). Aucun redirection de port ni configuration NAT particulière n'est nécessaire pour un nœud.

Côté vigie, ouvrez les trois ports entrants publics (udp/443, udp/4433, tcp/443) sur le pare-feu de l'hôte et, le cas échéant, sur la passerelle en amont. Le contrôleur teste ces trois listeners depuis l'extérieur avant toute allocation de trafic : une vigie qui ne serait joignable qu'en sortie ne devient jamais opérationnelle. Le pas-à-pas de déploiement figure sur /docs/vigie-privee.

Lire ensuiteRéférence : CLI et fichiers de configuration

In English

A regular VIGIL-MESH node opens no inbound ports at all — it only makes outbound connections and relies on NAT traversal, so no firewall rule or port forwarding is required.

A vigie (relay) exposes three public inbound ports: udp/443 for QUIC transport, udp/4433 for NAT-traversal coordination, and tcp/443 for reachability qualification.

The transport is QUIC over UDP with TLS 1.3 only, ALPN "vigil-e2e/1", raw Ed25519 public keys (RFC 7250), ChaCha20-Poly1305 / AES-256-GCM, and a hybrid X25519 + ML-KEM768 key exchange.