Magic Transit: Netzwerkfunktionen in Cloudflare-Größenordnung

Heute haben wir Cloudflare Magic Transitangekündigt, das Cloudflares Netzwerk für jeden IP-Datenverkehr im Internet verfügbar macht. Bisher hat Cloudflare hauptsächlich Proxydienste betrieben: Unsere Server beenden HTTP-, TCP- und UDP-Sitzungen mit Internetbenutzern und übergeben diese Daten in neuen Sitzungen, die sie mit Ursprungsservern erstellen. Mit Magic Transit arbeiten wir nun auch auf IP-Ebene: Neben dem Beenden von Sitzungen wenden unsere Server eine Reihe von Netzwerkfunktionen (DoS-Abwehr, Firewalling, Routing usw.) auf Paket-für-Paket-Basis an.

In den letzten neun Jahren haben wir ein robustes, skalierbares globales Netzwerk aufgebaut, das derzeit 193 Städte in über 90 Ländern umfasst und ständig wächst. Alle Cloudflare-Kunden profitieren von diesem Ausmaß dank zweier wichtiger Techniken. Die erste ist „Anycast Networking“. Cloudflare war ein früher Anwendervon Anycast und benutzte diese Routing-Technik, um den Internetverkehr über unsere Rechenzentren zu verteilen. Das bedeutet, dass jedes Rechenzentrum den Datenverkehr jedes Kunden verarbeiten kann und wir neue Rechenzentren einrichten können, ohne neue IP-Adressen erwerben und bereitstellen zu müssen. Die zweite Technik ist unsere homogene Serverarchitektur. Jeder Server in jedem unserer Edge-Rechenzentren ist in der Lage, jede Aufgabe auszuführen. Wir bauen unsere Server auf Standardhardware auf, wodurch wir unsere Verarbeitungskapazität schnell und einfach erhöhen können, indem wir bestehende Rechenzentren mit neuen Servern ergänzen. Die Tatsache, dass wir keine spezielle Hardware haben, von der wir abhängen, hat uns auch dazu gebracht, ein Know-how aufzubauen, um die Grenzen dessen zu erweitern, was in der Vernetzung mit modernen Linux-Kernel-Techniken möglich ist.

Magic Transit basiert auf dem gleichen Netzwerk mit den gleichen Techniken, was bedeutet, dass unsere Kunden ihre Netzwerkfunktionen jetzt in Cloudflare-Größenordnung ausführen können. Unsere schnelle, sichere, zuverlässige globale Edge wird zur Edge unserer Kunden. Um zu illustrieren, wie dies funktioniert, folgen wir der Reise eines Datenpakets von einem Nutzer im Internet zum Netzwerk eines „Magic Transit“-Kunden.

Im Ankündigungs-Blogbeitrag beschreiben wir ein Bereitstellungsbeispiel für Acme Corp. Lassen Sie uns mit diesem Beispiel hier fortfahren. Wenn Acme das IP-Präfix 203.0.113.0/24 in Cloudflare einbringt, kündigen wir dieses Präfix in jedem unserer Rechenzentren auf der ganzen Welt unseren Transitanbietern, Peering-Partnern und den Internet-Knoten an. Darüber hinaus stoppt Acme die Ankündigung des Präfixes für ihre eigenen ISPs. Das bedeutet, dass jedes IP-Paket im Internet mit einer Zieladresse innerhalb des Acme-Präfixes an ein nahegelegenes Cloudflare-Rechenzentrum und nicht an den Router von Acme übermittelt wird.

Angenommen, ich möchte von meinem Computer im Cloudflare-Büro in Champaign, Illinois, auf Acmes FTP-Server auf 203.0.113.100 zugreifen. Mein Computer generiert ein TCP-SYN-Paket mit der Zieladresse 203.0.113.100 und schickt es in das Internet. Dank Anycast landet dieses Paket im Rechenzentrum von Cloudflare in Chicago, dem nächstgelegenen Rechenzentrum zu Champaign (in Bezug auf die Routing-Entfernung im Internet). Das Paket kommt im Router des Rechenzentrums an, dieser verwendet ECMP-Routing (Equal Cost Multi-Path), um auszuwählen, welcher Server das Paket verarbeiten soll, und schickt das Paket an den ausgewählten Server.

