Nextcloud Talk im Docker Container, TURN Server auf Docker Host - kein Video

ralfi · June 9, 2020, 2:03pm

Nextcloud 19.0.0.5
Debian 10

Guten Tag allesamt,

ich versuche - zunehmend verzweifelt - mein Nextcloud Talk in einem Docker Container dazu zu bringen, mit dem auf dem selben Docker Host laufenden TURN Server zu spielen. Dabei geht es mir natürlich um die Audio / Video Funktionalität.

Alles läuft per NAT hinter einer Fritzbox. Die Port-Weiterleitung auf den STUN / TURN Standardport in der Fritzbox 3478 ist eingerichtet, also External_IP:3478 -> Docker_Host_IP:3478.

In den Einstellungen von Talk habe ich meinen STUN Zugang ( FQDN:3478 ) hinzugefügt und den TURN-Server konfiguriert ( FQDN, secret, TCP und UDP ). Wenn ich die Einstellungen teste, ist dieser Test als erfolgreich in der turnserver.log protokolliert, soweit und auch gut ( siehe auch Bild ).

Wenn ich nun einen Anruf starte, versucht der TURN Server eine Audio / Video Verbindung aufzubauen, kann aber offensichtlich die Endpunkte der Verbindung nicht auflösen. Ich werde gleich noch die Logs beifügen.

In der Doku habe ich gelesen - und das könnte auch hier das Problem sein - dass die Pakete auf der Docker_Host_IP:3478 zum Docker_Nextcloud_IP weitergeleitet werden müssen. Nur leider steht nicht da, wie…

Also hier meine Frage: Hat jemand eine derartige Konfig zum Laufen bekommen?

Reiner_Nippes · June 9, 2020, 2:20pm

Link dorthin?

Und um die Frage zu beantworten: Nö, Ich hab’s irgendwann aufgegeben. Mein letzter Versuch war - glaube ich - network_mode: host. Dann benutzt der turnserver im Container direkt die IP des Host und macht kein NAT mehr.

github.com

ReinerNippes/nextcloud_on_docker/blob/9772d52a7bbdd203e77a982d8c745dece8b219b4/roles/docker_container/tasks/turnserver.yml#L31


      
            --total-quota=100
            --bps-capacity=0
            --stale-nonce
            --cert=/etc/ssl/nextcloud/ssl/{{ nextcloud_server_fqdn }}.crt
            --pkey=/etc/ssl/nextcloud/ssl/{{ nextcloud_server_fqdn }}.key
            --cipher-list="ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AES:RSA+3DES:!ADH:!AECDH:!MD5"
            --no-multicast-peers
          volumes:
            - '{{ traefik_config_dir }}:/etc/ssl/nextcloud:ro'
            - 'turnserver-data-vol:/var/lib/coturn:rw'
          network_mode: host
          state:          '{{ state | default("started") }}'

ralfi · June 9, 2020, 2:23pm

Hallo Reiner_Nippes,

hilf mir bitte auf die Sprünge… Wie mache ich das?

Reiner_Nippes · June 9, 2020, 2:25pm

Ähmm. Sorry. Ich meinte: “Könntest du den Link auf die Doku, die benutzt hast, hier teilen?”

ralfi · June 9, 2020, 2:32pm

Momang bitte …

Aber vorab: Ich habe auch versucht, ewig mit dem COTURN Docker Container zu basteln, was nicht geklappt hat, inklusive Host-Mode. Mein eigentliches Ziel war genau die gleiche Lösung für Jitsi-Meet, welches ich auch auf meinem Server mit Hilfe von docker-jitsi-meet gehostet habe. Auch da lief diese Verbindungsart nicht.

Zur Weißglut brachte mich, dass die Jungs und Mädels von meet.ffmuc.net das Problem offensichtlich gelöst haben denn bei einer Conf auf deren Server funktioniert WerbRTC komplett und tadellos. Also habe ich in deren Chat mal nachgefragt und die Antwort erhalten dass sie sich nicht sicher sind ob ein STUN / TURN so über NAT überhaupt richtig funktioniert.

Als Folge dessen habe ich diese Variante verworfen und mich wieder daran gemacht, den coturn auf dem Docker Host zum Laufen zu bringen, was ganz offensichtlich schon teilweise funktioniert.

ralfi · June 9, 2020, 2:39pm

Sch … finde ich auf die Schnelle nicht mehr. Aber ich trage die Logs nochmal zusammen und melde mich später dann.

ralfi · June 9, 2020, 3:01pm

Ich meine, vom Prinzip ist die Ursache des Problems schon klar.

Ich setze die external-ip in der turnserver.conf und beim Starten werden alle vorhandenen möglichen “echten” Listener und Relay Adressen erkannt und der Port 3478 an alle möglichen Adressen gebunden. Mist ist nur, dass die einzig wirklich benötigte Adresse - die des Nextcloud Docker Containers - da nicht dabei ist.

In meinem Fall benutze ich das Docker Subnetz 172.18.1.0/16 für Nextcloud und der Container hat die IP 172.18.1.4.

Wenn ich das coturn Log richtig verstehe, wird nun aber als Relay nur die 172.18.1.1 erkannt und der Port 3478 daran gebunden, was ja wohl nicht richtig ist denn das müsste doch die 172.18.1.4 sein, oder?

