Порт блоков UFW Ubuntu даже при том, что это включено

Я выполняю NGINX базирующийся loadbalancer на Ubuntu 16.04.2 LTS.

Я настроил брандмауэр с помощью 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

Порт доступен от мира.

Вот строка от моего/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

Мой вопрос состоит в том, почему я вижу записи от UFW в системном журнале о портах, заблокированных даже при том, что порты являются открытыми и рабочими?

Я думал, что это могло бы быть некоторое ограничение скорости на соединениях для предотвращения DDOS или чего-то подобного, но нет никакого предельного набора.

Что я пропускаю?

Я видел, что этот вопрос уже задали в нескольких изменениях, но никогда не отмечали, ответил, Таким образом, я попытал своего счастья...

Спасибо, Tal

0
задан 11 May 2017 в 01:24

1 ответ

Важно отметить флаги TCP в Ваших строках системного журнала в качестве примера, "ACK RST".

также важно знать, что для соединений TCP, Linux имеет тенденцию использовать "полудуплексную" близкую последовательность, где любая сторона сессии может инициировать завершение соединения через единственные 2 пути квитирование FIN-ACK вместо полных 4 путей квитирование FIN-ACK. (хотя в этом случае это, кажется, было сбросом (RST) пакет).

заблокированные пакеты происходят, вероятно, из-за некоторых дополнительных пакетов в конце сеанса TCP, где таблица отслеживания соединения уже забыла о сессии, и поэтому они считаются неправильно сформированными НОВЫМИ пакетами. Они - ничто для волнения о, и фактический сеанс TCP, вероятно, работал просто великолепно.

0
ответ дан 3 November 2019 в 06:41

Другие вопросы по тегам:

Похожие вопросы: