Jitsi docker-compose: Unable to connect

_ash · Beitrag von **_ash** » 08.07.2024 20:05:50

Gestern habe ich auf meinem V-Server das aktuelle Debian stable Update eingespielt. Auf dem Server läuft nur Jitsi in docker-compose, das tut aber seither nicht mehr. Ich verwendet seit Jahren dieses image: https://github.com/jitsi/docker-jitsi-meet

Will ich in einem Browser Jitsi aufrufen, bekomme ich nur ein "Unable to connect".

Auf dem Server sieht es so aus:

Code: Alles auswählen

# docker ps
CONTAINER ID   IMAGE                         COMMAND   CREATED          STATUS          PORTS                                                                      NAMES
1f8f03f107bf   jitsi/web:stable-9584-1       "/init"   25 minutes ago   Up 44 seconds   0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp   docker-jitsi-meet-stable_web_1
cd4fced3a109   jitsi/jvb:stable-9584-1       "/init"   25 minutes ago   Up 44 seconds   127.0.0.1:8080->8080/tcp, 0.0.0.0:10000->10000/udp, :::10000->10000/udp    docker-jitsi-meet-stable_jvb_1
a67557eeec43   jitsi/jicofo:stable-9584-1    "/init"   25 minutes ago   Up 45 seconds   127.0.0.1:8888->8888/tcp                                                   docker-jitsi-meet-stable_jicofo_1
cccb4523ca73   jitsi/prosody:stable-9584-1   "/init"   25 minutes ago   Up 45 seconds   5222/tcp, 5269/tcp, 5280/tcp, 5347/tcp                                     docker-jitsi-meet-stable_prosody_1

Sprich alle Container laufen.

Code: Alles auswählen

# netstat -tulpe | grep docker
tcp        0      0 0.0.0.0:http            0.0.0.0:*               LISTEN      root       33576      13162/docker-proxy  
tcp        0      0 localhost:8888          0.0.0.0:*               LISTEN      root       17015      1124/docker-proxy   
tcp        0      0 0.0.0.0:https           0.0.0.0:*               LISTEN      root       33535      13142/docker-proxy  
tcp        0      0 localhost:http-alt      0.0.0.0:*               LISTEN      root       17372      1260/docker-proxy   
tcp6       0      0 [::]:http               [::]:*                  LISTEN      root       33581      13167/docker-proxy  
tcp6       0      0 [::]:https              [::]:*                  LISTEN      root       33540      13147/docker-proxy  
udp        0      0 0.0.0.0:10000           0.0.0.0:*                           root       17147      1197/docker-proxy   
udp6       0      0 [::]:10000              [::]:*                              root       17192      1202/docker-proxy

Sieht so aus, als ob das Jitsi docker-compose auf 80 und 443 hört, so wie es soll.

Code: Alles auswählen

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy DROP)
target     prot opt source               destination         
DOCKER-USER  all  --  anywhere             anywhere            
DOCKER-ISOLATION-STAGE-1  all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain DOCKER (4 references)
target     prot opt source               destination         
ACCEPT     tcp  --  anywhere             172.20.0.2           tcp dpt:8888
ACCEPT     tcp  --  anywhere             172.20.0.4           tcp dpt:https
ACCEPT     udp  --  anywhere             172.20.0.5           udp dpt:10000
ACCEPT     tcp  --  anywhere             172.20.0.4           tcp dpt:http
ACCEPT     tcp  --  anywhere             172.20.0.5           tcp dpt:http-alt

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target     prot opt source               destination         
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere            
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere            
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere            
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere            
RETURN     all  --  anywhere             anywhere            

Chain DOCKER-ISOLATION-STAGE-2 (4 references)
target     prot opt source               destination         
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
RETURN     all  --  anywhere             anywhere            

