UFW, иногда блокирующий HTTPS (443/TCP), хотя настроено для разрешения тот порт на Ubuntu 16.04

На моей машине Ubuntu 16.04 я настроил UFW как это:

$ sudo apt-get install ufw

$ sudo ufw limit 22/tcp
$ sudo ufw allow 80/tcp
$ sudo ufw allow 443/tcp

$ sudo ufw enable

Теперь, если я работаю sudo ufw status verbose, вывод следующий:

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp                     LIMIT IN    Anywhere                  
80/tcp                     ALLOW IN    Anywhere                  
443/tcp                    ALLOW IN    Anywhere                  
22/tcp (v6)                LIMIT IN    Anywhere (v6)             
80/tcp (v6)                ALLOW IN    Anywhere (v6)             
443/tcp (v6)               ALLOW IN    Anywhere (v6)

Который выглядит хорошим, насколько я вижу: Это позволяет SSH, который (отрегулировали) и также HTTP и HTTPS. Который является тем, что было желаемо.

Но после нескольких дней, изучая /var/log/ufw.log показывает довольно много записей как следующие примеры:

Jan 1 00:00:00 <SERVER_NAME> kernel: [<UPTIME>] [UFW BLOCK] IN=eth0 OUT= MAC=<41_CHARACTERS> SRC=<IP_V4> DST=<IP_V4> LEN=40 TOS=0x00 PREC=0x00 TTL=56 ID=1234 DF PROTO=TCP SPT=17708 DPT=443 WINDOW=0 RES=0x00 RST URGP=0

Jan 2 23:59:59 <SERVER_NAME> kernel: [<UPTIME>] [UFW BLOCK] IN=eth0 OUT= MAC=<41_CHARACTERS> SRC=<IP_V4> DST=<IP_V4> LEN=52 TOS=0x00 PREC=0x00 TTL=51 ID=23456 DF PROTO=TCP SPT=29199 DPT=443 WINDOW=1061 RES=0x00 ACK FIN URGP=0

Согласно DPT=443, UFW блокирует некоторые Запросы HTTPS? Почему это? HTTPS (т.е. порт 443 через TCP) явно позволяется в конфигурации UFW, как замечено выше, не так ли? Чем могли там состоять в том другие причины, чтобы UFW заблокировал эти запросы?

(UFW ясно не блокирует все Запросы HTTPS, поскольку я могу открыть свой веб-сайт через HTTPS в браузере, когда я пробую его.)

1
задан 11 November 2019 в 20:07

1 ответ

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

важная информация здесь флаги TCP, "RST" (Сброс), и "ACK FIN" для Ваших двух примеров.

2
ответ дан 7 December 2019 в 13:13

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

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