🥇Quando Linux conntrack non è più un amico

Il tracciamento delle connessioni ("conntrack") è una funzione fondamentale dello stack di rete del kernel Linux. Consente al kernel di monitorare tutte le connessioni di rete logiche o i flussi e, in tal modo, identificare tutti i pacchetti che compongono ciascun flusso, in modo da poterli elaborare insieme in modo sequenziale.

Conntrack è una funzione cruciale del kernel, utilizzata in alcune situazioni chiave:

NAT si basa sulle informazioni fornite da conntrack, in modo da poter gestire in modo uniforme tutti i pacchetti di un singolo flusso. Ad esempio, quando un pod accede a un servizio Kubernetes, il bilanciatore di carico kube-proxy utilizza NAT per reindirizzare il traffico a un pod specifico all'interno del cluster. Conntrack registra che per una determinata connessione tutti i pacchetti diretti all'IP del servizio devono essere inviati allo stesso pod e che i pacchetti restituiti dal pod di backend devono essere reindirizzati tramite NAT di nuovo al pod da cui è arrivata la richiesta.
I firewall con tracciamento dello stato, come Calico, si basano su informazioni fornite da conntrack per aggiungere il traffico di risposta all'elenco bianco. Questo consente di scrivere una politica di rete che afferma: «permetti al mio pod di connettersi a qualsiasi indirizzo IP remoto» senza necessità di scrivere una politica per autorizzare esplicitamente il traffico di risposta. (Senza questo, sarebbe necessario aggiungere una regola molto meno sicura, come «permetti i pacchetti al mio pod da qualsiasi IP».)

