Comment vérifier les routes BGP et la validité RPKI

Quand les routes tournent mal

Le scénario est familier à quiconque a exploité un service public : le site se charge chez vous, le serveur est sain, le certificat est valide — et les clients d’un autre pays n’obtiennent rien. La supervision depuis votre propre bureau dit que tout va bien. Leur trafic n’arrive jamais, parce que la joignabilité n’est pas une propriété de votre serveur. C’est une propriété des annonces qui transportent votre préfixe à travers les réseaux des autres, et ces annonces peuvent changer, être filtrées ou être contredites sans que rien ne change sur votre machine. « Le site est en panne » est parfois un fait de routage en costume de serveur.

Les pannes de routage ont trois formes qu’il vaut la peine de distinguer. Un détournement : un autre système autonome annonce votre préfixe — ou une tranche plus spécifique de celui-ci — et attire un trafic qui n’a jamais été le sien. Une fuite de route : un réseau propage des routes qu’il a reçues à des pairs ou des fournisseurs à qui il n’aurait pas dû les envoyer, si bien que le trafic fait des détours absurdes ou tombe dans un réseau incapable de le livrer. Et la silencieuse : une annonce retirée ou filtrée par un changement de configuration, un différend de peering ou un rejet RPKI, si bien qu’une partie d’internet n’a tout simplement plus de chemin. Les corrections pour les trois sont entièrement différentes, et c’est pourquoi le premier travail est de les distinguer — et cela commence par regarder ce qui est réellement annoncé.

Commencez par l’annonce

La première question est la plus simple : ce préfixe est-il annoncé dans la table globale tout court et, si oui, par qui ? Le dernier AS de l’annonce — l’ASN d’origine — nomme le réseau qui prétend détenir le préfixe, et les données de registre derrière lui nomment l’organisation à laquelle cet ASN appartient. Si l’origine est votre propre ASN, ou celui de votre fournisseur, l’annonce revendique au moins le bon domicile. Si c’est un nom que vous n’avez jamais vu, vous avez appris quelque chose d’important dans les dix premières secondes.

Les cas limites portent l’information. Un préfixe sans aucune origine n’est annoncé nulle part où les collecteurs peuvent voir — une faute de frappe dans le préfixe, une annonce jamais faite, ou une annonce retirée partout ; cherchez un préfixe moins spécifique qui le couvre avant de conclure quoi que ce soit, car le trafic peut encore circuler sous l’agrégat. Plusieurs origines pour un même préfixe ne sont pas automatiquement suspectes : les services anycast et les grands CDN originent le même préfixe depuis de nombreux réseaux par conception, et un préfixe en cours de transfert entre fournisseurs peut légitimement afficher deux origines pendant un temps. Plusieurs origines plus un détenteur que vous ne reconnaissez pas, à partir d’un moment où vous n’avez rien changé : voilà la combinaison qui mérite l’alarme.

Visibilité et chemins AS

Un looking glass n’interroge pas votre routeur ; il interroge les collecteurs de routes — les collecteurs RIPE RIS derrière les données de ce site peerent avec des réseaux du monde entier et enregistrent ce que ces pairs leur annoncent. La visibilité est le nombre de pairs de collecteurs qui voient votre préfixe tout court. Un préfixe sain et ancien est typiquement vu par presque tous. Un nombre en chute libre — ou un nombre complet hier et réduit à une poignée aujourd’hui — suggère une annonce en train d’être retirée, filtrée, ou vue seulement à travers un ensemble de chemins qui se rétrécit.

Le chemin AS est la chaîne de réseaux qu’une annonce a traversée : lisez-le de droite à gauche, de l’origine vers l’extérieur à travers les fournisseurs de transit jusqu’au pair du collecteur. Il vous dit quels upstreams transportent la route et où votre propre fournisseur siège dans la chaîne — et quand une fuite se produit, le chemin montre le réseau qui ne devrait pas être là, au milieu, en train de réacheminer le trafic de côté. Une habitude de lecture à prendre : un ASN répété dans un chemin est en général un prepending délibéré, un signal d’ingénierie de trafic, pas une boucle ; et le chemin le plus court n’est pas toujours celui que prend le trafic réel, parce que le routage suit la politique commerciale, pas la géographie.

Calibrez l’instrument avant de lui faire confiance. Les collecteurs voient les vues des réseaux qui peerent avec eux — un échantillon large et bien placé, mais pas chaque routeur de la planète. Un préfixe peut être invisible pour les collecteurs et pourtant joignable à l’intérieur d’un fournisseur qui ne peere pas avec RIS, et visible pour les collecteurs pendant qu’un transit précis le filtre plus en aval. Le résultat d’un looking glass est une preuve sur la table globale vue depuis des points d’observation sérieux. Ce n’est pas une photographie de chaque décision d’acheminement prise sur votre préfixe en ce moment même.

RPKI en termes simples

