Quitter un FAI filaire : Starlink donne-t-il une IP publique ?

Sans adresse IPv4 publique sur votre routeur, y ouvrir un port ne suffit pas

Si votre routeur détient une adresse IPv4 publique, une redirection de port (port forwarding) sur ce routeur envoie les connexions venues d’Internet vers une machine de la maison. Sinon, un appareil situé en amont qui fait de la traduction d’adresses réseau (NAT) détient cette adresse, le vôtre ou celui de votre opérateur, et une redirection de port sur votre routeur n’atteint Internet que si ce NAT redirige lui aussi le port. Quand le NAT en amont est le NAT au niveau de l’opérateur (CGNAT) d’un fournisseur d’accès, la RFC 6269 indique « If a CGN is present, the port must also be opened in the CGN. CGN makes subscribers dependent on their service provider for this functionality. » (Si un CGN est présent, le port doit aussi être ouvert dans le CGN. Le CGN rend les abonnés dépendants de leur fournisseur d’accès pour cette fonction ; section 5.2.1, consultée en octobre 2026.) La RFC 6888 ajoute que les abonnés ont sur un NAT au niveau de l’opérateur « limited or no control » (peu ou pas de contrôle ; section 2, consultée en octobre 2026).

La page 1, le guide pour héberger un serveur sans adresse IPv4 publique, a testé une connexion Starlink à la maison. Son tracé de la route vers l’extérieur correspond au CGNAT sans le prouver, puisque le deuxième saut n’a jamais répondu. Depuis un ordinateur du réseau domestique, les connexions sortantes en IPv4 sur le port 25 ont expiré, et l’endroit où elles ont été bloquées n’apparaît pas. La page 1 a aussi essayé des ports entrants depuis un serveur privé virtuel (VPS), un serveur dans le cloud.

La page d’aide de Starlink elle-même, « What IP address does Starlink provide? » (quelle adresse IP Starlink fournit-il ?), indique « Starlink WiFi routers do not support port forwarding or firewall rules for IPv4 or IPv6. » (Les routeurs WiFi de Starlink ne prennent en charge ni la redirection de port ni les règles de pare-feu, en IPv4 comme en IPv6.) La même page indique « Outbound ports TCP/25 (SMTP) and TCP/445 (SMB) are blocked for all customers per information security best practices. » (Les ports sortants TCP/25 pour SMTP et TCP/445 pour SMB sont bloqués pour tous les clients, conformément aux bonnes pratiques de sécurité de l’information.) Les deux lignes ont été consultées en octobre 2026.

Ce qui dépend d’une adresse IPv4 publique à la maison :

• un serveur auquel d’autres personnes se connectent, comme un serveur de jeu, un site web ou un bureau à distance ;
• une application qui ouvre elle-même des ports sur le routeur ;
• un serveur de messagerie qui reçoit le courrier d’autres serveurs ;
• tout ce qui est lié à une adresse qui ne change pas, comme une liste d’autorisation ou un enregistrement DNS (plus bas).

Une application ouvre des ports en le demandant au routeur installé chez vous, le CPE dans les termes de la RFC 6269. Les routeurs domestiques ouvrent des ports entrants « either manually, or with a protocol such as » (soit à la main, soit avec un protocole comme) UPnP IGD, indique la RFC, et avec un NAT au niveau de l’opérateur sur le chemin, « CPE and CGN will need to cooperate in order for port forwarding functionality to work » (le CPE et le CGN devront coopérer pour que la redirection de port fonctionne ; section 5.2.1). Un protocole prévu pour cela, le Port Control Protocol (PCP), « allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a Network Address Translator (NAT) or simple firewall » (permet à un hôte IPv6 ou IPv4 de contrôler la façon dont les paquets IPv6 ou IPv4 entrants sont traduits et transmis par un NAT ou un simple pare-feu ; RFC 6887, résumé, consultée en octobre 2026). L’exigence REQ-9 de la RFC 6888 dit « A CGN MUST implement a protocol giving subscribers explicit control over NAT mappings. That protocol SHOULD be the Port Control Protocol » (un CGN DOIT mettre en œuvre un protocole qui donne aux abonnés un contrôle explicite sur les correspondances NAT, et ce protocole DEVRAIT être le Port Control Protocol) : une exigence envers quiconque en construit un, qui ne dit rien de ce qu’un opérateur donné fait tourner.

