Réseau Train at Home : ports, P2P (iroh), pare-feu et VPN

Le réseau de Train at Home est conçu pour rester invisible : vous ne configurez aucun port, et vous ne devriez pas essayer. Ce guide détaille ce à quoi l'application se connecte réellement, en clair, pour qui veut comprendre le trafic observé plutôt que simplement lui faire confiance. Si vous n'avez pas encore lu le guide de configuration optimale, il couvre déjà l'essentiel en résumé ; voici la version approfondie.

En résumé

Train at Home communique sur le réseau de trois façons distinctes, et aucune ne nécessite d'ouvrir, de rediriger ou de configurer quoi que ce soit :

1. Une connexion de contrôle locale entre l'application officielle et son processus de calcul — en boucle locale uniquement, jamais accessible depuis l'extérieur de votre Mac.
2. Du HTTPS sortant vers une poignée d'hôtes fixes — l'API de l'orchestrateur, Cloudflare R2, et Hugging Face.
3. Des transferts pair-à-pair sur un port UDP éphémère, via un transport pensé précisément pour éviter la redirection de port.

Les ports locaux

Port	Ce que c'est	Faut-il y toucher ?
127.0.0.1:8010	Le WebSocket de contrôle entre l'application Electron officielle et son processus de calcul (main_pool). Ce dernier fait office de serveur WebSocket ; l'application est le client.	Non. Il est en boucle locale uniquement, et l'application possède déjà la seule connexion dont elle a besoin.
*:8009	Observé en écoute sur toutes les interfaces, pas seulement en boucle locale, lors de la recherche menée pour ce projet.	Rien à faire ici — voir l'avertissement ci-dessous.

Ne vous connectez jamais vous-même à 127.0.0.1:8010, et ne l'exposez jamais au-delà de votre propre Mac. Ce n'est pas une API publique — c'est un canal de contrôle privé entre deux processus qui tournent déjà sur la même machine, et son jeton d'accès change à chaque redémarrage de l'application.

Le trafic sortant : ce qui est normal

Le processus de calcul de Train at Home effectue des requêtes HTTPS (443) sortantes vers :

• L'API de l'orchestrateur (iota.api.macrocosmos.ai) — inscription, heartbeats, configuration de run, activations, partitions, chemins de poids et télémétrie de flotte passent tous par cet unique hôte.
• Cloudflare R2 — les poids du modèle sont récupérés via des URL présignées r2.cloudflarestorage.com fournies par l'orchestrateur. C'est du stockage objet classique en HTTPS, pas un protocole propriétaire.
• Hugging Face — les ressources de tokenizer et de modèle (une dépendance attendue, mais que la recherche menée pour ce projet n'a pas capturée indépendamment comme trafic réel dans sa propre fenêtre d'observation).

Rien de tout cela n'exige de port entrant ouvert, de redirection de port, ni d'exception de pare-feu au-delà du HTTPS sortant standard, déjà autorisé par la quasi-totalité des réseaux domestiques.

Le transport P2P : iroh sur un port UDP éphémère

La couche pair-à-pair de Train at Home repose sur iroh↗, un transport basé sur QUIC — pas un protocole P2P générique ou maison. Le journal du mineur le confirme directement : son relevé périodique du « registre des nœuds » utilise les champs iroh_direct_addresses, iroh_relay_url et p2p_node_ids, qui sont le vocabulaire propre à iroh.

Cela a une conséquence concrète : la conception d'iroh, hole-punching plus relais de secours, vise justement à éviter le besoin d'une redirection de port manuelle, grâce au hole-punching au niveau QUIC, avec un relais de secours quand une connexion directe échoue. Il n'existe donc pas, en premier lieu, de port P2P fixe à rediriger — le processus de calcul se lie à un port UDP éphémère qui peut changer (et change effectivement) d'une exécution à l'autre, et aucune variable d'environnement ni option de ligne de commande pour un port fixe n'existe dans la configuration de lancement de l'application.

Vérifier votre propre accessibilité : trois contrôles sûrs

Il n'est ni nécessaire ni souhaitable de sonder vous-même les ports du mineur. Trois contrôles en lecture seule suffisent à comprendre ce qui se passe :

1. lsof -nP -i — liste tous les sockets réellement détenus par l'application et son processus de calcul : ce qui écoute, et à quoi c'est connecté. Un processus de calcul sans aucun socket établi est un signal local fort que quelque chose ne va pas.
2. Chercher No routable peers dans le journal CLI — la ligne d'avertissement exacte ressemble à No routable peers for layer-<N> (activation <uuid>): 0 node(s) matched. Elle signifie que l'application n'a pas trouvé de pair P2P pour un transfert donné à ce moment-là.
3. Chercher Registered with P2P node ID dans le même journal — sa présence (ou son absence répétée sur les dernières exécutions) indique si cette installation a déjà établi une identité P2P.

tail -f ~/Library/Logs/IOTA\ Train\ at\ Home/*-cli.log | grep --line-buffered -E "No routable peers|Registered with P2P node ID"

Pare-feu, routeurs et VPN

Pour une configuration domestique classique, il n'y a rien à configurer sur votre pare-feu ou votre routeur : aucun port entrant à ouvrir, et le hole-punching d'iroh avec son relais de secours est conçu pour gérer le NAT sans votre intervention. Si votre routeur ou votre logiciel de sécurité bloque largement l'UDP sortant (rare sur une connexion domestique, plus fréquent sur certains réseaux d'entreprise ou de campus), cela pourrait plausiblement gêner le chemin P2P — mais ce n'est pas quelque chose que la recherche pour ce guide a pu tester directement.

Par précaution générale, envisagez d'éviter les VPN pendant l'entraînement — Macrocosmos n'a rien publié de tel officiellement, mais un VPN s'intercale entre votre Mac et le chemin réseau dont Train at Home dépend, à la fois pour ses appels API sortants et ses tentatives P2P, et c'est une source plausible du même type de bruit de connexion dont il est question dans ce guide : un saut supplémentaire qui peut casser le hole-punching, ajouter de la latence, ou couper une connexion que Train at Home comptait voir rester stable.

Checklist

1. Ne touchez pas à 127.0.0.1:8010 — ne vous y connectez jamais, ne l'exposez jamais.
2. N'essayez pas de rediriger un port pour le P2P ; il n'y en a pas de fixe à rediriger.
3. Vérifiez que le HTTPS sortant (443) n'est pas bloqué par un logiciel de sécurité.
4. Évitez les VPN pendant l'entraînement.
5. En cas d'avertissements répétés « No routable peers », vérifiez d'abord si le mineur progresse encore (heartbeats, changements de phase) avant de penser qu'il est bloqué — voir le guide de dépannage.
6. Utilisez lsof -nP -i si vous voulez confirmer que le processus de calcul détient bien des sockets.
7. Si vos chiffres de speed test semblent étranges pendant que vous enquêtez sur un problème réseau, écartez cette piste séparément — voir le guide sur le speed test.

Pour l'installation et la veille du côté d'une configuration stable, consultez le guide de configuration optimale complet. Si vous ne savez pas où vous en êtes dans la file, ce guide montre quoi lire dans le journal.