RPKI est la tentative d’internet de faire de « je peux annoncer ceci » une affirmation vérifiable plutôt qu’un cri. Le détenteur d’un préfixe publie un ROA — une autorisation d’origine de route, un objet signé déclarant qu’un ASN nommé peut originer ce préfixe, jusqu’à une longueur de préfixe maximale déclarée. Des validateurs comme Routinator — celui qui se trouve derrière la vérification de ce site — récupèrent les ROA depuis les ancres de confiance des cinq registres régionaux (APNIC, ARIN, LACNIC, RIPE NCC et AFRINIC) et testent chaque annonce contre eux. Une déclaration signée couvre votre annonce ou ne la couvre pas ; c’est tout le mécanisme.

Chaque annonce tombe dans l’un de trois états. Valide : un ROA couvre ce préfixe, cet ASN d’origine et cette longueur. Invalide : un ROA couvre le préfixe mais l’annonce enfreint ses termes — et la distinction au sein d’invalide compte : invalid_asn signifie que le mauvais réseau l’origine, tandis qu’invalid_length signifie que le bon réseau annonce un préfixe plus spécifique que le ROA ne l’autorise. Inconnu (souvent appelé not-found) : aucun ROA ne couvre le préfixe du tout, donc il n’y a rien contre quoi vérifier.

Maintenant, l’honnêteté. Invalide est une preuve, pas la démonstration d’un détournement. Les ROA sont mal émis, deviennent obsolètes après un transfert de préfixe, ou sont écrits avec une longueur maximale que l’équipe d’exploitation oublie ensuite en désagrégeant — le cas du mauvais ASN mérite un appel rapide, mais vérifiez vos propres papiers avant d’accuser quiconque. Et inconnu signifie en général simplement que personne n’a publié de ROA ; une grande partie des préfixes du monde n’en a toujours aucun, donc inconnu est une lacune du système, pas une marque contre le préfixe. Invalide a quand même de vraies dents : de nombreux grands réseaux rejettent désormais directement les annonces invalides, si bien qu’un état invalide peut être la cause directe du trou de joignabilité par lequel vous avez commencé.

Une routine de vérification en cinq étapes

Écartez d’abord les couches plus simples — un nouvel enregistrement DNS encore en propagation (vérifiez-le avec le vérificateur de propagation DNS) ou un port de service fermé vers l’extérieur (vérifiez-le avec le scanner de ports) imitent parfaitement les pannes de routage. Ouvrez ensuite la recherche BGP et travaillez dans l’ordre. Étape un, le préfixe : saisissez l’IP ou le préfixe et confirmez l’annonce couvrante qui transporte réellement votre trafic. Étape deux, l’origine : lisez l’ASN d’origine et son détenteur — le vôtre, celui de votre fournisseur, ou celui d’un inconnu. Étape trois, la visibilité : combien de pairs de collecteurs le voient, et ce nombre ressemble-t-il à la normale de ce préfixe ?

Étape quatre, RPKI : valide, invalide (de quel type ?) ou inconnu — et si invalid_asn nomme un inconnu, escaladez avant de finir la liste. Étape cinq, les chemins AS : quels upstreams transportent l’annonce, et un réseau siège-t-il dans un chemin où il n’a pas sa place ? Puis écrivez-le pendant qu’il est devant vous : le préfixe, l’ASN d’origine et son détenteur, le nombre de visibilité, l’état RPKI, les chemins que vous avez vus — et l’heure, en UTC. Les données de l’outil viennent de RIPEstat et RIPE RIS et sont mises en cache environ une heure, donc une capture sans horodatage est une anecdote ; une note qui en a un est une preuve que vous pouvez comparer à la vérification suivante.

Des limites à énoncer

Trois limites appartiennent à tout rapport que ces données alimentent. La couverture des collecteurs est biaisée : les pairs de RIS sont nombreux mais pas répartis uniformément — certaines régions et certains types de réseaux sont bien mieux représentés que d’autres, donc un nombre de visibilité est un échantillon, pas un recensement. La propagation prend des minutes, pas des secondes : un changement légitime que vous venez de faire peut légitimement ne pas être encore visible, et une route retirée peut persister dans les collecteurs après que le trafic réel est passé à autre chose ; attendez et revérifiez avant de déclarer une réparation ou un désastre. La couverture RPKI est partielle : de nombreux préfixes n’ayant toujours pas de ROA, la couche de validation ne peut juger que la partie de la table qui y participe.

Et la limite qui compte le plus dans un désaccord : un résultat propre ici ne prouve pas ce que contient la table de votre propre routeur. Vos sessions, vos filtres, votre préférence locale peuvent tous faire que votre coin d’internet diffère légitimement de ce que voient les collecteurs. Servez-vous de la recherche BGP pour établir ce que le monde annonce et voit ; servez-vous de la table BGP de votre propre routeur pour établir ce que vous en faites. Un rapport d’incident qui garde ces deux affirmations séparées est un rapport que personne n’a à retirer.

Questions fréquentes