Connection Tracking ("conntrack") ass eng Kär Feature vum Linux Kernel Netzwierkstack. Et erlaabt de Kernel all logesch Netzwierkverbindungen oder Flux ze verfollegen an doduerch all d'Päckchen z'identifizéieren, déi all Floss ausmaachen, sou datt se sequenziell veraarbecht kënne ginn.
Conntrack ass eng wichteg Kernel Feature déi an e puer Grondfäll benotzt gëtt:
- NAT hänkt op Informatioun vum Conntrack of, sou datt et all Pakete vum selwechte Stroum gläich behandele kann. Zum Beispill, wann e Pod Zougang zu engem Kubernetes Service benotzt, benotzt de Kube-Proxy Loadbalancer NAT fir de Verkéier op e spezifesche Pod am Cluster ze dirigéieren. Conntrack records datt fir eng bestëmmte Verbindung all Päckchen un den IP-Service an dee selwechte Pod geschéckt musse ginn, an datt Päckchen, déi vum Backend Pod zréckkommen, mussen NATed zréck an de Pod aus deem d'Ufro koum.
- Stateful Firewalls wéi Calico vertrauen op Informatioun vum Connecttrack zum Whitelist "Äntwert" Traffic. Dëst erlaabt Iech eng Netzpolitik ze schreiwen déi seet "erlaabt mäi Pod fir mat all Remote IP Adress ze verbannen" ouni eng Politik ze schreiwen fir explizit den Äntwertverkéier z'erméiglechen. (Ouni dëst musst Dir déi vill manner sécher "Erlaabt Päckchen op meng Pod vun all IP" Regel derbäisetzen.)
Zousätzlech verbessert conntrack typesch d'Systemleistung (duerch d'Reduktioun vum CPU Konsum a Paketlatenz) zënter nëmmen den éischte Paket an engem Stream
muss duerch de ganze Reseau Stack goen fir ze bestëmmen wat mat et ze maachen. Kuckt de Post ""fir e Beispill ze gesinn wéi et funktionnéiert.
Wéi och ëmmer, Conntrack huet seng Aschränkungen ...
Also wou ass alles falsch gaang?
D'Conntrack Dësch huet eng konfiguréierbar maximal Gréisst, a wann et voll gëtt, fänken Verbindungen normalerweis verworf oder erof. Et gëtt genuch fräi Plaz an der Tabell fir de Verkéier vun de meeschten Uwendungen ze verschaffen, an dëst wäert ni e Problem ginn. Wéi och ëmmer, et ginn e puer Szenarie an deenen Dir wëllt iwwerleeën d'Conntrack Tabelle ze benotzen:
- Deen offensichtlechste Fall ass wann Äre Server eng extrem grouss Zuel vu gläichzäiteg aktive Verbindungen handhabt. Zum Beispill, wann Är conntrack Dësch fir 128k Entréen konfiguréiert ass, mä Dir hutt> 128k concurrent Verbindungen, Dir wäert sécher zu engem Problem lafen!
- E bësse manner offensichtlech Fall: wann Äre Server eng ganz grouss Zuel vu Verbindungen pro Sekonn veraarbecht. Och wann d'Verbindunge kuerzlieweg sinn, gi se weider vu Linux iwwerwaacht fir eng gewëssen Zäit (120s par défaut). Zum Beispill, wann Är Conntrack Dësch fir 128k Entréen konfiguréiert ass an Dir probéiert 1100 Verbindungen pro Sekonn ze handhaben, wäerte se d'Gréisst vun der Conntrack Dësch iwwerschreiden, och wann d'Verbindunge ganz kuerzlieweg sinn (128k / 120s = 1092 Verbindungen / s).
Et gi verschidde Nischarten vun Apps déi an dës Kategorien falen. Zousätzlech, wann Dir vill schlecht Akteuren hunn, fëllt Äre Server Conntrack Dësch mat vill vun Halschent-oppe Verbindungen kéint als Deel vun engem Denial of Service (DOS) Attack benotzt ginn. A béide Fäll kann conntrack e limitéierende Flaschenhals an Ärem System ginn. An e puer Fäll, kann de Conntrack Dësch Parameteren ugepasst ginn genuch Äre Besoinen ze treffen - duerch Erhéijung vun der Gréisst oder Reduktioun vun der conntrack timeouts (awer wann Dir et falsch maachen, Dir wäert an vill Problemer lafen). Fir aner Fäll ass et néideg Conntrack fir aggressiv Verkéier ze Contournement.
Real Beispill
Loosst eis e spezifescht Beispill ginn: ee grousse SaaS Provider mat deem mir geschafft hunn, hat eng Zuel vu memcached Serveren op Hosten (net virtuelle Maschinnen), déi all 50K+ kuerzfristeg Verbindungen pro Sekonn veraarbecht hunn.
Si hunn experimentéiert mat der Conntrack Konfiguratioun, d'Tabellegréissten erhéicht an d'Verfollegungszäit reduzéiert, awer d'Konfiguratioun war onzouverlässeg, de RAM Konsum ass wesentlech eropgaang, wat e Problem war (op der Uerdnung vu GBytes!), An d'Verbindunge ware sou kuerz datt de Conntrack net schafen seng üblech Leeschtung Virdeel (reduzéiert Konsum CPU oder Paket latency).
Si hu sech op Calico als Alternativ gedréint. Calico Reseau Politik erlaabt Iech net Conntrack fir verschidden Zorte vu Verkéier ze benotzen (mat der doNotTrack Politik Optioun). Dëst huet hinnen den Niveau vun der Leeschtung déi se gebraucht hunn, plus den zousätzleche Sécherheetsniveau vum Calico.
Wéi eng Längt musst Dir goen fir de Conntrack z'iwwergoen?
- Net-Track Netzpolitik soll allgemeng symmetresch sinn. Am Fall vum SaaS-Provider: hir Uwendungen lafe bannent der geschützter Zone an dofir, mat der Netzpolitik, kënne se Traffic vun anere spezifesche Applikatiounen whitelistéieren, déi Zougang zu memcached erlaabt hunn.
- D'Do-Net-Streck Politik berücksichtegt d'Richtung vun der Verbindung net. Also, wann de memcached Server gehackt ass, kënnt Dir theoretesch probéieren mat engem vun de memcached Clienten ze verbannen, soulaang et de richtege Quellport benotzt. Wann Dir awer d'Netzwierkpolitik fir Är memcached Clienten korrekt definéiert hutt, da ginn dës Verbindungsversuche nach ëmmer op der Client Säit verworf.
- D'Do-not-track Politik gëtt op all Paket ugewannt, am Géigesaz zu normalen Politiken, déi nëmmen op den éischte Paket an engem Floss applizéiert ginn. Dëst kann den CPU Konsum pro Paket erhéijen, well d'Politik muss fir all Paket applizéiert ginn. Awer fir kuerzlieweg Verbindungen ass dës Ausgab duerch d'Reduktioun vum Ressourceverbrauch fir d'Conntrackveraarbechtung ausgeglach. Zum Beispill, am Fall vun engem SaaS-Provider, war d'Zuel vu Pakete fir all Verbindung ganz kleng, sou datt den zousätzleche CPU-Verbrauch bei der Uwendung vun Politiken op all Paket gerechtfäerdegt war.
Loosst eis testen ufänken
Mir hunn den Test op engem eenzege Pod mat engem memcached Server a multiple memcached Client Pods lafen op Remote Wirbelen, sou datt mir eng ganz grouss Zuel vu Verbindungen pro Sekonn ausféieren. De Server mam memcached Server Pod hat 8 Cores an 512k Entréen an der Conntrack Tabell (déi Standard konfiguréiert Tabellgréisst fir den Host).
Mir gemooss der Leeschtung Ënnerscheed tëscht: keng Reseau Politik; mat regelméisseg Calico Politik; an Calico net-Streck Politik.
Fir den éischten Test setzen mir d'Zuel vun de Verbindungen op 4.000 pro Sekonn, sou datt mir op den Ënnerscheed am CPU Konsum konzentréiere kënnen. Et waren keng bedeitend Differenzen tëscht keng Politik a regulärer Politik, awer net-verfollegt erhéicht CPU Konsum ëm ongeféier 20%:
Am zweeten Test hu mir sou vill Verbindunge lancéiert wéi eis Clienten déi maximal Unzuel u Verbindungen pro Sekonn generéiere kënnen a gemooss hunn, déi eise memcached Server handhaben konnt. Wéi erwaart hunn d'"Keng Politik" an d'"regulär Politik" Fäll souwuel d'Conntrack Limit vun iwwer 4,000 Verbindungen pro Sekonn erreecht (512k / 120s = 4,369 Verbindungen / s). Mat enger Do-Net-Streck Politik hunn eis Clienten 60,000 Verbindungen pro Sekonn ouni Probleemer geschéckt. Mir si sécher datt mir dës Zuel kéinte erhéijen andeems Dir méi Clienten derbäigesat, awer mir mengen datt dës Zuelen scho genuch sinn fir de Punkt vun dësem Artikel ze illustréieren!
Konklusioun
Conntrack ass eng wichteg Kernel Feature. Hien mécht seng Aarbecht perfekt. Et gëtt dacks vu Schlësselsystemkomponenten benotzt. Wéi och ëmmer, an e puer spezifesche Szenarien ass de Stau wéinst Conntrack méi wéi déi normal Virdeeler déi et ubitt. An dësem Szenario kann d'Calico Netzwierkpolitik benotzt ginn fir d'Benotzung vu Conntrack selektiv auszeschalten wärend d'Netzsécherheet erhéicht. Fir all anere Verkéier, Conntrack weider Äre Frënd ze sinn!
Liest och aner Artikelen op eisem Blog:
Source: will.com