Einmal auf dem Server angekommen, durchläuft das Paket unsere XDP- und iptables-basierten DoS-Erkennungs- und Abwehrfunktionen. Wenn dabei erkannt werden würde, dass dieses TCP-SYN-Paket Teil eines Angriffs ist, würde es verworfen, und damit wäre die Sache erledigt. Zu meinem Glück wird das Paket durchgelassen.

Bisher sieht das alles genauso aus wie bei jedem anderen Datenverkehr im Cloudflare-Netzwerk. Aufgrund unserer Expertise beim Betrieb eines globalen Anycast-Netzwerks sind wir in der Lage, „Magic Transit“-Kundenverkehr in jedes Rechenzentrum zu lenken und die gleiche DoS-Abwehrlösung anzuwenden, durch die Cloudflare seit Jahren geschützt wird. Unsere DoS-Lösung hat einigen der größten jemals registrierten Angriffe widerstanden, darunter eine SYN-Food von 942 Gbit/s im Jahr 2018. Unten haben wir einen Screenshot einer kürzlichen SYN-Flood von 300 Millionen Paketen pro Sekunde. Unsere Architektur ermöglicht uns eine Skalierung, um die größten Angriffe zu stoppen.

Was ich oben beschrieben habe, sah genauso aus wie die Verarbeitung jedes anderen Cloudflare-Datenverkehrs, aber hier hören die Ähnlichkeiten auf. Für unsere anderen Dienste würde das TCP-SYN-Paket nun an einen lokalen Proxy-Prozess gesendet (z. B. an unseren nginx-basierten HTTP/S-Stack). Für Magic Transit möchten wir stattdessen kundendefinierte Netzwerkfunktionen wie Firewalls und Routing dynamisch bereitstellen und anwenden. Wir mussten also eine Möglichkeit finden, diese Netzwerkfunktionen schnell einzurichten und zu konfigurieren und gleichzeitig eine Netzwerkisolation zu ermöglichen. Zu diesem Zweck setzen wir Netzwerk-Namespaces ein.

Namespaces sind eine Sammlung von Linux-Kernelfunktionen zum Erstellen einfacher virtueller Instanzen von Systemressourcen, die für eine Gruppe von Prozessen freigegeben werden können. Namespaces sind ein grundlegender Baustein für die Containerisierung in Linux. Insbesondere basiert Docker auf Linux-Namespaces. Ein Netzwerk-Namespace ist eine isolierte Instanz des Linux-Netzwerkstapels, einschließlich eigener Netzwerkschnittstellen (mit eigenen eBPF-Hooks), Routingtabellen, Netzwerkfilterkonfiguration usw. Netzwerk-Namespaces bieten uns einen kostengünstigen Mechanismus, um kundendefinierte Netzwerkkonfigurationen schnell und isoliert anzuwenden – alle mit integrierten Linux-Kernelfunktionen, sodass es keine Leistungseinbußen durch Userspace-Paketweiterleitung oder Proxying gibt.

Wenn ein neuer Kunde Magic Transit verwendet, erstellen wir einen brandneuen Netzwerk-Namespace für diesen Kunden auf jedem Server in unserem Edge-Netzwerk (habe ich erwähnt, dass jeder Server jede Aufgabe ausführen kann?). Wir haben einen Daemon erstellt, der auf unseren Servern ausgeführt wird und für die Verwaltung dieser Netzwerk-Namespaces und deren Konfigurationen verantwortlich ist. Dieser Daemon liest ständig Konfigurationsupdates von Quicksilver, unserem global verteilten Schlüsselwertspeicher, und wendet kundendefinierte Konfigurationen für Firewalls, Routing usw. im Namespace des Kunden an. Wenn Acme z. B. eine Firewallregel bereitstellen möchte, um FTP-Datenverkehr (TCP-Ports 20 und 21) zu 203.0.113.100 zuzulassen, wird diese Konfiguration global über Quicksilver weitergegeben. Der „Magic Transit“-Daemon wendet dann die Firewallregel an, indem eine nftables-Regel zum Acme-Kundennamespace hinzugefügt wird:

# 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

# Anwendung der nftables-Regel im Namespace von Acme

$ sudo ip netns exec acme_namespace nft add rule inet filter prerouting ip daddr 203.0.113.100 tcp dport 20-21 accept

Um den Datenverkehr des Kunden zu seinem Netzwerk-Namespace zu bringen, ist eine kleine Routingkonfiguration im Standard-Netzwerk-Namespace erforderlich. Wenn ein Netzwerk-Namespace erstellt wird, wird auch ein Paar virtueller Ethernet-Schnittstellen (veth) erstellt: eine im Standard-Namespace und eine im neu erstellten Namespace. Dieses Schnittstellenpaar erstellt eine „virtuelle Leitung“ für den Netzwerkdatenverkehr in und aus dem neuen Netzwerk-Namespace. Im Standard-Netzwerk-Namespace unterhalten wir eine Routingtabelle, die die IP-Präfixe von „Magic Transit“-Kunden an die veths weiterleitet, die den Namespaces dieser Kunden entsprechen. Wir verwenden iptables, um die Pakete zu markieren, die für „Magic Transit“-Kundenpräfixe bestimmt sind, und wir haben eine Routingregel, die angibt, dass diese speziell markierten Pakete die „Magic Transit“-Routingtabelle verwenden sollen.

(Warum der Aufwand des Markierens von Paketen in iptables und des Verwaltens einer separaten Routingtabelle? Isolation. Indem wir „Magic Transit“-Routingkonfigurationen getrennt halten, verringern wir das Risiko, dass versehentlich die Standard-Routingtabelle auf eine Weise geändert wird, die den Nicht-„Magic Transit“-Datenverkehr durch unsere Edge beeinträchtigt.)

Netzwerk-Namespaces bieten eine einfache Umgebung, in der ein „Magic Transit“-Kunde Netzwerkfunktionen isoliert ausführen und verwalten kann, sodass wir die volle Kontrolle in die Hände des Kunden legen können.

Nach dem Durchlaufen der Edge-Netzwerkfunktionen ist das TCP-SYN-Paket endlich bereit, an die Netzwerkinfrastruktur des Kunden zurückgesendet zu werden. Da Acme Corp. keinen Netzwerk-Footprint in einer Colocation-Einrichtung mit Cloudflare hat, müssen wir ihren Netzwerkverkehr über das öffentliche Internet bereitstellen.

Das stellt ein Problem dar. Die Zieladresse des TCP-SYN-Pakets lautet 203.0.113.100, aber das einzige Netzwerk, das das IP-Präfix 203.0.113.0/24 im Internet ankündigt, ist Cloudflare. Das bedeutet, dass wir dieses Paket nicht einfach an das Internet weiterleiten können – es würde wie ein Bumerang wieder zu uns zurückkommen! Um dieses Paket an Acme zu liefern, müssen wir eine als „Tunneling“ bezeichnete Technik verwenden.

Tunneling ist eine Methode, um Datenverkehr von einem Netzwerk über ein anderes Netzwerk zu übertragen. In unserem Fall geht es darum, Acmes IP-Pakete innerhalb von IP-Paketen einzukapseln, die über das Internet an den Router von Acme übermittelt werden können. Es gibt eine Reihe von gängigen Tunneling-Protokollen, aber Generic Routing Encapsulation (GRE) wird häufig wegen seiner Einfachheit und der breiten Unterstützung durch die Anbieter eingesetzt.

GRE-Tunnelendpunkte werden sowohl auf den Servern von Cloudflare (innerhalb des Netzwerk-Namespace von Acme) als auch auf dem Router von Acme konfiguriert. Cloudflare-Server kapseln dann IP-Pakete, die für 203.0.113.0/24 bestimmt sind, in IP-Paketen ein, die für eine öffentlich routingfähige IP-Adresse für Acmes Router bestimmt sind. Dieser entkapselt die Pakete und gibt sie in das interne Netzwerk von Acme aus.

