Ubuntu UFW блокирует порт, хотя он включен
Я использую loadbalancer на основе NGINX на 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 в syslog о заблокированных портах, хотя порты (! d5)
Я думал, что это может быть какой-то предел скорости для подключений для предотвращения DDOS или чего-то подобного, но ограничений не существует.
Что мне не хватает? [ ! d7]
Я видел, что этот вопрос уже задавался в нескольких вариантах, но не был отмечен как ответ, поэтому я стараюсь удачи ...
Спасибо, Tal
3 ответа
Важно отметить флаги TCP в вашем примере строк syslog, «ACK RST».
Также важно знать, что для TCP-соединений Linux имеет тенденцию использовать «полудуплекс», закрытие последовательности, когда обе стороны сеанса могут инициировать завершение соединения с помощью одного двухстороннего рукопожатия FIN-ACK, а не полного 4-х стороннего рукопожатия FIN-ACK. (хотя в этом случае это был пакет сброса (RST)).
Блокированные пакеты, вероятно, связаны с некоторыми дополнительными пакетами в конце сеанса TCP, где таблица отслеживания соединений уже забыта о сеансе, и поэтому они считаются некорректно сформированными НОВЫМИ пакетами. Им не о чем беспокоиться, и фактическая сессия TCP, вероятно, работала нормально.
-
1Спасибо, ваше объяснение очень разумно. Учитывая, что я изменил настройки TCPv4, чтобы быстрее закрыть соединения в / proc / sys / net / ipv4 / tcp_tw_reuse / proc / sys / net / ipv4 / tcp_tw_recycle / proc / sys / net / ipv4 / tcp_fin_timeout до 30 – Tal.Z 12 May 2017 в 09:03
Важно отметить флаги TCP в вашем примере строк syslog, «ACK RST».
Также важно знать, что для TCP-соединений Linux имеет тенденцию использовать «полудуплекс», закрытие последовательности, когда обе стороны сеанса могут инициировать завершение соединения с помощью одного двухстороннего рукопожатия FIN-ACK, а не полного 4-х стороннего рукопожатия FIN-ACK. (хотя в этом случае это был пакет сброса (RST)).
Блокированные пакеты, вероятно, связаны с некоторыми дополнительными пакетами в конце сеанса TCP, где таблица отслеживания соединений уже забыта о сеансе, и поэтому они считаются некорректно сформированными НОВЫМИ пакетами. Им не о чем беспокоиться, и фактическая сессия TCP, вероятно, работала нормально.
Важно отметить флаги TCP в вашем примере строк syslog, «ACK RST».
Также важно знать, что для TCP-соединений Linux имеет тенденцию использовать «полудуплекс», закрытие последовательности, когда обе стороны сеанса могут инициировать завершение соединения с помощью одного двухстороннего рукопожатия FIN-ACK, а не полного 4-х стороннего рукопожатия FIN-ACK. (хотя в этом случае это был пакет сброса (RST)).
Блокированные пакеты, вероятно, связаны с некоторыми дополнительными пакетами в конце сеанса TCP, где таблица отслеживания соединений уже забыта о сеансе, и поэтому они считаются некорректно сформированными НОВЫМИ пакетами. Им не о чем беспокоиться, и фактическая сессия TCP, вероятно, работала нормально.