UFW блокирует существующие исходящие соединения, когда включено

У меня возникла проблема, когда ufw, кажется, блокирует существующие исходящие соединения на порту 443, когда он включен. Пример:

24 февраля 17:53:00 ядро ​​сервера5: [18571501.131985] [UFW BLOCK] IN=eno1 OUT= MAC=d0:50:99:db:0a:be:00:6b:f1:17:4a:81:08: 00 SRC=35.196.37.91 DST=1.2.3.4 LEN=40 TOS=0x00 PREC=0x60 TTL=51 ID=24902 DF PROTO=TCP SPT=443 DPT=44496 WINDOW=0 RES=0x00 RST URGP=0 
24 февраля 17:33:40 ядро ​​server5: [18570340.976130] [UFW BLOCK] IN=eno1 OUT= MAC=d0:50:99:db:0a:be:00:6b:f1:17:4a:81:08: 00 SRC=52.10.136.43 DST=1.2.3.4 LEN=83 TOS=0x00 PREC=0x00 TTL=228 ID=23746 DF PROTO=TCP SPT=443 DPT=59404 WINDOW=118 RES=0x00 ACK PSH URGP=0
27 февраля 00:47:07 ядро ​​server5: [18769144.299731] [UFW BLOCK] IN=eno1 OUT= MAC=d0:50:99:db:0a:be:00:6b:f1:17:4a:81:08: 00 SRC=35.196.37.91 DST=1.2.3.4 LEN=1460 TOS=0x00 PREC=0x60 TTL=51 ID=60877 DF PROTO=TCP SPT=443 DPT=42030 WINDOW=229 RES=0x00 ACK URGP=0

Также блокируются некоторые пакеты UDP, хотя я специально разрешил UDP от 1025-65535:

24 февраля, 17:52:19, ядро ​​server5: [18571459.414576] [UFW BLOCK] IN=eno1 OUT= MAC=d0:50:99:db:0a:be:00:6b:f1:17:4a:81:08: 00 SRC=5.6.7.8 DST=1.2.3.4 LEN=69 TOS=0x00 PREC=0x00 TTL=44 ID=59557 PROTO=UDP SPT=58678 DPT=49900 LEN=49 

(Я заменил наш IP-адрес сервера на 1.2.3.4). Заблокированный трафик — это исходящие curl-соединения с Google Drive и Vimeo.

Вот как я это настроил:

сбросить
ufw по умолчанию разрешает исходящие
ufw по умолчанию запрещает входящие
ufw разрешить с 96.54.177.7 proto tcp на любой порт 22
ufw разрешить от 50.70.255.166 proto tcp к любому порту 22
ufw разрешить 443/tcp
ufw разрешить 80/tcp
ufw разрешить 25/tcp
ufw разрешить 587/tcp
ufw разрешить 1025:65535/udp

статус ufw показывает:

Статус: активен
Ведение журнала: включено (низкий уровень)
По умолчанию: запрещать (входящие), разрешать (исходящие), отключенные (маршрутизируемые)
Новые профили: пропустить

К действию от
-- ------ ----
22/tcp РАЗРЕШИТЬ ВХОД 99.99.99.99               
22/tcp РАЗРЕШИТЬ ВХОД 99.99.99.99             
443/tcp РАЗРЕШИТЬ ВХОД В любом месте                  
80/tcp РАЗРЕШИТЬ ВХОД В любом месте                  
25/tcp РАЗРЕШИТЬ ВХОД ВСЕГДА                  
587/tcp РАЗРЕШИТЬ ВХОД В любом месте                  
  

В тестировании:

• запуск новой загрузки в Vimeo после включения ufw работает нормально.Вроде ничего не заблокировано.
• включение ufw в середине загрузки Vimeo, кажется, ломает его.
• Подключение по телнету к порту 587 (почта) с сервера куда-то еще и включение ufw, похоже, не вызывает никаких проблем. Соединение остается открытым, и я могу ввести help и т. д.
• conntrack никогда не показывает исходящие соединения, но показывает входящие соединения в порядке.
• когда я тестирую новый экземпляр облачного сервера Ubuntu 20.04, проблем нет ... Я не вижу пакетов, заблокированных для порта 443, и загрузка работает нормально. Но на тестовом облачном сервере conntrack не установлен, и даже после установки conntrack и conntrackd я вообще не вижу никаких подключений, перечисленных в «conntrack -L».

Итак, я немного смущен тем, что именно здесь происходит и стоит ли мне беспокоиться об этом. Я действительно не хочу включать ufw, пока полностью не пойму, что он будет делать с моим трафиком. Как именно он отслеживает исходящие соединения, если conntrack их не отслеживает?

Я думаю, что здесь может быть несколько вещей, но я хотел бы понять, почему я это вижу. Блоки UDP и ACK вызывают больше всего беспокойства, но они, кажется, происходят только на долю секунды после включения ufw, поэтому мне интересно, есть ли небольшая задержка, когда ufw включает правила. Другой (RST) может быть просто из-за закрытия соединения. Блоки ACK, похоже, вызывают проблемы с любыми существующими открытыми исходящими соединениями, которые активно отправляют данные, когда брандмауэр включен.

Для этого:

24 февраля 17:53:00 ядро ​​сервера5: [18571501.131985] [UFW BLOCK] IN=eno1 OUT= MAC=d0:50:99:db:0a:be:00:6b:f1:17:4a:81:08: 00 SRC=35.196.37.91 DST=1.2.3.4 LEN=40 TOS=0x00 PREC=0x60 TTL=51 ID=24902 DF PROTO=TCP SPT=443 DPT=44496 WINDOW=0 RES=0x00 RST URGP=0 

В этом нет ничего необычного. Подробнее см. в одном из моих предыдущих ответов. здесь.

Следующий:

24 февраля 17:33:40 ядро ​​server5: [18570340.976130] [UFW BLOCK] IN=eno1 OUT= MAC=d0:50:99:db:0a:be:00:6b:f1:17:4a:81:08: 00 SRC=52.10.136.43 DST=1.2.3.4 LEN=83 TOS=0x00 PREC=0x00 TTL=228 ID=23746 DF PROTO=TCP SPT=443 DPT=59404 WINDOW=118 RES=0x00 ACK PSH URGP=0

Это не так ясно, но в прошлом также были проблемы с разрывом соединения при переходе с отключенного UFW на включенный. Некоторые методы исследования представлены в другом моем предыдущем ответе. здесь

Для этого:

conntrack никогда не показывает исходящие соединения, но показывает входящие соединения в порядке.

Это неправда. Вот пример:

doug@s15:~$ sudo conntrack -L | грэп 192.168.111.134
TCP 6 35972 УСТАНОВЛЕНО src=192.168.111.1 dst=192.168.111.134 sport=36866 dport=22 src=192.168.111.134 dst=192.168.111.1 sport=22 dport=36866 [ASSURED] mark=0 use=1
conntrack v1.4.6 (conntrack-tools): показано 68 записей потоков.

Это исходящее соединение с моего основного сервера шлюза по адресу 192.168.111.1 на Raspberry Pi по адресу 192.168.111.134.

Если вы внимательно посмотрите, то увидите, что ваш отброшенный трафик — это входящий трафик. Летнее время = 1.2.3.4 DST означает пункт назначения, и, как вы сказали, 1.2.3.4 — ваш IP-адрес.

Согласно выводам статус ufw Трафик имеет исходный порт 443 (SPT), а не DPT (что было бы разрешено), и поэтому ufw отбрасывает его.

Я предполагаю, что вы где-то допустили ошибку (вероятно, связанную с преобразованием сетевых адресов), из-за которой брандмауэр не сохраняет состояние.