Nun habe ich ein wichtiges Detail im obigen Diagramm weggelassen: die IP-Adresse von Cloudflares Seite des GRE-Tunnels. Das Konfigurieren eines GRE-Tunnels erfordert die Angabe einer IP-Adresse für jede Seite, und der äußere IP-Header für Pakete, die über den Tunnel gesendet werden, muss diese spezifischen Adressen verwenden. Aber Cloudflare verfügt über Tausende von Servern, von denen womöglich jeder Pakete über einen Tunnel an den Kunden liefern muss. Mit wie vielen Cloudflare-IP-Adressen (und GRE-Tunneln) muss der Kunde kommunizieren? Die Antwort: nur mit einer, dank des Zaubers von Anycast.

Cloudflare verwendet Anycast-IP-Adressen für unsere GRE-Tunnelendpunkte, was bedeutet, dass jeder Server in jedem Rechenzentrum in der Lage ist, Pakete für denselben GRE-Tunnel einzukapseln und zu entkapseln. Wie ist das möglich? Ist ein Tunnel nicht eine Punkt-zu-Punkt-Verbindung? Das GRE-Protokoll selbst ist zustandslos – jedes Paket wird unabhängig und ohne Aushandlung oder Koordination zwischen Tunnelendpunkten verarbeitet. Während der Tunnel technisch an eine IP-Adresse gebunden ist_,_ muss er nicht an ein bestimmtes Gerät gebunden sein. Jedes Gerät, das die äußeren Header abstreifen und dann das innere Paket weiterleiten kann, kann jedes GRE-Paket verarbeiten, das über den Tunnel gesendet wird. Tatsächlich ist der Begriff „Tunnel“ im Zusammenhang mit Anycast irreführend, da er eine Verbindung zwischen zwei Fixpunkten impliziert. Mit Cloudflares Anycast GRE bietet Ihnen ein einzelner „Tunnel“ einen Kanal zu jedem Server in jedem Rechenzentrum an Cloudflares globaler Edge.

Eine sehr bedeutende Folge von Anycast GRE ist, dass es einzelne Fehlerpunkte eliminiert. Traditionell kann GRE-over-Internet problematisch sein, da ein Internetausfall zwischen den beiden GRE-Endpunkten den „Tunnel“ vollständig unterbricht. Das bedeutet, dass für eine zuverlässige Datenübermittlung redundante GRE-Tunnel eingerichtet und unterhalten werden müssen, die an verschiedenen physischen Standorten enden, und dass der Datenverkehr umgeleitet werden muss, wenn einer der Tunnel unterbrochen wird. Da Cloudflare jedoch Kundendatenverkehr von jedem Server in jedem Rechenzentrum einkapselt und sendet, gibt es keinen einzelnen „Tunnel“, der unterbrochen werden kann. Das bedeutet, dass „Magic Transit“-Kunden die Redundanz und Zuverlässigkeit von Endtunneln an mehreren physischen Standorten genießen können, während sie nur einen einzelnen GRE-Endpunkt einrichten und unterhalten, wodurch ihre Arbeit vereinfacht wird.

Magic Transit ist eine leistungsstarke neue Möglichkeit, Netzwerkfunktionen in großem Maßstab bereitzustellen. Wir geben Ihnen nicht nur eine virtuelle Instanz, sondern auch eine globale virtuelle Edge. Magic Transit nimmt die Hardware-Appliances, die Sie normalerweise in Ihrem lokalen Netzwerk unterbringen würden, und verteilt sie auf jeden Server in jedem Rechenzentrum im Cloudflare-Netzwerk. Dies ermöglicht Ihnen den Zugriff auf unser globales Anycast-Netzwerk, unsere Serverflotte, die Ihre Aufgaben ausführen kann, und auf unser Engineering-Know-how zum Aufbau schneller, zuverlässiger und sicherer Netzwerke. Unsere Größenordnung ist jetzt Ihre Größenordnung.