Atualmente, estou tentando solucionar o problema de disparar em um servidor de e-mail que permitirá que os usuários enviem e-mails, mas não efetuem login no servidor (POP3) ou recebam e-mails usando seus clientes do Outlook. Anteriormente isso era factível, mas mover o servidor para sua localização atual o quebrou. Por razões óbvias, suspeito que seja o firewall que está causando problemas.
Em primeiro lugar, aqui está a aparência do handshake (ou tentativa) antes de fazer qualquer alteração no firewall:
servidor de e-mail : 192.168.25.26 cliente : 192.168.25.50
Source | Destination | PROTO | INFO
192.168.25.50 192.168.25.26 TCP 50861 > pop3 [SYN] seq=0 win=65535 len=0
192.168.25.26 192.168.25.50 TCP pop3 > 58601 [RST, ACK] seq=1 win=1 len=0
192.168.25.50 192.168.25.26 TCP [TCP Retransmission] 58061 > pop3 [Syn] etc....
e a dança [rst, ack], [tcp retransmission] acontece mais uma vez antes de falhar.
As regras para o firewall (Cisco) referentes a 192.168.25.26 e pop3 são as seguintes:
dentro:
source | destination | service
any 192.168.25.0/24 tcp/pop3
192.168.25.0/24 any tcp/smtp
208.105.121.196
fora:
source | destination | service
any 192.168.25.26 tcp/pop3
any tcp/smtp
Para mim, parece bem.
Para ter certeza, no servidor de email (Zentyal) eu executei os seguintes comandos:
(as tabelas de IP foram HEAVILY configuradas. Suspeito que o problema esteja aqui. Existe alguma maneira de permitir o tráfego all , apenas para fins de teste?)
sudo iptables -F
sudo iptables -P INPUT ACCEPT
sudo iptables -P FORWARD ACCEPT
sudo iptables -P OUTPUT ACCEPT
No entanto, ainda não há capacidade de conexão do outlook. Neste ponto, no servidor de email, executei o comando:
telnet 127.0.0.1 110
e conseguiu efetuar login no servidor de e-mail. De um cliente dentro da rede, eu corri o mesmo comando e foi dito que a "conexão falhou".
Após essas alterações, quando tento "testar as configurações" no Outlook, aqui está o aspecto do handshake. Notei algo peculiar.
Source | Destination | PROTO | INFO
192.168.25.50 192.168.25.26 TCP apollo-status > pop3 [SYN] seq=0 win=65535 len=0
192.168.25.26 192.168.25.50 TCP pop3 > apollo-status [RST, ACK] seq=1 win=1 len=0
192.168.25.50 192.168.25.26 TCP [TCP Retransmission] apollo-status > pop3 [Syn] etc....
e faz isso mais duas vezes, como da última vez. No painel INFO, vejo agora o status de apollo em vez de um número de porta. As próximas duas vezes que eu corri, eu vi npep_messaging e sinapse, respectivamente. Eu suspeito que estas são portas aleatórias escolhidas pelo dovecot, porque no dovecot.config eu mudei o ouvinte padrão para um asterisco "*" da porta anteriormente especificada, que parecia ser uma porta arbitrária na 4.000 e não tinha regras no firewall.
Só para confirmar, parece que a porta que usa cada vez está mudando com base na configuração (recomendada). Na porta de interface de loopback, 110 tem claramente um ouvinte conectado a ele, mas de outro computador, parece estar fechado.
Qualquer ajuda é apreciada. Eu acumulei meu cérebro com isso, e espero que a comunidade de falhas de servidor tenha algumas ideias novas.
Obrigado!