Distribuzione di più MCU 3CX e motori di trascrizione AI in una singola LAN.

Quando si eseguono più istanze di servizi che richiedono FQDN rivolti al pubblico e certificati SSL, la gestione dei certificati può rappresentare una sfida.

Per fornire esempi significativi di ciò che è possibile e non è possibile ottenere, utilizzeremo uno scenario comune come punto di partenza, per poi approfondire come le variazioni influiscano sulla strategia di gestione dei certificati SSL.

Configurazione di esempio comune
Per spiegare meglio la situazione, prenderemo in considerazione una configurazione con 3 macchine all’interno della stessa LAN locale:

  • 3CX PhoneSystem – Indirizzo IP 192.168.0.10
  • 3CX On-Board MCU – Indirizzo IP 192.168.0.20
  • 3CX On-Board AI – Indirizzo IP 192.168.0.30

FQDN forniti da 3CX

La distribuzione standard di 3CX utilizza un client ACME personalizzato per fornire e rinnovare automaticamente i certificati Let’s Encrypt. Questo metodo lega il certificato direttamente all’installazione 3CX e all’FQDN. Vi sono 3 requisiti come descritto di seguito:

1. Indirizzi IP pubblici dedicati

Affinché questa configurazione funzioni, ciascuna di queste 3 macchine richiederà un indirizzo IP pubblico dedicato; si consideri questo esempio:

FQDN Sistema Indirizzo IP LAN Indirizzo IP pubblico
mypbx.3cx.com.cy 3CX PhoneSystem 192.168.0.10 20.20.20.20
mymcu.my3cx.net (assegnato automaticamente) 3CX On-Board MCU 192.168.0.20 20.20.20.21
myai.my3cx.net (assegnato automaticamente) 3CX On-Board AI 192.168.0.30 20.20.20.22

2. Split DNS

Il server DNS della LAN deve essere configurato per garantire che:

  • All’interno della LAN, i tuoi FQDN si risolvano nei loro indirizzi IP LAN
  • All’esterno della LAN, i tuoi FQDN si risolvano nei loro indirizzi IP PUBBLICI

Il modo più semplice per farlo è creare record A (o AAAA) specifici per l’FQDN per le macchine LAN, dove il server DNS locale è configurato come segue:

  • FQDN: mypbx.3cx.com.cy – 3CX PhoneSystem – Indirizzo IP 192.168.0.10
  • FQDN: mymcu.my3cx.net – 3CX On-Board MCU – Indirizzo IP 192.168.0.20
  • FQDN: myai.my3cx.net – 3CX On-Board AI – Indirizzo IP 192.168.0.30

Queste configurazioni sono indicate con nomi diversi, tra cui:

  • Zone DNS Pinpoint
  • Response Policy Zone (RPZ)
  • DNS Split-Horizon o Views
  • Zone Shadow

3. Port Forwarding per l’aggiornamento automatico del certificato

Sarà necessario configurare il firewall o il router di bordo per:

  • Inoltrare tutto il traffico (per mymcu.my3cx.net) da 20.20.20.21:80 a 192.168.0.20:80
  • Inoltrare tutto il traffico (per mymcu.my3cx.net) da 20.20.20.22:80 a 192.169.0.30:80

Ciò consentirà a Let’s Encrypt di raggiungere la macchina per gli aggiornamenti dei certificati.

Il sistema 3CX (mypbx.3cx.com.cy) non richiede questo port forwarding poiché sfrutta l’infrastruttura Cloud di 3CX per aggiornare i certificati dei suoi FQDN 3CX.

NOTA: Se non si è in grado di fornire indirizzi IP pubblici distinti a tutte le macchine MCU e/o IA all’interno della LAN, allora DOVRETE utilizzare i vostri FQDN personalizzati.

FQDN personalizzati che utilizzano Let’s Encrypt con automazione DNS

Questo approccio è adatto se si hanno tutte e tre le macchine 3CX nella LAN e nessuna è direttamente raggiungibile dalla rete internet pubblica. Ciò richiede una configurazione manuale al di fuori della configurazione standard di 3CX. Ai fini di questo esempio, ipotizzeremo i seguenti FQDN:

  • mypbx.example.com
  • mymcu.example.com
  • myai.example.com

Come in precedenza, vi sono dei requisiti da seguire descritti di seguito:

1. Script di automazione

Sarà necessario creare uno script di automazione su una macchina nella LAN che:

  • Utilizzi il meccanismo di challenge DNS-01 di Let’s Encrypt
  • Venga eseguito periodicamente per garantire il rinnovo anticipato dei certificati
  • Comunichi con Let’s Encrypt per richiedere il rinnovo del certificato
  • Comunichi con le API del tuo provider DNS per creare i record necessari per la verifica di Let’s Encrypt
  • Salvi il file PEM del certificato scaricato e il file KEY in una cartella; ad esempio:
/etc/letsencrypt/live/mymcu.example.com/fullchain.pem
/etc/letsencrypt/live/mymcu.example.com/privkey.pem

2. Script di aggiornamento del certificato

Successivamente, dovrete creare uno script di aggiornamento del certificato che:

  • Controlli la presenza di nuovi file di certificato
  • Se li trova, li copi nelle destinazioni corrette
  • Elimini i file sorgente per evitare di copiarli di nuovo inutilmente a ogni esecuzione

Ecco un esempio di script per la macchina mymcu.example.com che potreste salvare in “/root/certupdate.sh”:

#!/bin/bash
cp /etc/letsencrypt/live/mymcu.example.com/fullchain.pem /opt/3cxwm/cert/server.crt
cp /etc/letsencrypt/live/mymcu.example.com/privkey.pem /opt/3cxwm/cert/server.key
chown www-data:www-data /opt/3cxwm/cert/server.*
chmod 600 /opt/3cxwm/cert/server.*

Impostate i permessi corretti per lo script:

chmod +x /root/certupdate.sh

…e aggiungetelo al vostro crontab per eseguirlo, ad esempio, ogni mattina alle 3:00.

FQDN personalizzato – Rinnovo manuale del certificato

Se siete limitati al rinnovo manuale del certificato, ad esempio perché il vostro provider DNS non dispone di API per l’automazione, e possibilmente anche perché state utilizzando certificati wildcard, la procedura è essenzialmente la stessa di cui sopra, con la differenza che dovrete eseguire le modifiche manualmente anziché godere dei vantaggi dell’automazione.

Autorità di certificazione (CA) alternativa

Per CA diverse da Let’s Encrypt, forniamo una guida generale con consigli su come scegliere quale utilizzare qui.