Nous avons annoncé aujourd’hui Cloudflare Magic Transit, qui rend le réseau Cloudflare disponible pour tout trafic IP sur Internet. Jusqu'à présent, Cloudflare utilisait principalement des services proxy. En effet, nos serveurs mettent fin aux sessions HTTP, TCP et UDP avec les utilisateurs Internet et transmettent ces données via les nouvelles sessions qu’ils créent avec les serveurs d'origine. Avec Magic Transit, nous travaillons désormais également au niveau de la couche IP : en plus de mettre fin aux sessions, nos serveurs appliquent une série de fonctions réseau (atténuation des DoS, pare-feu, routage, etc.) paquet par paquet.
Au cours des neuf dernières années, nous avons mis en place un réseau mondial robuste et évolutif, qui s'étend actuellement dans 193 villes de plus de 90 pays et est toujours en croissance. Tous les clients de Cloudflare bénéficient de cette échelle, grâce à deux techniques importantes. Le premier est le réseau anycast. Cloudflare a été l'un des premiers utilisateurs d'anycast, utilisant cette technique de routage pour répartir le trafic Internet à travers nos centres de données. Cela signifie que n’importe quel centre de données peut gérer le trafic de n'importe quel client et que nous pouvons créer de nouveaux centres de données sans avoir à acquérir et à fournir de nouvelles adresses IP. La seconde technique est l’architecture de serveur homogène. Chaque serveur de chacun de nos centres de données périphériques est capable d'exécuter chaque tâche. Nous construisons nos serveurs sur du matériel standard, ce qui permet d’accroître rapidement notre capacité de traitement en ajoutant de nouveaux serveurs aux centres de données existants. Ne pas compter sur du matériel spécialisé nous a également amené à développer une expertise pour repousser les limites de ce qu’il est possible de faire en réseau grâce aux techniques modernes du noyau Linux.
Magic Transit est construit sur le même réseau en utilisant les mêmes techniques, ce qui signifie que nos clients peuvent désormais gérer leurs fonctions réseau à l'échelle de Cloudflare. Notre avantage mondial rapide, sécurisé et fiable devient l’avantage de nos clients. Pour en comprendre le fonctionnement, suivons le parcours d’un paquet envoyé par un utilisateur d’Internet sur le réseau d’un client de Magic Transit.
Vous faire profiter... de notre atténuation des attaques DoS !
Dans l'annonce ou l'article, nous décrivons un exemple de déploiement pour Acme Corp. Continuons avec cet exemple ici. Lorsque Acme apporte son préfixe IP 203.0.113.0/24 à Cloudflare, nous commençons à annoncer ce préfixe à nos fournisseurs de transit, nos pairs et échanges Internet de chacun de nos centres de données dans le monde. De plus, Acme cesse d’annoncer le préfixe à ses propres ISP. Cela signifie que tout paquet IP sur Internet avec une adresse de destination dans le préfixe Acme est transmis à un centre de données Cloudflare à proximité, et non au routeur Acme.
Supposons que je souhaite accéder au serveur FTP d'Acme sur 203.0.113.100 à partir de mon ordinateur situé dans le bureau de Cloudflare à Champaign, dans l'Illinois. Mon ordinateur génère un paquet TCP SYN avec l'adresse de destination 203.0.113.100 et l'envoie à Internet. Grâce à anycast, ce paquet se retrouve au centre de données de Cloudflare à Chicago, qui est le centre de données le plus proche (en termes de distance de routage Internet) depuis Champaign. Le paquet arrive sur le routeur du centre de données, qui utilise le routage ECMP (Equal Cost Multi-Path) pour sélectionner le serveur qui gérera le paquet et le répartit au serveur sélectionné.
Une fois sur le serveur, le paquet passe par nos fonctions de détection et d'atténuation des attaques DoS basées sur XDP et iptables. S'il était déterminé que ce paquet TCP SYN faisait partie d'une attaque, il serait abandonné et c’en serait terminé. Heureusement pour moi, le paquet est autorisé à passer.
Jusqu'à présent, cela ressemble exactement à n’importe quel autre trafic sur le réseau Cloudflare. Grâce à notre expertise dans la gestion d’un réseau anycast mondial, nous sommes en mesure d’attirer le trafic client de Magic Transit vers tous les centres de données et d’appliquer la même solution d’atténuation des attaques DoS qui protège Cloudflare depuis des années. Notre solution contre les attaques DoS a permis de gérer certaines des plus grandes attaques jamais enregistrées, notamment un SYN flood à 942 Gbps en 2018. Vous trouverez ci-dessous une capture d'écran d'un SYN flood récent de 300 millions de paquets par seconde. Notre architecture nous permet d’évoluer pour arrêter les plus grandes attaques.
Espaces de noms du réseau pour l'isolation et le contrôle
Si ce qui précède semble identique à la façon dont tout le trafic Cloudflare est traité, c’est ici que se terminent les similitudes. Pour nos autres services, le paquet TCP SYN serait désormais envoyé à un processus proxy local (par exemple, notre pile HTTP/S basée sur nginx). Pour Magic Transit, nous souhaitons plutôt mettre en place et appliquer de manière dynamique des fonctions réseau définies par le client, telles que les pares-feu et le routage. Nous avions besoin d'un moyen de développer et de configurer rapidement ces fonctions réseau tout en assurant une isolation entre réseaux. Pour cela, nous nous sommes tournés vers les espaces de noms réseau.
Les espaces de noms constituent un ensemble de fonctionnalités du noyau Linux permettant de créer des instances virtuelles légères de ressources système pouvant être partagées dans un groupe de processus. Les espaces de noms sont un élément fondamental de la conteneurisation sous Linux. Docker est notamment construit sur des espaces de noms Linux. Un espace de noms réseau est une instance isolée de la pile réseau Linux, notamment ses propres interfaces réseau (avec leurs propres points d'ancrage eBPF), ses tables de routage, sa configuration Netfilter, etc. Les espaces de noms réseau nous offrent un mécanisme peu coûteux pour appliquer rapidement les configurations réseau définies par le client de manière isolée, toutes dotées de fonctionnalités intégrées au noyau Linux, de sorte que les performances de transfert de paquets ou de proxy dans l’espace utilisateur ne soient pas affectées.
Lorsqu'un nouveau client commence à utiliser Magic Transit, nous créons un nouvel espace de nom réseau pour ce client sur chaque serveur de notre réseau périphérique (ai-je déjà mentionné que chaque serveur peut exécuter toutes les tâches ?). Nous avons créé un démon qui s'exécute sur nos serveurs et est responsable de la gestion de ces espaces de noms réseau et leurs configurations. Ce démon lit en permanence les mises à jour de configuration depuis Quicksilver, notre magasin de valeurs-clés distribué dans le monde entier et applique des configurations définies par le client pour les pare-feux, le routage, etc., dans l’espace de noms du client. Par exemple, si Acme souhaite configurer une règle de pare-feu pour autoriser le trafic FTP (ports TCP 20 et 21) vers 203.0.113.100, cette configuration est propagée de manière globale par Quicksilver et le démon de Magic Transit applique la règle de pare-feu en ajoutant une règle nftables à l'espace de noms client Acme :
# Apply nftables rule inside Acme’s namespace
$ sudo ip netns exec acme_namespace nft add rule inet filter prerouting ip daddr 203.0.113.100 tcp dport 20-21 accept# Appliquer la règle nftables dans l’espace de noms Acme
$ sudo ip netns exec acme_namespace nft add rule inet filter prerouting ip daddr 203.0.113.100 tcp dport 20-21 accept
Obtenir le trafic du client vers son espace de noms réseau nécessite une petite configuration de routage dans l’espace de noms réseau par défaut. Lorsqu'un espace de nom réseau est créé, une paire d'interfaces Ethernet virtuelles (veth) est également créée : une dans l'espace de nom par défaut et une dans le nouvel espace de nom créé. Cette paire d'interfaces crée un « câble virtuel » permettant d'acheminer le trafic réseau vers et depuis le nouvel espace de noms réseau. Dans l’espace de noms réseau par défaut, nous maintenons une table de routage qui transmet les préfixes IP des clients Magic Transit aux veths correspondant aux espaces de noms de ces clients. Nous utilisons iptables pour marquer les paquets destinés aux préfixes des clients Magic Transit. Nous avons une règle de routage qui précise que ces paquets spécialement marqués doivent utiliser la table de routage Magic Transit.
(Pourquoi nous sommes-nous donné la peine de marquer des paquets dans iptables et maintenir une table de routage différente ? Isolation. En gardant les configurations de routage Magic Transit différentes, nous réduisons le risque de modification accidentelle de la table de routage par défaut de manière à affecter la façon dont le trafic non-Magic Transit circule vers notre réseau.)
Les espaces de noms réseau fournissent un environnement léger, dans lequel un client Magic Transit peut exécuter et gérer les fonctions réseau de manière isolée. Cela nous permet de confier le contrôle total au client.
GRE + anycast = magie
Après avoir traversé les fonctions de réseau périphérique, le paquet TCP SYN est enfin prêt à être renvoyé à l’infrastructure réseau du client. Étant donné qu'Acme Corp. n'a pas de couverture réseau dans un centre de colocation avec Cloudflare, nous devons livrer son trafic réseau sur Internet public.
Cela pose un problème. L'adresse de destination du paquet TCP SYN est 203.0.113.100, mais le seul réseau qui annonce le préfixe IP 203.0.113.0/24 sur Internet est Cloudflare. Cela signifie que nous ne pouvons pas simplement transférer ce paquet sur Internet. Il nous reviendra immédiatement ! Afin de livrer ce paquet à Acme, nous devons utiliser une technique appelée tunnellisation.
La tunnellisation est une méthode de transfert du trafic d'un réseau vers un autre réseau. Dans notre cas, il s’agit d’encapsuler les paquets IP d’Acme à l’intérieur de paquets IP pouvant être livrés au routeur d’Acme sur Internet. Il existe un certain nombre de protocoles de tunnellisation courants, mais l’Encapsulation de routage générique (GRE) est souvent utilisée pour sa simplicité et son support des fournisseurs répandu.
Les points de terminaison de tunnel GRE sont configurés à la fois sur les serveurs de Cloudflare (dans l’espace de noms réseau d’Acme) et sur le routeur d’Acme. Les serveurs de Cloudflare encapsulent ensuite les paquets IP destinés à 203.0.113.0/24 à l’intérieur de paquets IP destinés à une adresse IP publique routable pour le routeur Acme, qui ouvre les paquets et les émet dans le réseau interne d’Acme.
Aussi, ai-je omis un détail important dans le diagramme ci-dessus : l’adresse IP du tunnel GRE du côté de Cloudflare. La configuration d'un tunnel GRE nécessite la précision d'une adresse IP pour chaque côté et l'en-tête IP externe des paquets envoyés via le tunnel doit utiliser ces adresses spécifiques. Mais Cloudflare a des milliers de serveurs, qui peuvent tous avoir besoin de livrer des paquets au client via un tunnel. Alors, à combien d'adresses IP Cloudflare (et de tunnels GRE) le client doit-il envoyer ? La réponse : une seule, grâce à la magie d'anycast.
Cloudflare utilise les adresses IP anycast pour nos points de terminaison de tunnel GRE, ce qui signifie que n’importe quel serveur de n'importe quel centre de données est capable d'encapsuler et de décapsuler des paquets pour le même tunnel GRE. Comment est-ce possible ? Un tunnel n'est-il pas un lien point à point ? Le protocole GRE lui-même est sans statut. Chaque paquet est traité indépendamment et sans nécessiter de négociation ni de coordination entre les points de terminaison du tunnel. Bien que le tunnel soit techniquement lié à une adresse IP, il n’est pas nécessaire de le lier à un dispositif spécifique. Tout dispositif capable de supprimer les en-têtes externes puis d'acheminer le paquet interne peut gérer n’importe quel paquet GRE envoyé sur le tunnel. En réalité, dans le contexte de anycast, le terme « tunnel » est trompeur puisqu'il implique un lien entre deux points fixes. Avec Anycast GRE de Cloudflare, un seul « tunnel » vous offre un chemin vers tous les serveurs de tous les centres de données situés à la périphérie globale de Cloudflare.
Anycast GRE a pour conséquence notoire d’éliminer les points de défaillance uniques. De manière traditionnelle, le GRE sur Internet peut être problématique, car une panne d’Internet entre les deux points de terminaison GRE détruit complètement le « tunnel ». Cela signifie qu'une transmission de données fiable nécessite de passer par la tâche ardue de configurer et de maintenir des tunnels GRE redondants se terminant sur différents sites physiques et de rediriger le trafic en cas de panne d'un des tunnels. Mais comme Cloudflare encapsule et fournit le trafic client à partir de chaque serveur dans chaque centre de données, aucun « tunnel » ne peut être défaillant. Cela signifie que les clients de Magic Transit peuvent profiter de la redondance et de la fiabilité des tunnels de terminaison sur plusieurs sites physiques tout en configurant et en maintenant un seul point de terminaison GRE, ce qui simplifie leur travail.
Notre échelle est maintenant votre échelle
Magic Transit est un nouveau moyen puissant de déployer des fonctions réseau à grande échelle. Nous ne vous donnons pas seulement une instance virtuelle, nous vous donnons un avantage virtuel global. Magic Transit prend les applicatifs matériels que vous stockeriez généralement sur votre réseau et les distribue sur chaque serveur de chaque centre de données du réseau Cloudflare. Cela vous donne accès à notre réseau global anycast, à notre flotte de serveurs capables d'exécuter vos tâches et à notre expertise en ingénierie pour la création de réseaux rapides, fiables et sécurisés. Notre échelle est maintenant la votre.