Make usable behind reverse proxy (like https://meet.jit.si/) #22
Comments
|
This is covered in the TODO section of the README: what we need is a 'TURN server.' and a second public address, not sure how this is handled with docker. |
|
@damencho We could also use that nginx module to proxy to a different upstream based on ALPN, right? That would be to do TURN on 443. |
|
Maybe, we need to test it, whether it works :) |
|
Do you have a example of nginx configuration with alpn ? |
|
Nope, there is nothing we had tried, here is some stuff that I was reading: |
|
It seems I ran into the same issue. It's described well here jitsi/jitsi-meet#2805. I tried to use Turncredentials module to point my Coturn server, but Prosody crashes immediately after login, even with this module disabled. It's enough to have it in modules path. So I would like to know if there is any way to enable TURN server for this Docker Compose setup? Here's the relevant part of the log file |
Not at the moment, sorry. |
|
It seems I have managed to fix this with #147, but that seemed far simpler than what I expected when reading earlier exchange regarding NGinx. My P2P connections are using our dockerized Coturn server behind a reverse proxy, and I can successfully see Coturn receiving connections and am able to call other people on different networks. In terms of configuration, I'm using something similar to this: # Frontend
web:
#image: jitsi/web
image: monogramm/jitsi-web:dev
# ...
environment:
- JVB_ENABLE_STUN_TURN=1
- JVB_ENABLE_P2P_STUN_TURN=1
# ...
# XMPP server
prosody:
#image: jitsi/prosody
image: monogramm/jitsi-prosody:dev
# ...
environment:
- GLOBAL_MODULES=turncredentials
- GLOBAL_CONFIG=turncredentials_secret = "${COTURN_TURN_SECRET}";\nturncredentials_host = "turn.${DOMAIN}";\nturncredentials_port = 5349;
# ...
# Coturn
coturn:
image: monogramm/docker-coturn:4
container_name: coturn
restart: always
network_mode: "host"
tty: true
expose:
- '3478'
- '5349'
- '3479'
- '5350'
environment:
- LISTENING_PORT=3478
- TLS_LISTENING_PORT=5349
- ALT_LISTENING_PORT=3479
- ALT_TLS_LISTENING_PORT=5350
- LISTEN_IPS=${COTURN_LISTEN_IPS}
- RELAY_IP=${COTURN_RELAY_IP}
- STATIC_AUTH_SECRET=${COTURN_TURN_SECRET}
- TLS_CERT=/ssl/coturn/live/${DOMAIN}/fullchain.pem
- TLS_KEY=/ssl/coturn/live/${DOMAIN}/privkey.pem
- REALM=turn.${DOMAIN}
- VERBOSE=1
- DEBUG=0
- PROD=1
volumes:
- /srv/coturn/data:/srv
- /etc/letsencrypt/live/${DOMAIN}:/ssl/coturn/live/${DOMAIN}:ro
- /etc/letsencrypt/archive/${DOMAIN}:/ssl/coturn/archive/${DOMAIN}:ro
- /etc/localtime:/etc/localtime:ro
- /etc/timezone:/etc/timezone:roWhat do you guys think ? |
|
@madmath03 I haven't looked in details but just wanted to give an idea, something I'm trying to test these days. First, we use one other version of mod_turncredentials.lua which allows multiple entries configured. Like stun, turn and turns. https://github.com/otalk/mod_turncredentials/blob/master/mod_turncredentials.lua And my idea is running coturn on some port, and advertise coturn turns to the main domain and port 443 and use nginx's preread and coturn ALPN to forward traffic from nginx to coturn. Here is some info I found on the subject: The above idea is something I want to add to jitsi-meet default install and add the mod_turncredentials to come with jitsi-meet-prosody pcakage, but few other changes are needed. I have it in my todo to test it and move some stuff ... but cannot give any ETA, as it is not my primary focus right now. |
|
Thank you @damencho for your answer. Being able to set multiple STUN / TURN entries definitely sounds nice. Modifying my PR to use another version of mod_turncredentials.lua is fairly easy, just need to have this other version either publicly accessible or in the repository. Maybe I can give it a try if you do not mind. The idea to use port 443 and use NGinx preread + Coturn ALPN seems really nice too but rather complicated... I do not think I would be able to help with that. I think the PR I sent is not incompatible with your objective, as you just need to replace mod_turncredentials and add the NGinx / Coturn config, and it might give a working solution for those who need a TURN server with Jitsi Meet. |
|
Yep, I agree. I'm not so familiar with docker, so my goal is debian packages. But we were discussing this with Saul at some point and will try to add it. As a started next week I can try pushing the mod_turncredntials to jitsi-meet repo so we have it there, need to do some more testing with it, though to make sure it works for the trunk we use and 0.11 |
|
Hi there, |
|
I have worked also on the same and had good progress using ALPN. Browsers though send ALPN for the http traffic, this is how I did it. I send http traffice to the part serving meet and rest to cotrurn. I have plans to create a PR for that next week. I had also included the mod_turncredentials. I will compare your version with mine before creating the PR. |
|
Here is the changes I was working on jitsi/jitsi-meet#4959 |
|
is there a known-to-work, thoroughly documented example of setup & config for this^ jitsi-on-docker-behind-nginx-proxy anywhere yet? even if it's a WIP wiki doc ... @madmath03 's config above is the closest I've found. so far ... |
|
Not yet, we'll get to it soon. |
|
+1 for instructions on reverse-proxying behind nginx. I tried the naive approach (quick start guide + setting up nginx reverse proxying rules) without much luck. Would be nice to have a turn-key solution. |
|
Hello All, I am also searching for a configuration of this |
|
Any updates on this? |
It is working fine right now, actually. Just proxypass to http 8000 and NAT the 10000/udp ports. The only problem for me now is how to restrict the landing page from the public, at the same time allowing an access to the rooms, i.e. |
I've tried this, but continually get 502 Bad Gateway with "connection reset by peer" errors in the nginx logs when I try to hit my subdomain. Can you paste your nginx configuration, as well as any relevant docker-compose.yml/.env changes that you had to make? |
|
My reverse-proxy config for jitsi domain: Here the 192.168.0.100 is the local address for docker host In the .env file I edited only DOCKER_HOST_ADDRESS=YOUR_PUBLIC_IP all the other settings are the same as in example.env To make audio & video working, you have to NAT the 10000/udp port from YOUR_PUBLIC_IP into 192.168.0.100 docker host using your firewall. |
|
I'm still having issues getting nginx to talk to the container when the Docker daemon is running on localhost (502 codes, no matter the config). At this point I'm going to assume it's something silly that I'm missing. I think an authoritative guide would at least help point to issues that I'm not considering right now. |
|
After much frustration, I finally discovered the configuration that got things working for me. Here were my steps:
This needed to be changed to the following:
I hope this helps. Good luck! |
|
@jwillaz |
|
Just to remind a thing : the whole point of this issue was to be able to deploy jitsi without needing opening ports aside 443 : like meet.jit.si ! |
|
@nicolaspernoud By documenting the tweaks that enable functionality for our given setups, I believe this provides good information for someone more well-versed to implement actual fixes. I agree with you - ideally I would not open anything beyond port 443, but for now it's either do this or don't use the tool at all. @osscombat Yes, I am using the 'linuxserver/letsencrypt' image for nginx, and I'm mapping those certs to the Jitsi web container in my docker-compose. |
In support of this, I would like to illustrate my setup, which I assume is very common for hobbyist deployments:
Since I'm trying to deploy Jitsi alongside other services that are on the machine, being able to reverse proxy requests to the subdomain to my container (including redirecting ports) is pretty critical. Obviously if the machine was just running the single Jitsi service, exposing the ports directly would make this task fairly trivial (minus the bit about self-managing certs). I also am running a small number of other services successfully using this config, including LE certs and everything, so it's a bit frustrating to not understand why nginx reverse-proxy'd requests are resulting in 502s given that this is the only container where I'm having this issue. |
|
@jwillaz
Here is my nginx config (I'm using a linuxserver/letsencrypt nginx container) For anyone seeing this post in times to come, I followed the https://github.com/jitsi/docker-jitsi-meet readme, but set |
This one worked for me! I was having problems because of the corrupted and not deleted ~/.jitsi-meet-cfg folder. |
|
I wonder, is it really necessary to |
|
when I make the change you suggested, to And try a docker-compose up/down, I get Do you see same? Did you make add'l changes? |
|
@pgnd did you put the right indentation and quotes? ports:
- '5222:5222'
- '5347:5347'
- '5280:5280' |
|
Hi @pgnd , sorry about the delay in the answer. Here is the docker-compose.yml diff, these were all the changes |
|
@pruje The quotes didn't work for me in ports, Im using Docker version 19.03.6 and docker-compose docker-compose version 1.25.5, build 8a1c60f6 on Ubuntu 18.04 |
|
I am a bit late to the party and sorry if I am getting the wrong end of the stick. I use an Nginx reverse proxy and have got it working with lots of docker recipes. I just add To the end of the docker file and something like to the service that is web-facing. That's all it seems to take. the proxy I am using is at https://github.com/funkytwig/nginx-proxy. I've tried a few things (like adding nginx-proxy external network and changing all the networks to nginx-proxy) but can't get it working. Sorry if I am barking up the wrong tree here but what have I missed. |
|
To supplement the TURN configuration of @madmath03, there is nowadays an official documentation on how this should be configured: |
https://meet.jit.si/ is usable behind a corporate reverse proxy (only TCP ports 80 and 443 allowed).
It would be amazing if the self hosted dockerised version would be as well...
Thanks.
Best regards and kudos for the fantastic work...
The text was updated successfully, but these errors were encountered: