Ein Großteil der Cloudflare-Technologie ist gut dokumentiert. Beispielsweise wie wir den Traffic zwischen den Eyeballs (Clients) und unseren Servern handhaben, wurde in diesem Blog bereits mehrfach besprochen: „Eine kurze Einführung in Anycast (2011)“, „Load Balancing ohne Load Balancer (2013)“, „Pfad-MTU-Ermittlung in der Praxis (2015)“, „Cloudflares Edge Load Balancer (2020)“, „Wie wir die BSD-Socket-API repariert haben (2022)“.
Wir haben jedoch nur selten über den zweiten Teil unseres Netzwerk-Setups gesprochen – und zwar wie unsere Server die Inhalte aus dem Internet abrufen. In diesem Blog schließen wir diese Lücke. Wir gehen darauf ein, wie wir die Cloudflare-IP-Adressen verwalten, die zum Abrufen der Daten aus dem Internet verwendet werden, wie sich unser Egress-Netzwerkdesign entwickelt hat und wie wir es für die beste Nutzung des verfügbaren IP-Raums optimiert haben.
Machen Sie sich bereit! Es gibt viel zu berichten.
Zuerst die Terminologie
Jeder Cloudflare-Server bearbeitet viele Arten von Netzwerk-Traffic, aber zwei grobe Kategorien stechen hervor:
- Traffic, der aus dem Internet stammt – Eingehende Verbindungen, die von Eyeball zu unseren Servern initiiert werden. Im Kontext dieses Blogbeitrags nennen wir diese „Ingress-Verbindungen“ (eingehende Verbindung).
- Traffic, der von Cloudflare stammt – Ausgehende Verbindungen, die von unseren Servern zu anderen Hosts im Internet initiiert werden. Der Einfachheit halber nennen wir diese Verbindungen „Egress-Verbindungen“ (ausgehende Verbindungen).
Der Egress-Teil wird in diesem Blog zwar selten behandelt, ist aber entscheidend für unseren Betrieb Unsere Server müssen für ihre Arbeit ausgehende Verbindungen initiieren! Zum Beispiel:
- In unserem CDN-Produkt werden die Inhalte vor dem Cachen von den Ursprungsservern abgerufen. Siehe „Pingora, der Proxy, der Cloudflare mit dem Internet verbindet (2022)“ sowie Argo und Tiered Cache.
- Für das Spectrum-Produkt führt jede eingehende TCP-Verbindung zu einer ausgehenden Verbindung.
- Worker führen zum Aufbau einer HTTP-Antwort oft mehrere Unterabfragen durch. Einige von ihnen könnten Abfragen an Server im Internet sein.
- Wir betreiben auch clientorientierte Forward-Proxy-Produkte – wie WARP und Cloudflare Gateway. Diese Proxys befassen sich mit Eyeball-Verbindungen, die für das Internet bestimmt sind. Unsere Server müssen im Auftrag unserer Nutzer Verbindungen zum Internet herstellen.
Und so weiter.
Anycast beim Ingress, Unicast beim Egress
Die Architektur unseres Ingress-Netzwerks unterscheidet sich stark von der des Egress-Netzwerks. Die eingehenden Verbindungen aus dem Internet werden ausschließlich über unsere Anycast-IP-Bereiche abgewickelt. Anycast ist eine Technologie, bei der jedes unserer Rechenzentren dieselben IP-Bereiche „ankündigt“ und bearbeiten kann. Woher weiß das Internet bei den vielen möglichen Zielen, wohin es die Pakete routen soll? Nun, die Eyeball-Pakete werden an das Rechenzentrum geroutet, das auf der Grundlage von BGP-Metriken am nächsten liegt, oft ist es auch das geografisch nächstgelegene. Normalerweise ändern sich die BGP-Routen nicht wesentlich, und man kann davon ausgehen, dass jede Eyeball-IP an ein einziges Rechenzentrum geroutet wird.
Anycast funktioniert zwar gut in der eingehenden Richtung, aber nicht in der ausgehenden. Der Aufbau einer ausgehenden Verbindung von einer Anycast-IP aus wird nicht funktionieren. Denken Sie an das Antwortpaket. Es wird wahrscheinlich an einen falschen Ort geroutet – und zwar an ein Rechenzentrum, das dem Absender geographisch am nächsten liegt, nicht unbedingt an das Quellrechenzentrum!
Aus diesem Grund haben wir bis vor kurzem ausgehende Verbindungen auf eine einfache und konventionelle Weise hergestellt: Jeder Server erhielt seine eigene Unicast-IP-Adresse. „Unicast IP“ bedeutet, dass es weltweit nur einen Server gibt, der diese Adresse verwendet. Rücksendepakete funktionieren einwandfrei und werden genau an den richtigen, durch die Unicast-IP identifizierten Server zurückgesendet.
Segmentierung des Traffics basierend auf der Egress-IP
Ursprünglich handelte es sich bei den von Cloudflare gesourcten Verbindungen hauptsächlich um HTTP-Abrufe, die zu Ursprungsservern im Internet gingen. Mit dem Wachstum unserer Produktlinie wurde auch der Traffic immer vielfältiger. Das beste Beispiel ist unsere WARP-App. Für WARP betreiben unsere Server einen Forward Proxy und wickeln den Traffic ab, der von den Endkundengeräten stammt. Dies geschieht ohne das gleiche Maß an Zwischenschaltung wie bei unserem CDN-Produkt. Dadurch entsteht ein Problem. Server von Drittanbietern im Internet – wie die Ursprungsserver – müssen unterscheiden könne, welche Verbindungen von Cloudflare-Diensten und welche von unseren WARP-Nutzern stammen. Eine solche Segmentierung des Traffics erfolgt traditionell durch die Verwendung unterschiedlicher IP-Bereiche für verschiedene Arten von Traffic (obwohl wir kürzlich robustere Techniken wie Authenticated Origin Pulls eingeführt haben).
Um das Problem der Unterscheidung zwischen vertrauenswürdigen und nicht vertrauenswürdigen Traffic-Pools zu umgehen, haben wir jedem unserer Server eine nicht vertrauenswürdige WARP-IP-Adresse hinzugefügt:
Egress-IP-Adressen mit Länder-Tag
Es wurde schnell klar, dass die Tags „vertrauenswürdig“ und „nicht vertrauenswürdig“ allein nicht ausreichen. Für den WARP-Dienst benötigen wir auch Länder-Tags. WARP-Nutzer aus dem Vereinigten Königreich erwarten beispielsweise, dass die Website bbc.com einfach funktioniert. Die BBC schränkt jedoch viele ihrer Dienste auf Personen im Vereinigten Königreich ein.
Dies geschieht durch Geofencing – mit Hilfe einer Datenbank, die öffentliche IP-Adressen Ländern zuordnet und nur welche des Vereinigten Königreichs zulässt. Geofencing ist im heutigen Internet weit verbreitet. Um Geofencing-Probleme zu vermeiden, müssen wir je nach Standort des WARP-Nutzers bestimmte Egress-Adressen auswählen, die mit einem entsprechenden Land getaggt sind. Wie viele andere Parteien im Internet kennzeichnen wir unseren Egress-IP-Raum mit Ländercodes und veröffentlichen ihn als Geofeed (wie diesen). Beachten Sie, dass es sich bei dem veröffentlichten Geofeed nur um Daten handelt. Die Tatsache, dass eine IP als z. B. UK gekennzeichnet ist, bedeutet nicht, dass sie aus dem Vereinigten Königreich geliefert wird, sondern nur, dass der Betreiber möchte, dass sie im Vereinigten Königreich geolokalisiert wird. Wie viele andere Dinge im Internet basiert auch dies auf Vertrauen.
Beachten Sie, dass wir an dieser Stelle drei unabhängige geografische Tags haben:
- das Länder-Tag des WARP-Nutzers – die Eyeball-Verbindungs-IP
- den Standort des Rechenzentrums, mit dem der Eyeball verbunden ist
- den Länder-Tag der ausgehenden IP
Um einen optimalen Service zu gewährleisten, möchten wir die Egressing-IP so wählen, dass ihr Länder-Tag mit dem Land der Eyeball-IP übereinstimmt. Aber das Egressing von einer bestimmten IP mit Länder-Tag ist eine Herausforderung: Unsere Rechenzentren bedienen Nutzer aus der ganzen Welt, potenziell aus vielen Ländern! Denken Sie daran: Aufgrund von Anycast haben wir keine direkte Kontrolle über das Ingress-Routing. Die Geographie des Internets stimmt nicht immer mit der physischen Geographie überein. Unser Londoner Rechenzentrum empfängt zum Beispiel nicht nur Traffic von Nutzern aus dem Vereinigten Königreich, sondern auch aus Irland und Saudi-Arabien. Daher benötigen unsere Server in London viele WARP-Egress-Adressen, die mit vielen Ländern verbunden sind:
Erkennen Sie, wohin das führt? Der Problembereich explodiert förmlich! Statt einer oder zwei Egress-IP-Adressen für jeden Server benötigen wir jetzt Dutzende, und IPv4-Adressen sind nicht günstig. Mit diesem Aufbau benötigen wir viele Adressen pro Server, und wir betreiben Tausende von Servern. Das wird eine sehr teure Architektur.
Ist Anycast ein Problem?
Zur Erinnerung: Beim Anycast-Ingress haben wir keine Kontrolle darüber, zu welchem Rechenzentrum der Nutzer geroutet wird. Daher muss jedes unserer Rechenzentren von einer Adresse mit jedem denkbaren Tag ausgehen können. Auch innerhalb des Rechenzentrums haben wir keine Kontrolle darüber, zu welchem Server die Verbindung geroutet wird. Es gibt potenziell viele Tags, viele Rechenzentren und viele Server in einem Rechenzentrum.
Vielleicht liegt das Problem in der Ingress-Architektur? Vielleicht ist ein traditionelles Netzwerkdesign besser, bei dem ein bestimmter Eyeball mit DNS an ein bestimmtes Rechenzentrum oder sogar einen Server geroutet wird?
Das ist eine Möglichkeit, aber wir haben uns dagegen entschieden. Wir bevorzugen unser Anycast beim Ingress. Es bringt uns viele Vorteile:
- Performance: Bei Anycast wird der Eyeball per Definition zum nächstgelegenen Rechenzentrum geroutet (nach BGP-Metriken). Dies ist in der Regel das schnellste Rechenzentrum für einen bestimmten Nutzer.
- Automatisches Failover: Wenn eines unserer Rechenzentren nicht mehr verfügbar ist, wird der Traffic sofort und automatisch an den nächstbesten Ort umgeleitet.
- DDoS-Ausfallsicherheit: Bei einem Denial-of-Service-Angriff oder einer Traffic-Spitze wird die Last automatisch auf viele Rechenzentren verteilt, was die Auswirkungen erheblich reduziert.
- Einheitliche Software: Die Funktionalität jedes Rechenzentrums und jedes Servers innerhalb eines Rechenzentrums ist identisch. Wir verwenden auf allen Servern auf der ganzen Welt denselben Software-Stack. Jeder Rechner kann jede Aktion für jedes Produkt ausführen. Dies erlaubt ein einfaches Debugging und eine gute Skalierbarkeit.
Aus diesen Gründen würden wir gerne den Anycast am Ingress beibehalten. Wir haben beschlossen, das Problem der Kardinalität der Egress-Adressen auf andere Weise zu lösen.
Millionen-Dollar-Problem lösen
Von den Tausenden der von uns betriebenen Server sollte jeder einzelne in der Lage sein, eine Egress-IP mit einem der möglichen Tags zu verwenden. Am einfachsten lässt sich unsere Lösung erklären, wenn wir Ihnen zunächst zwei extreme Designs zeigen.
Jeder Server besitzt alle benötigten IPs: Jeder Server verfügt über alle spezialisierten Egress-IPs mit den benötigten Tags.
Ein Server besitzt die benötigte IP: eine spezialisierte Egress-IP mit einem bestimmten Tag befindet sich an einem Ort, andere Server leiten den Traffic an sie weiter.
Beide Optionen haben Vor- und Nachteile:
| Spezialisierte IP auf jedem Server | Spezialisierte IP auf einem Server |
|---|---|
| Super teuer €€€, jeder Server benötigt viele IP-Adressen. | Günstig €, nur eine spezielle IP pro Tag erforderlich. |
| Egress immer lokal – schnell | Egress fast immer weitergeleitet – langsam |
| Ausgezeichnete Zuverlässigkeit – jeder Server ist unabhängig | Geringe Zuverlässigkeit – Einführung von Engpässen |
Es gibt einen dritten Weg
Wir haben intensiv über dieses Problem nachgedacht. Ehrlich gesagt ist die erste extreme Option, also jede benötigte IP lokal auf jedem Cloudflare-Server verfügbar zu haben, nicht völlig undurchführbar. Das ist in etwa das, was wir für IPv6 erreichen konnten. Bei IPv6 ist der Zugriff auf den großen benötigten IP-Raum kein Problem.
Bei IPv4 ist jedoch keine der beiden Optionen akzeptabel. Die erste bietet einen schnellen und zuverlässigen Egress, ist aber mit hohen Kosten verbunden – die benötigten IPv4-Adressen sind teuer. Die zweite Option verwendet den kleinstmöglichen IP-Raum, ist also billig, aber erfordert Abstriche bei der Performance und Zuverlässigkeit.
Unsere Lösung ist ein Kompromiss zwischen den beiden Extremen. Die grobe Idee besteht in der Änderung der Zuweisungseinheit. Anstatt jedem Server eine /32-IPv4-Adresse zuzuweisen, haben wir eine Methode entwickelt, um eine /32-IP pro Rechenzentrum zuzuweisen und diese dann auf die physischen Server aufzuteilen.
| Spezialisierte IP auf jedem Server | Spezialisierte IP pro Rechenzentrum | Spezialisierte IP auf einem Server |
|---|---|---|
| Super teuer €€€ | Angemessener Preis €€ | Günstig € |
| Egress immer lokal – schnell | Egress immer lokal – schnell | Egress fast immer weitergeleitet – langsam |
| Ausgezeichnete Zuverlässigkeit – jeder Server ist unabhängig | Ausgezeichnete Zuverlässigkeit – jeder Server ist unabhängig | Schlechte Zuverlässigkeit – viele Engpässe |
Teilen einer IP im Rechenzentrum
Die Idee, dass Server eine IP gemeinsam nutzen, ist nicht neu. Herkömmlicherweise gelingt dies durch Source-NAT auf einem Router. Leider können wir uns aufgrund der schieren Anzahl der benötigten Egress-IPs und der Größe unseres Unternehmens nicht auf eine Stateful-Firewall / NAT auf Router-Ebene verlassen. Außerdem mögen wir keinen geteilten Status, daher sind wir keine Anhänger von verteilten NAT-Installationen.
Wir haben uns stattdessen dafür entschieden, eine Egress-IP über einen Portbereich auf mehrere Server aufzuteilen. Für eine bestimmte Egress-IP besitzt jeder Server einen kleinen Teil der verfügbaren Quell-Ports – einen Port Slice.
Wenn Rücksendepakete aus dem Internet ankommen, müssen wir sie an den richtigen Rechner zurückrouten. Für diese Aufgabe haben wir „Unimog“ angepasst – unseren L4 XDP-basierten Load Balancer – („Unimog, Cloudflares Load Balancer (2020)“) und er funktioniert einwandfrei.
Mit einem Port Slice von beispielsweise 2.048 Ports können wir eine IP für 31 Server freigeben. Die Ports können jedoch immer ausgehen. Um dies zu vermeiden, haben wir viel Mühe in die effiziente Wiederverwendung der Egress-Ports gesteckt. Gehen Sie dazu auf „Wie Ihnen nicht die Ports ausgehen (2022)“, „Wie Sie IPv4-Adressen teilen (2022)“ sowie auf unseren Cloudflare.TV Beitrag.
Das ist so ziemlich alles. Jeder Server weiß, welche IP-Adressen und Port-Slices ihm gehören. Beim eingehenden Routing prüft Unimog die Ports und leitet die Pakete an die entsprechenden Rechner weiter.
Teilen eines Subnetzes zwischen Rechenzentren
Damit ist die Sache aber noch nicht zu Ende. Wir haben noch nicht darüber gesprochen, wie wir eine einzelne /32-Adresse in ein Rechenzentrum routen können. Traditionell ist es im öffentlichen Internet nur möglich, Subnetze mit einer Granularität von /24 oder 256 IP-Adressen zu routen. In unserem Fall würde dies zu einer großen Verschwendung von IP-Speicherplatz führen.
Um dieses Problem zu lösen und die Nutzung unseres IP-Speicherplatzes zu verbessern, haben wir unsere Egress-Bereiche als ... Anycast eingerichtet! Daraufhin haben wir Unimog angepasst und ihm beigebracht, die Pakete über unser Backbone-Netzwerk an das richtige Rechenzentrum weiterzuleiten. Unimog verwaltet eine Datenbank wie diese:
198.51.100.1 - forward to LHR
198.51.100.2 - forward to CDG
198.51.100.3 - forward to MAN
...
Bei diesem Aufbau spielt es keine Rolle, an welches Rechenzentrum die zurückgesendeten Pakete geliefert werden. Unimog kann es immer reparieren und die Daten an die richtige Stelle weiterleiten. Auf der Ebene von BGP verwenden wir zwar Anycast, aber aufgrund unseres Aufbaus identifiziert eine IP semantisch ein Rechenzentrum und eine IP und ein Portbereich identifizieren einen bestimmten Rechner. Es verhält sich fast wie ein Unicast.
Wir nennen diesen Technologie-Stack „Soft-Unicast“ und es fühlt sich an wie Magie. Es ist, als hätten wir Unicast in Software über Anycast in der BGP Ebene umgesetzt.
Soft-Unicast ist von Magie nicht zu unterscheiden
Mit diesem Setup erzielen wir erhebliche Vorteile:
- Wir können eine /32-Egress-IP für viele Server freigeben.
- Wir können ein einziges Subnetz über viele Rechenzentren verteilen und es einfach und schnell ändern. So können wir unsere Egress-IPv4-Bereiche vollständig nutzen.
- Wir können ähnliche IP-Adressen in Gruppen zusammenfassen. Zum Beispiel könnten alle IP-Adressen mit dem Tag „UK“ einen einzigen zusammenhängenden Bereich bilden. Dadurch wird die Größe des veröffentlichten Geofeeds reduziert.
- Es ist für uns einfach, neue Egress-IP-Bereiche, wie Kunden-IPs, zu integrieren. Dies ist nützlich für einige unserer Produkte, wie Cloudflare Zero Trust.
All dies geschieht zu vernünftigen Kosten, ohne Einbußen bei der Performance und Zuverlässigkeit:
- In der Regel kann der Nutzer direkt aus dem nächstgelegenen Rechenzentrum aussteigen, was die bestmögliche Performance bietet.
- Je nach dem tatsächlichen Bedarf können wir die IP-Adressen zuweisen oder freigeben. Dadurch sind wir bei der Verwaltung der IP-Kosten flexibel und müssen nicht im Voraus zu viel ausgeben.
- Da wir mehrere Egress-IP-Adressen an verschiedenen Standorten betreiben, gibt es keine Kompromisse bei der Zuverlässigkeit.
Der wahre Standort unserer IP-Adressen ist: „die Cloud“
Trotz der großen Effizienz, die wir mit Soft-Unicast erzielen, sind wir auf einige Probleme gestoßen. Mitunter werden wir gefragt: „Wo befindet sich diese IP-Adresse physisch?“ Aber darauf gibt es keine Antwort! Unsere Egress-IPs existieren physisch nirgendwo. Aus Sicht von BGP sind unsere Egress-Ranges anycast, d. h. sie existieren überall. Logischerweise wird jede Adresse jeweils in einem Rechenzentrum verwendet, aber wir können sie bei Bedarf verschieben.
Content Delivery Networks leiten Nutzer in die Irre
Ein weiteres Beispiel eines Problems, auf das wir mit CDN von Drittanbietern gestoßen sind, ist das folgende. Wie wir bereits erwähnt haben, gibt es drei Länder-Tags in unserer Pipeline:
- Der Länder-Tag der IP, von der sich Eyeball verbindet.
- Der Standort unseres Rechenzentrums.
- Der Länder-Tag der IP-Adressen, die wir für die ausgehenden Verbindungen gewählt haben.
Die Tatsache, dass unsere Egress-Adresse als „UK“ gekennzeichnet ist, bedeutet nicht immer, dass sie tatsächlich im Vereinigten Königreich verwendet wird. Es ist schon vorgekommen, dass ein WARP-Nutzer, der als „UK“ gekennzeichnet war, aufgrund der Wartung unseres LHR-Rechenzentrums nach Paris geroutet wurde. Ein beliebtes CDN führte einen Reverse-Lookup unserer Egress-IP durch, fand den Tag „UK“ und leitete den Nutzer an einen Londoner CDN-Server weiter. Das ist normalerweise in Ordnung ... aber zu dem Zeitpunkt gingen wir tatsächlich von Paris aus. Dieser Nutzer routete die Pakete letztendlich von seinem Wohnort im Vereinigten Königreich nach Paris und zurück ins Vereinigte Königreich. Das ist schlecht für die Performance.
Wir lösen dieses Problem, indem wir DNS-Anfragen in dem Rechenzentrum durchführen, aus dem die Daten stammen. Für DNS verwenden wir IP-Adressen, die mit dem Standort des Rechenzentrums gekennzeichnet sind, nicht mit der beabsichtigten Geolokation des Nutzers. Dadurch wird das Problem im Allgemeinen behoben, aber leider gibt es immer noch einige Ausnahmen.
Die Zukunft ist da
Unsere Experimente mit Addressing Agility aus dem Jahr 2021 haben gezeigt, dass es bei der Adressierung auf der Eingangsseite noch viele Möglichkeiten für Innovationen gibt. Soft-Unicast zeigt uns, dass wir auf der Egress-Seite große Flexibilität und Dichte erreichen können.
Mit jedem neuen Produkt wächst die Anzahl der Tags, die wir auf der Egress-Seite benötigen – von der Vertrauenswürdigkeit des Traffics über die Produktkategorie bis hin zur Geolokation. Da der Pool an nutzbaren IPv4-Adressen schrumpft, können wir ganz sicher mit mehr Innovationen in diesem Bereich rechnen. Soft-unicast ist unsere Lösung, aber sicher nicht unsere letzte Entwicklung.
Im Moment sieht es jedoch so aus, als ob wir uns vom traditionellen Unicast wegbewegen. Unsere Egress-IPs existieren nicht mehr an einem festen Ort, und einige unserer Server besitzen heutzutage nicht einmal mehr eine echte Unicast-IP.