cscli hub update: intermittent 'connection reset' on HEAD via IPv6 to cdn-hub.crowdsec.net

Abierto
  • ¿Algo no está bien?
#4,469 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
45/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
go
Área
cli

Línea de trabajo

Comienza buscando en el repositorio el texto de advertencia 'Failed to check last modified' para encontrar dónde cscli emite la solicitud HEAD para el archivo .index.json del hub durante cscli hub update. Determina si el fallo del sondeo HEAD puede degradarse a registro debug/verbose (mitigación 1 en el issue) manteniendo el fallback GET existente, y comprueba si ya existe una ruta de código o un flag para preferir IPv4. Se considera terminado cuando: al ejecutar cscli hub update ya no se imprime la WARNING alarmante ante un fallo del HEAD, y el fallback sigue funcionando; ten en cuenta que el issue lleva 141 días inactivo con solo 2 comentarios, así que confirma con los maintainers qué mitigación quieren antes de codificar.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

needs/kind needs/triage

Description

cscli hub update consistently logs a warning about a failed HEAD request to cdn-hub.crowdsec.net when the host has dual-stack (IPv4 + IPv6) connectivity. The HEAD request is sent over IPv6 to a CloudFront edge node and gets read: connection reset by peer. The update still succeeds because cscli falls back to GET, but the warning is noisy and confusing.

Reproduction

Server with working dual-stack IPv4/IPv6 connectivity.

$ cscli hub update
WARNING Failed to check last modified: failed to make HEAD request for https://cdn-hub.crowdsec.net/crowdsecurity/master/.index.json:
  Head "https://cdn-hub.crowdsec.net/crowdsecurity/master/.index.json":
  read tcp [2a02:121f:1dd:8001::2000]:58536->[2600:9000:202a:4800:b:9c87:4c80:93a1]:443: read: connection reset by peer
Downloading /etc/crowdsec/hub/.index.json
Nothing to do, the hub index is up to date.

Isolated test

# IPv6 HEAD — fails intermittently (~2/3 attempts timeout/RST)
$ for i in 1 2 3; do curl -6 -sI --max-time 5 -X HEAD https://cdn-hub.crowdsec.net/crowdsecurity/master/.index.json | head -1; done
(empty)
(empty)
HTTP/2 200

# IPv4 HEAD — always succeeds
$ curl -4 -sI --max-time 5 -X HEAD https://cdn-hub.crowdsec.net/crowdsecurity/master/.index.json | head -1
HTTP/2 200

# IPv6 GET — always succeeds
$ curl -6 -sI --max-time 5 https://cdn-hub.crowdsec.net/crowdsecurity/master/.index.json | head -1
HTTP/2 200

So the failure is specific to HEAD requests over IPv6 hitting certain CloudFront edges. Different edge nodes are contacted on each retry (different /48 prefixes within 2600:9000:*), and only some respond correctly to HEAD over IPv6.

Environment

  • CrowdSec: v1.7.8-debian-pragmatic-amd64-63227459 (codename alphaga, GoVersion 1.26.2)
  • OS: Ubuntu 24.04.4 LTS, kernel 6.8.0-111-generic
  • Network: dual-stack, MTU 1500 on enp6s18, no firewall blocking outbound IPv6

Suspected cause

CloudFront edge configuration inconsistency on IPv6: some edges return HTTP/2 200 for HEAD, others reset the connection. This is upstream (AWS/CloudFront or CrowdSec's CDN config), not a CrowdSec code bug per se.

Suggested mitigations on the cscli side

  1. Treat HEAD failures as a soft error and fall back to GET silently (current behavior already falls back, but logs a WARNING that confuses operators).
  2. Add a --prefer-ipv4 flag, or document the workaround (/etc/gai.conf precedence override, or /etc/hosts pin to an IPv4 CloudFront address).
  3. Open an upstream ticket with the CDN provider to fix the inconsistent HEAD-over-IPv6 behavior.

Happy to provide more traces (tcpdump, etc.) if useful.

Lenguaje dominante
Go
Estrellas
15.1k
Forks
726
Merge medio
2 d 51 min
PR fusionados (30 d)
18

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de crowdsecurity/crowdsec

Todos los issues de crowdsecurity/crowdsec

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.