Acho que encontrei o problema aqui (no fim, o problema estava do nosso lado), mas há alguns bugs para relatar, embora essa não seja uma stack com a qual eu me sinta confortável, então espero que alguém possa dar uma olhada mais adequada.
Primeiro, a causa. Ao examinar diretamente a tabela do banco de dados screened_ip_addresses, descobri que ela estava bloqueando dois blocos inteiros que não deveria (176.59.0.0/16 e 109.252.0.0/16). Honestamente, não sei como eles foram adicionados, e as duas entradas estavam lá desde fevereiro. Existe algum botão no admin do Discourse para bloquear um bloco inteiro /16 de uma só vez!?
De qualquer forma, isso provavelmente foi o culpado pelo meu problema inicial. Ainda há alguns problemas que a equipe do Discourse pode querer investigar, pois foi isso que tornou isso especialmente difícil de resolver:
-
Esses intervalos bloqueados não aparecem listados em IPs filtrados por algum motivo. Tive que procurar diretamente no banco de dados para encontrá-los. Usar a busca com “176.59” ou “109.252”, no entanto, os mostra. Existe algum limite de resultados sendo aplicado em
/admin/logs/screened_ip_addresses? -
Na exportação, eles aparecem como 176.59.0.0 e 109.252.0.0, ou seja, não mostra nenhuma informação de bloco. Isso é verdade mesmo para os intervalos padrão (127.0.0.0/8, 10.0.0.0/8, etc) — nenhuma máscara é mostrada no arquivo de exportação.
-
Mesmo que essas entradas tenham estado bloqueando usuários, elas têm um valor de
match_countigual a 0 elast_match_atestá vazio (para toda a tabela). Isso é intencional? Provavelmente não se quer contar todas as correspondênciasallow, mas se os bloqueios não são contados, essas colunas parecem não ser usadas/necessárias. Ou talvez o login via SSO não esteja disparando essas correspondências?