michi-80337
commented
2 years ago In standard configuration Greenlight lives in a docker container which could be moved around all over a cluster. If that happens, Greenlight and BigBlueButton end up on different servers and local sockets are no option anymore. It is the charme of a container, that it can be moved around without looking into it. If you take a closer look, you will see, that a complete different network is used inside the container.
SSL certificates contain server names, no IP addresses. When Your browser checks a connection with the certificate, it compares the name from the URL with the name(s) from the presented certificate and checks the certificate chain. That's it. If an IP address is used in the URL to connect to the server, a reverse lookup is done, and the certificate has to match the server name found by the resolver. Adding an IP address into the certificate will make your certificate unusable as soon as the IP address changes, and it will be of course a big security risk, as dynamic or private IP addresses are not under your complete control and even static addresses may get reassigned to other people.
The nginx at the server acts as a transparent proxy between the outer world (inside and outside the NAT) and the Greenlight container. Your browser connects to the nginx, and the nginx connects to the container forwarding the data between your browser and the container. The connections between nginx and the container will use a local loopback address (127.0.0.1) when Greenlight and BigBlueButton reside - as usual - on the same system.
To do its job, Greenlight has to call the BigBlueButton API. The container doesn't know anything about the network in the outer world. All it has is a default route to the server where it is running. By setting BIGBLUEBUTTON_ENDPOINT in the .env file, the URL to connect to is given to Greenlight. If Greenlight should connect directly without using the external address, there needs to be an entry added for the internal IP address (10.x) into the /etc/hosts of the container. Adding this entry to the servers /etc/hosts after installation and (re-)configuration is finished could do the trick, too. But I haven't tested that, it might also fail.
Please check, wether the external IP address (164.X) is reachable from your internal network (10.x), and wether connections are correctly forwarded to your server from external and internal sources. Please check further, if there is an entry for 127.0.1.1 (used by MongoDB) and the external IP address in your /etc/hosts matching the (external visible) server name on the system where BigBlueButton resides. There might be a need for a STUN server to enable client communication with other clients over the NAT and firewall border(s), too. Make sure, the container gets rebuild and restarted when Greenlight configuration is modified.
ffdixon
Ubuntu 18.04 server, fresh install.
Server inside corporate network with 10.x IP. External IP is 164.X
I wish to run greenlight and bigbluebutton on the same server. It is publicly reachable through an enterprise router that maps the 10.x address to the public.
The ssl certificate name is in dns and reachable with lets encrypt. The problem is the config is not smart enough to have greenlight stop trying to use a public IP that is not reachable under NAT.
So it all works until I try to use it and get "Invalid BigBlueButton Endpoint and Secret".
Greenlight is timing out trying to resolve my external IP from the certificate name. Okay, I'll change it to my internal IP in the .env file.... Now it fails SSL validation because my internal IP != external. Okay, I'll remove https in the url... Now I get error about missing
tags and it still fails. I get crafty and drop an http proxy, now it's untrusted host and I can't specify more than one. So I HAVE to have Https yet now my own SSL is working against myself even though it's correctly setup for the rest of the world outside my nat. As if greenlight should be outside my network?Why is greenlight not written to use a socket if it's communicating intra-server? Why am I doing SSL internally to myself and then failing because I'm not interfaced with my public IP?
Am I missing something simple here?