¿Cuándo rastrea el módulo conntrack de iptable los estados de los paquetes?

Solución 1:

Presentación introductoria de Netfilter y conntrack

Primero, el esquema obligatorio sobre el flujo de paquetes en Netfilter y redes generales:

Netfilter es el marco de filtrado de paquetes que se inserta sobre el resto de la pila de la red (representada por la "decisión de enrutamiento" y otras partes de la caja blanca con bordes redondeados). Netfilter proporciona ganchos y API para otros subsistemas y "clientes". Entre estas partes se encuentran conntrack (el rastreador de conexiones) y iptables (o nftables ). La separación entre Netfilter y conntrack es bastante borroso. Puedes considerar conntrack como parte integrada de Netfilter.

En el esquema que describe los diversos pasos que atraviesa un paquete, puede ver que en algún punto (entre raw/PREROUTING y mangle/PREROUTING, o entre raw/OUTPUT y mangle/OUTPUT) el paquete atraviesa conntrack .

En este punto, conntrack buscará en sus propias tablas de búsqueda (una mini base de datos de búsqueda guardada en la memoria del kernel):

• si no se encuentran las características de este paquete (y si no se declara UNTRACKED en la tabla sin procesar), una nueva tupla bidireccional conntrack entrada (protocolo, luego información específica de familia y protocolo:fuente y puerto inicial, destino y puerto inicial, fuente y puerto de respuesta, destino y puerto de respuesta (estos dos últimos suelen ser al revés, a menos que NAT o algunos protocolos extraños estén involucrados, como echo la respuesta que coincide con la solicitud de eco para ICMP)) que describe el flujo se crea con el estado NUEVO.
• si coincide (en cualquier dirección) con una entrada anterior y es compatible con el estado de este flujo, el estado del flujo podría modificarse (p. ej., cambiando de NUEVO a ESTABLECIDO si ese no era el caso antes).
• si, por alguna razón específica, el paquete no puede coincidir con un flujo existente a pesar de tener sus características (p. ej., un paquete TCP tardío recibido después de que una retransmisión ya se inició con éxito, por lo que está fuera de la ventana con respecto a la secuencia y SACK valores) el paquete se etiquetará como NO VÁLIDO.
• hay algunos otros casos como RELACIONADO:se trata de paquetes que no forman parte del flujo en sí, sino que están relacionados con un nuevo flujo que se puede asociar con otro flujo existente (es decir, en la base de datos). Dos ejemplos son un error ICMP creado al recibir un paquete (p. ej.:puerto UDP inalcanzable) o cuando un ayudante de protocolo especial como el módulo del kernel nf_conntrack_ftp , que es un complemento para conntrack subsistema, detecta que un paquete es parte del flujo de datos separado asociado con los comandos FTP PASV/EPSV o PORT/EPRT realizados en el flujo de comandos (en el puerto 21).

Abordando la pregunta

Habiendo dicho todo esto, aquí están las respuestas a sus dos viñetas:

• en el espacio de nombres de la red principal conntrack comienza a rastrear las conexiones tan pronto como se cargan sus módulos (incluidos los posibles submódulos específicos del protocolo). Para espacios de nombres de red no iniciales (contenedores...) esto también requiere que algún otro subsistema lo haga referencia (como iptables de OP 's conntrack module o usando una vez el comando conntrack descrito más adelante). Este es el valor predeterminado y un paquete debe marcarse específicamente como SIN SEGUIMIENTO antes la pista de control el subsistema lo ve para que este paquete no sea rastreado. En Linux, solo hay unos pocos casos en los que no se necesitaría el seguimiento, pero, por supuesto, el cortafuegos con estado y el NAT con estado/dinámico ya no estarán disponibles (el NAT sin control, que incluso podría requerir el uso de UNTRACKED en primer lugar, todavía puede ser hecho, pero no con iptables . tc o nftables pueden). Para evitar conntrack manejando algunos paquetes, este tipo de iptables se puede usar la regla (p. ej.:puerto 80/tcp):

  iptables -t raw -A PREROUTING -p tcp --dport 80 -j CT --notrack
  iptables -t raw -A OUTPUT -p tcp --sport 80 -j CT --notrack
  

• Cuando el paquete atraviesa el filtro/ENTRADA y alcanza esta regla:

   iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
  

  Las iptables módulo kernel específico de xt_conntrack consulta el conntrack subsistema (manejado por varios módulos del kernel relevantes nf_conntrack* ) y pregunta sobre el estado de este paquete en su base de datos de búsqueda. Si la respuesta es RELATED o ESTABLISHED el paquete coincide y procede al veredicto ACCEPT. En realidad, el resultado ya está almacenado en caché en el paquete la primera vez que se realizó la búsqueda (generalmente por conntrack ) por lo que esta es una "búsqueda" barata. Esta es, por lo tanto, una regla genérica para manejar flujos ya aceptados anteriormente. Esos flujos se pueden aceptar inicialmente en reglas que mencionan explícitamente -m conntrack --ctstate NEW o simplemente reglas que no lo mencionan pero que se colocan después esta regla genérica (pero tenga en cuenta el estado NO VÁLIDO, que por lo general se debe ELIMINAR antes de hacerlo).

• agregando una viñeta:el manejo de los paquetes entrantes y salientes es bastante simétrico entre PREROUTING y OUTPUT (incluso si no parecen simétricos):conntrack interfaces en PREROUTING así como en OUTPUT (y en algunos otros lugares, considerando NAT está trabajando con conntrack , a excepción de su primer paquete en estado NUEVO atravesando iptables 's nat table). Esto podría ser ligeramente diferente de la descripción que escribió sobre IPFW. Si un servidor que ejecuta aplicaciones también restringe los flujos salientes, lo más probable es que necesite estas mismas iptables genéricas. regla tanto en filtro/SALIDA como en filtro/ENTRADA, para permitir que pasen los paquetes de respuesta salientes del tráfico entrante ya aceptado.

Información adicional

Hay herramientas dedicadas para interactuar con el conntrack tablas de búsqueda del subsistema de conntrack-tools.

• conntrack :para consultar, eliminar o actualizar el contenido de las tablas de búsqueda manejadas por conntrack .

  Algunos ejemplos.

  Puede enumerar todas las entradas rastreadas (que pueden ser grandes sin filtro adicional) con:

  conntrack -L
  

  Si su sistema está haciendo NAT (por ejemplo, un enrutador frente a una LAN privada o ejecutando máquinas virtuales y contenedores), puede usar --any-nat , --src-nat o --dst-nat para mostrar solamente resp. todos los NAT, todos los NAT de origen (enmascaramiento) o todos los NAT de destino (normalmente para puertos reenviados):

  Supervisión en tiempo real de conntrack eventos:

  conntrack -E
  

• conntrackd :un demonio cuyos dos propósitos principales son (conntrack) contabilidad y estadísticas de flujo, o sincronización de estado de clúster de cortafuegos con estado de alta disponibilidad.

Solución 2:

El seguimiento de la conexión es una función separada de Netfilter y no está configurada con IPTables.

En la imagen, hay dos conntrack pasos en la ruta de ENTRADA y uno en la ruta de SALIDA. Estos pasos asocian paquetes individuales con conexiones existentes rastreadas en la tabla de seguimiento de conexiones, o crean nuevas entradas de seguimiento de conexiones en la tabla.

La funcionalidad Conntrack es un módulo del kernel de Linux y, a menudo, se incluye en el kernel en la configuración predeterminada.

La operación Conntrack se puede ajustar ajustando net.netfilter.nf_conntrack valores sysctl.

Su segunda alternativa es lo que sucede. La función Conntrack registra la información de estado y la regla IPTables simplemente consulta la tabla Conntrack para obtener información.