Anslutningsspårning ("conntrack") är en kärnfunktion i Linux-kärnan-nätverksstacken. Det tillåter kärnan att hålla reda på alla logiska nätverksanslutningar eller flöden och därigenom identifiera alla paket som utgör varje flöde så att de kan bearbetas tillsammans sekventiellt.
Conntrack är en viktig kärnfunktion som används i vissa grundläggande fall:
- NAT förlitar sig på information från conntrack så att den kan behandla alla paket från samma ström lika. Till exempel, när en pod får åtkomst till en Kubernetes-tjänst, använder kube-proxy-lastbalanseraren NAT för att dirigera trafik till en specifik pod inom klustret. Conntrack registrerar att för en given anslutning måste alla paket till IP-tjänsten skickas till samma pod, och att paket som returneras av backend-podden måste NATeras tillbaka till podden som begäran kom från.
- Stateful brandväggar som Calico förlitar sig på information från connecttrack till vitlista "svar" trafik. Detta låter dig skriva en nätverkspolicy som säger "tillåt min pod att ansluta till valfri fjärr-IP-adress" utan att behöva skriva en policy för att uttryckligen tillåta svarstrafik. (Utan detta skulle du behöva lägga till den mycket mindre säkra regeln "tillåt paket till min pod från valfri IP".)
Dessutom förbättrar conntrack vanligtvis systemets prestanda (genom att minska CPU-förbrukningen och paketfördröjningen) eftersom endast det första paketet i en ström
måste gå igenom hela nätverksstacken för att avgöra vad man ska göra med den. Se inlägget"" för att se ett exempel på hur det fungerar.
Men conntrack har sina begränsningar...
Så var gick allt fel?
Conntrack-tabellen har en konfigurerbar maximal storlek, och om den blir full börjar anslutningar vanligtvis avvisas eller avbrytas. Det finns tillräckligt med ledigt utrymme i tabellen för att hantera trafiken för de flesta applikationer, och detta kommer aldrig att bli ett problem. Det finns dock några scenarier där du kanske vill överväga att använda conntrack-tabellen:
- Det mest uppenbara fallet är om din server hanterar ett extremt stort antal samtidigt aktiva anslutningar. Till exempel, om din conntrack-tabell är konfigurerad för 128k poster, men du har >128k samtidiga anslutningar, kommer du säkert att stöta på ett problem!
- Ett lite mindre uppenbart fall: om din server bearbetar ett mycket stort antal anslutningar per sekund. Även om anslutningarna är kortlivade, fortsätter de att övervakas av Linux under en viss tid (120s som standard). Till exempel, om din conntrack-tabell är konfigurerad för 128k-poster och du försöker hantera 1100 anslutningar per sekund, kommer de att överskrida storleken på conntrack-tabellen även om anslutningarna är mycket kortlivade (128k/120s = 1092 anslutningar/s) ).
Det finns flera nischtyper av appar som faller inom dessa kategorier. Dessutom, om du har många dåliga skådespelare, kan det användas som en del av en DOS-attack (denial of service) att fylla din servers conntrack-tabell med massor av halvöppna anslutningar. I båda fallen kan conntrack bli en begränsande flaskhals i ditt system. I vissa fall kan det räcka med att justera conntrack-tabellparametrarna för att möta dina behov - genom att öka storleken eller minska tidsgränserna för conntrack (men om du gör det fel kommer du att stöta på en hel del problem). I andra fall kommer det att vara nödvändigt att kringgå förbindelsen för aggressiv trafik.
Verkligt exempel
Låt oss ge ett specifikt exempel: en stor SaaS-leverantör som vi arbetade med hade ett antal memcachade servrar på värdar (inte virtuella maskiner), som var och en behandlade 50K+ korttidsanslutningar per sekund.
De experimenterade med conntrack-konfigurationen, ökade tabellstorlekar och minskade spårningstiden, men konfigurationen var opålitlig, RAM-förbrukningen ökade avsevärt, vilket var ett problem (i storleksordningen GByte!), och anslutningarna var så korta att conntrack inte gjorde det. skapa sin vanliga prestandafördel (minskad CPU-förbrukning eller paketfördröjning).
De vände sig till Calico som ett alternativ. Calico-nätverkspolicyer tillåter dig att inte använda conntrack för vissa typer av trafik (med hjälp av policyalternativet doNotTrack). Detta gav dem den prestandanivå de behövde, plus den extra säkerhetsnivån från Calico.
Vilka längder måste du gå för att kringgå förbindelsen?
- Nätverkspolicyer för spåra ej bör i allmänhet vara symmetriska. I fallet med SaaS-leverantören: deras applikationer körde inom den skyddade zonen och därför kunde de, med hjälp av nätverkspolicy, vitlista trafik från andra specifika applikationer som fick åtkomst till memcached.
- Spåra inte-policyn tar inte hänsyn till riktningen för anslutningen. Således, om den memcachade servern är hackad, kan du teoretiskt försöka ansluta till någon av de memcachade klienterna, så länge den använder rätt källport. Men om du har definierat nätverkspolicyn korrekt för dina memcachade klienter, kommer dessa anslutningsförsök fortfarande att avvisas på klientsidan.
- Don-track-policyn tillämpas på varje paket, till skillnad från normala policyer, som endast tillämpas på det första paketet i ett flöde. Detta kan öka CPU-förbrukningen per paket eftersom policyn måste tillämpas för varje paket. Men för kortlivade anslutningar balanseras denna kostnad av minskningen av resursförbrukningen för anslutningsbearbetning. Till exempel, i fallet med en SaaS-leverantör, var antalet paket för varje anslutning mycket litet, så den extra CPU-förbrukningen när policyer tillämpades på varje paket var motiverad.
Låt oss börja testa
Vi körde testet på en enda pod med en memcachad server och flera memcachade klientpoddar som kördes på fjärrnoder så att vi kunde köra ett mycket stort antal anslutningar per sekund. Servern med den memcachade serverpodden hade 8 kärnor och 512k poster i conntrack-tabellen (den standardkonfigurerade tabellstorleken för värden).
Vi mätte prestandaskillnaden mellan: ingen nätverkspolicy; med regelbunden Calico-policy; och Calico spårar inte policy.
För det första testet satte vi antalet anslutningar till 4.000 20 per sekund, så vi kunde fokusera på skillnaden i CPU-förbrukning. Det fanns inga signifikanta skillnader mellan ingen policy och vanlig policy, men spåra inte ökad CPU-förbrukning med cirka XNUMX %:
I det andra testet lanserade vi så många anslutningar som våra klienter kunde generera och mätte det maximala antalet anslutningar per sekund som vår memcachade server kunde hantera. Som väntat nådde fallen "ingen policy" och "vanlig policy" båda gränsen för anslutning på över 4,000 512 anslutningar per sekund (120k / 4,369s = 60,000 XNUMX anslutningar/s). Med en inte-spår-policy skickade våra kunder XNUMX XNUMX anslutningar per sekund utan problem. Vi är säkra på att vi skulle kunna öka detta antal genom att lägga till fler kunder, men vi anser att dessa siffror redan är tillräckligt för att illustrera poängen med den här artikeln!
Slutsats
Conntrack är en viktig kärnfunktion. Han gör sitt jobb perfekt. Det används ofta av viktiga systemkomponenter. Men i vissa specifika scenarier uppväger trängseln på grund av conntrack de normala fördelarna det ger. I det här scenariot kan Calico nätverkspolicyer användas för att selektivt inaktivera användningen av conntrack samtidigt som nätverkssäkerheten ökar. För all annan trafik fortsätter conntrack att vara din vän!
Läs även andra artiklar på vår blogg:
Källa: will.com