тайм-аут http с сетью моста докеров, но порт 80 открыт в брандмауэре

Я пытаюсь установить mailcow-dockerized на свой сервер, но у меня проблемы с сетью Docker. Я пробовал несколько способов, но у меня много тайм-аутов соединения в контейнерах.

Чтобы решить эту проблему, я решил оставить Mailcow позади и установил только Docker, чтобы попытаться определить источник этих тайм-аутов соединения.

Итак, я установил новый образ Ubuntu 20.04 от моего поставщика VPS и настроил брандмауэр ufw следующим образом:

sudo ufw по умолчанию разрешить исходящие
sudo ufw по умолчанию запрещает входящие
sudo ufw лимит ssh
sudo ufw разрешить ssh
sudo ufw разрешить http
sudo ufw разрешить https
sudo ufw разрешить smtp
sudo ufw разрешить отправку
sudo ufw разрешить отправку
sudo ufw разрешить pop3
sudo ufw разрешить pop3s
sudo ufw разрешить imap2
sudo ufw разрешить imaps
sudo ufw разрешить 4190/tcp
sudo ufw разрешить 8080/tcp
sudo systemctl включить ufw
sudo ufw включить

Я установил Docker со скриптом получить-докер.sh от https://get.docker.com

Затем я включил IPV6 в файле /etc/docker/daemon.json с помощью:

{
  "ipv6": правда,
  "фиксированный-cidr-v6": "2001:db8:1::/64"
}

Перезагрузил сервер и создал docker-compose.yaml:

версия: '2.1'
Сервисы:
    С2:
      изображение: nginx: последний
      порты:
        - 80:80
      перезапуск: всегда
      сети:
        n1:
          ipv4_адрес: 172.22.1.254
          псевдонимы:
            - с2
    С3:
      изображение: nginx: последний
      порты:
        - 8080:80
      перезапуск: всегда
      сети:
        n1:
          ipv4_адрес: 172.22.1.248
          псевдонимы:
            - с3
сети:
  n1:
    водитель: мост
    driver_opts:
      com.docker.network.bridge.name: n1
    включить_ipv6: правда
    IPAM:
      драйвер: по умолчанию
      конфигурация:
        - подсеть: 172.22.1.0/24
        - подсеть: fd4d:6169:6c63:6f77::/64

Эту сетевую конфигурацию я получил из docker-compose.yaml в Mailcow git и изменил ее, чтобы адаптировать к моему тесту.

И я запускаю контейнеры с docker-compose up -d.

Когда я делаю завить локальный хост 80 на хост-сервере, он возвращает содержимое index.html по умолчанию из Nginx., но... соединение приостанавливается на несколько минут, а затем в конце оболочка показывает следующее сообщение:

curl: (28) Не удалось подключиться к порту 80 80: время ожидания подключения истекло

Когда я бегу curl <myservername.com> 80 на моем локальном компьютере он также возвращает содержимое index.html из Nginx по умолчанию, но с сообщением в конце:

curl: (7) Не удалось подключиться к порту 80 0.0.0.80 через 0 мс: сеть недоступна

Любая подсказка о том, почему я получаю эти ошибки?

PS: мой статус ufw:

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

К действию от
-- ------ ----
22/tcp РАЗРЕШИТЬ ВХОД ВСЕГДА
80/tcp РАЗРЕШИТЬ ВХОД В любом месте
443/tcp РАЗРЕШИТЬ ВХОД В любом месте
25/tcp РАЗРЕШИТЬ ВХОД ВСЕГДА
587/tcp РАЗРЕШИТЬ ВХОД В любом месте
465/tcp РАЗРЕШИТЬ ВХОД В любом месте
110/tcp РАЗРЕШИТЬ ВХОД ВСЕГДА
995/tcp РАЗРЕШИТЬ ВХОД В любом месте
143/tcp РАЗРЕШИТЬ ВХОД В любом месте
993/tcp РАЗРЕШИТЬ ВХОД В любом месте
4190/tcp РАЗРЕШИТЬ ВХОД В любом месте
8080/tcp РАЗРЕШИТЬ ВСЕГДА
22/tcp (v6) РАЗРЕШИТЬ ВХОД ВСЕГДА (v6)
80/tcp (v6) РАЗРЕШИТЬ ВХОД ВСЕГДА (v6)
443/tcp (v6) РАЗРЕШИТЬ ВХОД ВСЕГДА (v6)
25/tcp (v6) РАЗРЕШИТЬ ВХОД ВСЕГДА (v6)
587/tcp (v6) РАЗРЕШИТЬ ВХОД ВСЕГДА (v6)
465/tcp (v6) РАЗРЕШИТЬ ВХОД ВСЕГДА (v6)
110/tcp (v6) РАЗРЕШИТЬ ВХОД ВСЕГДА (v6)
995/tcp (v6) РАЗРЕШИТЬ ВХОД ВСЕГДА (v6)
143/tcp (v6) РАЗРЕШИТЬ ВХОД ВСЕГДА (v6)
993/tcp (v6) РАЗРЕШИТЬ ВХОД ВСЕГДА (v6)
4190/tcp (v6) РАЗРЕШИТЬ ВХОД ВСЕГДА (v6)
8080/tcp (v6) РАЗРЕШИТЬ ВХОД ВСЕГДА (v6)

