Starlink IP : la solution NATCloud

Résumé Quand les clients Starlink se plaignent que « mon IP a encore changé », le problème visible est la rotation, mais le problème profond est le CGNAT. Le réseau par défaut de Starlink place les clients derrière un NAT partagé, donc la disponibilité inbound IPv4 n’existe pas vraiment sauf si vous payez l’option IP publique. Les modèles classiques d’accès distant — redirection de ports, DDNS, listes blanches d’IP — se dégradent ou cessent complètement de fonctionner. NATCloud résout ce problème en remplaçant la dépendance inbound par un tunnel outbound authentifié, restaurant l’accès à la gestion sans avoir besoin d’une IP publique.

Pourquoi Starlink change-t-il constamment mon IP ?

Les clients Starlink voient ce qui ressemble à une rotation rapide d’IP car le service par défaut place les abonnés derrière un CGNAT (Carrier-Grade NAT, espace d’adresses partagé RFC 6598 à 100.64.0.0/10). Sous CGNAT, l’adresse publique visible aux services externes est partagée entre plusieurs abonnés et peut changer lors des réaffectations de pool d’egress sans que le WAN du routeur client soit réellement renuméroté. Ajoutez la capacité dynamique de Starlink, les décisions de résilience et d’expansion, et le résultat est une adresse qui semble dériver sur une échelle de temps bien plus courte qu’un WAN haut débit typique.

La distinction importe car elle change la solution. Si le seul problème était « mon IP est dynamique », DDNS suffirait — garder le nom d’hôte mappé sur l’IP actuelle et c’est fait. Mais sous CGNAT, il n’y a pas du tout d’IPv4 globalement routable sur le WAN du client. DDNS résout le nom d’hôte en ce que le client pense être « son » IP, mais les connexions inbound vers cette adresse échouent ou atterrissent sur une session de quelqu’un d’autre. L’espace d’adresses partagé casse l’hypothèse « un client, une IP publique » que la boîte à outils classique d’accès distant dépend.

Pourquoi cela nuit à l’accès plus que les gens ne l’attendent

L’accès distant traditionnel dépend d’une chaîne fragile : IPv4 public sur le WAN, disponibilité inbound à travers le FAI, une règle de redirection de port sur le routeur du client, un trou de pare-feu vers un appareil spécifique, et souvent un modèle de confiance basé sur les IP du côté de la destination. Cette chaîne a des faiblesses en sécurité même sur un lien haut débit normal. Sur Starlink CGNAT, elle devient opérationnellement instable.

L’accès inbound devient une loterie : parfois l’adresse route vers votre abonné, parfois elle route vers un autre client sur le même pool d’egress, parfois la publication inbound n’a jamais existé du tout. Les journaux, la géolocalisation, les hypothèses d’audit et les listes blanches d’IP se dégradent. C’est particulièrement difficile pour les techniciens gérant les caméras, les routeurs, les DVR, les interfaces web et les appareils de branche qui n’ont jamais été conçus pour les modèles d’accès basés sur l’identité — ils supposaient une IP publique stable qu’ils pouvaient mettre en liste blanche.

Pourquoi NATCloud s’adapte mieux au cas Starlink

NATCloud n’est pas juste une autre façon d’atteindre un appareil sur internet — il inverse le modèle. Au lieu de demander à l’internet public de trouver un appareil par son IPv4 public actuel, NATCloud garde la relation ancrée dans un tunnel outbound authentifié établi du site client vers le cloud. La dépendance pratique se déplace de « quelle est mon IP publique maintenant ? » à « le site a-t-il la connectivité outbound ? » — et la connectivité outbound est presque toujours disponible sur Starlink, même quand la publication inbound ne l’est pas.