En octobre 2026, la vérification réseau de Tailscale, tailscale netcheck, lancée sur un ordinateur du réseau domestique, n’a listé aucun des services de mappage de ports qu’elle cherche (UPnP, NAT-PMP et PCP). La référence de la CLI de Tailscale indique « If any fields are blank, it means Tailscale wasn't able to measure that network property » (si des champs sont vides, cela signifie que Tailscale n’a pas pu mesurer cette propriété du réseau ; validée pour la dernière fois en juillet 2026, consultée en octobre 2026) ; un champ vide ne montre donc pas qu’un tel service n’existe pas.

Le courrier entre serveurs passe par le port 25. La RFC 6409 indique « Message relay is unaffected, and continues to use SMTP over port 25 » (le relais des messages n’est pas concerné et continue d’utiliser SMTP sur le port 25), alors que les logiciels de messagerie soumettent les messages « normally over port 587 » (normalement sur le port 587 ; résumé, consultée en octobre 2026). Un serveur de messagerie à la maison reçoit le courrier des autres serveurs sur le port 25.

Vérifier si votre routeur a aujourd’hui une adresse IPv4 publique

Ce que le changement vous enlève dépend de ce que votre connexion vous donne aujourd’hui, et votre propre routeur le montre.

1. Désactivez tout réseau privé virtuel (VPN), proxy ou nœud de sortie sur l’appareil que vous utilisez pour cela. Comparez ensuite l’adresse WAN ou Internet affichée sur la page d’état de votre routeur avec l’adresse IPv4 publique qu’un service de consultation indique pour votre connexion. Si elles sont identiques, le routeur détient une adresse IPv4 publique, et une redirection de port sur ce routeur peut recevoir des connexions.
2. Si elles diffèrent, un NAT situé entre votre routeur et Internet détient l’adresse publique, et l’adresse WAN du routeur lui-même indique à qui il appartient. Dans 100.64.0.0/10, le bloc que la RFC 6598 réserve comme espace d’adresses partagé pour le NAT au niveau de l’opérateur, c’est celui de l’opérateur. Dans 10.0.0.0/8, 172.16.0.0/12 ou 192.168.0.0/16, les blocs privés de la RFC 1918, c’est un autre NAT, un routeur à vous ou à l’opérateur. Dans les deux cas, une redirection de port sur votre routeur n’atteint Internet que si ce NAT redirige lui aussi le port, et le seul fait que les adresses diffèrent ne dit pas s’il le fait.

Les deux étapes s’appuient sur les RFC ci-dessus (consultées en octobre 2026) ; cette page n’a fait la comparaison sur aucune connexion.

Qui doit joindre le serveur décide de la solution de remplacement

Sans adresse IPv4 publique sur votre routeur, un serveur à la maison a besoin d’un autre accès. Cette page en décrit cinq d’après les pages de leurs propres fournisseurs et n’en teste aucun.

Accès	Qui peut joindre le serveur
L’option d’adresse IPv4 publique de Starlink	Qui peut joindre le serveurN’importe qui, sur les ports que redirige votre propre routeur
Un relais sur un VPS	Qui peut joindre le serveurN’importe qui, sur les ports que redirige le VPS
Un tunnel sortant (Cloudflare Tunnel)	Qui peut joindre le serveurN’importe qui avec un navigateur, pour un service web ; pour les autres services, seulement les visiteurs qui utilisent le client de Cloudflare
Un VPN maillé (Tailscale ou Headscale)	Qui peut joindre le serveurSeulement les appareils que vous y ajoutez
L’IPv6 entrant, avec votre propre routeur	Qui peut joindre le serveurNon précisé sur la page d’aide de Starlink, qui oriente les clients qui ont besoin de trafic entrant vers un routeur tiers

Ce que change l’option d’adresse IPv4 publique, selon Starlink

La page d’aide « What IP address does Starlink provide? » nomme deux politiques IPv4, « default » (par défaut) et « public » (publique). La politique « default », indique-t-elle, « does not allow inbound traffic » (n’autorise pas le trafic entrant). Quand « IPv4 inbound traffic is needed » (du trafic IPv4 entrant est nécessaire), elle renvoie à « a Starlink service plan with the public IPv4 option » (un forfait Starlink avec l’option d’adresse IPv4 publique ; consultée en octobre 2026).

