Update files for coturn (#3953)
* Update docs/configuring-playbook-turn.md: add a section for description about installing Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org> * Update docs/configuring-playbook-turn.md and a related file - Edit the introducion based on docs/configuring-playbook-client-element-web.md - Adopt the commont format by creating the section "Adjusting the playbook configuration" - Add the section "Extending the configuration" - Move the section "Disabling Coturn" to the bottom Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org> * Fix capitalization: Coturn → coturn See: https://github.com/coturn/coturn. Note that "coturn" is not capitalized even on the start of a sentence, except some rare cases like on the releases page: https://github.com/coturn/coturn/releases Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org> --------- Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org> Co-authored-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
This commit is contained in:
38
CHANGELOG.md
38
CHANGELOG.md
@ -536,7 +536,7 @@ For 6 years, `matrix-nginx-proxy` has been the front-most reverse-proxy in our s
|
||||
To us, `matrix-nginx-proxy` was:
|
||||
|
||||
- an [nginx](https://nginx.org/)-based reverse-proxy
|
||||
- an Ansible role organizing the work of [certbot](https://certbot.eff.org/) - retrieving free [Let's Encrypt](https://letsencrypt.org/) SSL certificates for `matrix-nginx-proxy` and for the [Coturn TURN server](./docs/configuring-playbook-turn.md)
|
||||
- an Ansible role organizing the work of [certbot](https://certbot.eff.org/) - retrieving free [Let's Encrypt](https://letsencrypt.org/) SSL certificates for `matrix-nginx-proxy` and for the [coturn TURN server](./docs/configuring-playbook-turn.md)
|
||||
- a central component for reverse-proxying to the [long list of services](./docs/configuring-playbook.md) supported by the playbook. As such, it became a dependency that all these services had to inject themselves into during runtime
|
||||
- an intermediary through which addons (bridges, bots) communicated with the homeserver. Going through an intermediary (instead of directly talking to the homeserver) is useful when certain components (like [matrix-media-repo](./docs/configuring-playbook-matrix-media-repo.md) or [matrix-corporal](./docs/configuring-playbook-matrix-corporal.md)) are enabled, because it lets these services "steal routes" from the homeserver
|
||||
- a webserver for serving the `/.well-known/matrix` static files (generated by the `matrix-base` role until now)
|
||||
@ -1200,7 +1200,7 @@ Switching to Traefik will obtain new SSL certificates from Let's Encrypt (stored
|
||||
|
||||
Treafik directly reverse-proxies to **some** services right now, but for most other services it goes through `matrix-nginx-proxy` (e.g. Traefik -> `matrix-nginx-proxy` -> [Ntfy](docs/configuring-playbook-ntfy.md)). So, even if you opt into Traefik, you'll still see `matrix-nginx-proxy` being installed in local-only mode. This will improve with time.
|
||||
|
||||
Some services (like [Coturn](docs/configuring-playbook-turn.md) and [Postmoogle](docs/configuring-playbook-bridge-postmoogle.md)) cannot be reverse-proxied to directly from Traefik, so they require direct access to SSL certificate files extracted out of Traefik. The playbook does this automatically thanks to a new [com.devture.ansible.role.traefik_certs_dumper](https://github.com/devture/com.devture.ansible.role.traefik_certs_dumper) role utilizing the [traefik-certs-dumper](https://github.com/ldez/traefik-certs-dumper) tool.
|
||||
Some services (like [coturn](docs/configuring-playbook-turn.md) and [Postmoogle](docs/configuring-playbook-bridge-postmoogle.md)) cannot be reverse-proxied to directly from Traefik, so they require direct access to SSL certificate files extracted out of Traefik. The playbook does this automatically thanks to a new [com.devture.ansible.role.traefik_certs_dumper](https://github.com/devture/com.devture.ansible.role.traefik_certs_dumper) role utilizing the [traefik-certs-dumper](https://github.com/ldez/traefik-certs-dumper) tool.
|
||||
|
||||
Our Traefik setup mostly works, but certain esoteric features may not work. If you have a default setup, we expect you to have a good experience.
|
||||
|
||||
@ -1260,29 +1260,29 @@ Other roles which aren't strictly related to Matrix are likely to follow this fa
|
||||
|
||||
# 2023-01-26
|
||||
|
||||
## Coturn can now use host-networking
|
||||
## coturn can now use host-networking
|
||||
|
||||
Large Coturn deployments (with a huge range of ports specified via `matrix_coturn_turn_udp_min_port` and `matrix_coturn_turn_udp_max_port`) experience a huge slowdown with how Docker publishes all these ports (setting up firewall forwarding rules), which leads to a very slow Coturn service startup and shutdown.
|
||||
Large coturn deployments (with a huge range of ports specified via `matrix_coturn_turn_udp_min_port` and `matrix_coturn_turn_udp_max_port`) experience a huge slowdown with how Docker publishes all these ports (setting up firewall forwarding rules), which leads to a very slow coturn service startup and shutdown.
|
||||
|
||||
Such deployments don't need to run Coturn within a private container network anymore. Coturn can now run with host-networking by using configuration like this:
|
||||
Such deployments don't need to run coturn within a private container network anymore. coturn can now run with host-networking by using configuration like this:
|
||||
|
||||
```yaml
|
||||
matrix_coturn_container_network: host
|
||||
```
|
||||
|
||||
With such a configuration, **Docker no longer needs to configure thousands of firewall forwarding rules** each time Coturn starts and stops. This, however, means that **you will need to ensure these ports are open** in your firewall yourself.
|
||||
With such a configuration, **Docker no longer needs to configure thousands of firewall forwarding rules** each time coturn starts and stops. This, however, means that **you will need to ensure these ports are open** in your firewall yourself.
|
||||
|
||||
Thanks to us [tightening Coturn security](#backward-compatibility-tightening-coturn-security-can-lead-to-connectivity-issues), running Coturn with host-networking should be safe and not expose neither other services running on the host, nor other services running on the local network.
|
||||
Thanks to us [tightening coturn security](#backward-compatibility-tightening-coturn-security-can-lead-to-connectivity-issues), running coturn with host-networking should be safe and not expose neither other services running on the host, nor other services running on the local network.
|
||||
|
||||
## (Backward Compatibility) Tightening Coturn security can lead to connectivity issues
|
||||
## (Backward Compatibility) Tightening coturn security can lead to connectivity issues
|
||||
|
||||
**TLDR**: users who run and access their Matrix server on a private network (likely a small minority of users) may experience connectivity issues with our new default Coturn blocklists. They may need to override `matrix_coturn_denied_peer_ips` and remove some IP ranges from it.
|
||||
**TLDR**: users who run and access their Matrix server on a private network (likely a small minority of users) may experience connectivity issues with our new default coturn blocklists. They may need to override `matrix_coturn_denied_peer_ips` and remove some IP ranges from it.
|
||||
|
||||
Inspired by [this security article](https://www.rtcsec.com/article/cve-2020-26262-bypass-of-coturns-access-control-protection/), we've decided to make use of Coturn's `denied-peer-ip` functionality to prevent relaying network traffic to certain private IP subnets. This ensures that your Coturn server won't accidentally try to forward traffic to certain services running on your local networks. We run Coturn in a container and in a private container network by default, which should prevent such access anyway, but having additional block layers in place is better.
|
||||
Inspired by [this security article](https://www.rtcsec.com/article/cve-2020-26262-bypass-of-coturns-access-control-protection/), we've decided to make use of coturn's `denied-peer-ip` functionality to prevent relaying network traffic to certain private IP subnets. This ensures that your coturn server won't accidentally try to forward traffic to certain services running on your local networks. We run coturn in a container and in a private container network by default, which should prevent such access anyway, but having additional block layers in place is better.
|
||||
|
||||
If you access your Matrix server from a local network and need Coturn to relay to private IP addresses, you may observe that relaying is now blocked due to our new default `denied-peer-ip` lists (specified in `matrix_coturn_denied_peer_ips`). If you experience such connectivity problems, consider overriding this setting in your `vars.yml` file and removing certain networks from it.
|
||||
If you access your Matrix server from a local network and need coturn to relay to private IP addresses, you may observe that relaying is now blocked due to our new default `denied-peer-ip` lists (specified in `matrix_coturn_denied_peer_ips`). If you experience such connectivity problems, consider overriding this setting in your `vars.yml` file and removing certain networks from it.
|
||||
|
||||
We've also added `no-multicast-peers` to the default Coturn configuration, but we don't expect this to cause trouble for most people.
|
||||
We've also added `no-multicast-peers` to the default coturn configuration, but we don't expect this to cause trouble for most people.
|
||||
|
||||
|
||||
# 2023-01-21
|
||||
@ -2059,9 +2059,9 @@ Additional details are available in [Setting up Heisenbridge bouncer-style IRC b
|
||||
|
||||
# 2021-04-16
|
||||
|
||||
## Disabling TLSv1 and TLSv1.1 for Coturn
|
||||
## Disabling TLSv1 and TLSv1.1 for coturn
|
||||
|
||||
To improve security, we've [removed TLSv1 and TLSv1.1 support](https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/999) from our default [Coturn](https://github.com/coturn/coturn) configuration.
|
||||
To improve security, we've [removed TLSv1 and TLSv1.1 support](https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/999) from our default [coturn](https://github.com/coturn/coturn) configuration.
|
||||
|
||||
If you need to support old clients, you can re-enable both (or whichever one you need) with the following configuration:
|
||||
|
||||
@ -3184,11 +3184,11 @@ We've also started building our own Docker image of Ansible ([devture/ansible](h
|
||||
|
||||
# 2019-03-19
|
||||
|
||||
## TLS support for Coturn
|
||||
## TLS support for coturn
|
||||
|
||||
We've added TLS support to the Coturn TURN server installed by the playbook by default. The certificates from the Matrix domain will be used for the Coturn server.
|
||||
We've added TLS support to the coturn TURN server installed by the playbook by default. The certificates from the Matrix domain will be used for the coturn server.
|
||||
|
||||
This feature is enabled by default for new installations. To make use of TLS support for your existing Matrix server's Coturn, make sure to rebuild both Coturn and Synapse:
|
||||
This feature is enabled by default for new installations. To make use of TLS support for your existing Matrix server's coturn, make sure to rebuild both coturn and Synapse:
|
||||
|
||||
```sh
|
||||
ansible-playbook -i inventory/hosts setup.yml --tags=setup-coturn,setup-synapse,start
|
||||
@ -3198,9 +3198,9 @@ People who have an extra firewall (besides the iptables firewall, which Docker m
|
||||
|
||||
People who build their own custom playbook from our roles should be aware that:
|
||||
|
||||
- the `matrix-coturn` role and actually starting Coturn (e.g. `--tags=start`), requires that certificates are already put in place. For this reason, it's usually a good idea to have the `matrix-coturn` role execute after `matrix-nginx-proxy` (which retrieves the certificates).
|
||||
- the `matrix-coturn` role and actually starting coturn (e.g. `--tags=start`), requires that certificates are already put in place. For this reason, it's usually a good idea to have the `matrix-coturn` role execute after `matrix-nginx-proxy` (which retrieves the certificates).
|
||||
|
||||
- there are a few variables that can help you enable TLS support for Coturn. See the `matrix-coturn` section in [group_vars/matrix-servers](./group_vars/matrix-servers).
|
||||
- there are a few variables that can help you enable TLS support for coturn. See the `matrix-coturn` section in [group_vars/matrix-servers](./group_vars/matrix-servers).
|
||||
|
||||
|
||||
# 2019-03-12
|
||||
|
Reference in New Issue
Block a user