Ayuda al configurar el Motor de alto rendimiento en nextcloud dentro de truenas

Hola quisiera una aseoria de que camino seguir para resolver mi problema, primero les cuento como tengo instalado mi nextcloud y las configuraciones que tengo.
Tengo mi truenas el cual accedo a el de manera local con la direccion ip https://192.168.1.228 y dentro instalo nextcloud del catalogo y accedo mediante la ip https://192.168.1.228:30027 a continuacion les muesto la configuración dentro de truenas y tmb la configuracion de mi archivo config.php

<?php
$CONFIG = array (
  'htaccess.RewriteBase' => '/',
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'apps_paths' => 
  array (
    0 => 
    array (
      'path' => '/var/www/html/apps',
      'url' => '/apps',
      'writable' => false,
    ),
    1 => 
    array (
      'path' => '/var/www/html/custom_apps',
      'url' => '/custom_apps',
      'writable' => true,
    ),
  ),
  'memcache.distributed' => '\\OC\\Memcache\\Redis',
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'redis' => 
  array (
    'host' => 'redis',
    'password' => '12345',
    'port' => 6379,
  ),
  'trusted_proxies' => 
  array (
    0 => '127.0.0.1',
    1 => '192.168.0.0/16',
    2 => '172.16.0.0/12',
    3 => '10.0.0.0/8',    
  ),
  'upgrade.disable-web' => true,
  'passwordsalt' => 'TvC+3hZ6reFd8YA0J2niMzroUyYTvY',
  'secret' => 'dqZTS8K4FAHNBYNfOlvBCijsbrxY/4SU7VQ5XL8GlZA14l5c',
  'datadirectory' => '/var/www/html/data',
  'dbtype' => 'pgsql',
  'version' => '31.0.9.1',
  'dbname' => 'nextcloud',
  'dbhost' => 'postgres:5432',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'dbuser' => 'oc_admin',
  'dbpassword' => 'S8eB6PVokl21rlHq2mFr2x81l1PN0i',
  'installed' => true,
  'instanceid' => 'ochbzcy0v0jf',
  'overwrite.cli.url' => 'https://192.168.1.228:30027',
  'overwritehost' => '192.168.1.228:30027',
  'loglevel' => 2,
  'maintenance_window_start' => 1,
  'default_phone_region' => 'MX',
  'overwriteprotocol' => 'https',
  'mail_smtpmode' => 'smtp',
  'mail_sendmailmode' => 'smtp',
  'mail_smtphost' => 'mail.xxxx.mx',
  'mail_smtpauth' => 1,
  'mail_smtpport' => '465',
  'mail_smtpsecure' => 'ssl',
  'mail_from_address' => 'correo',
  'mail_domain' => 'xxxx.gob.mx',
  'mail_smtptimeout' => 30,
  'mail_smtpname' => 'xxxxx.gob.mx',
  'mail_smtppassword' => '12345',
  'trusted_domains' => 
  array (
    0 => '127.0.0.1',
    1 => '192.168.1.228',
    2 => '192.168.1.228:30027',
    3 => 'localhost',
    4 => 'nextcloud',
  ),
);

y con esas configuraciones ya tengo instalado nextcloud, entonces habilito talk dentro de nextcloud para acceder al panel de talk https://192.168.1.228:30027/apps/spreed/, entonces leo esta docuemtancion para configurar el motor de alto rendimiento y me baso en ello Quick install - Nextcloud Talk API documentation, pero el que sigo en realidad es este enlace How to configure talk HPB with Docker · nextcloud-snap/nextcloud-snap Wiki · GitHub dejando mi compose para mi motor de alto rendiemiento de esta manera

name: ‘hpb’

services:
nc-talk:
container_name: talk_hpb
image: ghcr.io/nextcloud-releases/aio-talk:latest
init: true
ports:
- 3478:3478/tcp
- 3478:3478/udp
- 8080:8081/tcp
environment:
- NC_DOMAIN=192.168.1.228:30027
- TALK_HOST=192.168.1.228:30027
- TURN_SECRET=caab86ee37253e031219182aaf3b214326c2bbfadda4bd5b76d796c0140ebbd5
- SIGNALING_SECRET=debc425db948b7658ce5bd83d4c2a374e5dcac202f7bfeb2b1f5ffe3dc277f82
- INTERNAL_SECRET=4962613579fc7ea92d86967087b623864fc7274cac05c0a442c06e9e7aafb9d9
- TALK_PORT=3478
- TZ=America/Mexico_City
restart: unless-stopped

una vez que creo mi contedor con ese compose, pruebo esto
root@truenas:/home/truenas_admin# curl http://localhost:8181/api/v1/welcome
{“nextcloud-spreed-signaling”:“Welcome”,“version”:“2.0.4~docker”}
root@truenas:/home/truenas_admin# curl https://localhost:8181/api/v1/welcome
curl: (35) OpenSSL/3.0.15: error:0A00010B:SSL routines::wrong version number
y por lo tanto al configurar mi motor de alto rendimiento falla diciendo esto