La page d’aide de Starlink sur le passage à une IP publique indique « The ability to update the IP policy to a Public IP is only available to the Local and Global Priority service plans. » (La possibilité de passer la politique IP à une IP publique n’est proposée que sur les forfaits Local et Global Priority ; consultée en octobre 2026.)

La page d’aide de Starlink sur le parrainage liste huit forfaits éligibles, chacun un forfait Residential ou Roam, et aucun forfait Priority (octobre 2026).

Cette page n’a pas testé l’option d’adresse IPv4 publique.

Un relais sur un VPS, pour un serveur que d’autres personnes joignent

Un relais sur un VPS est un VPS doté de sa propre IP publique qui fait passer les connexions des visiteurs, par un tunnel, jusqu’à un serveur à la maison. Cette page n’en a pas testé. La page sur le serveur de jeu en teste un : un relais TCP sur une VM gratuite dans le cloud, pour un serveur Minecraft à la maison sur Starlink.

La connexion part de la maison : le serveur de la maison garde un tunnel ouvert vers le VPS, par exemple avec WireGuard. Le Quick Start de WireGuard indique qu’un pair derrière un NAT « must keep the NAT/firewall mapping valid, by periodically sending keepalive packets » (doit garder valide la correspondance du NAT ou du pare-feu en envoyant périodiquement des paquets de maintien), que « A sensible interval that works with a wide variety of firewalls is 25 seconds » (un intervalle raisonnable, qui fonctionne avec une grande variété de pare-feu, est de 25 secondes), et que cela permet au pair de « receive incoming connections long after network traffic has gone silent » (recevoir des connexions entrantes longtemps après que le trafic réseau s’est tu ; section « NAT and Firewall Traversal Persistence », consultée en octobre 2026). Sur le VPS, les ports que vous choisissez sont redirigés dans le tunnel, ou un proxy inverse transmet les requêtes web : la directive reverse_proxy de Caddy « Proxies requests to one or more backends » (relaie les requêtes vers un ou plusieurs backends ; consultée en octobre 2026).

Les visiteurs se connectent à l’IP publique du VPS, et votre hébergeur de VPS transporte le trafic. Tout ce que le VPS redirige est ouvert sur Internet ; ne redirigez donc que le port que vous comptez publier.

Un tunnel sortant, pour les services web

Un tunnel sortant relie un serveur à la maison au réseau d’un fournisseur depuis l’intérieur, et les visiteurs joignent le serveur en passant par ce fournisseur. Aucun n’a été testé pour cette page.

La page de Cloudflare sur Cloudflare Tunnel indique qu’il relie des ressources à Cloudflare « without a publicly routable IP address » (sans adresse IP routable publiquement), que son connecteur, cloudflared, « creates outbound-only connections » (crée des connexions uniquement sortantes), et qu’il peut relier « HTTP web servers, SSH servers, remote desktops, and other protocols » (des serveurs web HTTP, des serveurs SSH, des bureaux à distance et d’autres protocoles ; page mise à jour pour la dernière fois en août 2026, consultée en octobre 2026). Sa page sur les protocoles des applications publiées indique qu’une route d’application publiée demande à Cloudflare « to proxy requests for your public hostname to a service running privately behind cloudflared » (de relayer les requêtes adressées à votre nom d’hôte public vers un service qui tourne en privé derrière cloudflared), et que « Non-HTTP services require installing cloudflared on the client for end users to connect » (les services non HTTP exigent d’installer cloudflared sur le client pour que les utilisateurs finaux se connectent) : pour TCP et SSH, les utilisateurs finaux lancent cloudflared access tcp ou cloudflared access ssh (consultée en octobre 2026).

Un visiteur d’un service web n’a donc besoin que d’un navigateur. Pour SSH, un bureau à distance ou un autre service non HTTP, chaque visiteur a besoin du client de Cloudflare. Le réseau de Cloudflare transporte le trafic.

Un VPN maillé, pour vos propres appareils

Un VPN maillé (mesh VPN) relie vos propres appareils entre eux : seuls les appareils que vous y ajoutez peuvent joindre un serveur à la maison, pas les visiteurs. Cette page n’en teste pas non plus.

