Ăvervakning av anslutningar ("conntrack") Ă€r en grundlĂ€ggande funktion i Linux kĂ€rnans nĂ€tverksstack. Det gör att kĂ€rnan kan spĂ„ra alla logiska nĂ€tverksanslutningar eller flöden och dĂ€rmed identifiera alla paket som utgör varje flöde, sĂ„ att de kan bearbetas sequentialt tillsammans.
Conntrack Àr en viktig kÀrnfunktion som anvÀnds i vissa centrala fall:
- NAT Àr beroende av information frÄn conntrack, sÄ att det kan hantera alla paket frÄn ett flöde pÄ samma sÀtt. Till exempel, nÀr en pod anropar en Kubernetes-tjÀnst, anvÀnder lastbalanseraren kube-proxy NAT för att styra trafiken till en specifik pod inom klustret. Conntrack registrerar att för en viss anslutning ska alla paket till tjÀnstens IP skickas till samma pod, och att paket som returneras frÄn backend-poden ska styras av NAT tillbaka till den pod som begÀrde.
- BrandvÀggar med tillstÄndsövervakning, sÄsom Calico, förlitar sig pÄ information frÄn conntrack för att lÀgga till "svars"-trafik i vitlistan. Detta tillÄter dig att skriva en nÀtverkspolicy som sÀger: "tillÄt min pod att ansluta till vilken fjÀrr-IP som helst" utan att behöva skriva en policy för att uttryckligen tillÄta svarstrafik. (Utan detta skulle du behöva lÀgga till en mycket mindre sÀker regel som "tillÄt paket till min pod frÄn vilken IP som helst.")
Dessutom ökar conntrack vanligtvis systemets prestanda (genom att minska processoranvÀndning och paketfördröjning), eftersom endast det första paketet i flödet
mÄste genomgÄ den fullstÀndiga behandlingen i nÀtverksstacken för att avgöra vad som ska göras med det. Se inlÀgget "" för att se ett exempel pÄ hur detta fungerar.
Men conntrack har sina begrÀnsningar...
SĂ„, var gick allt fel?
Conntrack-tabellen har en anpassningsbar maximal storlek, och om den fylls upp börjar normalt anslutningar att avvisas eller avbrytas. För att hantera trafiken för de flesta applikationer finns det vanligtvis tillrÀckligt med ledigt utrymme i tabellen, och detta blir aldrig ett problem. Men det finns nÄgra scenarier dÀr det kan vara vÀrt att övervÀga att anvÀnda conntrack-tabellen:
- Det mest uppenbara fallet Àr om din server hanterar ett extremt stort antal samtidiga aktiva anslutningar. Om din conntrack-tabell Àr instÀlld pÄ 128k poster, men du har > 128k samtidiga anslutningar, kommer du sannolikt att stöta pÄ problem!
- Ett nĂ„got mindre uppenbart fall: om din server hanterar ett mycket stort antal anslutningar per sekund. Ăven om anslutningarna Ă€r kortvariga, fortsĂ€tter de att spĂ„ras av Linux under en viss tidsperiod (som standard 120s). Till exempel, om din conntrack-tabell Ă€r instĂ€lld pĂ„ 128 000 poster och du försöker hantera 1100 anslutningar per sekund, kommer de att överskrida storleken pĂ„ conntrack-tabellen, Ă€ven om anslutningarna Ă€r mycket kortvariga (128k / 120s = 1092 anslutningar / s).
Det finns flera nischtyper av applikationer som faller inom dessa kategorier. Dessutom, om du har mĂ„nga illvilliga aktörer, kan fyllningen av din servers conntrack-tabell med mĂ„nga halvöppna anslutningar anvĂ€ndas som en del av en denial of service-attack (DOS). I bĂ„da fallen kan conntrack bli en begrĂ€nsande flaskhals i ditt system. I vissa fall kan justering av instĂ€llningarna för conntrack-tabellen vara tillrĂ€ckligt för att möta dina behov â genom att öka storleken eller minska tidsgrĂ€nserna för conntrack (men om du gör detta fel, kan du stöta pĂ„ stora problem). För andra fall kan det bli nödvĂ€ndigt att kringgĂ„ conntrack för aggressiv trafik.
Ett verkligt exempel
LÄt oss ta ett konkret exempel: en stor SaaS-leverantör som vi arbetade med hade ett antal memcached-servrar pÄ vÀrdar (inte virtuella maskiner), dÀr varje server hanterade över 50 000 kortvariga anslutningar per sekund.
De experimenterade med konfigurationen av conntrack, ökade storlekarna pÄ tabellerna och minskade spÄrningstiderna, men konfigurationen var opÄlitlig, minskade RAM-anvÀndningen avsevÀrt, vilket var ett problem (nÄgra GB!), och anslutningarna var sÄ korta att conntrack inte skapade sin vanliga prestandavinst (minskad CPU-anvÀndning eller paketförseningar).
Som ett alternativ kontaktade de Calico. Calicos nÀtverkspolicyer möjliggör att conntrack inte anvÀnds för viss typ av trafik (genom att anvÀnda alternativet doNotTrack för policyn). Detta gav dem den nödvÀndiga prestandanivÄn plus ytterligare en sÀkerhetsnivÄ tillhandahÄllen av Calico.
Vad mÄste göras för att kringgÄ conntrack?
- NÀtverkspolicyerna do-not-track bör generellt sett vara symmetriska. För en SaaS-leverantör: deras applikationer kördes inom en skyddad zon och dÀrför kunde de, med hjÀlp av nÀtverkspolicyn, vitlista trafik frÄn andra specifika applikationer som fick Ätkomst till memcached.
- Do-not-track policyn tar inte hÀnsyn till riktning av anslutningen. DÀrför, i hÀndelse av en hackning av memcached-servern, kan man teoretiskt försöka ansluta till vilken av memcached-klienterna som helst, om den anvÀnder rÀtt kÀllport. Men om du korrekt har definierat nÀtverkspolicyn för dina memcached-klienter, kommer dessa anslutningsförsök ÀndÄ att avvisas vid klientens sida.
- Do-not-track policyn tillÀmpas pÄ varje paket, till skillnad frÄn vanliga policyer som endast tillÀmpas pÄ det första paketet i strömmen. Detta kan öka CPU-resursförbrukningen per paket, eftersom policyn mÄste tillÀmpas pÄ varje paket. Men för kortvariga anslutningar balanseras denna förbrukning av den minskade resursanvÀndningen för att behandla conntrack. Som exempel, för en SaaS-leverantör var antalet paket för varje anslutning mycket litet, sÄ den extra CPU-resursförbrukningen nÀr man tillÀmpade policyer pÄ varje paket var motiverad.
LÄt oss börja med testerna
Vi genomförde ett test pÄ en pod med en memcached-server och flera poddar av memcached-klienter som kördes pÄ fjÀrrnoder, sÄ att vi kunde generera ett mycket stort antal anslutningar per sekund. Servern med memcached-podden hade 8 kÀrnor och 512k poster i conntrack-tabellen (standardinstÀllt storlek pÄ tabellen för vÀrden).
Vi mÀtte prestandaskillnaden mellan: utan nÀtverkspolicy; med vanlig Calico-policy; och Calico do-not-track-policy.
För det första testet stÀllde vi in antalet anslutningar till 4 000 per sekund, sÄ vi kunde fokusera pÄ skillnaden i CPU-förbrukning. HÀr fanns det inga betydande skillnader mellan avsaknaden av policy och vanlig policy, men do-not-track ökade CPU-förbrukningen med cirka 20%:
I det andra testet körde vi sÄ mÄnga anslutningar som vÄra klienter kunde generera och mÀtte det maximala antalet anslutningar per sekund som vÄr memcached-server kunde hantera. Som förvÀntat nÄdde bÄde 'utan policy' och 'vanlig policy' grÀnsen för conntrack med mer Àn 4 000 anslutningar per sekund (512k / 120s = 4 369 anslutningar/s). Med do-not-track-policy skickade vÄra klienter 60 000 anslutningar per sekund utan nÄgra problem. Vi Àr övertygade om att vi skulle kunna öka detta antal genom att ansluta fler klienter, men vi kÀnner att dessa siffror redan Àr tillrÀckliga för att illustrera budskapet i denna artikel!
Slutsats
Conntrack Àr en viktig kÀrnfunktion. Den gör sitt jobb utmÀrkt. Ofta anvÀnds den av systemets nyckelkomponenter. Men i vissa specifika scenarier kan överbelastningen frÄn conntrack övervÀga de vanliga fördelar som den ger. I detta scenario kan Calico-nÀtverkspolicyer anvÀndas för att selektivt stÀnga av 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 i vÄr blogg:
KĂ€lla: habr.com
