Investigando e-mails fantasmas, portas ocultas e redirecionamento de tráfego no VestaCP

Quem herda ou gerencia um servidor rodando VestaCP quase sempre se depara com um misto de simplicidade e surpresas estruturais. A interface gráfica é minimalista e rápida, mas sob o capô a arquitetura de arquivos e a gestão de serviços guardam particularidades que confundem até quem tem anos de experiência em Linux.

Basta uma situação prática: uma caixa de e-mail acusando quase meio gigabyte de ocupação que simplesmente não aparece onde deveria, um painel administrativo que se recusa a carregar na porta padrão e um roteador de borda descartando pacotes silenciosamente.

Abaixo está o roteiro detalhado de investigação que resolveu esse nó operacional, cobrindo o mapeamento de diretórios do Maildir, o rastreamento de portas por sockets e o uso de túneis SSH reversos para restabelecer o acesso.

1. Onde o VestaCP realmente guarda as mensagens de e-mail?#

Quem vem acostumado com outros painéis de controle costuma navegar direto para a pasta do domínio esperando encontrar a árvore de caixas postais ali dentro.

No VestaCP, ao inspecionar a raiz web da conta:

[root@servidor ~]# cd /home/admin/web/meudominio.com.br/
[root@servidor meudominio.com.br]# ls -la
cgi-bin/            logs/               private/            public_shtml/       stats/
document_errors/    mail.zip            public_html/        restore_errors.log

Nem sinal de caixas de entrada. A pasta /web/ do VestaCP é estritamente isolada para a entrega de páginas pelos servidores web (Apache e Nginx).

A arquitetura do painel adota uma separação rígida entre arquivos de configuração e conteúdo bruto das mensagens.

Configurações vs. mensagens reais#

Se você olhar a pasta de configurações do domínio:

[root@servidor ~]# ls /home/admin/conf/mail/meudominio.com.br/
aliases    antispam   antivirus  dkim.pem   fwd_only   passwd

Aqui moram apenas as regras de controle do Exim e do Dovecot: mapeamentos de apelidos (aliases), chaves criptográficas (dkim.pem), políticas de antispam e o arquivo passwd com os hashes das senhas das contas. Mas onde estão as mensagens das caixas que o painel acusa estarem cheias?

• [email protected] (1 MB)
• [email protected] (434 MB)
• [email protected] (259 MB)

Para manter o controle de quotas e a segurança de permissões do sistema operacional, as mensagens reais no formato Maildir ficam centralizadas fora de /conf/ e fora de /web/.

O caminho canônico dos e-mails no VestaCP é:

/home/USUARIO/mail/DOMINIO/CONTA/Maildir/

Confirmando o consumo real de disco via terminal com o utilitário du:

[root@servidor ~]# ls -F /home/admin/mail/meudominio.com.br/
faturamento/  contato/  financeiro/  suporte/

[root@servidor ~]# du -sh /home/admin/mail/meudominio.com.br/*
259M    /home/admin/mail/meudominio.com.br/faturamento
434M    /home/admin/mail/meudominio.com.br/contato
1.0M    /home/admin/mail/meudominio.com.br/suporte

Ao abrir qualquer uma dessas pastas de conta, observa-se a estrutura padrão do Dovecot:

[root@servidor ~]# ls -la /home/admin/mail/meudominio.com.br/contato/Maildir/
drwx------. 5 admin mail 4096 May 12 14:22 .
drwx------. 3 admin mail 4096 May 12 14:22 ..
drwx------. 2 admin mail 4096 May 12 14:22 cur
drwx------. 2 admin mail 4096 May 12 14:22 new
drwx------. 2 admin mail 4096 May 12 14:22 tmp
drwx------. 2 admin mail 4096 May 12 14:22 .Sent
drwx------. 2 admin mail 4096 May 12 14:22 .Trash

• new/: Mensagens que acabaram de chegar e ainda não foram visualizadas pelo cliente de e-mail.
• cur/: Mensagens já lidas ou manipuladas.
• .Sent / .Trash: Pastas e subpastas criadas pelo cliente IMAP (armazenadas como diretórios ocultos precedidos por ponto).

2. A porta oculta e o bloqueio de rede no gateway#

