Tilkoblingssporing ("conntrack") er en kjernefunksjon i Linux-kjernens nettverksstabel. Den lar kjernen holde styr på alle logiske nettverksforbindelser eller flyter og dermed identifisere alle pakkene som utgjør hver flyt slik at de kan behandles sammen sekvensielt.
Conntrack er en viktig kjernefunksjon som brukes i noen grunnleggende tilfeller:
- NAT er avhengig av informasjon fra conntrack slik at den kan behandle alle pakker fra samme strøm likt. For eksempel, når en pod får tilgang til en Kubernetes-tjeneste, bruker kube-proxy-lastbalanseren NAT for å dirigere trafikk til en bestemt pod i klyngen. Conntrack registrerer at for en gitt tilkobling må alle pakker til IP-tjenesten sendes til samme pod, og at pakker som returneres av backend-poden må NATeres tilbake til poden som forespørselen kom fra.
- Stateful brannmurer som Calico er avhengige av informasjon fra connecttrack til hviteliste "respons" trafikk. Dette lar deg skrive en nettverkspolicy som sier "tillat min pod å koble til en hvilken som helst ekstern IP-adresse" uten å måtte skrive en policy for å eksplisitt tillate responstrafikk. (Uten dette ville du måtte legge til den mye mindre sikre "tillat pakker til min pod fra hvilken som helst IP"-regel.)
I tillegg forbedrer conntrack vanligvis systemytelsen (ved å redusere CPU-forbruk og pakkeforsinkelse) siden bare den første pakken i en strøm
må gå gjennom hele nettverksstabelen for å finne ut hva du skal gjøre med den. Se innlegget "" for å se et eksempel på hvordan det fungerer.
Conntrack har imidlertid sine begrensninger...
Så hvor gikk det galt?
Conntrack-tabellen har en konfigurerbar maksimal størrelse, og hvis den blir full, begynner vanligvis tilkoblinger å bli avvist eller droppet. Det er nok ledig plass i tabellen til å håndtere trafikken til de fleste applikasjoner, og dette vil aldri bli et problem. Det er imidlertid noen scenarier der du kanskje vil vurdere å bruke conntrack-tabellen:
- Det mest åpenbare tilfellet er hvis serveren din håndterer et ekstremt stort antall samtidige aktive tilkoblinger. For eksempel, hvis conntrack-tabellen din er konfigurert for 128k oppføringer, men du har >128k samtidige tilkoblinger, vil du sikkert støte på et problem!
- Et litt mindre åpenbart tilfelle: hvis serveren din behandler et veldig stort antall tilkoblinger per sekund. Selv om forbindelsene er kortvarige, fortsetter de å bli overvåket av Linux i en periode (120s som standard). For eksempel, hvis conntrack-tabellen er konfigurert for 128k oppføringer og du prøver å håndtere 1100 tilkoblinger per sekund, vil de overskride størrelsen på conntrack-tabellen, selv om tilkoblingene er svært kortvarige (128k/120s = 1092 tilkoblinger/ s).
Det er flere nisjetyper av apper som faller inn i disse kategoriene. I tillegg, hvis du har mange dårlige skuespillere, kan det å fylle serverens conntrack-tabell med mange halvåpne tilkoblinger brukes som en del av et tjenestenektangrep (DOS). I begge tilfeller kan conntrack bli en begrensende flaskehals i systemet ditt. I noen tilfeller kan justering av conntrack-tabellparameterne være nok til å møte dine behov - ved å øke størrelsen eller redusere conntrack-tidsavbruddene (men hvis du gjør det feil, vil du få mye problemer). For andre tilfeller vil det være nødvendig å omgå tilkoblingsspor for aggressiv trafikk.
Virkelig eksempel
La oss gi et spesifikt eksempel: en stor SaaS-leverandør vi jobbet med hadde en rekke minnebufrede servere på verter (ikke virtuelle maskiner), som hver behandlet 50K+ kortsiktige tilkoblinger per sekund.
De eksperimenterte med conntrack-konfigurasjonen, økte tabellstørrelser og reduserte sporingstiden, men konfigurasjonen var upålitelig, RAM-forbruket økte betydelig, noe som var et problem (i størrelsesorden GBytes!), og tilkoblingene var så korte at conntrack ikke gjorde det. skape sin vanlige ytelsesfordel (redusert CPU-forbruk eller pakkeforsinkelse).
De henvendte seg til Calico som et alternativ. Calico-nettverkspolicyer lar deg ikke bruke conntrack for visse typer trafikk (ved å bruke doNotTrack-policyalternativet). Dette ga dem ytelsesnivået de trengte, pluss det ekstra sikkerhetsnivået fra Calico.
Hvilke lengder må du gå til for å omgå tilkoblingen?
- Ikke-spor nettverkspolicyer bør generelt være symmetriske. I tilfellet med SaaS-leverandøren: applikasjonene deres kjørte innenfor den beskyttede sonen, og ved hjelp av nettverkspolicy kunne de derfor hvitliste trafikk fra andre spesifikke applikasjoner som fikk tilgang til memcached.
- Ikke-spor-policyen tar ikke hensyn til retningen på forbindelsen. Dermed, hvis den memcached-serveren er hacket, kan du teoretisk prøve å koble til en av de memcached-klientene, så lenge den bruker riktig kildeport. Men hvis du har riktig definert nettverkspolicyen for dine memcachede klienter, vil disse tilkoblingsforsøkene fortsatt bli avvist på klientsiden.
- Ikke-spor-policyen brukes på hver pakke, i motsetning til vanlige retningslinjer, som bare brukes på den første pakken i en flyt. Dette kan øke CPU-forbruket per pakke fordi policyen må brukes for hver pakke. Men for kortvarige forbindelser balanseres denne utgiften av reduksjonen i ressursforbruket for koblingsprosessering. For eksempel, i tilfellet med en SaaS-leverandør, var antallet pakker for hver tilkobling svært lite, så det ekstra CPU-forbruket ved bruk av retningslinjer for hver pakke var berettiget.
La oss begynne å teste
Vi kjørte testen på en enkelt pod med en memcached server og flere memcached klient pods som kjørte på eksterne noder slik at vi kunne kjøre et veldig stort antall tilkoblinger per sekund. Serveren med den memcached server-poden hadde 8 kjerner og 512k oppføringer i conntrack-tabellen (standard konfigurert tabellstørrelse for verten).
Vi målte ytelsesforskjellen mellom: ingen nettverkspolicy; med vanlig Calico-policy; og Calico ikke-spor-policy.
For den første testen satte vi antall tilkoblinger til 4.000 per sekund, slik at vi kunne fokusere på forskjellen i CPU-forbruk. Det var ingen signifikante forskjeller mellom ingen policy og vanlig policy, men ikke-spor økt CPU-forbruk med omtrent 20 %:
I den andre testen lanserte vi så mange tilkoblinger som våre klienter kunne generere og målte det maksimale antallet tilkoblinger per sekund som vår memcached server kunne håndtere. Som forventet nådde "ingen policy" og "vanlig policy"-tilfelle begge tilkoblingsgrensen på over 4,000 tilkoblinger per sekund (512k / 120s = 4,369 tilkoblinger/s). Med en ikke-spor-policy sendte våre kunder 60,000 XNUMX tilkoblinger per sekund uten problemer. Vi er sikre på at vi kan øke dette tallet ved å legge til flere kunder, men vi føler at disse tallene allerede er nok til å illustrere poenget med denne artikkelen!
Konklusjon
Conntrack er en viktig kjernefunksjon. Han gjør jobben sin perfekt. Det brukes ofte av sentrale systemkomponenter. I noen spesifikke scenarier oppveier imidlertid overbelastningen på grunn av conntrack de normale fordelene det gir. I dette scenariet kan Calico-nettverkspolicyer brukes til å selektivt deaktivere bruken av conntrack samtidig som nettverkssikkerheten økes. For all annen trafikk, fortsetter conntrack å være din venn!
Les også andre artikler på bloggen vår:
Kilde: www.habr.com