🥇Wenn Linux conntrack Ihr Freund nicht mehr ist

Das Verfolgen von Verbindungen („conntrack“) ist eine grundlegende Funktion des Netzwerk-Stacks des Linux-Kernels. Sie ermöglicht es dem Kernel, alle logischen Netzwerkverbindungen oder -ströme zu verfolgen und dadurch alle Pakete zu identifizieren, die jeden Stream ausmachen, um sie zusammenhängend zu verarbeiten.

Conntrack ist eine wichtige Kernfunktion, die in einigen wesentlichen Fällen verwendet wird:

NAT basiert auf Informationen von conntrack, damit es alle Pakete aus einem Stream einheitlich verarbeiten kann. Zum Beispiel, wenn ein Pod einen Kubernetes-Service anruft, nutzt der Load Balancer kube-proxy NAT, um den Datenverkehr an einen bestimmten Pod innerhalb des Clusters zu leiten. Conntrack vermerkt, 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ückgesendet werden, von NAT wieder an den Pod geleitet werden müssen, von dem die Anfrage kam.
Zustandsüberwachte Firewalls wie Calico nutzen Informationen von conntrack, um eingehenden Datenverkehr in die Whitelist aufzunehmen. Dadurch können Sie eine Netzwerkrichtlinie formulieren wie: „Erlaube meinem Pod, sich mit jeder externen IP-Adresse zu verbinden“, ohne separate Regeln für eingehenden Datenverkehr schreiben zu müssen. (Ohne diese Funktion müssten Sie ein deutlich unsichereres Regelwerk verwenden, das wie folgt lautet: „Erlaube Pakete in meinen Pod von jeder IP-Adresse“.)

Darüber hinaus verbessert conntrack normalerweise die Systemleistung (indem es den CPU-Zeitverbrauch und die Paketverzögerungen reduziert), da nur das erste Paket in einem Datenstrom
eine vollständige Verarbeitung des Netzwerkstacks durchlaufen muss, um zu bestimmen, was damit geschehen soll. Siehe den Beitrag „Vergleich der kube-proxy-Modi“, um ein Beispiel dafür zu sehen, wie das funktioniert.

Dennoch hat conntrack seine Grenzen...

Also, wo ist alles schiefgelaufen?

Die conntrack-Tabelle hat eine anpassbare maximale Größe. Wenn sie voll ist, beginnen die Verbindungen normalerweise abgelehnt oder unterbrochen zu werden. Für den Datenverkehr der meisten Anwendungen reicht der freie Platz in der Tabelle aus, und dies wird in der Regel kein Problem darstellen. Allerdings gibt es einige Szenarien, in denen es sinnvoll ist, über die Verwendung der conntrack-Tabelle nachzudenken:

Der offensichtlichste Fall ist, wenn Ihr Server eine außergewöhnlich große Anzahl an gleichzeitig aktiven Verbindungen verarbeitet. Wenn Ihre conntrack-Tabelle beispielsweise auf 128.000 Einträge eingestellt ist, aber mehr als 128.000 gleichzeitige Verbindungen bestehen, 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) nachverfolgt. Wenn Ihre conntrack-Tabelle auf 128.000 Einträge eingestellt ist und Sie versuchen, 1.100 Verbindungen pro Sekunde zu verarbeiten, übersteigen diese die Größe der conntrack-Tabelle, selbst wenn die Verbindungen sehr kurzlebig sind (128.000 / 120 s = 1.092 Verbindungen/s).

Es gibt mehrere spezialisierte Arten von Anwendungen, die in diese Kategorien fallen. Wenn Sie jedoch viele Feinde haben, kann das Füllen der Conntrack-Tabelle Ihres Servers mit vielen halboffenen Verbindungen als Teil eines Denial-of-Service-Angriffs (DOS) genutzt werden. In beiden Fällen kann Conntrack zu einem engpassenden Knotenpunkt in Ihrem System werden. In einigen Fällen kann es ausreichen, die Einstellungen der Conntrack-Tabelle anzupassen — indem Sie entweder die Größe erhöhen oder die Zeitüberschreitungen von Conntrack verkürzen (aber wenn Sie dies falsch machen, werden Sie auf große Schwierigkeiten stoßen). In anderen Fällen wird es notwendig sein, Conntrack für aggressiven Datenverkehr zu umgehen.

Ein konkretes Beispiel

Nehmen wir ein konkretes Beispiel: Ein großer SaaS-Anbieter, mit dem wir gearbeitet haben, hatte mehrere Memcached-Server auf Hosts (nicht in virtuellen Maschinen), von denen jeder über 50.000 kurzfristige Verbindungen pro Sekunde abwickelte.