Outro problema frequente ocorre quando o painel administrativo simplesmente não abre pelo navegador. Por padrão, o VestaCP escuta na porta 8083. No entanto, ao tentar o acesso externo via https://meu-ip:8083, o navegador acusava timeout.

O primeiro passo é conferir diretamente na máquina quais portas estão realmente abertas usando o comando ss:

[root@servidor ~]# ss -tulnp
Netid State  Recv-Q Send-Q  Local Address:Port  Peer Address:Port
tcp   LISTEN 0      20      *:25                *:* users:(("exim",pid=1755,fd=3))
tcp   LISTEN 0      128     192.168.207.103:443 *:* users:(("httpd",pid=1954,fd=4))
tcp   LISTEN 0      128     *:2087              *:* users:(("vesta-nginx",pid=1889,fd=6))
tcp   LISTEN 0      50      *:3306              *:* users:(("mysqld",pid=2333,fd=15))
tcp   LISTEN 0      128     *:22                *:* users:(("sshd",pid=1738,fd=3))

O diagnóstico foi imediato:

1. O processo vesta-nginx (servidor web exclusivo do painel) não estava na porta 8083, mas sim customizado para escutar na porta 2087.
2. A placa de rede principal do servidor possuía apenas um IP local (192.168.207.103), operando atrás de um roteador/firewall com NAT.

Ao testar a conexão vinda de uma máquina externa na internet:

usuario@remoto:~$ telnet 203.0.113.86 2087
Trying 203.0.113.86...
^C

A conexão travava indefinidamente. Porém, testando localmente dentro do próprio servidor:

[root@servidor ~]# telnet 127.0.0.1 2087
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.

O serviço estava operando com perfeição. O gargalo estava no roteador da infraestrutura, que repassava as portas 80, 443 e 22 para a máquina interna, mas bloqueava completamente o tráfego destinado à porta 2087.

3. Furando o bloqueio de rede com túnel SSH reverso#

Quando você precisa acessar o painel com urgência e não tem acesso imediato à administração do roteador de borda para criar uma regra de redirecionamento (Port Forwarding), a saída mais limpa é criar uma ponte criptografada usando SSH Reverso.

Por que a tentativa local com -L falhou?#

Ao tentar criar um redirecionamento local apontando de dentro da máquina para o seu próprio IP público:

[root@servidor ~]# ssh -L 8083:127.0.0.1:2087 [email protected]
ssh: connect to host 203.0.113.86 port 22: No route to host

O kernel rejeita o pacote porque o roteador intermediário não possui suporte a NAT Hairpinning (capacidade de uma máquina interna acessar a si mesma pelo endereço público externo).

A solução com ponte reversa (ssh -R)#

Para contornar isso, utiliza-se um servidor intermediário acessível publicamente (aqui chamado de gateway.exemplo.com.br com IP 198.51.100.170).

De dentro do servidor VestaCP isolado, disparou-se a conexão reversa:

[root@servidor ~]# ssh -R 8888:127.0.0.1:2087 [email protected]

Essa diretiva instrui o servidor intermediário a abrir a porta 8888 e encaminhar qualquer pacote que chegar nela de volta para a porta 2087 interna do VestaCP.

Habilitando acesso externo no servidor intermediário#

Por padrão, o OpenSSH só vincula portas abertas via -R à interface local (127.0.0.1) da máquina receptora. Para que você consiga abrir https://gateway.exemplo.com.br:8888 do seu próprio computador, é necessário habilitar a escuta global:

1. No servidor intermediário, edite as configurações do SSH:

root@gateway:~# nano /etc/ssh/sshd_config

1. Ajuste ou inclua a linha:

GatewayPorts yes

1. Reinicie o serviço SSH:

root@gateway:~# systemctl restart ssh

1. Libere a porta escolhida no firewall do servidor intermediário:

root@gateway:~# ufw allow 8888/tcp
# Ou via iptables direto:
root@gateway:~# iptables -I INPUT -p tcp --dport 8888 -j ACCEPT

1. De volta ao servidor isolado do VestaCP, refaça o túnel informando expressamente a escuta em todas as interfaces (0.0.0.0):

[root@servidor ~]# ssh -R 0.0.0.0:8888:127.0.0.1:2087 [email protected]

Pronto. O painel do VestaCP agora pode ser acessado diretamente pelo navegador via https://gateway.exemplo.com.br:8888, navegando de forma segura através do túnel criptografado.

