Il tracciamento della connessione ("conntrack") è una caratteristica fondamentale dello stack di rete del kernel Linux. Consente al kernel di tenere traccia di tutte le connessioni o flussi di rete logici e quindi di identificare tutti i pacchetti che compongono ciascun flusso in modo che possano essere elaborati insieme in sequenza.
Conntrack è un'importante funzionalità del kernel utilizzata in alcuni casi di base:
- NAT si basa sulle informazioni provenienti da conntrack in modo da poter trattare allo stesso modo tutti i pacchetti provenienti dallo stesso flusso. Ad esempio, quando un pod accede a un servizio Kubernetes, il sistema di bilanciamento del carico kube-proxy utilizza NAT per indirizzare il traffico a un pod specifico all'interno del cluster. Conntrack registra che per una determinata connessione, tutti i pacchetti al servizio IP devono essere inviati allo stesso pod e che i pacchetti restituiti dal pod backend devono essere rinviati tramite NAT al pod da cui proviene la richiesta.
- I firewall stateful come Calico si basano sulle informazioni provenienti da connecttrack per inserire nella whitelist il traffico di “risposta”. Ciò ti consente di scrivere una policy di rete che dice "consenti al mio pod di connettersi a qualsiasi indirizzo IP remoto" senza dover scrivere una policy per consentire esplicitamente il traffico di risposta. (Senza questo, dovresti aggiungere la regola molto meno sicura "consenti pacchetti al mio pod da qualsiasi IP".)
Inoltre, conntrack in genere migliora le prestazioni del sistema (riducendo il consumo della CPU e la latenza dei pacchetti) poiché solo il primo pacchetto in un flusso
deve esaminare l'intero stack di rete per determinare cosa farne. Vedi il post"" per vedere un esempio di come funziona.
Tuttavia, Conntrack ha i suoi limiti...
Allora dove è andato tutto storto?
La tabella conntrack ha una dimensione massima configurabile e, se si riempie, le connessioni solitamente iniziano a essere rifiutate o interrotte. C'è abbastanza spazio libero nella tabella per gestire il traffico della maggior parte delle applicazioni e questo non diventerà mai un problema. Tuttavia, ci sono alcuni scenari in cui potresti prendere in considerazione l'utilizzo 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 è configurata per 128k voci, ma hai >128k connessioni simultanee, sicuramente incontrerai un problema!
- Un caso leggermente meno ovvio: se il tuo server elabora un numero molto elevato di connessioni al secondo. Anche se le connessioni sono di breve durata, continuano ad essere monitorate da Linux per un certo periodo di tempo (120 secondi per impostazione predefinita). Ad esempio, se la tabella conntrack è configurata per 128 voci e stai tentando di gestire 1100 connessioni al secondo, queste supereranno la dimensione della tabella conntrack, anche se le connessioni hanno una durata molto breve (128/120 = 1092 connessioni/ S).
Esistono diversi tipi di app di nicchia che rientrano in queste categorie. Inoltre, se sono presenti molti malintenzionati, riempire la tabella conntrack del server con molte connessioni semiaperte potrebbe essere utilizzato come parte di un attacco Denial of Service (DOS). In entrambi i casi, conntrack può diventare un collo di bottiglia limitante nel tuo sistema. In alcuni casi, la regolazione dei parametri della tabella conntrack potrebbe essere sufficiente per soddisfare le tue esigenze, aumentando le dimensioni o riducendo i timeout di conntrack (ma se lo fai in modo sbagliato, incontrerai molti problemi). Per gli altri casi sarà necessario bypassare il collegamento per traffico aggressivo.
Esempio reale
Facciamo un esempio specifico: un grande provider SaaS con cui abbiamo lavorato aveva un numero di server memcached sugli host (non macchine virtuali), ognuno dei quali elaborava oltre 50 connessioni a breve termine al secondo.
Hanno sperimentato la configurazione di conntrack, aumentando le dimensioni delle tabelle e riducendo il tempo di tracciamento, ma la configurazione era inaffidabile, il consumo di RAM è aumentato in modo significativo, il che era un problema (nell'ordine dei GByte!), e le connessioni erano così brevi che conntrack non ha funzionato. creare il suo consueto vantaggio in termini di prestazioni (consumo ridotto di CPU o latenza dei pacchetti).
Si sono rivolti a Calico come alternativa. Le policy di rete Calico ti consentono di non utilizzare conntrack per determinati tipi di traffico (utilizzando l'opzione della policy doNotTrack). Ciò ha garantito loro il livello di prestazioni di cui avevano bisogno, oltre al livello aggiuntivo di sicurezza fornito da Calico.
Quanto tempo dovrai percorrere per bypassare il collegamento?
- Le politiche di rete di non tracciamento dovrebbero generalmente essere simmetriche. Nel caso del provider SaaS: le loro applicazioni venivano eseguite all'interno della zona protetta e pertanto, utilizzando la politica di rete, potevano inserire nella whitelist il traffico proveniente da altre applicazioni specifiche a cui era consentito l'accesso a memcached.
- La politica di non tracciabilità non tiene conto della direzione della connessione. Pertanto, se il server memcached viene violato, puoi teoricamente provare a connetterti a uno qualsiasi dei client memcached, purché utilizzi la porta di origine corretta. Tuttavia, se hai definito correttamente la politica di rete per i tuoi client memcached, questi tentativi di connessione verranno comunque rifiutati dal lato client.
- La politica di non tracciabilità viene applicata a ogni pacchetto, a differenza delle politiche normali, che vengono applicate solo al primo pacchetto di un flusso. Ciò può aumentare il consumo di CPU per pacchetto poiché la policy deve essere applicata per ciascun pacchetto. Ma per le connessioni di breve durata, questa spesa è bilanciata dalla riduzione del consumo di risorse per l'elaborazione dei collegamenti. Ad esempio, nel caso di un provider SaaS, il numero di pacchetti per ciascuna connessione era molto ridotto, quindi il consumo aggiuntivo di CPU durante l'applicazione delle policy a ciascun pacchetto era giustificato.
Iniziamo i test
Abbiamo eseguito il test su un singolo pod con un server memcached e più pod client memcached in esecuzione su nodi remoti in modo da poter eseguire un numero molto elevato di connessioni al secondo. Il server con il server pod memcached aveva 8 core e 512 voci nella tabella conntrack (la dimensione della tabella configurata standard per l'host).
Abbiamo misurato la differenza di prestazioni tra: nessuna policy di rete; con la regolare politica Calico; e la politica di non tracciabilità di Calico.
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 sono state riscontrate differenze significative tra l'assenza di policy e la policy regolare, ma non è stato rilevato un aumento del consumo di CPU di circa il 20%:
Nel secondo test, abbiamo lanciato tutte le connessioni che i nostri client potevano generare e misurato il numero massimo di connessioni al secondo che il nostro server memcached poteva gestire. Come previsto, i casi “nessuna policy” e “policy regolare” hanno entrambi raggiunto il limite di connessione di oltre 4,000 connessioni al secondo (512k / 120s = 4,369 connessioni/s). Con una politica di non tracciamento, i nostri clienti hanno inviato 60,000 connessioni al secondo senza problemi. Siamo sicuri che potremmo aumentare questo numero aggiungendo più clienti, ma riteniamo che questi numeri siano già sufficienti per illustrare il senso di questo articolo!
conclusione
Conntrack è una funzionalità importante del kernel. Fa perfettamente il suo lavoro. Viene spesso utilizzato dai componenti chiave del sistema. Tuttavia, in alcuni scenari specifici, la congestione dovuta al collegamento supera i normali vantaggi offerti. In questo scenario, le policy di rete Calico possono essere utilizzate per disabilitare selettivamente l'uso di conntrack aumentando al tempo stesso la sicurezza della rete. Per tutto il resto del traffico, conntrack continua ad essere tuo amico!
Leggi anche altri articoli sul nostro blog:
Fonte: habr.com