Chain DOCKER-USER (1 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere

IP tables sehen für mich damit auch gut aus, Incoming accept.

Wenn ich den Server von außen scanne, bekomme ich:

Code: Alles auswählen

$ nmap 12.34.56.78
Starting Nmap 7.93 ( https://nmap.org ) at 2024-07-08 18:49 CEST
Nmap scan report for [domain] (12.34.56.78)
Host is up (0.11s latency).
All 1000 scanned ports on [domain] (12.34.56.78) are in ignored states.
Not shown: 1000 closed tcp ports (conn-refused)

Nmap done: 1 IP address (1 host up) scanned in 10.22 seconds

Keine Idee, warum das nicht läuft. Sieht jemand einen Fehler?

mat6937 · Beitrag von **mat6937** » 08.07.2024 21:30:18

_ash hat geschrieben:
08.07.2024 20:05:50
Wenn ich den Server von außen scanne, bekomme ich:
Code: Alles auswählen
$ nmap 12.34.56.78
Starting Nmap 7.93 ( https://nmap.org ) at 2024-07-08 18:49 CEST
Nmap scan report for [domain] (12.34.56.78)
Host is up (0.11s latency).
All 1000 scanned ports on [domain] (12.34.56.78) are in ignored states.
Not shown: 1000 closed tcp ports (conn-refused)

Nmap done: 1 IP address (1 host up) scanned in 10.22 seconds
Keine Idee, warum das nicht läuft. Sieht jemand einen Fehler?

Mach einen gezielten tcp-scan auf die Ports 80, 443 und schau mit tcpdump, ob der scan ankommt bzw. ob der Zähler der zuständigen iptables-Regel den tcp-scan berücksichtigt. Z. B.:

Code: Alles auswählen

nmap -sS 12.34.56.78 -p80,443

Code: Alles auswählen

tcpdump -c 100 -vvveni <Interface> port 80 or 443

(Interface anpassen und ohne spitze Klammern).

_ash · Beitrag von **_ash** » 08.07.2024 22:05:48

Da kommt zumindest etwas an, hier die letzten paar Zeilen:

Code: Alles auswählen

    <ip>.443 > 7<ip>.35024: Flags [P.], cksum 0x3987 (correct), seq 6812:7398, ack 1322, win 135, options [nop,nop,TS val 2154056651 ecr 1912882073], length 586
20:03:09.450541 96:00:01:86:ce:e6 > d2:74:7f:6e:37:e3, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 63, id 16733, offset 0, flags [DF], proto TCP (6), length 52)
    <ip>.35024 > <ip>.443: Flags [F.], cksum 0xf057 (incorrect -> 0xd859), seq 1322, ack 7398, win 501, options [nop,nop,TS val 1912884224 ecr 2154056651], length 0
20:03:09.472761 d2:74:7f:6e:37:e3 > 96:00:01:86:ce:e6, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 55, id 34592, offset 0, flags [DF], proto TCP (6), length 52)
    <ip>.443 > <ip>.35024: Flags [F.], cksum 0xd9ae (correct), seq 7398, ack 1323, win 135, options [nop,nop,TS val 2154056675 ecr 1912884224], length 0
20:03:09.472895 96:00:01:86:ce:e6 > d2:74:7f:6e:37:e3, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 63, id 16734, offset 0, flags [DF], proto TCP (6), length 52)
    <ip>.35024 > <ip>.443: Flags [.], cksum 0xf057 (incorrect -> 0xd829), seq 1323, ack 7399, win 501, options [nop,nop,TS val 1912884247 ecr 2154056675], length 0

Hilft das? Ich werde daraus nicht schlau.

mat6937 · Beitrag von **mat6937** » 08.07.2024 23:54:32

_ash hat geschrieben:
08.07.2024 22:05:48
Hilft das? Ich werde daraus nicht schlau.

Du kannst den Filter für tcpdump verbessern, um den kompletten Port-scan zu sehen. Ist evtl. eine iptables-Regel für den closed-Port (lt. nmap), zuständig?

_ash · Beitrag von **_ash** » 09.07.2024 12:28:41

Itables habe ich ja oben gepostet, da ist eigentlich alles offen.

Ich scanne später nochmal und poste erneut.

_ash · Beitrag von **_ash** » 09.07.2024 12:36:40

Hier der ganze Output:

Code: Alles auswählen