4. Depurando falhas de sintaxe no Nginx do vesta#

Durante os testes de alteração de portas no arquivo /usr/local/vesta/nginx/conf/nginx.conf, o serviço do painel parou de subir:

[root@servidor ~]# systemctl status vesta.service
May 12 16:59:56 vesta[23516]: Starting vesta-nginx: nginx: [emerg] invalid parameter "server_name" in /usr/local/vesta/nginx/conf/nginx.conf:83
May 12 16:59:56 vesta[23516]: [FAILED]

O diagnóstico da quebra#

O Nginx é rigoroso com a pontuação. Se uma linha não terminar com ponto e vírgula (;), o interpretador considera que a palavra da linha seguinte é um parâmetro da diretiva anterior, gerando mensagens confusas como invalid parameter "server_name".

Ao abrir o arquivo para correção:

[root@servidor ~]# vi +83 /usr/local/vesta/nginx/conf/nginx.conf

A estrutura foi corrigida garantindo a terminação adequada de cada bloco:

    # Vhost
    server {
        listen          2087;
        server_name     _;
        root            /usr/local/vesta/web;
        charset         utf-8;

A regra de ouro: testar a sintaxe antes do restart#

Para nunca derrubar um serviço web em produção ao editar configurações na mão, valide sempre o arquivo com a flag -t do binário específico do vesta-nginx:

[root@servidor ~]# /usr/local/vesta/nginx/sbin/nginx -t -c /usr/local/vesta/nginx/conf/nginx.conf
nginx: the configuration file /usr/local/vesta/nginx/conf/nginx.conf syntax is ok
nginx: configuration file /usr/local/vesta/nginx/conf/nginx.conf test is successful

Somente após o teste confirmar que a sintaxe está íntegra, reinicie o serviço com tranquilidade:

[root@servidor ~]# systemctl start vesta.service

Se ao mudar de porta surgir o erro:

nginx: [emerg] bind() to 0.0.0.0:443 failed (98: Address already in use)

Use ss -tulnp | grep :443 para identificar qual processo (geralmente o Apache ou o Nginx público dos sites) já está segurando aquele socket.

5. Onde fica a raiz padrão quando alguém acessa o servidor pelo IP cru?#

Em instalações comuns do Nginx, requisições diretas ao IP do servidor (http://203.0.113.86/) costumam cair em /usr/share/nginx/html/.

No VestaCP, todas as requisições sem cabeçalho de domínio (host header) são direcionadas para o VirtualHost que possui a diretiva default_server.

Essa pasta padrão fica localizada em:

/home/admin/web/default/public_html/

Se você quiser customizar a página de boas-vindas exibida quando alguém digita o IP direto do servidor na barra de endereços, basta editar os arquivos dentro desse diretório.

O mapa de sobrevivência para manutenção no VestaCP#

Quando você precisar diagnosticar serviços ou movimentar caixas postais no VestaCP, guarde estes pontos-chave:

1. E-mails ficam no /home/USUARIO/mail/: A pasta /web/ é apenas para sites; a pasta /conf/ contém apenas regras e senhas do Exim/Dovecot.
2. Confira sockets antes de culpar o serviço: O comando ss -tulnp revela rapidamente se o painel foi movido da porta 8083 para portas alternativas como 2087.
3. Use SSH reverso contra bloqueios de NAT: Encapsular portas internas com ssh -R e GatewayPorts yes permite acessar painéis isolados sem depender de alterações no roteador da infraestrutura.
4. Valide a sintaxe do Nginx com nginx -t -c: Testar o arquivo de configuração antes de rodar systemctl restart evita paradas acidentais.
5. A raiz do IP padrão fica em default/public_html: É lá que o servidor responde a acessos diretos desprovidos de domínio.

Entendendo a divisão de responsabilidades entre pastas e sockets no VestaCP, a resolução de problemas deixa de ser um jogo de adivinhação e passa a ser um fluxo rápido e previsível.

Veja também

E-mail "Sumiram com minhas pastas!": investigando logs do Dovecot e Exim para provar o que realmente aconteceu

Infraestrutura Quando o filesystem e o daemon entram em desincronia

Servidores Do 'no route to host' ao virtual host: debugging de Nginx standalone e redes na nuvem

Este post está licenciado sob CC BY-NC.