Forbindelsessporing ("conntrack") er en kernefunktion i Linux-kernenetværksstakken. Det giver kernen mulighed for at holde styr på alle logiske netværksforbindelser eller flows og derved identificere alle de pakker, der udgør hvert flow, så de kan behandles sammen sekventielt.
Conntrack er en vigtig kernefunktion, der bruges i nogle grundlæggende tilfælde:
- NAT er afhængig af information fra conntrack, så den kan behandle alle pakker fra den samme strøm ens. For eksempel, når en pod får adgang til en Kubernetes-tjeneste, bruger kube-proxy-belastningsbalanceren NAT til at dirigere trafik til en bestemt pod i klyngen. Conntrack registrerer, at for en given forbindelse skal alle pakker til IP-tjenesten sendes til den samme pod, og at pakker, der returneres af backend-poden, skal NATeres tilbage til den pod, som anmodningen kom fra.
- Stateful firewalls såsom Calico er afhængige af information fra connecttrack til whitelist "response" trafik. Dette giver dig mulighed for at skrive en netværkspolitik, der siger "tillad min pod at oprette forbindelse til enhver ekstern IP-adresse" uden at skulle skrive en politik for eksplicit at tillade svartrafik. (Uden dette ville du skulle tilføje en meget mindre sikker "tillad pakker til min pod fra enhver IP"-regel.)
Derudover forbedrer conntrack typisk systemets ydeevne (ved at reducere CPU-forbrug og pakkeforsinkelse), da kun den første pakke i en strøm
skal gennemgå hele netværksstakken for at bestemme, hvad der skal gøres med det. Se opslaget"" for at se et eksempel på, hvordan dette fungerer.
Conntrack har dog sine begrænsninger...
Så hvor gik det hele galt?
Conntrack-tabellen har en konfigurerbar maksimal størrelse, og hvis den bliver fuld, begynder forbindelser normalt at blive afvist eller droppet. Der er nok ledig plads i tabellen til at håndtere trafikken i de fleste applikationer, og dette vil aldrig blive et problem. Der er dog et par scenarier, hvor du måske vil overveje at bruge conntrack-tabellen:
- Det mest oplagte tilfælde er, hvis din server håndterer et ekstremt stort antal samtidigt aktive forbindelser. For eksempel, hvis din conntrack-tabel er konfigureret til 128k indgange, men du har >128k samtidige forbindelser, vil du helt sikkert løbe ind i et problem!
- Et lidt mindre oplagt tilfælde: hvis din server behandler et meget stort antal forbindelser i sekundet. Selvom forbindelserne er kortvarige, bliver de ved med at blive overvåget af Linux i nogen tid (120s som standard). For eksempel, hvis din conntrack-tabel er konfigureret til 128k indgange, og du forsøger at håndtere 1100 forbindelser i sekundet, vil de overstige størrelsen af conntrack-tabellen, selvom forbindelserne er meget kortvarige (128k/120s = 1092 forbindelser/ s).
Der er flere nichetyper af apps, der falder ind under disse kategorier. Derudover, hvis du har mange dårlige skuespillere, kan udfyldning af din servers conntrack-tabel med masser af halvåbne forbindelser bruges som en del af et lammelsesangreb (DOS). I begge tilfælde kan conntrack blive en begrænsende flaskehals i dit system. I nogle tilfælde kan justering af conntrack-tabellens parametre være nok til at opfylde dine behov - ved at øge størrelsen eller reducere conntrack-timeouts (men hvis du gør det forkert, vil du løbe ind i en masse problemer). I andre tilfælde vil det være nødvendigt at omgå forbindelsen for aggressiv trafik.
Rigtigt eksempel
Lad os give et specifikt eksempel: En stor SaaS-udbyder, vi arbejdede med, havde et antal memcachede servere på værter (ikke virtuelle maskiner), som hver behandlede 50K+ kortsigtede forbindelser i sekundet.
De eksperimenterede med conntrack-konfigurationen, øgede bordstørrelser og reducerede sporingstid, men konfigurationen var upålidelig, RAM-forbruget steg markant, hvilket var et problem (i størrelsesordenen GBytes!), og forbindelserne var så korte, at conntrack ikke gjorde det. skabe sin sædvanlige ydeevnefordel (reduceret CPU-forbrug eller pakkeforsinkelse).
De henvendte sig til Calico som et alternativ. Calico-netværkspolitikker tillader dig ikke at bruge conntrack til visse typer trafik (ved at bruge doNotTrack-politikindstillingen). Dette gav dem det præstationsniveau, de havde brug for, plus det ekstra sikkerhedsniveau leveret af Calico.
Hvilke længder skal du gå til for at omgå forbindelsen?
- Ikke-spor-netværkspolitikker bør generelt være symmetriske. I tilfældet med SaaS-udbyderen: deres applikationer kørte inde i den beskyttede zone, og derfor kunne de ved hjælp af netværkspolitik hvidliste trafik fra andre specifikke applikationer, som fik adgang til memcached.
- Ikke-spor-politikken tager ikke højde for forbindelsens retning. Så hvis den memcachede server er hacket, kan du teoretisk prøve at oprette forbindelse til enhver af de memcachede klienter, så længe den bruger den korrekte kildeport. Men hvis du har defineret netværkspolitikken korrekt for dine memcached klienter, vil disse forbindelsesforsøg stadig blive afvist på klientsiden.
- Ikke-spor-politikken anvendes på hver pakke, i modsætning til normale politikker, som kun anvendes på den første pakke i et flow. Dette kan øge CPU-forbruget pr. pakke, fordi politikken skal anvendes for hver pakke. Men for kortlivede forbindelser opvejes denne udgift af reduktionen i ressourceforbruget til forbindelsesbehandling. For eksempel i tilfældet med en SaaS-udbyder var antallet af pakker for hver forbindelse meget lille, så det ekstra CPU-forbrug ved anvendelse af politikker på hver pakke var berettiget.
Lad os begynde at teste
Vi kørte testen på en enkelt pod med en memcached server og flere memcached klient pods, der kørte på eksterne noder, så vi kunne køre et meget stort antal forbindelser pr. sekund. Serveren med den memcachede serverpod havde 8 kerner og 512k indgange i conntrack-tabellen (den standardkonfigurerede tabelstørrelse for værten).
Vi målte ydeevneforskellen mellem: ingen netværkspolitik; med almindelig Calico-politik; og Calico ikke-sporer politik.
Til den første test satte vi antallet af forbindelser til 4.000 i sekundet, så vi kunne fokusere på forskellen i CPU-forbrug. Der var ingen signifikante forskelle mellem ingen politik og almindelig politik, men ikke-spor øget CPU-forbrug med omkring 20 %:
I den anden test lancerede vi så mange forbindelser, som vores klienter kunne generere, og målte det maksimale antal forbindelser pr. sekund, som vores memcached-server kunne håndtere. Som forventet nåede både "ingen politik" og "almindelig politik"-tilfældet grænsen på over 4,000 forbindelser pr. sekund (512k / 120s = 4,369 forbindelser/s). Med en ikke-spor-politik sendte vores kunder 60,000 forbindelser i sekundet uden problemer. Vi er sikre på, at vi kunne øge dette antal ved at tilføje flere kunder, men vi føler, at disse tal allerede er nok til at illustrere pointen med denne artikel!
Konklusion
Conntrack er en vigtig kernefunktion. Han gør sit arbejde perfekt. Det bruges ofte af vigtige systemkomponenter. Men i nogle specifikke scenarier opvejer overbelastningen på grund af conntrack de normale fordele, det giver. I dette scenarie kan Calico-netværkspolitikker bruges til selektivt at deaktivere brugen af conntrack og samtidig øge netværkssikkerheden. For al anden trafik er conntrack fortsat din ven!
Læs også andre artikler på vores blog:
Kilde: www.habr.com