MRA: flusso di registrazione e Collab Edge

MRA in breve

Mobile and Remote Access (MRA) è l’architettura Cisco che consente a un client (Jabber, Webex App in modalità UC o endpoint Cisco) di registrarsi a CUCM e usare i servizi di collaboration da Internet senza VPN. Il traffico non entra mai direttamente nella LAN: viene mediato dalla coppia Expressway-E (in DMZ) ed Expressway-C (interna), che fanno da proxy applicativo sicuro. È l’evoluzione del vecchio accesso VPN-less: il tunnel è sostituito da una secure traversal zone fra le due Expressway.

Il flusso di registrazione

1. Il client esterno risolve il record DNS pubblico _collab-edge._tls.<dominio>, che punta a Expressway-E sulla porta 8443.
2. Stabilisce una connessione TLS verso Expressway-E in DMZ, scarica la configurazione (get_edge_config) e negozia i certificati.
3. Expressway-E inoltra la richiesta a Expressway-C attraverso la Unified Communications traversal zone (TLS su 7001).
4. Punto chiave del firewall interno: è Expressway-C ad aprire la connessione verso Expressway-E (modello traversal client → server). Nessuna porta in ingresso viene aperta dalla DMZ verso la LAN.
5. Expressway-C proxa la registrazione SIP e le richieste HTTP verso CUCM, che autentica e registra il dispositivo.
6. Segnalazione di ritorno e media seguono lo stesso percorso a ritroso.

_collab-edge._tls.example.com  SRV  8443  expe.example.com   ← client ESTERNO
_cisco-uds._tcp.example.com    SRV  8443  cucm.example.com    ← client INTERNO

Quali servizi attraversano Collab Edge

Secure registration e media SRTP

MRA è secure by design: la registrazione avviene sempre su TLS e il media è cifrato con SRTP sul tratto esterno. Le Expressway impongono la cifratura anche se CUCM è in modalità Non-Secure, perché il segmento Internet-DMZ è considerato non fidato. Il media RTP/SRTP dei client esterni è gestito da Expressway-E sul large port range UDP di default 36000-59999. I certificati sono centrali: il SAN di Expressway-E deve includere il dominio del record _collab-edge e i FQDN dei servizi, altrimenti il TLS handshake fallisce.

Registrazione interna vs Collab Edge

Un client dentro la LAN risolve _cisco-uds._tcp.<dominio> e si registra direttamente a CUCM, senza toccare le Expressway. All’avvio il client interroga entrambi i record: se _cisco-uds è raggiungibile sceglie il percorso interno; se risponde solo _collab-edge, attiva MRA. Questo “edge detection” automatico rende il client roaming senza intervento dell’utente.

Trappole tipiche d’esame

• Scenario: “gli utenti in smart working devono usare Jabber, quale VPN configuro?” → Risposta giusta: nessuna. MRA nasce apposta per essere VPN-less; introdurre una VPN è l’errore.
• Scenario: un utente in ufficio si registra e il traffico passa dalle Expressway. → Errato: i client interni si registrano direttamente a CUCM via _cisco-uds. Se passano da Collab Edge, il DNS interno (split-DNS) è mal configurato.
• Scenario: bisogna aprire porte in ingresso dal firewall interno, dalla DMZ verso CUCM. → No: è Expressway-C ad aprire la sessione verso Expressway-E; il firewall interno consente solo traffico in uscita (traversal client → server), nessun pinhole verso la LAN.
• Scenario: un telefono SCCP non si registra via MRA. → Comportamento atteso: MRA supporta solo SIP. La soluzione è migrare l’endpoint a SIP.
• Scenario: TLS handshake fallisce dall’esterno. → Verificare i certificati di Expressway-E: il SAN deve contenere il dominio del record _collab-edge e i FQDN dei servizi; un certificato incompleto blocca la secure registration.