L’architecture a un bénéfice de second ordre. Une fois que l’accès ne dépend plus du fait que l’IP WAN reste stable, le reste du modèle opérationnel devient plus propre : la surveillance, les alertes, les rapports de disponibilité, les permissions basées sur les équipes et l’inventaire deviennent partie intégrante du même plan de contrôle au lieu d’être improvisés autour des adresses changeantes, des exceptions pare-feu ad hoc et des listes sur feuille de calcul. Les permissions centralisées, l’inventaire automatique, les rapports et le support des scénarios CGNAT, double NAT et triple NAT sont des fonctionnalités de première classe au lieu de contournements.

Ce que cela signifie pour le reste de l’architecture

Une conception d’accès centrée sur NATCloud remodèle comment trois décisions adjacentes sont prises.

DDNS devient secondaire, pas primaire. DDNS est utile quand une vraie adresse inbound existe et change occasionnellement. Sous CGNAT, DDNS ne peut pas créer la disponibilité inbound par lui-même. Une architecture Starlink + NATCloud est opérationnellement plus forte que Starlink + DDNS pour la plupart des déploiements. DDNS a toujours un rôle pour les sites non-CGNAT dans la même flotte, mais il cesse d’être la réponse par défaut. Pour la ligne de base DDNS-uniquement, consultez notre guide Intelbras DDNS et le guide de gestion MikroTik basé sur VPS.

L’option IPv4 publique devient un choix commercial, pas une correction. Si une charge de travail spécifique a vraiment besoin du IPv4 inbound classique et que Starlink supporte IPv4 public sur ce plan, optez pour celui-ci pour cette charge de travail. Traitez-le comme une exception pour une exigence connue — pas comme l’architecture de base pour chaque appareil. La plupart de ces appareils ont seulement besoin d’un accès à la gestion sécurisé, pas d’une publication sur l’internet public.

IPv6 aide mais n’est pas une baguette magique. Starlink supporte IPv6 avec des mécanismes comme SLAAC et les préfixes délégués. IPv6 peut restaurer la disponibilité bout en bout quand le préfixe est correctement délégué et filtré, mais il demande toujours une politique de pare-feu disciplinée. Pour de nombreuses équipes d’exploitation, NATCloud est plus simple que de retouler chaque flux de travail autour d’une exposition IPv6 directe — particulièrement quand la flotte d’appareils inclut des équipements plus anciens avec un support IPv6 faible ou absent.

Documentation et références

Deux principes fondamentaux techniques sous-tendent le cas Starlink : RFC 1918 définit les plages IPv4 privées pour les réseaux internes, tandis que RFC 6598 réserve 100.64.0.0/10 comme l’espace d’adresses partagé utilisé par CGNAT. RFC 4862 couvre IPv6 SLAAC. Ensemble, ces documents expliquent pourquoi « l’internet fonctionne » n’est pas la même chose que « j’ai une disponibilité inbound publique stable ».

Les matériaux de support propres à Starlink confirment que IPv4 public est une configuration facultative liée à certains plans de service, tandis que le comportement par défaut utilise CGNAT, et que le réseau est dynamique avec des adresses sujettes au changement dans le cadre des décisions de capacité, de résilience et d’expansion. La combinaison de ces deux faits — CGNAT par défaut plus l’adressage dynamique — est ce qui rend les modèles d’accès basés sur les IP inbound peu fiables.

Passer à l’étape suivante

Si votre conception d’accès dépend toujours de « mon IP publique actuelle », Starlink continuera de sembler instable. Le problème profond n’est pas émotionnel, et n’est même pas purement spécifique à Starlink — c’est une question d’architecture. Dans le modèle Starlink par défaut, la stabilité IPv4 publique et la disponibilité inbound ne sont pas des hypothèses sûres. NATCloud résout cela en supprimant la dépendance IP publique du chemin de gestion et en la remplaçant par un tunnel outbound contrôlé qui se comporte beaucoup mieux sous CGNAT et l’adressage dynamique.

La meilleure réponse aux changements d’IP Starlink n’est pas de se battre plus fort pour la même ancienne méthode d’accès. C’est d’arrêter de faire de la stabilité IPv4 publique la pierre angulaire de votre stratégie d’accès.

Commencez votre essai gratuit MKController