Tailscale en est un. Headscale se présente comme « an open source, self-hosted implementation of the Tailscale control server » (une implémentation open source et auto-hébergée du serveur de contrôle de Tailscale), limitée à « a single Tailscale network (tailnet), suitable for a personal use » (un seul réseau Tailscale, ou tailnet, adapté à un usage personnel ; consultée en octobre 2026) ; tailnet est le mot de Tailscale pour un tel réseau. La page de Tailscale sur les types de connexion indique « All connections start as relayed through a DERP server » (toutes les connexions commencent relayées par un serveur DERP), les serveurs relais de Tailscale, et « In most environments, Tailscale successfully establishes direct connections, but some network configurations (hard NAT) can prevent this » (dans la plupart des environnements, Tailscale parvient à établir des connexions directes, mais certaines configurations réseau, le hard NAT, peuvent l’empêcher ; validée pour la dernière fois en juin 2026, consultée en octobre 2026). Quand aucun chemin direct ne s’établit, les relais de Tailscale transportent le trafic. Son billet de 2020 « How NAT traversal works » (comment fonctionne la traversée de NAT) indique « you can't reconfigure the ISP's CGNAT » (vous ne pouvez pas reconfigurer le CGNAT du fournisseur d’accès), et « Aside from the port mapping protocols, everything from our current bag of tricks works fine in a CGNAT world » (à part les protocoles de mappage de ports, tout ce que contient notre panoplie actuelle fonctionne bien dans un monde CGNAT ; août 2020, consultée en octobre 2026).

La vérification de Tailscale sur le réseau domestique, en octobre 2026, a aussi trouvé que le NAT placé devant lui gardait la même correspondance quelle que soit la destination (MappingVariesByDestIP: false). La référence de la CLI de Tailscale oppose cela à « a difficult NAT that varies the device's IP address depending on the destination » (un NAT difficile qui fait varier l’adresse IP de l’appareil selon la destination). La vérification montre le NAT au moment où elle a tourné, sans connexion entre deux appareils à observer ; elle ne montre donc pas si un chemin direct s’établirait.

Ce que Starlink dit de l’IPv6

La page d’aide de Starlink « What IP address does Starlink provide? » indique « Starlink supports native IPv6 across all Starlink routers, kit versions, and service plans. » (Starlink prend en charge l’IPv6 natif sur tous les routeurs Starlink, toutes les versions de kit et tous les forfaits.) Elle indique aussi « Each Starlink is allocated one IPv4 address via DHCPv4 and a delegated /56 IPv6 prefix via DHCPv6-PD. » (Chaque Starlink reçoit une adresse IPv4 par DHCPv4 et un préfixe IPv6 /56 délégué par DHCPv6-PD.) Sur le trafic entrant : « Customers needing inbound traffic should consider using a third-party router, and if IPv4 inbound traffic is needed, a Starlink service plan with the public IPv4 option. » (Les clients qui ont besoin de trafic entrant devraient envisager un routeur tiers et, s’ils ont besoin de trafic IPv4 entrant, un forfait Starlink avec l’option d’adresse IPv4 publique.) Sa note sur la redirection de port, citée plus haut, nomme l’IPv6 comme l’IPv4. Et, en termes généraux, elle indique « As Starlink continues to expand and upgrades its global internet service, users may experience changes such as publicly routable addresses and non-CGNAT configurations. » (À mesure que Starlink continue de s’étendre et améliore son service Internet mondial, les utilisateurs peuvent constater des changements, comme des adresses routables publiquement et des configurations sans CGNAT.) Tout cela a été consulté en octobre 2026.

Ce sont des déclarations de Starlink, et cette page n’en teste aucune. Rien ici ne montre si une connexion en IPv6 atteint un serveur à la maison.

Ce que dit la page d’aide de Starlink d’une IP fixe

Sur la page d’aide de Starlink « What IP address does Starlink provide? », le paragraphe sur l’option d’adresse IPv4 publique indique « Although truly static IPs are not available, a reservation system retains the public IPv4 address and IPv6 prefix even when the system is off or rebooted. However, relocating the Starlink or software updates may change these addresses. » (Même si de véritables IP fixes ne sont pas disponibles, un système de réservation conserve l’adresse IPv4 publique et le préfixe IPv6 même quand le système est éteint ou redémarré. Déplacer le Starlink ou des mises à jour logicielles peuvent toutefois changer ces adresses ; consultée en octobre 2026.)