# tcpdump -c 100 -vvveni eth0 port 80 or 443
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:34:32.603850 d2:74:7f:6e:37:e3 > 96:00:01:86:ce:e6, ethertype IPv4 (0x0800), length 58: (tos 0x0, ttl 23, id 56501, offset 0, flags [none], proto TCP (6), length 44)
    <from_ip>.33845 > <server_ip>.443: Flags [S], cksum 0x0e42 (correct), seq 2140956963, win 1024, options [mss 1399], length 0
10:34:32.604354 96:00:01:86:ce:e6 > d2:74:7f:6e:37:e3, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    <server_ip>.443 > <from_ip>.33845: Flags [R.], cksum 0x29ae (correct), seq 0, ack 2140956964, win 0, length 0
10:34:32.604372 d2:74:7f:6e:37:e3 > 96:00:01:86:ce:e6, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 27, id 43454, offset 0, flags [none], proto TCP (6), length 40)
    <from_ip>.33845 > <server_ip>.80: Flags [.], cksum 0x271e (correct), seq 0, ack 2140956963, win 1024, length 0
10:34:32.604480 96:00:01:86:ce:e6 > d2:74:7f:6e:37:e3, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    <server_ip>.80 > <from_ip>.33845: Flags [R], cksum 0x2b2a (correct), seq 2140956963, win 0, length 0
10:34:32.802757 d2:74:7f:6e:37:e3 > 96:00:01:86:ce:e6, ethertype IPv4 (0x0800), length 58: (tos 0x0, ttl 28, id 35586, offset 0, flags [none], proto TCP (6), length 44)
    <from_ip>.34101 > <server_ip>.80: Flags [S], cksum 0x3020 (correct), seq 1533504485, win 1024, options [mss 1399], length 0
10:34:32.802760 d2:74:7f:6e:37:e3 > 96:00:01:86:ce:e6, ethertype IPv4 (0x0800), length 58: (tos 0x0, ttl 26, id 65416, offset 0, flags [none], proto TCP (6), length 44)
    <from_ip>.34101 > <server_ip>.443: Flags [S], cksum 0x2eb5 (correct), seq 1533504485, win 1024, options [mss 1399], length 0
10:34:32.802912 96:00:01:86:ce:e6 > d2:74:7f:6e:37:e3, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    <server_ip>.80 > <from_ip>.34101: Flags [R.], cksum 0x4b8c (correct), seq 0, ack 1533504486, win 0, length 0
10:34:32.802928 96:00:01:86:ce:e6 > d2:74:7f:6e:37:e3, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    <server_ip>.443 > <from_ip>.34101: Flags [R.], cksum 0x4a21 (correct), seq 0, ack 1533504486, win 0, length 0
^C
8 packets captured
8 packets received by filter
0 packets dropped by kernel

Ideen, was hier den Port blockt?

mat6937 · Beitrag von **mat6937** » 09.07.2024 15:28:56

_ash hat geschrieben:
09.07.2024 12:28:41
Itables habe ich ja oben gepostet, da ist eigentlich alles offen.

Poste die Ausgabe von:

Code: Alles auswählen

iptables -nvx -L

In iptables ist nicht alles offen. Die default policy der FORWARD chain ist auf DROP und Du hast auch benutzerdefinierte chains mit dem target DROP und RETURN bzw. sogar mit einem benutzerdeifiniertem target.

_ash · Beitrag von **_ash** » 09.07.2024 15:32:05

Ich haben eben versuchshalber einen neuen Server von null aufgesetzt, genau gleiches Problem.

Hier die Ausgabe:

Code: Alles auswählen

