🥇When Linux conntrack is no longer your ally

Forbindelsessporing (“conntrack”) er en nøkkelfunksjon i nettverksstakken til Linux-kjernen. Den lar kjernen spore alle logiske nettverksforbindelser eller strømmer, og på den måten identifisere alle pakker som utgjør hver strøm, slik at de kan behandles sekvensielt sammen.

Conntrack er en viktig funksjon i kjernen som brukes i flere grunnleggende tilfeller:

NAT er avhengig av informasjon fra conntrack, slik at den kan behandle alle pakker fra én strøm likt. For eksempel, når en pod henvender seg til en Kubernetes-tjeneste, bruker kube-proxy lastbalanserer NAT for å lede trafikken til en spesifikk pod inne i klyngen. Conntrack registrerer at for en bestemt forbindelse skal alle pakker til IP-tjenesten sendes til den samme poden, og at pakkene som returneres av backend-pod’en, skal NAT lede tilbake til pod’en som sendte forespørselen.
Brannmurer med tilstandssporing, som Calico, er avhengige av informasjon fra conntrack for å legge til "tilbakestrøm"-trafikk på hvitelisten. Dette lar deg skrive en nettverkspolitikk som sier: "tillate min pod å koble til hvilken som helst ekstern IP-adresse" uten å måtte skrive en politikk for eksplisitt å tillate tilbakestrømmet trafikk. (Uten dette måtte du legge til en langt mindre sikker regel for å "tillate pakker inn i min pod fra hvilken som helst IP").

I tillegg øker conntrack vanligvis systemytelsen (reduserer prosessorbruken og forsinkelsen i pakker), siden kun den første pakken i strømmen
må gjennomgå full behandling av nettverksstakken for å bestemme hva som skal gjøres med den. Se innlegget "Sammenligning av kube-proxy-moduser", for å se et eksempel på hvordan dette fungerer.

Likevel har conntrack sine begrensninger…

Så, hvor gikk alt galt?

Conntrack-tabellen har en konfigurerbar maksimal størrelse, og hvis den fylles opp, begynner forbindelsene vanligvis å bli avvist eller avbrutt. For å håndtere trafikken til de fleste applikasjoner er det som regel tilstrekkelig ledig plass i tabellen, og dette vil sjelden bli et problem. Likevel er det flere scenarier der det kan være lurt å vurdere bruken av conntrack-tabellen:

Det mest åpenbare tilfellet er hvis serveren din håndterer et ekstremt stort antall samtidig aktive tilkoblinger. For eksempel, hvis conntrack-tabellen din er konfigurert til 128 000 poster, men du har > 128 000 samtidige tilkoblinger, vil du garantert støte på problemer!
Et litt mindre åpenbart tilfelle er hvis serveren din behandler et svært stort antall tilkoblinger per sekund. Selv om tilkoblingene er kortvarige, fortsetter Linux å spore dem i en viss periode (som standard 120 sekunder). For eksempel, hvis conntrack-tabellen din er konfigurert til 128 000 poster og du prøver å håndtere 1100 tilkoblinger per sekund, vil de overskride størrelsen på conntrack-tabellen, selv om tilkoblingene er veldig kortvarige (128k / 120s = 1092 tilkoblinger / s).

Det finnes noen nisjetyper applikasjoner som faller inn under disse kategoriene. I tillegg, hvis du har mange fiender, kan fylling av conntrack-tabellen på serveren din med mange halvåpne tilkoblinger brukes som en del av en «denial of service» (DOS) angrep. I begge tilfeller kan conntrack bli en begrensende flaskehals i systemet ditt. I noen tilfeller kan justering av conntrack-tabellens innstillinger være tilstrekkelig for å møte behovene dine — ved å øke størrelsen eller redusere conntrack-tidsavbruddene (men hvis du gjør dette feil, vil du stå overfor store problemer). For andre tilfeller vil det være nødvendig å omgå conntrack for aggressiv trafikk.

Et ekte eksempel

La oss gi et konkret eksempel: en stor SaaS-leverandør vi jobbet med hadde en rekke memcached-servere på verter (ikke virtuelle maskiner), hver av dem håndterte 50K+ kortvarige tilkoblinger per sekund.

De eksperimenterte med conntrack-konfigurasjonen, økte størrelsen på tabellene og reduserte sporingsvarigheten, men konfigurasjonen var ustabil, og minnebruken økte betydelig, noe som var et problem (flere GB!), og tilkoblingene var så korte at conntrack ikke oppnådde sin vanlige gevinsten i ytelse (reduksjon i CPU-forbruk eller pakketid).

Som alternativ vendte de seg til Calico. Nettverksreglene til Calico lar dem unngå å bruke conntrack for bestemte typer trafikk (ved å bruke opsjonen doNotTrack for reglene). Dette ga dem det nødvendige ytelsesnivået pluss et ekstra nivå av sikkerhet levert av Calico.

Hva må man gjøre for å unngå conntrack?

Nettverksreglene for do-not-track bør som regel være symmetriske. I tilfelle av en SaaS-leverandør: deres applikasjoner var operert innen et beskyttet område og dermed kunne de via nettverksreglene liste opp trafikk fra spesifikke applikasjoner som fikk tilgang til memcached.
Regelen om do-not-track tar ikke hensyn til retningen av forbindelsen. Dermed, i tilfelle et angrep på memcached-serveren, kan det teoretisk forsøkes å koble seg til hvilken som helst av memcached-klientene hvis den bruker riktig kildeport. Men, hvis du har definert nettverksreglene for dine memcached-klienter korrekt, vil disse tilkoblingsforsøkene fortsatt bli avvist på klientsiden.
Regelen om do-not-track anvendes på hver pakke, i motsetning til vanlige regler som kun anvendes på den første pakken i en strøm. Dette kan øke CPU-ressursbruken per pakke, siden regelen må anvendes for hver pakke. Men for kortvarige forbindelser balanseres denne kostnaden av en reduksjon i ressursbruken til behandling av conntrack. For eksempel, i tilfelle av en SaaS-leverandør, var antallet pakker for hver forbindelse svært lite, så det ekstra ressursforbruket til CPU ved å anvende regler på hver pakke var berettiget.

La oss begynne testene

Vi gjennomførte en test på en pod med en memcached-server og mange memcached-klient-podder, som kjørte på eksterne noder, slik at vi kunne kjøre et veldig stort antall forbindelser per sekund. Serveren med memcached-server-podden hadde 8 kjerner og 512k oppføringer i conntrack-tabellen (standardinnstilt størrelse på tabellen for verten).
Vi målte ytelsesforskjellen mellom: uten nettverksregler; med vanlig Calico-regel; og Calico do-not-track-regel.

For the first test, we set the number of connections to 4,000 per second, allowing us to focus on the difference in CPU consumption. There were no significant differences between having no policy and a regular policy, but the do-not-track policy increased CPU consumption by about 20%:

In the second test, we launched as many connections as our clients could generate and measured the maximum number of connections per second that our memcached server could handle. As expected, under both 'no policies' and 'regular policy', both reached the conntrack limit of over 4,000 connections per second (512k / 120s = 4,369 connections/s). With the do-not-track policy, our clients sent 60,000 connections per second without any issues. We are confident that we could increase this number by connecting more clients, but we feel that these figures are already sufficient to illustrate the point of this article!

Konklusjon

Conntrack is an important kernel feature. It works exceptionally well. Often, it is utilized by key system components. However, in certain scenarios, the overhead from conntrack outweighs the usual benefits it provides. In this scenario, Calico network policies can be used to selectively disable conntrack usage while enhancing network security. For all other traffic, conntrack continues to be your ally!