El seguimiento de conexiones (“conntrack”) es una característica central de la pila de redes del kernel de Linux. Permite al kernel realizar un seguimiento de todas las conexiones o flujos de red lógica y así identificar todos los paquetes que componen cada flujo para que puedan procesarse juntos de forma secuencial.
Conntrack es una característica importante del kernel que se utiliza en algunos casos básicos:
- NAT se basa en información de conntrack para poder tratar todos los paquetes del mismo flujo por igual. Por ejemplo, cuando un pod accede a un servicio de Kubernetes, el equilibrador de carga kube-proxy utiliza NAT para dirigir el tráfico a un pod específico dentro del clúster. Conntrack registra que para una conexión determinada, todos los paquetes al servicio IP deben enviarse al mismo pod y que los paquetes devueltos por el pod de backend deben enviarse mediante NAT al pod desde el que provino la solicitud.
- Los firewalls con estado como Calico dependen de la información de connecttrack para incluir el tráfico de "respuesta" en la lista blanca. Esto le permite escribir una política de red que diga "permitir que mi pod se conecte a cualquier dirección IP remota" sin tener que escribir una política para permitir explícitamente el tráfico de respuesta. (Sin esto, tendría que agregar la regla "permitir paquetes a mi pod desde cualquier IP", mucho menos segura).
Además, conntrack normalmente mejora el rendimiento del sistema (al reducir el consumo de CPU y la latencia de paquetes), ya que solo el primer paquete de una secuencia
Debe revisar toda la pila de la red para determinar qué hacer con ella. Ver la publicación "" para ver un ejemplo de cómo funciona esto.
Sin embargo, conntrack tiene sus limitaciones...
Entonces, ¿dónde salió todo mal?
La tabla conntrack tiene un tamaño máximo configurable y, si se llena, las conexiones generalmente comienzan a rechazarse o descartarse. Hay suficiente espacio libre en la tabla para manejar el tráfico de la mayoría de las aplicaciones y esto nunca será un problema. Sin embargo, existen algunos escenarios en los que quizás desee considerar el uso de la tabla conntrack:
- El caso más obvio es si su servidor maneja una cantidad extremadamente grande de conexiones activas simultáneamente. Por ejemplo, si su tabla de conntrack está configurada para 128k entradas, pero tiene >128k conexiones simultáneas, ¡seguramente tendrá un problema!
- Un caso un poco menos obvio: si su servidor procesa una gran cantidad de conexiones por segundo. Incluso si las conexiones son de corta duración, Linux continúa supervisándolas durante un período de tiempo (120 de forma predeterminada). Por ejemplo, si su tabla conntrack está configurada para 128k entradas y está intentando manejar 1100 conexiones por segundo, excederán el tamaño de la tabla conntrack, incluso si las conexiones son de muy corta duración (128k/120s = 1092 conexiones/ s).
Hay varios tipos de aplicaciones especializadas que se incluyen en estas categorías. Además, si tiene muchos malos actores, llenar la tabla de conexiones de su servidor con muchas conexiones medio abiertas podría usarse como parte de un ataque de denegación de servicio (DOS). En ambos casos, conntrack puede convertirse en un cuello de botella limitante en su sistema. En algunos casos, ajustar los parámetros de la tabla de conntrack puede ser suficiente para satisfacer sus necesidades, aumentando el tamaño o reduciendo los tiempos de espera de conntrack (pero si lo hace mal, tendrá muchos problemas). En otros casos, será necesario omitir conntrack por tráfico agresivo.
Ejemplo real
Demos un ejemplo específico: un gran proveedor de SaaS con el que trabajamos tenía varios servidores Memcached en hosts (no máquinas virtuales), cada uno de los cuales procesaba más de 50 conexiones a corto plazo por segundo.
Experimentaron con la configuración de conntrack, aumentando el tamaño de las tablas y reduciendo el tiempo de seguimiento, pero la configuración no era confiable, el consumo de RAM aumentó significativamente, lo cual fue un problema (¡del orden de GBytes!), y las conexiones eran tan cortas que conntrack no funcionó. crear su beneficio de rendimiento habitual (consumo reducido de CPU o latencia de paquetes).
Recurrieron a Calico como alternativa. Las políticas de red de Calico le permiten no utilizar conntrack para ciertos tipos de tráfico (usando la opción de política doNotTrack). Esto les dio el nivel de rendimiento que necesitaban, además del nivel adicional de seguridad que brinda Calico.
¿Hasta dónde tendrás que llegar para evitar conntrack?
- Las políticas de red de no seguimiento deberían ser generalmente simétricas. En el caso del proveedor de SaaS: sus aplicaciones se ejecutaban dentro de la zona protegida y, por lo tanto, utilizando la política de red, podían incluir en la lista blanca el tráfico de otras aplicaciones específicas a las que se les permitía acceder a Memcached.
- La política de no seguimiento no tiene en cuenta la dirección de la conexión. Por lo tanto, si el servidor Memcached es pirateado, en teoría puedes intentar conectarte a cualquiera de los clientes Memcached, siempre que utilice el puerto de origen correcto. Sin embargo, si ha definido correctamente la política de red para sus clientes de Memcached, estos intentos de conexión seguirán siendo rechazados en el lado del cliente.
- La política de no seguimiento se aplica a cada paquete, a diferencia de las políticas normales, que se aplican sólo al primer paquete de un flujo. Esto puede aumentar el consumo de CPU por paquete porque la política debe aplicarse para cada paquete. Pero para las conexiones de corta duración, este gasto se compensa con la reducción del consumo de recursos para el procesamiento de conntrack. Por ejemplo, en el caso de un proveedor SaaS, el número de paquetes por cada conexión era muy pequeño, por lo que se justificaba el consumo adicional de CPU al aplicar políticas a cada paquete.
Empecemos a probar
Ejecutamos la prueba en un solo pod con un servidor Memcached y múltiples pods de cliente Memcached ejecutándose en nodos remotos para poder ejecutar una gran cantidad de conexiones por segundo. El servidor con el pod de servidor Memcached tenía 8 núcleos y 512k entradas en la tabla conntrack (el tamaño de tabla configurado estándar para el host).
Medimos la diferencia de rendimiento entre: sin política de red; con póliza regular de Calico; y la política de no seguimiento de Calico.
Para la primera prueba, establecimos el número de conexiones en 4.000 por segundo, para poder centrarnos en la diferencia en el consumo de CPU. No hubo diferencias significativas entre ninguna política y la política regular, pero no realizar un seguimiento aumentó el consumo de CPU en aproximadamente un 20 %:
En la segunda prueba, lanzamos tantas conexiones como nuestros clientes pudieron generar y medimos la cantidad máxima de conexiones por segundo que nuestro servidor Memcached podía manejar. Como se esperaba, los casos de “política sin política” y de “política regular” alcanzaron el límite de conexión de más de 4,000 conexiones por segundo (512k/120s = 4,369 conexiones/s). Con una política de no seguimiento, nuestros clientes enviaron 60,000 conexiones por segundo sin ningún problema. Estamos seguros de que podríamos aumentar este número agregando más clientes, ¡pero creemos que estos números ya son suficientes para ilustrar el objetivo de este artículo!
Conclusión
Conntrack es una característica importante del kernel. Hace su trabajo perfectamente. A menudo lo utilizan componentes clave del sistema. Sin embargo, en algunos escenarios específicos, la congestión debida a conntrack supera los beneficios normales que proporciona. En este escenario, las políticas de red de Calico se pueden utilizar para deshabilitar selectivamente el uso de conntrack y al mismo tiempo aumentar la seguridad de la red. Para el resto del tráfico, ¡conntrack sigue siendo tu amigo!
Lea también otros artículos en nuestro blog:
Fuente: habr.com