http timeout cu rețeaua docker bridge, dar portul 80 este deschis în firewall

Încerc să instalez mailcow-dockerized pe serverul meu, dar am probleme cu rețeaua Docker. Am încercat mai multe moduri, dar am o mulțime de timeout-uri de conectare în containere.

Pentru a defalca problema, am decis să las Mailcow în urmă și am instalat doar Docker pentru a încerca să identific sursa acestor expirări de conexiune.

Deci, am instalat o imagine proaspătă Ubuntu 20.04 de la furnizorul meu VPS și am configurat firewall-ul ufw astfel:

sudo ufw default permit outgoing
sudo ufw implicit deny incoming
sudo ufw limit ssh
sudo ufw permit ssh
sudo ufw permit http
sudo ufw permit https
sudo ufw permit smtp
sudo ufw permit trimiterea
sudo ufw permit trimiteri
sudo ufw permit pop3
sudo ufw permit pop3s
sudo ufw permit imap2
sudo ufw permit imaps
sudo ufw permit 4190/tcp
sudo ufw permit 8080/tcp
sudo systemctl enable ufw
sudo ufw enable

Am instalat Docker cu scriptul get-docker.sh din https://get.docker.com

Apoi am activat IPV6 în fișierul /etc/docker/daemon.json cu:

{
  „ipv6”: adevărat,
  "fixed-cidr-v6": "2001:db8:1::/64"
}

A repornit serverul și a creat un docker-compose.yaml:

versiunea: „2.1”
Servicii:
    S2:
      imagine: nginx:latest
      porturi:
        - 80:80
      reporniți: întotdeauna
      retele:
        n1:
          adresa_ipv4: 172.22.1.254
          aliasuri:
            - s2
    S3:
      imagine: nginx:latest
      porturi:
        - 8080:80
      reporniți: întotdeauna
      retele:
        n1:
          adresa_ipv4: 172.22.1.248
          aliasuri:
            - s3
retele:
  n1:
    şofer: pod
    driver_opts:
      com.docker.network.bridge.name: n1
    enable_ipv6: adevărat
    ipam:
      driver: implicit
      config:
        - subrețea: 172.22.1.0/24
        - subrețea: fd4d:6169:6c63:6f77::/64

Această configurație de rețea am primit-o de la docker-compose.yaml în Mailcow git și am schimbat-o pentru a se adapta testului meu.

Și conduc containerele cu docker-compune până -d.

Când fac o curl localhost 80 pe serverul gazdă, returnează conținutul implicit index.html de la Nginx, dar... conexiunea este în așteptare pentru câteva minute și apoi shell-ul arată următorul mesaj la sfârșit:

curl: (28) Nu s-a putut conecta la portul 80 80: Conexiune a expirat

Când alerg curl <myservername.com> 80 în computerul meu local, returnează conținutul index.html și din Nginx implicit, dar cu mesajul la sfârșit:

curl: (7) Nu s-a putut conecta la portul 80 0.0.0.80 după 0 ms: Rețea inaccesabilă

Aveți vreo idee despre de ce primesc aceste erori?

PS: starea mea ufw:

# ufw status verbose
Stare: activ
Înregistrare: activată (scăzută)
Implicit: deny (incoming), allow (outgoing), deny (direcționat)
Profiluri noi: săriți

La Acțiune De la
-- ------ ----
22/tcp PERMITERE PENTRU Oriunde
80/tcp PERMITERE PENTRU Oriunde
443/tcp PERMITERE PENTRU Oriunde
25/tcp PERMITERE PENTRU Oriunde
587/tcp PERMITERE ÎN Oriunde
465/tcp PERMITERE PENTRU Oriunde
110/tcp PERMITEȚI IN Oriunde
995/tcp PERMITERE PENTRU Oriunde
143/tcp PERMITEȚI IN Oriunde
993/tcp PERMITERE ÎN Oriunde
4190/tcp PERMISĂ ÎN Oriunde
8080/tcp PERMISĂ ÎN Oriunde
22/tcp (v6) PERMITĂȚI oriunde (v6)
80/tcp (v6) PERMITERE Oriunde (v6)
443/tcp (v6) PERMITERE Oriunde (v6)
25/tcp (v6) PERMISĂ IN Oriunde (v6)
587/tcp (v6) PERMITERE Oriunde (v6)
465/tcp (v6) PERMITERE Oriunde (v6)
110/tcp (v6) PERMITERE Oriunde (v6)
995/tcp (v6) PERMITERE Oriunde (v6)
143/tcp (v6) PERMITERE Oriunde (v6)
993/tcp (v6) PERMITERE Oriunde (v6)
4190/tcp (v6) PERMITERE Oriunde (v6)
8080/tcp (v6) PERMITERE Oriunde (v6)

Și lsof rezultate:

# lsof -i -P -n | grep ASCULTĂ
sshd 967 root 3u IPv4 35459 0t0 TCP *:22 (ASCULTATE)
sshd 967 root 4u IPv6 35461 0t0 TCP *:22 (ASCULTATE)
docker-pr 1290 root 4u IPv4 39102 0t0 TCP *:80 (ASCULTARE)
docker-pr 1308 root 4u IPv6 38124 0t0 TCP *:80 (ASCULTARE)
docker-pr 1322 root 4u IPv4 38165 0t0 TCP *:8080 (ASCULTARE)
docker-pr 1328 root 4u IPv6 38172 0t0 TCP *:8080 (ASCULTARE)

Monitorizare Termshark la rulare curl localhost 80 in gazda:

 Nu.- Timp - Sursă - Destinație - Protocol - Lungime - Informații -                                      
 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 [segment TCP al unei reasamblari
 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 (text/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 Retransmission] 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 Retransmission] 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 Retransmission] 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 Retransmission] 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 Retransmission] 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 Retransmission] 39946 â 80 [FIN, ACK]  
 25 137.5131 fd4d:6169:6c63 fd4d:6169:6c63 TCP 74 80 â 39946 [RST] Seq=855 Win=0 Len=0        

Rezultatele Termshark la rulare curl <serverul meu.com> 80 în computerul meu

 Nr. - Ora - Sursa - Destinatie - Protocol - Lungime - Info -                                      
 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 [segment TCP al unei reasamblari
 7 0,010001 172.22.1.254 170.78.36.7 HTTP 669 HTTP/1.1 200 OK (text/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  

Am schimbat domeniul de aplicare al testului meu la un server VPS simplu cu instalare NGinx, fără Docker, iar problema timeout-ului http a persistat așa că... Am descoperit că problema a fost cauzată de infrastructura furnizorului meu local de VPS...

Mi-am schimbat serverul cu alt furnizor și totul a funcționat bine...

Aveți grijă că, cu unele firewall, Docker adaugă reguli specifice pentru a funcționa corect. Nu sunt sigur dacă acest lucru este legat și de UFW, dar ar putea fi.

Când mi s-a întâmplat acest lucru cu Iptables, a trebuit să adaug o regulă pentru a redirecționa conexiunea de intrare pe un anumit port către portul specific al serviciului meu din rețeaua Docker. Deci, dacă primesc conexiune pe portul 80, dar serviciul meu dockerizat expune portul 8080, în unele cazuri, chiar dacă specificați maparea: "80:8080", mai este nevoie să adăugați o regulă de redirecționare la firewall-ul dvs. .

Un alt lucru pe care l-ați putea verifica este dacă serverul gazdă se poate „apela”.

O comandă care vă poate ajuta să depanați este:

curl -Ivvv portul gazdă