Vielleicht geht das wirklich nicht, denn es handelt sich ja quasi um ein “doppeltes” NAT…

Man müsste also eine Lösung finden, wie man dieses “doppelte” NAT (externe_IP -> Docker_Host_IP -> Nextcloud_Container_IP) irgendwie auflösen kann. Ich hab da aber noch keine wirklich gute Idee.

ralfi · June 10, 2020, 1:41pm

Habs gefunden, steht in der Nextcloud Doku…
Der Test mit der Browser Console funktioniert natürlich auch nicht…

Hatte heute im Matrix Nextcloud Kanal einen längeren Chat, in welchem mir jemand darlegte, dass dies alles komplett inklusive Audio / Video unter Docker mit dem NC18-fpm (nexctloud-fpm-alpine:18) funktioniert.

ralfi · June 10, 2020, 2:11pm

Das ist der Ausschnitt aus der turnserver log wenn ich in der nextcloud Talk Sektion meine Konfiguration [fqdn:3478]:[secret]:[tcp] teste. Sieht echt gut aus. Reicht aber offensichtlich nicht.

In der Nextcloud Doku steht aber auch ja, dass der TURN Server mit Port 3478 Zugriff auf alle Talk Teilnehmer haben muss. Versuche ich aus der Shell des Nextcloud Containers per Nmap die 192.168.178.21:3478 zu erreichen klappt das tadellos. Der Weg zurück zur IP des Nextcloud Docker Image auf 172.18.1.4:3478 geht aber nicht.

Reiner_Nippes · June 10, 2020, 8:11pm

update: hab’s mittlerweile hinbekommen. auf einer ec2 in der aws. das wäre meine konfig. falls du ansible/jinja2 lesen kannst.

github.com

ReinerNippes/nextcloud_on_docker/blob/0001c9fb268746c9d7325222e49530c20081ee61/roles/docker_container/tasks/turnserver.yml#L6


      
          ---
          # tasks file to start turnserver container
          
          - name: "{{ 'Create' if (state is undefined or 'absent' not in state) else 'Terminate' }} the turnserver container"
            docker_container:
              name:           'turn_server'
              image:          "{{ 'serverror' if ansible_architecture == 'aarch64' else 'instrumentisto' }}/coturn:{{ docker_turnserver_image | default('latest') }}"
              restart_policy: 'unless-stopped'
              command: >
                -n
                --log-file=stdout
                --external-ip=$(detect-external-ip)
                --listening-port=3478
                --no-cli
                --fingerprint
                --use-auth-secret

github.com

ReinerNippes/nextcloud_on_docker/blob/0001c9fb268746c9d7325222e49530c20081ee61/roles/nextcloud_config/tasks/talk.yml#L10


      
          ---
          
          - name: install talk app
            shell: '{{ docker_occ_cmd }} app:install spreed'
            args:
              creates: '{{ nextcloud_www_dir }}/apps/spreed'
            register: talk_app_installed
          
          - name: configure talk app
            shell: '{{ docker_occ_cmd }} {{ item }}'
            loop:
              - app:enable spreed
              - config:app:set spreed stun_servers --value '["{{ nextcloud_fqdn }}:3478"]'
              - config:app:set spreed turn_servers --value '[{"server":"{{ nextcloud_server_fqdn }}:3478","secret":"{{ lookup('password', '{{ nextcloud_credential_store }}/talk_secret chars=ascii_letters,digits length=32') | lower }}","protocols":"udp,tcp"}]'
          #  when: talk_app_installed is changed
            
          - name: open ufw firewall
            include_role:
              name: prep_ufw
            vars:

@ralfi wenn du bei dir eine zweite debian installation aufsetzen kannst, kannst du ja einfach mal das playbook laufen lassen und schauen, ob die konfig geht.

ralfi · July 21, 2020, 9:20am

Hi,

hab ein Weilchen hier micht mehr reingeschaut … Danke für die Infos.

Ich denke, es liegt wohl an der Netzkonfiguration der Virtualisierungsumgebung bzw. des Container-Layouts. Ein ähnliches Phänomen gibt es auch ja auch bei Jitsi.

SvenJ · October 6, 2020, 12:22pm

Maybe it helps someone:

docker run -d --network=host \

    -v /etc/letsencrypt:/etc/letsencrypt:ro \

    --name=coturn \

    instrumentisto/coturn \

    -n --log-file=stdout \

    --listening-ip=x.x.x.x \

    --listening-ip=x.x.x.x \

    --listening-ip=x:x:x:x:x:x:x:x \

    --min-port=49160 \

    --max-port=49200 \

    --fingerprint \

    --no-multicast-peers \

    --no-tlsv1 \

    --no-tlsv1_1 \

    --realm=sub.domain.tld \

    --external-ip='$(detect-external-ip)' \

    --relay-ip='$(detect-external-ip)' \

    --use-auth-secret \

    --static-auth-secret=<yourverysecretpassword> \

    --total-quota=100 \

    --bps-capacity=0 \

    --cert=/etc/letsencrypt/live/some.domain.tld/fullchain.pem \

    --pkey=/etc/letsencrypt/live/some.domain.tld/privkey.pem \

    --cli-password=<anothersecretpass> \

    --stale-nonce=600