Bring Your Own IP sur un VPS avec BGP : guide complet

Cette page est le point central du parcours BYOIP complet. Elle relie chaque étape, de l'obtention d'un ASN à la supervision de vos annonces BGP en production. Chaque section renvoie vers un article dédié où vous trouverez configurations, commandes et étapes de vérification.

Si vous savez déjà ce que sont BGP et BYOIP, passez directement à De quoi avez-vous besoin avant votre première session BGP ?.

Que signifie « Bring Your Own IP » sur un VPS ?

Bring Your Own IP (BYOIP) consiste à annoncer un espace d'adresses IP que vous possédez ou louez auprès d'un registre Internet régional (RIR) via le réseau d'un hébergeur, en utilisant BGP. Au lieu d'utiliser les adresses IP du fournisseur, votre VPS origine les routes pour vos propres préfixes. Le trafic destiné à ces IP atteint votre serveur via les liens upstream et les points d'échange du fournisseur.

Vous gardez le contrôle des adresses. Si vous changez de fournisseur, vos IP vous suivent. Pas de modification DNS, pas de réputation à reconstruire, pas d'interruption visible pour les clients au-delà de la fenêtre de convergence.

Pourquoi apporter ses propres IP ?

Continuité de la réputation IP. La délivrabilité des emails, la réputation DNS et les listes blanches des pare-feu suivent l'adresse, pas le serveur. Changer de fournisseur avec des IP attribuées par ce dernier signifie reconstruire la réputation depuis zéro.

Portabilité entre fournisseurs. Vos préfixes ne sont liés à aucun hébergeur. Vous pouvez basculer vers un autre fournisseur, ou fonctionner en multi-homing sur deux, sans changer les adresses auxquelles vos clients se connectent.

Multi-homing et redondance. Annoncez le même préfixe depuis plusieurs emplacements. BGP gère le basculement automatiquement. Votre service reste joignable même lorsqu'un site tombe.

Conformité et audit. Certains environnements réglementés exigent une documentation sur la propriété des adresses IP. Détenir votre allocation via un RIR vous fournit cette traçabilité.

Anycast. Annoncez le même préfixe depuis des nœuds géographiquement distribués. Les utilisateurs sont routés vers le plus proche. C'est ainsi que fonctionnent les serveurs racine DNS et les points de présence CDN.

Comment BGP s'inscrit-il dans le BYOIP ?

BGP (Border Gateway Protocol) est le protocole que les routeurs utilisent pour échanger des informations d'accessibilité entre systèmes autonomes sur Internet. Lorsque vous apportez votre propre IP sur un VPS, vous exécutez un démon BGP sur votre serveur. Ce démon établit une session avec le routeur de votre fournisseur et annonce vos préfixes. Le fournisseur propage ces annonces à ses upstreams et ses pairs. En quelques minutes, les routeurs à travers Internet apprennent que votre espace IP est joignable via le réseau de votre fournisseur.

C'est le même protocole que chaque FAI, fournisseur cloud et réseau de contenu utilise. La différence est l'échelle : vous annoncez un ou deux préfixes au lieu de milliers.

Vous n'avez pas besoin de comprendre chaque attribut BGP pour démarrer. Vous devez savoir comment configurer une session, annoncer un préfixe et filtrer ce que vous acceptez. Les articles détaillés de ce cocoon couvrent chacun de ces points.

De quoi avez-vous besoin avant votre première session BGP ?

Six briques de base, dans l'ordre des dépendances :

Un numéro de système autonome (ASN). Votre identité sur l'Internet BGP. Vous l'obtenez auprès d'un RIR (RIPE NCC en Europe, ARIN en Amérique du Nord, APNIC en Asie-Pacifique) via un LIR parrain. Le traitement prend 2 à 5 jours ouvrés au RIPE NCC.
Une allocation IP. Au minimum un /24 pour IPv4 ou un /48 pour IPv6. Les préfixes plus petits sont filtrés par la plupart des réseaux et ne se propageront pas. Vous pouvez détenir de l'espace IPv4 via un RIR (de plus en plus rare et cher) ou en louer auprès d'un broker. Les allocations IPv6 sont facilement disponibles auprès de tous les RIR.
Des objets route IRR. Des entrées dans l'Internet Routing Registry qui documentent quel ASN est autorisé à originer votre préfixe. De nombreux fournisseurs de transit construisent leurs filtres BGP à partir des données IRR. Sans objet route correspondant, votre annonce peut être silencieusement rejetée. Créez-les dans la base de données RIPE (ou l'équivalent de votre RIR) avant votre première session.
Des ROA RPKI (Route Origin Authorizations). Des objets cryptographiques qui lient votre préfixe à votre ASN. Plus de 51 % des routes IPv4 et 57 % des routes IPv6 possèdent désormais des ROA valides. Les réseaux effectuant la validation d'origine de route (ROV) rejetteront les annonces qui échouent aux vérifications RPKI. Créez les ROA dans le portail de votre RIR.
Un démon de routage. Un logiciel sur votre VPS qui parle BGP. Les trois principales options sont BIRD2, FRRouting (FRR) et VyOS. Voir la comparaison ci-dessous.
Un fournisseur avec support de session BGP. Tous les fournisseurs de VPS ne proposent pas cela. Vous avez besoin d'un fournisseur qui configurera une session BGP entre son routeur et votre VPS, acceptera vos annonces de préfixe et les propagera en amont.

Liste de contrôle pré-vol

Avant de demander une session BGP à votre fournisseur, assurez-vous d'avoir :

Élément	Où l'obtenir	Délai estimé
ASN	RIR via LIR parrain	2-5 jours ouvrés
IPv4 /24 ou plus grand	Allocation RIR ou location	Jours à semaines
IPv6 /48 ou plus grand	Allocation RIR	1-2 jours ouvrés
Objets route/route6 IRR	Base de données RIPE ou équivalent	Minutes (après ASN)
ROA RPKI pour chaque préfixe	Portail membre RIR	Minutes
LOA (Lettre d'autorisation)	Vous la signez, le fournisseur peut la demander	Minutes
Fournisseur avec support BGP	ou similaire	Variable

Votre fournisseur aura généralement besoin de votre ASN, des préfixes que vous prévoyez d'annoncer et possiblement d'une LOA confirmant que vous êtes autorisé à les annoncer.

Comment l'ASN, l'allocation IP et le RPKI s'articulent-ils ?

Ces trois éléments forment la chaîne de confiance qui permet à Internet de vérifier que vos annonces sont légitimes.

Votre ASN identifie votre réseau. Chaque annonce BGP porte l'ASN d'origine dans son AS-path. Les réseaux en amont utilisent cette information pour construire leur politique de routage.

Votre allocation IP est l'espace d'adresses que vous êtes autorisé à utiliser. La base de données du RIR vous enregistre (ou votre LIR parrain) comme détenteur.

Les objets IRR constituent la couche de politique de routage. Un objet route dans la base de données RIPE dit « AS64500 est autorisé à originer 192.0.2.0/24 ». Les fournisseurs de transit interrogent les données IRR pour construire des filtres de préfixes. Si votre objet route est manquant ou erroné, les filtres automatisés de votre fournisseur de transit peuvent rejeter votre annonce.

Les ROA RPKI sont la couche cryptographique. Un ROA est un objet signé stocké dans le dépôt RPKI de votre RIR. Il dit la même chose que l'objet route IRR, mais il est vérifiable cryptographiquement. Les réseaux exécutant des validateurs ROV (Routinator, rpki-client, Fort, RIPE NCC RPKI Validator) récupèrent les ROA et transmettent les résultats de validation à leurs routeurs. Une annonce sans ROA valide a de plus en plus de chances d'être rejetée.

La chaîne de dépendances ressemble à ceci :

ASN (from RIR)
  └── IP allocation (from RIR)
        ├── IRR route objects (RIPE Database)
        ├── RPKI ROAs (RIR portal)
        └── BGP session (provider router <-> your daemon)
              └── Prefix announcement (your daemon originates routes)

Mettez en place les couches supérieures correctement avant de toucher à la configuration BGP. Une annonce sans enregistrements IRR et RPKI correspondants sera soit filtrée, soit signalée comme un potentiel détournement.

Quel démon de routage choisir : BIRD2, FRR ou VyOS ?

Trois options dominent le BGP sur les environnements VPS Linux. Les trois supportent le dual-stack (IPv4 + IPv6), la validation RPKI et les fonctionnalités nécessaires au BYOIP. Le choix se résume au style de configuration préféré et aux exigences opérationnelles.

Fonctionnalité	BIRD2	FRRouting (FRR)	VyOS
Style de configuration	Langage déclaratif propriétaire	CLI type Cisco IOS (vtysh)	CLI type JunOS (set/commit)
Langage de filtrage	Filtres puissants, Turing-complets	Route-maps + prefix-lists	Route-maps (FRR sous le capot)
Dual-stack	Fichier de config unique, multi-table	Blocs address-family séparés	Blocs address-family séparés
Support RPKI	Protocole `rpki` intégré	Module rpki intégré	Via intégration FRR
Utilisation mémoire	Plus faible (2x plus efficace que FRR dans les benchmarks)	Plus élevée, surtout avec les tables complètes	Plus élevée (overhead d'un OS complet)
Courbe d'apprentissage	Plus raide si vous venez de Cisco	Faible pour les habitués Cisco/IOS	Faible pour les habitués JunOS
Idéal pour	Serveurs de route IXP, configurations riches en politiques	Workflow familier type Cisco	Expérience complète de routeur OS

BIRD2 possède le langage de filtrage le plus expressif. Vous pouvez écrire des politiques d'import/export complexes dans un seul fichier de configuration. Il gère IPv4 et IPv6 dans une seule instance de démon. L'empreinte mémoire est environ la moitié de celle de FRR pour des charges équivalentes. La contrepartie : sa syntaxe de configuration n'a pas d'équivalent dans le monde des équipementiers. Vous apprenez le langage BIRD ou vous n'utilisez pas BIRD.

FRRouting (FRR) utilise un CLI type Cisco IOS via vtysh. Si vous avez travaillé avec Cisco, Arista ou l'ancien Quagga, FRR vous semblera immédiatement familier. Les route-maps et prefix-lists fonctionnent comme vous l'attendez. C'est la suite de routage open-source la plus déployée.

VyOS est un système d'exploitation réseau complet qui utilise FRR comme moteur de routage. Vous configurez tout via un workflow set / commit à la JunOS. Il fournit une expérience de routeur complète : pare-feu, NAT, VPN, DHCP et routage dans un seul paquet. Sur Virtua Cloud, vous pouvez déployer VyOS en un clic. La contrepartie : c'est un OS complet, pas juste un démon. Vous perdez la flexibilité d'un serveur Linux généraliste.

Lequel choisir ? Si vous voulez un contrôle et une efficacité maximaux, choisissez BIRD2. Si vous voulez la familiarité Cisco sur un serveur Linux, choisissez FRR. Si vous voulez un routeur dédié clé en main, choisissez VyOS.

Comment sécuriser un déploiement BGP ?

La sécurité en BGP n'est pas optionnelle. Une session BGP mal configurée peut fuiter des routes, accepter des préfixes détournés ou exposer votre réseau à l'injection de trafic. Chaque déploiement BGP devrait inclure ces couches dès le premier jour.

RPKI et validation d'origine de route

Configurez votre démon pour valider les routes reçues par rapport aux données RPKI. Exécutez un cache RPKI local (Routinator ou rpki-client) ou connectez-vous à un validateur hébergé. Rejetez les routes avec un état RPKI « invalid ». Cela empêche votre routeur d'accepter des préfixes détournés.

En 2025, plus de 51 % des routes IPv4 et 57 % des routes IPv6 possèdent des ROA valides. Tous les grands fournisseurs de transit effectuent la ROV. Si vos propres préfixes n'ont pas de ROA, certains réseaux rejetteront vos annonces.

Filtrage de routes

N'exécutez jamais export all ou import all en production. Ce sont l'équivalent BGP de chmod 777.

Côté export, n'annoncez que les préfixes que vous êtes autorisé à originer. Utilisez une prefix-list qui correspond explicitement à vos allocations. Côté import, si vous êtes single-homed (un seul upstream), vous acceptez typiquement uniquement une route par défaut. Si vous êtes multi-homed, filtrez les imports par prefix-list et AS-path pour éviter les fuites de routes.

Rejetez les préfixes bogon (espace RFC 1918, plages de documentation, blocs non alloués) à l'import. Rejetez les préfixes plus longs qu'un /24 pour IPv4 ou /48 pour IPv6. Définissez des limites max-prefix pour vous protéger contre un pair qui déverserait accidentellement une table de routage complète dans votre session.

GTSM (Generalized TTL Security Mechanism)

GTSM (RFC 5082) garantit que les paquets BGP arrivent avec un TTL de 255, ce qui signifie qu'ils ont été émis par un voisin directement connecté. Cela bloque les attaquants distants qui tenteraient d'injecter des paquets BGP. La plupart des fournisseurs le supportent. Activez-le de votre côté lorsque votre fournisseur confirme le support.

Règles de pare-feu

Autorisez le port TCP 179 uniquement depuis l'IP du routeur BGP de votre fournisseur. Rejetez tout le reste à destination du port 179. C'est une seule règle nftables ou iptables, mais elle empêche les tentatives de connexion BGP non autorisées.

Pièges courants

rp_filter qui casse le trafic. Le filtrage par chemin inverse de Linux (rp_filter=1, la valeur par défaut sur de nombreuses distributions) rejette les paquets arrivant sur une interface si la table de routage du noyau indique que l'IP source devrait arriver sur une interface différente. Avec des préfixes annoncés par BGP sur des interfaces dummy, cela casse le trafic légitime. Réglez rp_filter=0 ou rp_filter=2 (mode loose) sur les interfaces concernées. Testez après chaque mise à jour du noyau.

Confusion entre config BIRD 1.x et BIRD 2.x. BIRD 2 utilise une syntaxe de configuration complètement différente de BIRD 1.x. De nombreux tutoriels en ligne (y compris des résultats en tête de recherche chez Vultr et d'autres) montrent encore la syntaxe BIRD 1.x. Si vous copiez-collez une configuration d'un ancien tutoriel dans BIRD 2, le démon refusera de démarrer. Vérifiez toujours quelle version vous exécutez avec birdc show status.

Objets IRR manquants. Vous avez créé les ROA RPKI mais oublié l'objet route IRR. Le constructeur de filtres automatisé de votre upstream interroge l'IRR, ne trouve aucun objet correspondant et rejette silencieusement votre annonce. Votre préfixe est RPKI-valid mais reste inaccessible. Créez toujours les deux.

Que pouvez-vous faire avec BGP au-delà des annonces de base ?

Une fois votre préfixe annoncé et joignable, BGP ouvre la porte à plusieurs cas d'usage avancés.

Anycast

Annoncez le même préfixe depuis plusieurs emplacements géographiques. Chaque site exécute un service identique (résolveur DNS, point de présence CDN, endpoint API). Les utilisateurs sont routés vers le site le plus proche par la sélection de chemin BGP. Si un site tombe en panne, sa session BGP s'interrompt, le préfixe est retiré de cet emplacement et le trafic bascule automatiquement vers les sites restants.

L'anycast est le principe de fonctionnement du système de serveurs racine DNS. Vous pouvez reproduire ce modèle avec deux ou trois nœuds VPS dans différents centres de données.

Basculement et multi-homing

Annoncez votre préfixe depuis deux fournisseurs ou deux emplacements chez le même fournisseur. Utilisez LOCAL_PREF et MED pour définir la préférence primaire/secondaire. Lorsque le primaire tombe, le trafic bascule vers le secondaire dans la fenêtre de convergence BGP (typiquement 30 à 90 secondes avec BFD activé).

Pour la maintenance planifiée, utilisez la communauté graceful shutdown (RFC 8326). Votre démon signale aux pairs de déprioriser le préfixe avant que vous ne coupiez la session. Le trafic se vide vers le site de secours sans perte de paquets.

Communautés BGP pour l'ingénierie de trafic

Les communautés sont des tags attachés aux annonces BGP qui influencent la façon dont les réseaux en amont traitent vos routes. Utilisations courantes :

Communauté blackhole : Signalez à votre upstream de rejeter tout le trafic vers un préfixe spécifique lors d'une attaque DDoS.
Contrôle du prepending : Demandez à votre upstream de prependre votre AS pour rendre un chemin moins préféré, orientant le trafic vers un autre upstream.
Annonce sélective : Annoncez aux pairs mais pas au transit, ou inversement, contrôlant où votre préfixe se propage.
Limitation géographique : Limitez l'annonce à des régions ou IXP spécifiques.

Chaque fournisseur définit ses propres valeurs de communautés. Consultez la documentation des communautés BGP de votre fournisseur avant de les utiliser.

Comment superviser les annonces BGP ?

Vous devez savoir quand quelque chose change avec vos préfixes. Les détournements de routes, les retraits accidentels, les changements d'état RPKI et les baisses de visibilité nécessitent tous une attention immédiate. Ne partez pas du principe que vos annonces sont stables parce qu'elles fonctionnaient hier.

BGPalerter est un outil de supervision auto-hébergé qui surveille vos préfixes et votre ASN. Il se connecte aux sources de données BGP publiques (RIPE RIS, RouteViews) et vous alerte sur :

Les détournements de préfixe (un autre ASN qui origine votre préfixe)
Les détournements de sous-préfixe (quelqu'un qui annonce un plus spécifique de votre préfixe)
Les fuites de routes
Les changements d'état RPKI invalid
Les baisses de visibilité (votre préfixe disparaît d'un nombre significatif de points d'observation)

Exécutez-le comme service systemd sur un VPS distinct de celui qui fait du BGP. Si votre nœud BGP tombe, vous voulez toujours recevoir les alertes. Configurez les notifications vers Slack, email ou votre stack de monitoring.

Outils de validation externe

Utilisez-les pour vérifier que vos annonces sont correctes vues de l'extérieur :

bgp.tools -- Vue en temps réel de votre préfixe, AS-path, état RPKI et cohérence IRR
RIPE Stat -- Looking glass opéré par le RIR avec historique de routage et validation RPKI
Hurricane Electric BGP Toolkit (bgp.he.net) -- Informations AS, rapports de préfixes, statut IRR et RPKI
Serveurs looking glass -- La plupart des fournisseurs de transit et des IXP offrent un accès looking glass pour vérifier comment votre préfixe apparaît depuis leur perspective

Vérifiez ces outils après votre première annonce et périodiquement ensuite. Une annonce qui semble correcte du point de vue de votre démon peut être filtrée ou détournée plus en amont.

Le parcours complet : de zéro au BGP supervisé

Voici le chemin complet, avec les liens vers l'article qui couvre chaque étape :

Obtenir un ASN auprès de votre RIR via un LIR parrain.
Obtenir de l'espace IP. Au minimum /24 IPv4, /48 IPv6. Auprès de votre RIR ou d'un broker.
Créer des objets route IRR dans la base de données RIPE pour chaque préfixe.
Créer des ROA RPKI dans le portail de votre RIR pour chaque préfixe.
Choisir un démon de routage : BIRD2 , FRR , ou VyOS .
Configurer BGP sur votre VPS. Établir la session, annoncer vos préfixes, appliquer les filtres.
Sécuriser le déploiement. Validation RPKI, filtrage de routes, GTSM, règles de pare-feu.
Vérifier depuis l'extérieur. Consultez bgp.tools, RIPE Stat et le looking glass de votre fournisseur.
Mettre en place la supervision. Déployez BGPalerter pour surveiller les détournements et les problèmes de visibilité.
Explorer les cas d'usage avancés. Communautés , anycast , basculement .

Avez-vous besoin de votre propre ASN ou pouvez-vous utiliser un ASN privé ?

Si vous annoncez des préfixes à un seul upstream et ne prévoyez jamais de multi-homing ou de peering dans un IXP, un ASN privé (64512-65534 pour les 16 bits, 4200000000-4294967294 pour les 32 bits) peut fonctionner. Votre fournisseur le retire de l'AS-path avant de propager vos routes en amont.

Obtenez votre propre ASN public si l'un de ces cas s'applique :

Vous prévoyez de vous connecter à plusieurs upstreams (multi-homing)
Vous voulez peerer dans un point d'échange Internet
Vous voulez que votre ASN soit visible dans les traceroutes et les looking glasses BGP
Vous voulez utiliser des communautés BGP qui référencent votre ASN
Vous opérez un service où l'identité réseau compte (CDN, DNS, infrastructure email)

La différence de coût est minime. Un ASN public via le RIPE NCC coûte les frais du LIR parrain (typiquement quelques centaines d'euros par an). Pour la plupart des cas d'usage, un ASN public est le bon choix.

Copyright 2026 Virtua.Cloud. Tous droits réservés. Ce contenu est une création originale de l'équipe Virtua.Cloud. Toute reproduction, republication ou redistribution sans autorisation écrite est interdite.