🥇Wenn Linux conntrack Ihnen nicht mehr hilfreich ist

Die Verfolgung von Verbindungen („conntrack“) ist eine grundlegende Funktion des Netzwerkstacks des Linux-Kernels. Sie ermöglicht es dem Kernel, alle logischen Netzwerkverbindungen oder -ströme nachzuverfolgen und damit alle Pakete zu identifizieren, die jeden Strom bilden, sodass diese zusammen verarbeitet werden können.

Conntrack ist eine wichtige Funktion des Kernels, die in einigen grundlegenden Szenarien verwendet wird:

NAT basiert auf Informationen von conntrack, sodass es alle Pakete aus einem Strom gleich behandeln kann. Zum Beispiel, wenn ein Pod auf einen Kubernetes-Service zugreift, verwendet der Load Balancer kube-proxy NAT, um den Verkehr an einen bestimmten Pod innerhalb des Clusters weiterzuleiten. Conntrack zeichnet auf, dass für eine bestimmte Verbindung alle Pakete an die IP des Services an denselben Pod gesendet werden müssen und dass die Pakete, die vom Backend-Pod zurückgegeben werden, durch NAT an den Pod zurückgeleitet werden müssen, von dem die Anfrage kam.
Firewalls mit Zustandsverfolgung, wie Calico, basieren auf Informationen von conntrack, um „Antwort“ -Verkehr auf die Whitelist zu setzen. Dies ermöglicht es Ihnen, eine Netzwerkpolitik zu schreiben, die besagt: „erlaube meinem Pod, eine Verbindung zu jeder entfernten IP-Adresse herzustellen“, ohne eine Politik schreiben zu müssen, um den eingehenden Verkehr explizit zuzulassen. (Andernfalls müssten Sie eine viel weniger sichere Regel hinzufügen, die besagt: „erlaube Pakete in meinen Pod von jeder IP“.)

Außerdem erhöht conntrack in der Regel die Systemleistung (verringert die CPU-Auslastung und die Paketverzögerung), da nur das erste Paket im Strom
die vollständige Verarbeitung des Netzwerkstacks durchlaufen muss, um zu bestimmen, was damit zu tun ist. Siehe den Beitrag „Vergleich der kube-proxy-Modi“, um ein Beispiel dafür zu sehen, wie das funktioniert.

Dennoch gibt es auch einige Einschränkungen bei conntrack …

Wo also lief alles schief?

Die conntrack-Tabelle hat eine anpassbare maximale Größe, und wenn sie voll ist, beginnen Verbindungen normalerweise, abgelehnt oder unterbrochen zu werden. Für die Verarbeitung des Verkehrs der meisten Anwendungen gibt es in der Tabelle normalerweise genügend freien Speicherplatz, und das wird nie zu einem Problem. Dennoch gibt es einige Szenarien, in denen es sinnvoll ist, über die Verwendung der conntrack-Tabelle nachzudenken:

Der offensichtlichste Fall ist, wenn Ihr Server eine äußerst große Anzahl gleichzeitig aktiver Verbindungen verarbeitet. Wenn Ihre conntrack-Tabelle beispielsweise auf 128.000 Einträge eingestellt ist, Sie jedoch mehr als 128.000 gleichzeitige Verbindungen haben, werden Sie mit Sicherheit auf Probleme stoßen!
Ein etwas weniger offensichtlicher Fall ist, wenn Ihr Server eine sehr hohe Anzahl an Verbindungen pro Sekunde verarbeitet. Selbst wenn die Verbindungen kurzlebig sind, werden sie von Linux für eine gewisse Zeit (standardmäßig 120 Sekunden) verfolgt. Wenn Ihre conntrack-Tabelle zum Beispiel auf 128.000 Einträge eingestellt ist und Sie versuchen, 1.100 Verbindungen pro Sekunde zu verarbeiten, überschreiten diese die Größe der conntrack-Tabelle, auch wenn die Verbindungen sehr kurzlebig sind (128k / 120s = 1.092 Verbindungen / s).

Es gibt mehrere spezielle Anwendungsarten, die in diese Kategorien fallen. Darüber hinaus kann das Füllen der conntrack-Tabelle Ihres Servers mit zahlreichen halb geöffneten Verbindungen bei vielen Feinden im Rahmen einer Denial-of-Service-Attacke (DOS) verwendet werden. In beiden Fällen kann conntrack zum Engpass Ihrer Systeme werden. In manchen Fällen kann es ausreichen, die Parameter der conntrack-Tabelle anzupassen – durch Erhöhen der Größe oder Reduzierung der Zeitüberschreitungen für conntrack (aber wenn Sie das falsch machen, werden Sie auf erhebliche Schwierigkeiten stoßen). In anderen Fällen wird es notwendig sein, conntrack für aggressiven Verkehr zu umgehen.

Ein konkretes Beispiel

Ein konkretes Beispiel: Ein großer SaaS-Anbieter, mit dem wir gearbeitet haben, hatte eine Reihe von memcached-Servern auf Hosts (nicht virtuellen Maschinen), von denen jeder über 50.000 kurzlebige Verbindungen pro Sekunde verarbeitete.