tambien trate de configurar el proxy nginx que viene dnetro de la instalacion de nextcloud en la opcion de Custom Nginx Configurations y agregando la ruta para mi arhcivo nginx-custom.conf basandome tmb en este enalce https://github.com/strukturag/nextcloud-spreed-signaling
tambien probe dentro del contendor para mi motor de alto rendimiento ahi configurar el nginx ya que el nginx que se instala con la aplicaicon de nextcloud dentro de truenas no me deja utilizar varios comandos esta limitado, entonces hice esto tambien

name: hpb
services:
nc-talk:
container_name: talk_hpb
environment:
- NC_DOMAIN=192.168.1.228:30027
- TALK_HOST=talk_hpb
- >-
TURN_SECRET=caab86ee37253e031219182aaf3b214326c2bbfadda4bd5b76d796c0140ebbd5
- >-
SIGNALING_SECRET=debc425db948b7658ce5bd83d4c2a374e5dcac202f7bfeb2b1f5ffe3dc277f82
- >-
INTERNAL_SECRET=4962613579fc7ea92d86967087b623864fc7274cac05c0a442c06e9e7aafb9d9
- TALK_PORT=3478
- TZ=America/Mexico_City
image: ghcr.io/nextcloud-releases/aio-talk:latest
init: True
ports:
- 3478:3478/tcp
- 3478:3478/udp
restart: unless-stopped
nginx-proxy:
container_name: nginx_hpb
depends_on:
- nc-talk
image: nginx:alpine
ports:
- ‘8443:443’
- ‘8080:8080’
restart: unless-stopped
volumes:
- >-
/mnt/Pool6x1TB/Applications/Nextcloud/custom/nginx-hpb.conf:/etc/nginx/nginx.conf:ro
- /mnt/Pool6x1TB/Applications/Nextcloud/Certificados:/etc/nginx/certs:ro

y entonces cree un nginx-custom.conf en el cual ya podia usar mas comandos quedando de esta manera

events {}
http {
    server {
      listen 443 ssl;
      server_name 192.168.1.228;
      ssl_certificate /etc/nginx/certs/CA_Local_Nextcloud.crt;
      ssl_certificate_key /etc/nginx/certs/CA_Local_Nextcloud.key;
    
    location /api/v1/ {
        proxy_pass http://nc-talk:8081/api/v1/;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

server {
    listen 8080;

    server_name 192.168.1.228;

    location /api/v1/ {
        proxy_pass http://nc-talk:8081/api/v1/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}
}

y probe y me resulto esto
root@truenas:/home/truenas_admin# curl -k https://192.168.1.228:8443/api/v1/welcome
{“nextcloud-spreed-signaling”:“Welcome”,“version”:“2.0.4~docker”}
root@truenas:/home/truenas_admin# curl http://192.168.1.228:8080/api/v1/welcome
{“nextcloud-spreed-signaling”:“Welcome”,“version”:“2.0.4~docker”}
y pruebo otra vez talk y me sale esto

Espero me pudieran orientar sobre que podria estar pasando y por que camino seguir poder solucionarlo, de antemano gracias

I’m sorry my Spanish is not the best but most likely your problem is you are tying to setup the system using local ip address. This means you don’t have valid public TLS certificate which makes TLS connection impossible (by default). Technically it is possible but as long you don’t have very strong knowledge about self-signed-certificate you should avoid them.

I would recommend you switch to public DNS domain and use real TLS certificates as first step.

Thanks for your comment, I’ll try with a DNS domain to compare the results.

My point:

I have my Nextcloud/Talk HPB server running on a local IP (192.168.x.x) with a self-signed certificate:

  • On a client where the certificate is manually installed, the WebSocket connection with the HPB works correctly.

  • On another client where the certificate is not installed, the connection fails even though the HPB is already configured on the server, because the browser rejects the certificate.

Inside the TrueNAS server, this is reflected using curl:

# Ignoring certificate validation works
curl -k https://192.168.1.228:8443/api/v1/welcome
{"nextcloud-spreed-signaling":"Welcome","version":"2.0.4~docker"}

# Validating the certificate fails
curl https://192.168.1.228:8443/api/v1/welcome
curl: (60) SSL certificate problem: unsuitable certificate purpose

The first test works because -k forces the connection and ignores the certificate; the second fails because the self-signed certificate is not trusted by the system. This explains why each client needs to explicitly trust the certificate for the HPB to work correctly.

1 Like

this is exactly the point with self-signed and other non-public TLS certificates - you must manage the client to make it work. this might be OK for enterprises with devices under control but makes it more or less no-go for private and SoHo installations