El seguiment de connexió ("conntrack") és una característica bàsica de la pila de xarxes del nucli de Linux. Permet al nucli fer un seguiment de totes les connexions o fluxos de xarxa lògics i, per tant, identificar tots els paquets que componen cada flux perquè es puguin processar conjuntament de manera seqüencial.
Conntrack és una característica important del nucli que s'utilitza en alguns casos bàsics:
- NAT es basa en la informació de conntrack perquè pugui tractar tots els paquets del mateix flux per igual. Per exemple, quan un pod accedeix a un servei de Kubernetes, l'equilibrador de càrrega kube-proxy utilitza NAT per dirigir el trànsit a un pod específic dins del clúster. Conntrack registra que per a una connexió determinada, tots els paquets al servei IP s'han d'enviar al mateix pod, i que els paquets retornats pel pod de fons s'han de tornar a NAT al pod des del qual prové la sol·licitud.
- Els tallafocs amb estat com Calico es basen en la informació de connecttrack al trànsit de "resposta" a la llista blanca. Això us permet escriure una política de xarxa que digui "permet que el meu pod es connecti a qualsevol adreça IP remota" sense haver d'escriure una política per permetre explícitament el trànsit de resposta. (Sense això, hauríeu d'afegir la regla molt menys segura de "permetre paquets al meu pod des de qualsevol IP".)
A més, conntrack normalment millora el rendiment del sistema (reduint el consum de CPU i la latència de paquets) ja que només el primer paquet d'un flux
ha de passar per tota la pila de xarxa per determinar què fer-hi. Veure la publicació "" per veure un exemple de com funciona.
Tanmateix, conttrack té les seves limitacions...
Llavors, on va sortir tot malament?
La taula de conntrack té una mida màxima configurable i, si s'omple, les connexions comencen a ser rebutjades o abandonades. Hi ha prou espai lliure a la taula per gestionar el trànsit de la majoria d'aplicacions, i això mai es convertirà en un problema. Tanmateix, hi ha alguns escenaris en què potser voldreu considerar l'ús de la taula de conntrack:
- El cas més obvi és si el vostre servidor gestiona un nombre extremadament gran de connexions actives simultàniament. Per exemple, si la vostra taula de conntrack està configurada per a 128k entrades, però teniu més de 128k connexions concurrents, segur que trobareu un problema!
- Un cas una mica menys evident: si el vostre servidor processa un nombre molt gran de connexions per segon. Fins i tot si les connexions són de curta durada, Linux continuen sent supervisades durant un període de temps (120 segons per defecte). Per exemple, si la vostra taula conntrack està configurada per a 128k entrades i esteu intentant gestionar 1100 connexions per segon, superaran la mida de la taula conntrack, fins i tot si les connexions són de molt curta durada (128k/120s = 1092 connexions/ s).
Hi ha diversos tipus d'aplicacions de nínxol que es troben en aquestes categories. A més, si teniu molts actors dolents, omplir la taula de conntrack del vostre servidor amb moltes connexions mig obertes es podria utilitzar com a part d'un atac de denegació de servei (DOS). En ambdós casos, conntrack es pot convertir en un coll d'ampolla limitant al vostre sistema. En alguns casos, ajustar els paràmetres de la taula de conntrack pot ser suficient per satisfer les vostres necessitats, augmentant la mida o reduint els temps d'espera de conntrack (però si ho feu malament, trobareu molts problemes). Per a altres casos serà necessari evitar el conntrack per trànsit agressiu.
Exemple real
Posem un exemple concret: un gran proveïdor de SaaS amb el qual vam treballar tenia diversos servidors memcached en amfitrions (no màquines virtuals), cadascun dels quals processava més de 50 connexions a curt termini per segon.
Van experimentar amb la configuració de conntrack, augmentant la mida de la taula i reduint el temps de seguiment, però la configuració no era fiable, el consum de memòria RAM va augmentar significativament, cosa que va ser un problema (de l'ordre de GBytes!), i les connexions eren tan curtes que conntrack no ho va fer. crear el seu benefici de rendiment habitual (reducció de consum de CPU o latència de paquets).
Van recórrer a Calico com a alternativa. Les polítiques de xarxa de Calico us permeten no utilitzar conntrack per a determinats tipus de trànsit (utilitzant l'opció de política doNotTrack). Això els va donar el nivell de rendiment que necessitaven, a més del nivell de seguretat afegit que proporciona Calico.
Quines longituds haureu de recórrer per evitar conntrack?
- Les polítiques de xarxa de no rastrejar han de ser generalment simètriques. En el cas del proveïdor SaaS: les seves aplicacions s'executaven dins d'una zona protegida i, per tant, utilitzant la política de xarxa, podien incloure a la llista blanca el trànsit d'altres aplicacions específiques que tenien accés a memcached.
- La política de no rastrejar no té en compte la direcció de la connexió. Així, si el servidor memcached està piratejat, teòricament podeu intentar connectar-vos a qualsevol dels clients memcached, sempre que utilitzi el port d'origen correcte. Tanmateix, si heu definit correctament la política de xarxa per als vostres clients memcache, aquests intents de connexió encara es rebutjaran al costat del client.
- La política de no rastrejar s'aplica a cada paquet, a diferència de les polítiques normals, que només s'apliquen al primer paquet d'un flux. Això pot augmentar el consum de CPU per paquet perquè s'ha d'aplicar la política per a cada paquet. Però per a connexions de curta durada, aquesta despesa es compensa amb la reducció del consum de recursos per al processament de conntrack. Per exemple, en el cas d'un proveïdor de SaaS, el nombre de paquets per a cada connexió era molt petit, per la qual cosa es justificava el consum addicional de CPU a l'hora d'aplicar polítiques a cada paquet.
Comencem a provar
Vam executar la prova en un sol pod amb un servidor Memcached i múltiples pods de client Memcached que s'executen en nodes remots de manera que podríem executar un nombre molt gran de connexions per segon. El servidor amb el pod del servidor memcached tenia 8 nuclis i 512k entrades a la taula conntrack (la mida de taula configurada estàndard per a l'amfitrió).
Hem mesurat la diferència de rendiment entre: cap política de xarxa; amb la política regular de Calico; i la política de no seguiment de Calico.
Per a la primera prova, vam establir el nombre de connexions a 4.000 per segon, de manera que ens podríem centrar en la diferència de consum de CPU. No hi va haver diferències significatives entre la política sense política i la política normal, però no fer el seguiment de l'augment del consum de CPU al voltant d'un 20%:
A la segona prova, vam llançar tantes connexions com els nostres clients podien generar i vam mesurar el nombre màxim de connexions per segon que podia gestionar el nostre servidor memcached. Com era d'esperar, els casos de "sense política" i de "política regular" van arribar al límit de conntrack de més de 4,000 connexions per segon (512k / 120s = 4,369 connexions/s). Amb una política de no rastrejar, els nostres clients van enviar 60,000 connexions per segon sense cap problema. Estem segurs que podríem augmentar aquest nombre afegint més clients, però creiem que aquests números ja són suficients per il·lustrar el punt d'aquest article!
Conclusió
Conntrack és una característica important del nucli. Fa la seva feina perfectament. Sovint és utilitzat pels components clau del sistema. Tanmateix, en alguns escenaris específics, la congestió deguda a conntrack supera els beneficis normals que proporciona. En aquest escenari, les polítiques de xarxa de Calico es poden utilitzar per desactivar selectivament l'ús de conntrack alhora que augmenta la seguretat de la xarxa. Per a la resta de trànsit, conntrack continua sent el teu amic!
Llegiu també altres articles al nostre blog:
Font: www.habr.com