Sie experimentierten mit der Konfiguration von conntrack, erhöhten die Tabellengrößen und reduzierten die Verfolgungszeiten, aber die Konfiguration war instabil, der RAM-Verbrauch stieg erheblich an, was ein Problem darstellte (einige Gigabyte!), und die Verbindungen waren so kurz, dass conntrack seinen üblichen Leistungsgewinn (Verringerung der CPU-Nutzung oder der Paketverzögerungen) nicht erzielte.

Als Alternative wandten sie sich an Calico. Die Netzwerk-Richtlinien von Calico ermöglichen es, conntrack für bestimmte Arten von Verkehr nicht zu verwenden (indem sie die Option doNotTrack in den Richtlinien verwenden). Dies gewährte ihnen das notwendige Leistungsniveau sowie ein zusätzliches Sicherheitsniveau, das von Calico bereitgestellt wird.

Was muss man tun, um conntrack zu umgehen?

Die do-not-track Netzwerk-Richtlinien sollten in der Regel symmetrisch sein. Im Falle eines SaaS-Anbieters: Ihre Anwendungen arbeiteten innerhalb einer geschützten Zone, und daher konnten sie durch die Netzwerk-Richtlinie den Verkehr von anderen bestimmten Anwendungen, die Zugriff auf memcached erhielten, auf die Whitelist setzen.
Die do-not-track Richtlinie berücksichtigt nicht die Verbindungsrichtung. Somit könnte man im Falle eines Hacks eines memcached-Servers theoretisch versuchen, eine Verbindung zu einem der memcached-Clients herzustellen, wenn der richtige Quellport verwendet wird. Wenn jedoch die Netzwerk-Richtlinie für Ihre memcached-Clients korrekt definiert wurde, werden diese Verbindungsversuche dennoch auf der Client-Seite abgelehnt.
Die do-not-track Richtlinie wird auf jedes Paket angewendet, im Gegensatz zu den üblichen Richtlinien, die nur auf das erste Paket eines Streams angewendet werden. Dies kann den CPU-Ressourcenverbrauch pro Paket erhöhen, da die Richtlinie für jedes Paket angewendet werden muss. Für kurzfristige Verbindungen wird dieser Aufwand jedoch durch die Verringerung des Ressourcenverbrauchs für die Verarbeitung von conntrack ausgeglichen. Zum Beispiel war im Falle des SaaS-Anbieters die Anzahl der Pakete pro Verbindung sehr gering, sodass der zusätzliche Ressourcenverbrauch beim Anwenden der Richtlinien auf jedes Paket gerechtfertigt war.

Lass uns mit den Tests beginnen.

Wir haben einen Test auf einem Pod mit einem memcached-Server und mehreren Pod mit memcached-Clients durchgeführt, die auf entfernten Knoten ausgeführt wurden, damit wir eine sehr hohe Anzahl von Verbindungen pro Sekunde herstellen konnten. Der Server mit dem Pod des memcached-Servers hatte 8 Kerne und 512k Einträge in der conntrack-Tabelle (standardmäßig eingestellte Größe der Tabelle für den Host).
Wir haben den Leistungsunterschied zwischen folgenden Szenarien gemessen: ohne Netzwerk-Richtlinie; mit üblicher Calico-Richtlinie; und mit Calico do-not-track-Richtlinie.

Für den ersten Test haben wir die Anzahl der Verbindungen auf 4.000 pro Sekunde festgelegt, sodass wir uns auf die Unterschiede im CPU-Verbrauch konzentrieren konnten. Hier gab es keine wesentlichen Unterschiede zwischen dem Fehlen einer Richtlinie und der üblichen Richtlinie, aber die Do-Not-Track-Richtlinie erhöhte den CPU-Verbrauch um etwa 20 %:

Im zweiten Test haben wir so viele Verbindungen gestartet, wie unsere Clients generieren konnten, und haben die maximale Anzahl von Verbindungen pro Sekunde gemessen, die unser Memcached-Server verarbeiten konnte. Wie erwartet haben sowohl die „ohne Richtlinien“ als auch die „übliche Richtlinie“ die conntrack-Grenze von über 4.000 Verbindungen pro Sekunde erreicht (512k / 120s = 4.369 Verbindungen/s). Mit der Do-Not-Track-Richtlinie haben unsere Clients 60.000 Verbindungen pro Sekunde ohne Probleme gesendet. Wir sind uns sicher, dass wir diese Zahl erhöhen könnten, wenn wir mehr Clients anschließen, aber wir sind der Meinung, dass diese Zahlen bereits ausreichen, um die Botschaft dieses Artikels zu veranschaulichen!

Fazit

Conntrack ist eine wichtige Funktion des Kernels. Es erfüllt seine Aufgabe hervorragend. Oft wird es von wichtigen Komponenten des Systems verwendet. In bestimmten Szenarien überwiegt jedoch die Überlastung durch conntrack die üblichen Vorteile, die es bietet. In diesem Szenario können die Netzwerkrichtlinien von Calico verwendet werden, um die Nutzung von conntrack selektiv zu deaktivieren und gleichzeitig die Netzwerksicherheit zu erhöhen. Für den gesamten anderen Datenverkehr bleibt conntrack Ihr Partner!