O servidor de correio Dovecot / Postfix responde a [SYN] com [RST, ACK] quando o usuário tenta se conectar (POP3). Provavelmente iptables?

Question

Atualmente, estou tentando solucionar problemas de 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:

• mail-server : 192.168.25.26

• client : 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 re-transmission] 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á conectividade 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.

Apenas 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 ligado a ele, mas de outro computador, parece estar fechado.

Qualquer ajuda é apreciada. Eu enfrentei meu cérebro com isso, e espero que essa comunidade tenha algumas idéias novas.

    

Answer 1

para que a mensagem do RST não te enlouqueça. Ocorre sempre que você tenta acessar um serviço que é firewall ou o sistema operacional está lhe dizendo que não há tal serviço escutando nesta porta (Incidentalmente, este truque é usado pelo traceroute para descobrir quando o traceroute precisa parar de sondar).

Vamos dar uma olhada no que eu sou sockets TCP no estado Listen na minha caixa

❯ netstat -an | grep LISTEN                                      [11:49:58 PM]
tcp4       0      0  *.9100                 *.*                    LISTEN
tcp4       0      0  *.17500                *.*                    LISTEN
tcp4       0      0  127.0.0.1.8021         *.*                    LISTEN
tcp6       0      0  ::1.8021               *.*                    LISTEN
tcp4       0      0  127.0.0.1.3306         *.*                    LISTEN
tcp4       0      0  *.22                   *.*                    LISTEN
tcp6       0      0  *.22                   *.*                    LISTEN
tcp4       0      0  127.0.0.1.631          *.*                    LISTEN
tcp6       0      0  ::1.631                *.*                    LISTEN

Então, vamos tentar nos conectar a um serviço inexistente e, ao mesmo tempo, bisbilhotar o meu tráfego.

 ❯ nc -v -z 127.0.0.1 12002                                       [11:50:12 PM]
nc: connectx to 127.0.0.1 port 12002 (tcp) failed: Connection refused

Aqui está o sistema operacional dizendo que não há tal serviço aqui. Firewalls fingem exatamente da mesma maneira (os bons quando você usa o destino REJECT. Destination DROP apenas / dev / null seu tráfego).

❯ sudo tshark -i lo -s0                                                                                                                                [11:50:04 PM]
Capturing on 'Loopback'
  1   0.000000    127.0.0.1 -> 127.0.0.1    TCP 68 54188→12002 [SYN] Seq=0 Win=65535 Len=0 MSS=16344 WS=32 TSval=688032360 TSecr=0 SACK_PERM=1
  2   0.000063    127.0.0.1 -> 127.0.0.1    TCP 44 12002→54188 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0

A conexão a uma porta ativa resulta no handshake & dança de desmontagem

 ❯ nc -v -z 127.0.0.1 8021                                        [11:50:23 PM]
found 0 associations
found 1 connections:
     1: flags=82<CONNECTED,PREFERRED>
    outif lo0
    src 127.0.0.1 port 54190
    dst 127.0.0.1 port 8021
    rank info not available
    TCP aux info available

E o tráfego de rede relevante:

  3  11.123990    127.0.0.1 -> 127.0.0.1    TCP 68 54190→8021 [SYN] Seq=0 Win=65535 Len=0 MSS=16344 WS=32 TSval=688043453 TSecr=0 SACK_PERM=1
  4  11.124082    127.0.0.1 -> 127.0.0.1    TCP 68 8021→54190 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=16344 WS=32 TSval=688043453 TSecr=688043453 SACK_PERM=1
  5  11.124091    127.0.0.1 -> 127.0.0.1    TCP 56 54190→8021 [ACK] Seq=1 Ack=1 Win=408288 Len=0 TSval=688043453 TSecr=688043453
  6  11.124099    127.0.0.1 -> 127.0.0.1    TCP 56 [TCP Window Update] 8021→54190 [ACK] Seq=1 Ack=1 Win=408288 Len=0 TSval=688043453 TSecr=688043453
  7  11.136377    127.0.0.1 -> 127.0.0.1    TCP 56 54190→8021 [FIN, ACK] Seq=1 Ack=1 Win=408288 Len=0 TSval=688043464 TSecr=688043453
  8  11.136406    127.0.0.1 -> 127.0.0.1    TCP 56 8021→54190 [ACK] Seq=1 Ack=2 Win=408288 Len=0 TSval=688043464 TSecr=688043464
  9  11.136415    127.0.0.1 -> 127.0.0.1    TCP 56 [TCP Dup ACK 7#1] 54190→8021 [ACK] Seq=2 Ack=1 Win=408288 Len=0 TSval=688043464 TSecr=688043464
 10  11.263097    127.0.0.1 -> 127.0.0.1    TCP 56 8021→54190 [FIN, ACK] Seq=1 Ack=2 Win=408288 Len=0 TSval=688043587 TSecr=688043464
 11  11.263126    127.0.0.1 -> 127.0.0.1    TCP 56 54190→8021 [ACK] Seq=2 Ack=2 Win=408288 Len=0 TSval=688043587 TSecr=688043587

Então, como você resolve o seu problema?

Verifique se o seu soquete está escutando em uma porta visível externamente (*: port_number)

❯ netstat -an | grep LISTEN                                      [11:49:58 PM]
tcp4       0      0  *.9100                 *.*                    LISTEN <<< COOL
tcp4       0      0  *.17500                *.*                    LISTEN
tcp4       0      0  127.0.0.1.8021         *.*                    LISTEN <<< NOT COOL

Comece com o firewall mais simples ou sem firewall e conecte-se à porta de serviço a partir de uma caixa remota na mesma LAN. Lembre-se de ativar o iptables encaminhando o sinalizador do kernel via sysctl No final do servidor

sudo iptables  -n -L -X -v
sudo tshark -i eth0 -s0 port 110

no final do cliente

sudo tshark -i eth0 -s0 port 110
nc  -v -z mailserver.example.org 110

É importante comparar a saída tshark de ambas as extremidades para garantir que o que você envia é o que chega à caixa remota