🔐 Interni Remoti nel VoIP: cosa sapere prima di farli funzionare davvero
Collegare interni remoti nel VoIP non è solo una questione di SIP e password. Il vero nodo è tutto ciò che sta nel mezzo: NAT, ACL, sicurezza e tipo di centralino.
Chi lavora con appliance UCM on-premise, sa che spesso gli interni locali funzionano al primo colpo, ma appena si esce in rete pubblica iniziano i problemi: audio monodirezionale, registrazioni instabili, telefoni che si registrano e dopo un po’ spariscono.
Con un PBX in Cloud (come CloudUCM di Grandstream), il discorso cambia: è il sistema stesso ad aspettarsi NAT e connessioni da reti diverse. Questo rende la gestione degli interni remoti molto più stabile, ma resta fondamentale configurare bene il telefono, specialmente lato SIP NAT.
🧭 Modalità di NAT compatibili con SIP
Il protocollo SIP non è nato per attraversare NAT. Ecco perché bisogna scegliere con cura:
- Full Cone NAT (o NAT 1:1) → funziona, ma è raro trovarlo
- Port Restricted Cone NAT / Symmetric NAT → i più diffusi, ma pongono limiti
- ALG (Application Layer Gateway) → spesso da disattivare, crea più problemi che soluzioni
- NAT Keep-Alive / Reregistration → da abilitare sempre per mantenere viva la sessione
I telefoni vanno configurati per segnalare correttamente IP e porta pubblica, oppure vanno supportati da sistemi cloud che gestiscono automaticamente il traversing (come RemoteConnect o STUN/TURN ben configurati).
🛡 ACL e sicurezza: il NAT va bloccato e gestito
Attivare interni remoti senza un controllo IP lato ACL è come lasciare la porta del PBX aperta su Internet.
Ogni indirizzo IP esterno andrebbe inserito tra quelli autorizzati (whitelist). I centralini moderni come UCM630X permettono di:
- definire ACL specifiche per tipo di traffico (SIP, RTP)
- abilitare Geo-IP per restringere l’accesso ai soli Paesi desiderati
- attivare MFA e regole Fail2Ban per bloccare tentativi sospetti
Senza questo, gli interni remoti sono instabili e mal funzionanti.
🧠 Se non funziona, il problema è fuori dal centralino
Il VoIP remoto non fallisce per colpa del PBX. Fallisce per:
• Router con NAT errato
• Firewall che blocca o apre troppo
• IP pubblico non presente o nattato
• Timeout sbagliati
• ACL mal impostate
La sicurezza e l’affidabilità del VoIP remoto non si improvvisano. Serve metodo, serve visione.
E ogni dettaglio – dal tipo di router al timeout del keep-alive – fa la differenza.
Noi di impianti.tel queste cose le vediamo tutti i giorni.
Se hai interni remoti che non vanno, scrivici.