Une adresse qui change casse tout ce qui y est lié : une liste d’autorisation, un enregistrement DNS, un client distant réglé sur une adresse. Avec une solution de remplacement, les visiteurs utilisent quelque chose qui ne change pas avec l’adresse de la maison. Avec un relais sur un VPS, c’est l’IP publique du VPS ; la page d’accueil de WireGuard indique « the server discovers the endpoint of its peers by examining from where correctly authenticated data originates » (le serveur découvre le point de terminaison de ses pairs en examinant d’où proviennent les données correctement authentifiées) et « Thus, there is full IP roaming on both ends » (il y a donc une itinérance IP complète aux deux bouts ; consultée en octobre 2026), ce que cette page n’a pas testé. Avec Cloudflare Tunnel, c’est le nom d’hôte public que Cloudflare achemine vers votre service.

Le DNS dynamique garde un nom pointé vers une adresse qui change. Sans adresse IPv4 publique sur votre routeur, la seule adresse IPv4 publique vers laquelle ce nom peut pointer est celle du NAT en amont, qui ne transmet une connexion que s’il redirige le port (RFC 6269, section 5.2.1, pour un NAT au niveau de l’opérateur).

Ce que dit des serveurs la politique d’utilisation acceptable de Starlink pour les États-Unis

L’Acceptable Use Policy de Starlink pour les États-Unis (sa politique d’utilisation acceptable), dans sa version d’octobre 2026, ne mentionne pas le fait de faire tourner un serveur. Elle ne mentionne pas non plus l’hébergement ni les connexions entrantes.

La politique liste 13 exemples de violations. Le dernier est « any conduct that SpaceX, in its discretion, reasonably determines to be a misuse of the Services or Starlink Kit » (tout comportement que SpaceX, à sa discrétion, juge raisonnablement être une utilisation abusive des services ou du kit Starlink), ce qui laisse cette appréciation à SpaceX. Sous « EXCESSIVE USE OF NETWORK RESOURCES » (utilisation excessive des ressources du réseau), elle indique « SpaceX reserves the right to engage in reasonable network management to protect the overall network » (SpaceX se réserve le droit de mettre en œuvre une gestion raisonnable du réseau pour protéger l’ensemble du réseau).

Garder votre ligne actuelle, ou changer après avoir prévu la suite

Votre vérification dit quel cas est le vôtre.

1. Si l’étape 1 n’a montré aucune adresse IPv4 publique sur votre routeur et que l’étape 2 désigne le NAT de votre opérateur, une redirection de port sur votre routeur n’atteint aujourd’hui Internet que si ce NAT redirige lui aussi le port (RFC 6269, section 5.2.1). Sans une telle redirection de la part de votre opérateur, vous n’avez aujourd’hui aucune redirection de port entrante en IPv4, et changer ne vous l’enlève pas. Si l’étape 2 désigne un routeur à vous en amont, vérifiez d’abord ce routeur.
2. Si seuls vos propres appareils doivent joindre vos services, c’est le cas du VPN maillé. La documentation de Tailscale le décrit, et cette page ne l’a pas testé.
3. Si d’autres personnes doivent joindre un serveur à la maison, prévoyez la solution de remplacement avant de changer : un relais sur un VPS ou un tunnel sortant, d’après leur documentation et sans test ici, ou l’option d’adresse IPv4 publique d’un forfait Priority, d’après les pages d’aide de Starlink.
4. Si vous faites tourner à la maison un serveur de messagerie qui envoie le courrier directement à d’autres serveurs, gardez la ligne sur laquelle il tourne. Le courrier entre serveurs utilise le port 25 (RFC 6409), et la page d’aide de Starlink indique que le TCP/25 sortant est « blocked for all customers » (bloqué pour tous les clients). Dans le test de la page 1, les connexions sortantes en IPv4 sur le port 25 ont expiré depuis un ordinateur du réseau domestique, et l’endroit où elles ont été bloquées n’apparaît pas. Le courrier passant par un relais sur un VPS n’est pas testé ici.

Pas encore testé ici

Les cinq accès : l’option d’adresse IPv4 publique de Starlink, un relais sur un VPS, un tunnel sortant, un VPN maillé et l’IPv6 entrant.

Si un relais continue de fonctionner quand l’adresse de la connexion de la maison change. La page d’accueil de WireGuard indique qu’il suit un pair dont l’adresse change ; rien ici ne le teste.

Le courrier envoyé par un relais.

L’endroit où les connexions sortantes sur le port 25 sont bloquées, que la page 1 laisse ouvert.