И результаты lsof:

# lsof -i -P -n | grep СЛУШАТЬ
sshd 967 root 3u IPv4 35459 0t0 TCP *:22 (СЛУШАТЬ)
sshd 967 root 4u IPv6 35461 0t0 TCP *:22 (СЛУШАТЬ)
docker-pr 1290 root 4u IPv4 39102 0t0 TCP *:80 (СЛУШАТЬ)
docker-pr 1308 root 4u IPv6 38124 0t0 TCP *:80 (СЛУШАТЬ)
docker-pr 1322 root 4u IPv4 38165 0t0 TCP *:8080 (СЛУШАТЬ)
docker-pr 1328 root 4u IPv6 38172 0t0 TCP *:8080 (СЛУШАТЬ)

Мониторинг termhark во время работы завить локальный хост 80 в хосте:

 Нет.- Время - Источник - Назначение - Протокол - Длина - Информация -                                      
 1 0.000000 fd4d:6169:6c63 fd4d:6169:6c63 TCP 94 39946 – 80 [SYN] Seq=0 Win=64800 Len=0 MSS= 
 2 0,000047 fd4d:6169:6c63 fd4d:6169:6c63 TCP 94 80 – 39946 [SYN, ACK] Seq=0 Ack=1 Win=64260
 3 0,000088 fd4d:6169:6c63 fd4d:6169:6c63 TCP 86 39946 – 80 [ACK] Seq=1 Ack=1 Win=64896 Len=
 4 0,000516 fd4d:6169:6c63 fd4d:6169:6c63 HTTP 159 GET / HTTP/1.1
 5 0,000544 fd4d:6169:6c63 fd4d:6169:6c63 TCP 86 80 – 39946 [ACK] Seq=1 Ack=74 Win=64256 Len
 6 0,000765 fd4d:6169:6c63 fd4d:6169:6c63 TCP 324 HTTP/1.1 200 OK [сегмент TCP повторной сборки
 7 0,000791 fd4d:6169:6c63 fd4d:6169:6c63 TCP 86 39946 – 80 [ACK] Seq=74 Ack=239 Win=64768 L
 8 0,000821 fd4d:6169:6c63 fd4d:6169:6c63 HTTP 701 HTTP/1.1 200 OK (текст/html)
 9 0.000829 fd4d:6169:6c63 fd4d:6169:6c63 TCP 86 39946 – 80 [ACK] Seq=74 Ack=854 Win=64256 L 
 10 65.01291 fd4d:6169:6c63 fd4d:6169:6c63 TCP 86 80 – 39946 [FIN, ACK] Seq=854 Ack=74 Win=64
 11 65.05677 fd4d:6169:6c63 fd4d:6169:6c63 TCP 86 39946 – 80 [ACK] Seq=74 Ack=855 Win=64256 L
 12 130.8576 fd4d:6169:6c63 fd4d:6169:6c63 TCP 86 39946 – 80 [FIN, ACK] Seq=74 Ack=855 Win=64
 13 130.8577 fd4d:6169:6c63 fd4d:6169:6c63 TCP 74 80 – 39946 [RST] Seq=855 Win=0 Len=0
 14 131.0647 fd4d:6169:6c63 fd4d:6169:6c63 TCP 86 [Повторная передача TCP] 39946 – 80 [FIN, ACK]
 15 131.0648 fd4d:6169:6c63 fd4d:6169:6c63 TCP 74 80 – 39946 [RST] Seq=855 Win=0 Len=0        
 16 131.2727 fd4d:6169:6c63 fd4d:6169:6c63 TCP 86 [Повторная передача TCP] 39946 – 80 [FIN, ACK]
 17 131.2728 fd4d:6169:6c63 fd4d:6169:6c63 TCP 74 80 – 39946 [RST] Seq=855 Win=0 Len=0
 18 131.6888 fd4d:6169:6c63 fd4d:6169:6c63 TCP 86 [Повторная передача TCP] 39946 – 80 [FIN, ACK]  
 19 131.6888 fd4d:6169:6c63 fd4d:6169:6c63 TCP 74 80 – 39946 [RST] Seq=855 Win=0 Len=0
 20 132.5208 fd4d:6169:6c63 fd4d:6169:6c63 TCP 86 [Повторная передача TCP] 39946 – 80 [FIN, ACK]
 21 132.5209 fd4d:6169:6c63 fd4d:6169:6c63 TCP 74 80 – 39946 [RST] Seq=855 Win=0 Len=0
 22 134.1847 fd4d:6169:6c63 fd4d:6169:6c63 TCP 86 [Повторная передача TCP] 39946 – 80 [FIN, ACK]
 23 134.1850 fd4d:6169:6c63 fd4d:6169:6c63 TCP 74 80 – 39946 [RST] Seq=855 Win=0 Len=0
 24 137.5129 fd4d:6169:6c63 fd4d:6169:6c63 TCP 86 [Повторная передача TCP] 39946 – 80 [FIN, ACK]  
 25 137.5131 fd4d:6169:6c63 fd4d:6169:6c63 TCP 74 80 – 39946 [RST] Seq=855 Win=0 Len=0        

Результаты termhark при запуске curl <myserver.com> 80 в моем компьютере

 № - Время - Источник - Назначение - Протокол - Длина - Информация -                                      
 1 0.000000 170.78.36.7 172.22.1.254 TCP 66 62787 – 80 [SYN] Seq=0 Win=64240 Len=0 MSS= 
 2 0.000063 172.22.1.254 170.78.36.7 TCP 66 80 – 62787 [SYN, ACK] Seq=0 Ack=1 Win=64240
 3 0.007119 170.78.36.7 172.22.1.254 TCP 54 62787 – 80 [ACK] Seq=1 Ack=1 Win=131840 Len
 4 0,009563 170.78.36.7 172.22.1.254 HTTP 133 GET / HTTP/1.1
 5 0.009628 172.22.1.254 170.78.36.7 TCP 54 80 – 62787 [ACK] Seq=1 Ack=80 Win=64256 Len
 6 0.009884 172.22.1.254 170.78.36.7 TCP 292 HTTP/1.1 200 OK [сегмент TCP повторной сборки
 7 0.010001 172.22.1.254 170.78.36.7 HTTP 669 HTTP/1.1 200 OK (текст/html)
 8 0.019889 170.78.36.7 172.22.1.254 TCP 54 62787 – 80 [ACK] Seq=80 Ack=854 Win=130816
 9 0.039001 170.78.36.7 172.22.1.254 TCP 54 62787 – 80 [FIN, ACK] Seq=80 Ack=854 Win=13 
 10 0.039211 172.22.1.254 170.78.36.7 TCP 54 80 – 62787 [FIN, ACK] Seq=854 Ack=81 Win=64 
 11 0.046453 170.78.36.7 172.22.1.254 TCP 54 62787 – 80 [ACK] Seq=81 Ack=855 Win=130816  

Будьте осторожны: с некоторыми брандмауэрами Docker добавляет определенные правила для правильной работы. Я не уверен, связано ли это также с UFW, но может быть.

Когда это случилось со мной с Iptables, мне пришлось добавить какое-то правило для переадресации входящего соединения на определенный порт на определенный порт моей службы в сети Docker. Так что, если я получаю соединение через порт 80, но моя докеризованная служба предоставляет порт 8080, в некоторых случаях, даже если вы укажете сопоставление: «80: 8080», все равно необходимо добавить какое-то правило переадресации в ваш брандмауэр. .

Еще одна вещь, которую вы могли бы перепроверить, это то, может ли хост-сервер «вызывать» себя.

Одна команда, которая может помочь вам устранить неполадки:

curl -Ivvv хост-порт

Я изменил область своего теста на простой VPS-сервер с установкой NGinx, без Docker, и проблема с тайм-аутом HTTP осталась, поэтому... Я обнаружил, что проблема была вызвана инфраструктурой моего местного поставщика VPS...

Я сменил свой сервер на другого поставщика, и все заработало нормально...