BYOIP chez Exoscale : utiliser vos propres adresses IP chez Exoscale

Exoscale ne publie rien sur l'apport de vos propres adresses IP. Le 15 octobre 2026, nous avons lu sa documentation, sa FAQ et sa page de tarifs, et aucune ne mentionne d'adresses appartenant au client. La documentation ne décrit que celles d'Exoscale. Chaque instance est provisionnée avec « a native IPv4 address, leased from a global pool and intrinsically tied to the Compute instance » (traduction : « une adresse IPv4 native, louée depuis un pool mondial et intrinsèquement liée à l'instance Compute »). Les Elastic IPs ajoutent des adresses statiques qu'Exoscale crée pour votre organisation, cinq par défaut, attachées à des instances dans une zone.

Private Connect, la liaison dédiée d'Exoscale vers vos réseaux privés, ne permet pas de contourner cela. Sa FAQ demande si Exoscale peut annoncer votre plage IP à vos routeurs en BGP, et répond : « No, Private Connect is a pure Layer 2 connection to your router. No routing is done inside of Exoscale. » (traduction : « Non, Private Connect est une pure connexion de couche 2 vers votre routeur. Aucun routage n'est fait au sein d'Exoscale. »)

La voie du tunnel

Un réseau capable d'annoncer le bloc l'annonce, et un tunnel GRE ou WireGuard achemine son trafic jusqu'à votre instance Exoscale et retour (comment fonctionne le tunnel). L'instance garde l'adresse IPv4 native qu'Exoscale lui a donnée, et cette adresse est l'extrémité extérieure du tunnel. Le bloc loué arrive à l'intérieur du tunnel. Vous configurez ses adresses sur l'interface du tunnel ou sur la loopback, et l'instance y répond comme si elles étaient locales. Le réseau d'Exoscale ne voit que du trafic entre deux adresses publiques.

• Utilisez l'adresse native pour le tunnel. Exoscale indique que les Elastic IPs ne fonctionnent nativement que pour le trafic entrant, et que le trafic sortant utilise toujours l'adresse native de l'instance comme source. Une Elastic IP manuelle contourne en partie cette limite : la page d'Exoscale sur l'utilisation d'une Elastic IP comme source du trafic y lie une application. Pour un tunnel, l'adresse native reste l'extrémité la plus simple : faites pointer l'autre extrémité vers l'adresse IPv4 native, pas vers une Elastic IP.
• Les réponses repartent par le tunnel. Ajoutez une route de politique pour que le trafic du bloc sorte par le tunnel. Envoyé directement, il porterait une adresse source qu'Exoscale n'a jamais attribuée à l'instance, et les réseaux filtrent ce trafic.
• Ouvrez le security group. Exoscale refuse tout le trafic entrant par défaut. Ajoutez une règle d'entrée depuis l'adresse de l'autre extrémité pour GRE, que les security groups proposent comme protocole aux côtés de TCP, UDP et ICMP, ou pour le port UDP de WireGuard. Le trafic sortant reste ouvert jusqu'à ce que vous créiez la première règle de sortie. Ensuite, autorisez aussi le tunnel en sortie.
• Réglez la MTU. 1 476 octets pour GRE, environ 1 420 pour WireGuard, avec du MSS clamping si l'instance route le bloc vers des conteneurs ou des machines virtuelles.
• Toute taille. Un tunnel livre moins de 256 adresses, jusqu'à une seule, ce que le BYOIP ne permet jamais.

La place de RTM Networks

Nous louons des /24 et plus grands depuis notre propre espace d'adresses RIPE NCC, et vendons des blocs dans les régions du RIPE NCC, de l'ARIN et de l'APNIC. Chaque location inclut le ROA, l'objet route, les enregistrements PTR et une lettre d'autorisation chaque fois que vous en avez besoin (louer de l'IPv4). Si Exoscale accepte d'annoncer un bloc, nous créons le ROA pour l'ASN qu'il indique et signons la lettre d'autorisation. D'ici là, nous annonçons nous-mêmes le bloc et le livrons à votre instance par GRE ou WireGuard, dans toute taille jusqu'à une seule adresse (tunnels GRE et WireGuard). Indiquez-nous la zone et le nombre d'adresses dont vous avez besoin. Autres fournisseurs : guides BYOIP.