Sie experimentierten mit der Konfiguration von conntrack, vergrößerten die Tabellengrößen und verkürzten die Verfolgungszeit, aber die Konfiguration war unzuverlässig. Der RAM-Verbrauch stieg erheblich an, was ein Problem darstellte (in der Größenordnung von Gigabyte!), und die Verbindungen waren so kurz, dass conntrack keinen seiner üblichen Leistungsvorteile (weder eine Reduzierung der CPU-Nutzung noch eine Verringerung der Paketverzögerungen) erzielen konnte.

Als Alternative wandten sie sich an Calico. Die Netzwerkrichtlinien von Calico ermöglichen es, conntrack für bestimmte Arten von Datenverkehr nicht zu verwenden (indem sie die Option doNotTrack für die Richtlinien verwenden). Dies gewährleistete ihnen das erforderliche Leistungsniveau sowie ein zusätzliches Maß an Sicherheit, das Calico bietet.

Was muss man tun, um conntrack zu umgehen?

Netzwerkrichtlinien, die do-not-track verwenden, sollten in der Regel symmetrisch sein. Im Fall eines SaaS-Anbieters: Ihre Anwendungen arbeiteten innerhalb einer geschützten Zone, und durch die Netzwerkrichtlinie konnten sie Datenverkehr von anderen bestimmten Anwendungen, die Zugriff auf memcached erhielten, auf die Whitelist setzen.
Die Do-Not-Track-Richtlinie berücksichtigt nicht die Richtung der Verbindung. Im Falle eines Hacks eines Memcached-Servers besteht theoretisch die Möglichkeit, sich mit jedem der Memcached-Clients zu verbinden, sofern der richtige Quellport verwendet wird. Wenn Sie jedoch die Netzwerkrichtlinien für Ihre Memcached-Clients korrekt festgelegt haben, werden diese Verbindungsversuche dennoch auf der Client-Seite abgelehnt.
Die Do-Not-Track-Richtlinie wird auf jedes Paket angewendet, im Gegensatz zu herkömmlichen Richtlinien, die nur für das erste Paket eines Streams gelten. Dies kann die CPU-Ressourcennutzung für ein einzelnes Paket erhöhen, da die Richtlinie für jedes Paket umgesetzt werden muss. Bei kurzfristigen Verbindungen jedoch wird dieser zusätzliche Ressourcenverbrauch durch die reduzierte Ressourcennutzung bei der Verarbeitung von Conntrack ausgeglichen. Zum Beispiel war bei einem SaaS-Anbieter die Anzahl der Pakete pro Verbindung sehr gering, weshalb der zusätzliche CPU-Ressourcenverbrauch beim Anwenden der Richtlinien auf jedes Paket gerechtfertigt war.

Lassen Sie uns mit den Tests beginnen

Wir haben einen Test auf einem Pod mit einem Memcached-Server und mehreren Memcached-Client-Pods durchgeführt, die auf entfernten Knoten gestartet wurden, um eine sehr hohe Anzahl von Verbindungen pro Sekunde zu generieren. Der Server mit dem Memcached-Pod verfügte über 8 Kerne und 512.000 Einträge in der Conntrack-Tabelle (standardmäßig für den Host konfigurierte Tabellengröße).
Wir haben den Leistungsunterschied gemessen zwischen: ohne Netzwerkrichtlinie; mit der üblichen Calico-Richtlinie; und der Calico do-not-track-Richtlinie.

Für den ersten Test haben wir die Anzahl der Verbindungen auf 4.000 pro Sekunde festgelegt, um uns auf den Unterschied im CPU-Verbrauch zu konzentrieren. Hier gab es keine signifikanten 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 Kunden generieren konnten, und haben die maximalen Verbindungen pro Sekunde gemessen, die unser Memcached-Server verarbeiten konnte. Wie erwartet erreichten sowohl die "ohne Richtlinien" als auch die "Standardrichtlinie" die Grenze von conntrack mit über 4.000 Verbindungen pro Sekunde (512k / 120s = 4.369 Verbindungen/s). Mit der "do-not-track"-Richtlinie sendeten unsere Kunden 60.000 Verbindungen pro Sekunde ohne Probleme. Wir sind uns sicher, dass wir diese Zahl erhöhen könnten, indem wir mehr Kunden anschließen, glauben jedoch, dass diese Zahlen 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 zentralen Komponenten des Systems verwendet. In bestimmten Szenarien überwiegt jedoch die Überlastung durch conntrack die üblichen Vorteile, die es bietet. In diesem Fall können die Calico-Netzwerkrichtlinien genutzt werden, um die Nutzung von conntrack selektiv abzuschalten und gleichzeitig das Niveau der Netzwerksicherheit zu erhöhen. Für allen anderen Datenverkehr bleibt conntrack Ihr treuer Begleiter!