# iptables -nvx -L
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy DROP 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
     620   185875 DOCKER-USER  0    --  *      *       0.0.0.0/0            0.0.0.0/0           
     620   185875 DOCKER-ISOLATION-STAGE-1  0    --  *      *       0.0.0.0/0            0.0.0.0/0           
     216   141515 ACCEPT     0    --  *      br-f80765013bb6  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
      55     3300 DOCKER     0    --  *      br-f80765013bb6  0.0.0.0/0            0.0.0.0/0           
     349    41060 ACCEPT     0    --  br-f80765013bb6 !br-f80765013bb6  0.0.0.0/0            0.0.0.0/0           
       0        0 ACCEPT     0    --  br-f80765013bb6 br-f80765013bb6  0.0.0.0/0            0.0.0.0/0           
     283   163589 ACCEPT     0    --  *      br-3c95c1bc205c  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
      17     1020 DOCKER     0    --  *      br-3c95c1bc205c  0.0.0.0/0            0.0.0.0/0           
     378    46084 ACCEPT     0    --  br-3c95c1bc205c !br-3c95c1bc205c  0.0.0.0/0            0.0.0.0/0           
       0        0 ACCEPT     0    --  br-3c95c1bc205c br-3c95c1bc205c  0.0.0.0/0            0.0.0.0/0           
       0        0 ACCEPT     0    --  *      docker0  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
       0        0 DOCKER     0    --  *      docker0  0.0.0.0/0            0.0.0.0/0           
       0        0 ACCEPT     0    --  docker0 !docker0  0.0.0.0/0            0.0.0.0/0           
       0        0 ACCEPT     0    --  docker0 docker0  0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Chain DOCKER (3 references)
    pkts      bytes target     prot opt in     out     source               destination         
       2      120 ACCEPT     6    --  !br-f80765013bb6 br-f80765013bb6  0.0.0.0/0            172.19.0.5           tcp dpt:80
      53     3180 ACCEPT     6    --  !br-f80765013bb6 br-f80765013bb6  0.0.0.0/0            172.19.0.5           tcp dpt:443

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
    pkts      bytes target     prot opt in     out     source               destination         
     349    41060 DOCKER-ISOLATION-STAGE-2  0    --  br-f80765013bb6 !br-f80765013bb6  0.0.0.0/0            0.0.0.0/0           
       0        0 DOCKER-ISOLATION-STAGE-2  0    --  docker0 !docker0  0.0.0.0/0            0.0.0.0/0           
     620   185875 RETURN     0    --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain DOCKER-ISOLATION-STAGE-2 (2 references)
    pkts      bytes target     prot opt in     out     source               destination         
       0        0 DROP       0    --  *      br-f80765013bb6  0.0.0.0/0            0.0.0.0/0           
       0        0 DROP       0    --  *      docker0  0.0.0.0/0            0.0.0.0/0           
     349    41060 RETURN     0    --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain DOCKER-USER (1 references)
    pkts      bytes target     prot opt in     out     source               destination         
    1298   396568 RETURN     0    --  *      *       0.0.0.0/0            0.0.0.0/0

_ash · Beitrag von **_ash** » 09.07.2024 17:18:03

Ich habs mit einem Workaround gelöst, und einen Reverse Proxy dazwischen geschalten, damit läuft es ohne Probleme.

mat6937 · Beitrag von **mat6937** » 09.07.2024 17:24:17

_ash hat geschrieben:
09.07.2024 15:32:05
Ich haben eben versuchshalber einen neuen Server von null aufgesetzt, genau gleiches Problem.

OK, an iptables dürfte es nicht liegen.
Du kannst noch Folgendes probieren: Installiere auf dem Server (wo auf dem Port 443 gelauscht wird)

Code: Alles auswählen

apt install bpfcc-tools

Schau nach welche PID der Dienst hat, der auf dem Port 443 lauscht und starte _vor dem Portscan_ auf dem Server:

Code: Alles auswählen

tcplife-bpfcc -4 -T -L 443 -p <PID>

(PID anpassen und ohne spitze Klammern).
Wenn nach dem Portscan (syn, reset+ack) tcplife den Traffic anzeigt (... vergleiche auch RPORT mit tcpdump-Ausgabe), ist es der Dienst mit der >PID>, der auf syn mit reset+ack antwortet (evtl. nicht richtig konfiguriert).

debianforum.de

Jitsi docker-compose: Unable to connect

Jitsi docker-compose: Unable to connect

Re: Jitsi docker-compose: Unable to connect

Re: Jitsi docker-compose: Unable to connect

Re: Jitsi docker-compose: Unable to connect

Re: Jitsi docker-compose: Unable to connect

Re: Jitsi docker-compose: Unable to connect

Re: Jitsi docker-compose: Unable to connect

Re: Jitsi docker-compose: Unable to connect

Re: Jitsi docker-compose: Unable to connect

Re: Jitsi docker-compose: Unable to connect