Inoltre, conntrack generalmente migliora le prestazioni del sistema (riducendo l'uso della CPU e i tempi di latenza dei pacchetti), poiché solo il primo pacchetto in un flusso
deve passare attraverso l'intero stack di rete per determinare cosa fare. Vedi il post «Confronto dei modi kube-proxy», per un esempio di come funziona.

Tuttavia, conntrack ha le sue limitazioni...

Quindi, dove è andato tutto storto?

La tabella conntrack ha una dimensione massima configurabile e, se si riempie, le connessioni tendono a essere rifiutate o interrotte. Per gestire il traffico della maggior parte delle applicazioni, la tabella di solito ha spazio libero sufficiente e questo non diventa mai un problema. Tuttavia, ci sono alcuni scenari da considerare per l'uso della tabella conntrack:

Il caso più ovvio è se il tuo server gestisce un numero estremamente elevato di connessioni attive contemporaneamente. Ad esempio, se la tua tabella conntrack è impostata su 128k record, ma hai più di 128k connessioni simultanee, sicuramente avrai problemi!
Un caso meno ovvio: se il tuo server gestisce un numero molto elevato di connessioni al secondo. Anche se le connessioni sono brevi, continuano a essere tracciate da Linux per un certo periodo di tempo (di default 120 secondi). Ad esempio, se la tua tabella conntrack è impostata su 128.000 record e stai cercando di gestire 1100 connessioni al secondo, queste supereranno la dimensione della tabella conntrack, anche se le connessioni sono molto brevi (128k / 120s = 1092 connessioni / s).

Ci sono diversi tipi di applicazioni di nicchia che rientrano in queste categorie. Inoltre, se hai molti ostili, il riempimento della tabella conntrack del tuo server con numerosi collegamenti semi-aperti può essere utilizzato come parte di un attacco di tipo 'negazione di servizio' (DOS). In entrambi i casi, conntrack può diventare un collo di bottiglia nel tuo sistema. In alcune situazioni, la configurazione dei parametri della tabella conntrack potrebbe essere sufficiente per soddisfare le tue esigenze, aumentando la dimensione o riducendo i timeout di conntrack (ma se lo fai in modo errato, potresti incontrare grandi difficoltà). Per altri casi, sarà necessario bypassare conntrack per il traffico aggressivo.

Un esempio concreto

Prendiamo ad esempio un grande fornitore di SaaS con cui abbiamo lavorato, che aveva una serie di server memcached su host (non su macchine virtuali), ognuno dei quali gestiva oltre 50K connessioni temporanee al secondo.

Hanno sperimentato con la configurazione di conntrack, aumentando le dimensioni delle tabelle e riducendo il tempo di tracciamento, ma la configurazione è risultata instabile, con un consumo di RAM notevolmente aumentato, il che è diventato un problema (nell'ordine dei GB!), e le connessioni erano così brevi che conntrack non forniva il solito guadagno in prestazioni (riduzione del consumo della CPU o delle latenze nei pacchetti).

Come alternativa, si sono rivolti a Calico. Le politiche di rete di Calico permettono di non utilizzare conntrack per determinati tipi di traffico (utilizzando l'opzione doNotTrack per le politiche). Questo ha fornito loro il livello di prestazioni necessario più un ulteriore livello di sicurezza offerto da Calico.

A cosa si deve rinunciare per evitare conntrack?

Le politiche di rete do-not-track devono generalmente essere simmetriche. Nel caso di un provider SaaS: le loro applicazioni operavano all'interno di una zona protetta e quindi, tramite la politica di rete, potevano inserire nella lista bianca il traffico proveniente da altre applicazioni specifiche, a cui era consentito l'accesso a memcached.
La politica do-not-track non tiene conto della direzione della connessione. Così, in caso di violazione del server memcached, si potrebbe teoricamente tentare di connettersi a uno qualsiasi dei client memcached, se utilizza la porta sorgente corretta. Tuttavia, se hai configurato correttamente la politica di rete per i tuoi client memcached, questi tentativi di connessione verranno comunque rifiutati dal lato client.
La politica do-not-track si applica a ciascun pacchetto, a differenza delle politiche normali, che si applicano solo al primo pacchetto del flusso. Questo può aumentare il consumo delle risorse CPU per un singolo pacchetto, poiché è necessaria l'applicazione della politica per ogni pacchetto. Ma per connessioni brevi, questo costo viene bilanciato dalla riduzione del consumo di risorse nella gestione di conntrack. Per esempio, nel caso di un fornitore SaaS, il numero di pacchetti per ogni connessione era molto ridotto, perciò l'ulteriore costo delle risorse CPU per applicare le politiche a ogni pacchetto era giustificato.

Iniziamo i test

Abbiamo condotto un test su un pod con un server memcached e diversi pod client memcached in esecuzione su nodi remoti, in modo da poter gestire un enorme numero di connessioni al secondo. Il server con il pod del server memcached aveva 8 core e 512k voci nella tabella conntrack (dimensione della tabella configurata standard per l'host).
Abbiamo misurato la differenza di prestazioni tra: senza politiche di rete; con una politica Calico standard; e la politica Calico do-not-track.

Per il primo test abbiamo impostato il numero di connessioni a 4.000 al secondo, in modo da poterci concentrare sulla differenza nel consumo della CPU. Non ci sono state differenze significative tra l'assenza di una politica e la politica standard, ma la do-not-track ha aumentato il consumo della CPU di circa il 20%:

Nel secondo test, abbiamo avviato il numero massimo di connessioni che i nostri clienti potevano generare e abbiamo misurato il numero massimo di connessioni al secondo che il nostro server memcached poteva gestire. Come previsto, nel caso della 'senza politiche' e della 'politica ordinaria', entrambi hanno raggiunto il limite di conntrack di oltre 4.000 connessioni al secondo (512k / 120s = 4.369 connessioni/s). Con la politica do-not-track, i nostri clienti hanno inviato 60.000 connessioni al secondo senza alcun problema. Siamo certi che avremmo potuto aumentare questo numero collegando un maggior numero di clienti, ma riteniamo che questi valori siano già sufficienti per illustrare il messaggio di questo articolo!

Conclusione

Conntrack è una funzione importante del kernel. Fa egregiamente il suo lavoro. Spesso viene utilizzato da componenti chiave del sistema. Tuttavia, in alcuni scenari specifici, il sovraccarico causato da conntrack supera i normali vantaggi che offre. In questo scenario, le politiche di rete Calico possono essere utilizzate per disattivare selettivamente l'uso di conntrack, aumentando nel contempo il livello di sicurezza della rete. Per tutto il resto del traffico, conntrack continua a essere il tuo compagno!