Héberger un serveur sur Starlink sans adresse IPv4 publique ?

Une adresse privée dans le réseau de Starlink précède la première adresse publique

Ce tracé a été lancé en octobre 2026 depuis un ordinateur du réseau domestique. C’était le second de deux passages faits le même jour, et le deuxième saut est resté muet dans les deux.

tracepath -n -m 8 1.1.1.1

La sortie, retapée avec une étiquette en anglais à la place de chaque adresse :

 1?: [LOCALHOST]                                    pmtu 1500
 1:  home router                                    1.998ms
 1:  home router                                    1.792ms
 2:  no reply
 3:  private address (RFC 1918), Starlink's side   34.218ms
 4:  public address, SpaceX (AS14593)              35.767ms (router returned corrupted payload) asymm 7
 5:  public address, SpaceX (AS14593)              36.125ms
 6:  public address, owner not checked             35.623ms asymm 7
 7:  public address, Cloudflare                    44.837ms
 8:  public address, Cloudflare                    36.379ms asymm 9
     Too many hops: pmtu 1500

Dans cette sortie, « home router » désigne le routeur de la maison, « no reply » une absence de réponse, « private address » et « public address » une adresse privée et une adresse publique, et « owner not checked » un propriétaire qui n’a pas été vérifié.

Le saut 1 est le routeur de la maison. Le saut 2 n’a rien renvoyé. Le saut 3 est une adresse privée dans le réseau de Starlink, et la première adresse publique est le saut 4, dans le réseau de SpaceX.

La RFC 1918 réserve des blocs d’adresses privées à l’usage interne d’un réseau. Ces adresses « have no global meaning » (n’ont pas de signification globale), et les routes qui y mènent ne doivent pas passer d’un réseau à un autre (section 3, consultée en octobre 2026). Le saut 3 n’a de sens qu’à l’intérieur du réseau de Starlink. Un saut privé avant le premier saut public, c’est ainsi qu’un NAT au niveau de l’opérateur (CGNAT) apparaît depuis l’intérieur de la maison.

La RFC 6598 réserve 100.64.0.0/10 comme « Shared Address Space » (espace d’adresses partagé) pour le NAT au niveau de l’opérateur, et prévoit que les opérateurs numérotent à partir de ce bloc les liens entre leurs équipements de CGNAT et les équipements installés chez leurs clients (résumé et sections 1 et 7, consultée en octobre 2026). Si le routeur de la maison est l’équipement placé sur ce lien, une adresse de ce bloc apparaîtrait au saut qui le suit immédiatement. C’est le saut 2, celui qui n’a pas répondu.

Avec le CGNAT, ouvrir un port sur votre routeur, par une redirection de port (port forwarding), ne suffit pas pour recevoir les connexions envoyées à l’adresse IPv4 publique. La RFC 6888 décrit un NAT au niveau de l’opérateur comme une fonction du réseau de l’opérateur qui partage une adresse IPv4 entre plusieurs abonnés. D’après sa section 2 (consultée en octobre 2026), les abonnés ont sur lui « limited or no control » (peu ou pas de contrôle), alors que sur un NAT installé chez eux, ils « typically have full control » (en ont en général le contrôle total). Une redirection de port est un réglage de ce second type de NAT.

Depuis un VPS, aucun des 8 ports n’a répondu sur l’adresse IPv4 publique

J’ai suivi ce test en octobre 2026 ; il a été lancé depuis un VPS, un serveur dans le cloud plutôt que mon propre matériel. Un script y a tenté une connexion TCP vers chacun des 8 ports de l’adresse IPv4 publique de la connexion de la maison, dont 22, 80 et 443, en laissant 6 secondes à chacun pour répondre. Aucune redirection de port n’était configurée pour ce test. Avant les ports de la maison, le script s’est vérifié sur des cibles dont la réponse était connue.

L’exécution a duré 56 secondes. Le port vide et les 8 ports de la maison, neuf sondes en tout, ont chacun attendu les 6 secondes entières : 54 des 56. Chaque « pas de réponse » correspond à une vraie attente, pas à un échec rapide de l’outil.

Le port 25 a expiré, le 587 s’est connecté

En octobre 2026, un ordinateur du réseau domestique a tenté des connexions TCP en IPv4 vers portquiz.net, un serveur public conçu pour tester des ports. Sa page d’accueil, consultée en octobre 2026, indique qu’il « listens on all TCP ports, allowing you to test any outbound TCP port » (écoute sur tous les ports TCP, ce qui permet de tester n’importe quel port TCP sortant). Chaque connexion avait un délai d’attente de 10 secondes. Le balayage a utilisé /dev/tcp de bash, et 25 et 445 ont été retentés avec socket.create_connection de Python et timeout=10.

Les deux ports de soumission de courrier, 465 et 587, se sont connectés. Les ports 25 et 445, non.

Pas encore testé

• Pourquoi le saut 2 ne répond pas. Un tracé dans lequel il répondrait montrerait ce qui se trouve juste après le routeur de la maison, et une adresse de 100.64.0.0/10 à cet endroit correspond à l’usage pour lequel la RFC 6598 réserve ce bloc.
• Où 25 et 445 sont bloqués. Il faudrait refaire le même test depuis un autre réseau.
• L’IPv6 entrant. Rien sur cette page ne montre si une connexion en IPv6 peut atteindre un serveur à la maison.

La page d’aide de Starlink What IP address does Starlink provide? décrit en termes généraux sa politique IPv4 par défaut : la configuration IPv4 par défaut « uses Carrier-Grade Network Address Translation (CGNAT) using private address space from the 100.64.0.0/10 prefix » (utilise le CGNAT avec un espace d’adresses privées du préfixe 100.64.0.0/10), et cette politique « does not allow inbound traffic » (n’autorise pas le trafic entrant). La même page indique que les clients qui ont besoin de trafic entrant « should consider using a third-party router, and if IPv4 inbound traffic is needed, a Starlink service plan with the public IPv4 option » (devraient envisager un routeur tiers et, s’ils ont besoin de trafic IPv4 entrant, un forfait Starlink avec l’option d’adresse IPv4 publique), et c’est une option des forfaits Priority (page consultée en octobre 2026). C’est ce que Starlink dit de son service, pas un résultat du tracé de cette page, et cette page ne teste aucune de ces deux voies. Ce qu’implique chacune de ces voies figure sur la page sur ce que l’on perd en quittant un fournisseur d’accès filaire.

Pour contourner l’absence d’adresse IPv4 publique, une solution consiste à établir une connexion qui part de l’intérieur de votre réseau. La documentation de Cloudflare sur Cloudflare Tunnel indique que son connecteur, cloudflared, n’ouvre que des connexions sortantes vers le réseau de Cloudflare, ce qui permet à un serveur de servir du trafic via Cloudflare sans adresse IP routable publiquement (page mise à jour pour la dernière fois en août 2026, consultée en octobre 2026). Cette page ne le teste pas.

Voir ce que ces résultats signifient si vous choisissez une connexion pour un homelab.