Mistério do IP “bloqueado”: firewall limpo, Dovecot saturado e falso positivo de bloqueio

Esse incidente é comum em escritório com NAT: usuário afirma que “o servidor bloqueou meu IP”, mas o firewall não mostra bloqueio. A causa real pode estar no limite de conexões simultâneas por IP no Dovecot, que derruba novas sessões sem mensagem clara para o usuário final.

Sintoma observado em campo

• Outlook/Webmail de alguns usuários não conecta;
• outros usuários do mesmo escritório ainda conectam;
• CSF sem bloqueio explícito;
• logs indicam recusas intermitentes de autenticação/sessão.

Etapa 1: validar se é firewall mesmo

csf -g 186.x.x.x

Se não houver deny, não force liberação cega no firewall.

Etapa 2: confirmar tráfego de rede ativo

ss -ntp | grep '186.x.x.x'
# ou
netstat -atun | grep '186.x.x.x'

Se há ESTABLISHED em 993/995, o tráfego chega ao host. O gargalo está na camada de serviço.

Etapa 3: medir pressão de sessões no Dovecot

doveadm who | grep '186.x.x.x'

Isso mostra quantas sessões simultâneas aquele IP já possui.

Etapa 4: conferir limite configurado

dovecot -n | grep mail_max_userip_connections

Em cenário NAT corporativo, valores baixos como 10 ou 15 são insuficientes quando cada usuário tem desktop + mobile + webmail.

Correção aplicada

Arquivo de ajuste (varia por distribuição):

/etc/dovecot/conf.d/99-custom-mail-limits.conf

Exemplo prático:

mail_max_userip_connections = 60

remote 127.0.0.1 {
  mail_max_userip_connections = 150
}

Aplicar e validar:

dovecot -n
systemctl restart dovecot
systemctl status dovecot --no-pager

Evidência em logs

Eu sempre correlaciono com logs antes/depois:

grep -Ei 'too many|connection|auth|login' /var/log/maillog | tail -n 80

Com ajuste correto, o padrão de rejeição por excesso reduz imediatamente.

Validação com cliente final

No endpoint do usuário:

ping 1.2.3.4
tracert 1.2.3.4

No servidor:

doveadm who | grep '186.x.x.x' | wc -l

Se sessões sobem e caem normalmente sem recusa, incidente encerrado.

Medidas preventivas

1. documentar perfil de conexão por cliente (usuários/dispositivos por IP);
2. ajustar limite com margem técnica, não valor arbitrário;
3. monitorar picos em horário comercial;
4. evitar “liberar tudo no firewall” sem causa raiz.

Diferenciando limite por usuário vs limite por IP

Além de mail_max_userip_connections, reviso também políticas por usuário para não confundir causa:

dovecot -n | grep -Ei 'mail_max_userip_connections|mail_max_userip'

Em alguns ambientes, a saturação ocorre por um único usuário com múltiplos clientes reconectando agressivamente. Nesses casos, corrijo cliente e intervalo de polling antes de apenas elevar limite global.

Plano de resposta para suporte N1/N2

Padronizei um playbook curto:

1. N1 valida CSF;
2. N2 valida sessões Dovecot e limite;
3. N2 ajusta parâmetro com janela controlada;
4. N1 confirma normalização com usuário final.

Esse fluxo reduziu tempo de diagnóstico e evitou mudanças aleatórias no firewall.

Conclusão

Nem todo “IP bloqueado” é firewall. Em ambientes DirectAdmin com Dovecot, o limite de conexões por IP pode simular bloqueio total. O diagnóstico correto é camada a camada: firewall, transporte, sessões e limite de serviço.

Este post está licenciado sob CC BY-NC.