O Ubuntu UFW bloqueia a porta mesmo que ela esteja ativada

Question

Estou executando um loadbalancer baseado no NGINX no Ubuntu 16.04.2 LTS.

Eu configurei o firewall usando o UFW.

ufw allow to X.X.X.X port 6633 proto tcp 
ufw allow to X.X.X.X port 80 proto tcp
ufw allow to X.X.X.X port 443 proto tcp

A porta está acessível do mundo.

Aqui está uma linha do meu / var / log / syslog:

May 11 06:55:26 FELB08 kernel: [735361.703709] [UFW BLOCK] IN=eth0 OUT= MAC=XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX SRC=X.X.X.X DST=X.X.X.X LEN=40 TOS=0x08 PREC=0x20 TTL=52 ID=51446 DF PROTO=TCP SPT=2022 DPT=80 WINDOW=4096 RES=0x00 ACK RST URGP=0
May 11 07:34:53 FELB08 kernel: [737729.068015] [UFW BLOCK] IN=eth0 OUT= MAC=XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX SRC=X.X.X.X DST=X.X.X.X LEN=40 TOS=0x08 PREC=0x20 TTL=52 ID=54132 DF PROTO=TCP SPT=1722 DPT=80 WINDOW=4096 RES=0x00 ACK RST URGP=0

Minha pergunta é por que vejo entradas do UFW no syslog sobre portas sendo bloqueadas mesmo que as portas estejam abertas e funcionando?

Eu pensei que poderia ser algum tipo de limite de taxa em conexões para evitar DDOS ou algo semelhante, mas não há limites definidos.

O que estou perdendo?

Eu vi que essa pergunta já foi feita em algumas variações, mas nunca marcada como respondida. Então, estou tentando a minha sorte ...

Obrigado Tal

    

Answer 1

É importante observar os sinalizadores TCP em suas linhas de syslog de exemplo, "ACK RST".

Também é importante saber que, para conexões TCP, o Linux tende a usar uma sequência fechada "semi-duplex", em que cada lado da sessão pode iniciar a conexão através de um handshake FIN-ACK de 2 vias Aperto de mão FIN-ACK de 4 vias. (embora neste caso pareça ter sido um pacote de reset (RST)).

Os pacotes bloqueados provavelmente são devidos a alguns pacotes extras no final de uma sessão TCP em que a tabela de controle de conexão já esqueceu a sessão e, portanto, são considerados NOVOS pacotes formados incorretamente. Eles não são nada para se preocupar, e a sessão TCP real provavelmente funcionou bem.