Creo que he encontrado el problema aquí (al final, el problema estaba de nuestro lado), pero hay algunos errores que reportar. Aunque no es una pila tecnológica con la que me sienta cómodo, espero que alguien pueda echar un vistazo más detallado.
En primer lugar, la causa. Al examinar directamente la tabla de base de datos screened_ip_addresses, descubrí que estaba bloqueando dos bloques completos que no debería (176.59.0.0/16 y 109.252.0.0/16). Honestamente, no sé cómo se añadieron y esas dos entradas estaban allí desde febrero. ¿Hay algún botón en el administrador de Discourse para bloquear un bloque completo /16 de una sola vez!?
De todos modos, eso probablemente sea el culpable de mi problema inicial. Aún quedan algunos problemas que el equipo de Discourse podría querer investigar, ya que eso es lo que hizo que esto fuera especialmente difícil de resolver:
-
Esas rangos bloqueados no aparecen listados en las IPs filtradas por alguna razón. Tuve que buscar directamente en la base de datos para encontrarlos. Sin embargo, usar la búsqueda con “176.59” o “109.252” sí los muestra. ¿Existe algún límite de resultados aplicado en
/admin/logs/screened_ip_addresses? -
En la exportación, aparecen como 176.59.0.0 y 109.252.0.0, es decir, no muestran información de bloque. Esto es cierto incluso para los rangos predeterminados (127.0.0.0/8, 10.0.0.0/8, etc.); no se muestra ninguna máscara en el archivo de exportación.
-
Aunque estas entradas han estado bloqueando usuarios, tienen un valor de
match_countde 0 ylast_match_atestá vacío (para toda la tabla). ¿Es esto intencional? Probablemente no se quiera contar todas las coincidencias deallow, pero si los bloqueos no se cuentan, estas columnas no parecen ser utilizadas ni necesarias. O quizás el inicio de sesión a través de SSO no está activando esas coincidencias?