![사용자가 연결(POP3)을 시도하면 Dovecot/Postfix 메일 서버는 [RST, ACK]로 [SYN]을 응답합니다. 어쩌면 iptables일까요?](https://linux55.com/image/58773/%EC%82%AC%EC%9A%A9%EC%9E%90%EA%B0%80%20%EC%97%B0%EA%B2%B0(POP3)%EC%9D%84%20%EC%8B%9C%EB%8F%84%ED%95%98%EB%A9%B4%20Dovecot%2FPostfix%20%EB%A9%94%EC%9D%BC%20%EC%84%9C%EB%B2%84%EB%8A%94%20%5BRST%2C%20ACK%5D%EB%A1%9C%20%5BSYN%5D%EC%9D%84%20%EC%9D%91%EB%8B%B5%ED%95%A9%EB%8B%88%EB%8B%A4.%20%EC%96%B4%EC%A9%8C%EB%A9%B4%20iptables%EC%9D%BC%EA%B9%8C%EC%9A%94%3F.png)
현재 사용자가 이메일을 보낼 수는 있지만 서버(POP3)에 로그인하거나 Outlook 클라이언트를 사용하여 이메일을 받을 수 없는 이메일 서버 문제를 해결하려고 합니다. 이전에는 작동했지만 서버를 현재 위치로 이동하면 문제가 발생했습니다. 나는 방화벽이 문제의 원인이라고 의심했습니다.
먼저, 방화벽을 변경하기 전(또는 변경하려고 시도하기 전)의 핸드셰이크는 다음과 같습니다.
- 메일 서버:192.168.25.26
고객: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....
그리고 [rst, ack], [tcp retransmit] 댄스가 실패하기 전에 다시 발생합니다.
192.168.25.26 및 POP3에 대한 방화벽(Cisco) 규칙은 다음과 같습니다.
안에: source | destination | service
any 192.168.25.0/24 tcp/pop3
192.168.25.0/24 any tcp/smtp
208.105.121.196
source | destination | service
any 192.168.25.26 tcp/pop3
any tcp/smtp
나에게는 이것이 좋아 보인다. 확실히 이메일 서버(Zentyal)에서 다음 명령을 실행했습니다.
(IP 테이블이 심하게 구성되어 있습니다. 여기에 문제가 있는 것 같습니다. 허용할 수 있는 방법이 있습니까?모두트래픽, 단지 테스트용인가요? )
sudo iptables -F
sudo iptables -P INPUT ACCEPT
sudo iptables -P FORWARD ACCEPT
sudo iptables -P OUTPUT ACCEPT
그러나 아직 Outlook 연결 기능은 없습니다. 이 시점에서 이메일 서버에서 다음 명령을 실행했습니다.
telnet 127.0.0.1 110
메일 서버에 로그인할 수 있습니다. 네트워크 내부의 클라이언트에서 동일한 명령을 실행했는데 "연결 실패"라는 메시지가 표시되었습니다.
이러한 변경을 수행한 후 Outlook에서 "설정 테스트"를 시도하면 핸드셰이크 프로세스가 다음과 같습니다. 뭔가 이상한 걸 발견했어요.
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....
지난번과 마찬가지로 2회 더 진행되었습니다. 이제 정보 창에 포트 번호 대신 apollo-status가 표시됩니다. 다음 두 번 실행했을 때 각각 npep_messaging과 synapse가 표시되었습니다. dovecot.config에서 기본 리스너를 이전에 지정된 포트에서 별표 "*"로 변경했기 때문에 이것이 dovecot에서 선택한 임의의 포트인 것으로 의심됩니다. 이는 4,000년대의 임의 포트인 것으로 보이며 방화벽 뒤에 있습니다.
확인하자면 (권장) 구성에 따라 사용하는 포트가 매번 변경되는 것 같습니다. 분명히 루프백 인터페이스 포트 110에 수신기가 연결되어 있지만 다른 컴퓨터에서는 작동이 중단된 것 같습니다.
어떤 도움이라도별말씀을요감사합니다. 저는 이를 위해 많은 노력을 기울였으며 커뮤니티에서 새로운 아이디어를 생각해 낼 수 있기를 바랍니다.
답변1
따라서 RST 뉴스가 당신을 놀라게해서는 안됩니다. 이는 방화벽이 있는 서비스에 액세스하려고 할 때마다 발생하거나 운영 체제에서 해당 서비스가 이 포트에서 수신 대기하고 있지 않다고 알려줄 때마다 발생합니다(BTW, Traceroute는 이 트릭을 사용하여 Traceroute가 감지를 중지해야 하는 시기를 알아냅니다.).
내 상자의 Listen 상태에 있는 TCP 소켓을 살펴보겠습니다.
❯ 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
그럼 내 로컬 트래픽을 스누핑하면서 존재하지 않는 서비스에 연결해 보겠습니다.
❯ 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
여기에는 그러한 서비스가 없다고 알려주는 운영 체제입니다. 방화벽은 정확히 같은 방식으로 이를 위조합니다(REJECT 대상을 사용할 때 훌륭하게 작동합니다. 대상은 트래픽에 대해 /dev/null을 삭제합니다).
❯ 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
활성 포트에 연결하면 TCP 핸드셰이크 및 해체 댄스가 발생합니다.
❯ 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
관련 네트워크 트래픽은 다음과 같습니다.
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
그렇다면 문제를 어떻게 해결합니까?
소켓이 외부에서 볼 수 있는 포트(*: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
가장 간단한 방화벽으로 시작하거나 방화벽 없이 시작하여 동일한 LAN의 원격 장치에서 서비스 포트에 연결합니다. 커널 플래그를 전달하려면 서버 측에서 sysctl을 통해 iptables를 열어야 합니다.
sudo iptables -n -L -X -v
sudo tshark -i eth0 -s0 port 110
클라이언트에서
sudo tshark -i eth0 -s0 port 110
nc -v -z mailserver.example.org 110
보내는 내용이 정확히 원격 상자에 도달하는 내용인지 확인하려면 양쪽 끝의 tshark 출력을 비교하는 것이 중요합니다.