Sistema di telefonia integrata

Articolo
06/19/2008

Da Giulio Martino - IT Security e Network Manager - Technical Writer e Supporter di ISAServer.it

Progetto Voip

Il progetto è stato realizzato per conto di un distributore farmaceutico a valenza nazionale. L’infrastruttura prevede una sede master e 7 sedi periferiche sparse su tutto il territorio nazionale, connesse tra loro in vpn MPLS con infrastruttura cisco di proprietà e connettività telecom, con banda minima garantita :

Sede Master : 8 Mb totale con 4 Mb garantiti

Sedi Periferiche 1 Mb Garantiti

L’obbiettivo del progetto è di integrare il sistema di telefonia esistente con quello voip e di IM.

Introduzione

In questi ultimi anni, il termine Voip è entrato di prepotenza nella nostra vita.
I vari responsabili dei sistemi informativi aziendali, vengono sommersi da offerte e proposte per la migrazione dei sistemi di fonia su Ip, senza che i proponenti si rendano conto che a volte le soluzioni offerte (belle teoricamente) sono praticamente irrealizzabili.
Vi immaginate in una azienda con più di 50 telefoni e posto/i operatore, dalla sera alla mattina, sostituire tutto con un sistema totalmente nuovo ? A me viene la febbre solo a pensarci, sia in termini di costi, che in termini di produttività.
L'obiettivo principale di questo documento è quello di aprire uno spiraglio per la migrazione a sistemi di fonia Ip, illustrando come sia possibile farlo, non sostituendo tutto, ma bensì integrando. Per Sistema Integrato, intendo un sistema che mantenga inalterata l'infrastruttura telefonica esistente, aggiungendo "semplicemente" il supporto per il Voip.

Vantaggi:

Costo accessibile
Comunicazione tra sedi periferiche a COSTO ZERO
Nessuna interruzione/variazione delle attività aziendali (Produttività Massima)
Nuovi servizi di comunicazione

Esempio:

Se prendiamo un media azienda italiana con circa 50 interni per la sede master e 15 interni per le sedi periferiche; volendo prendere in esame una offerta di sostituzione totale degli impianti, tra hardware/software/licenze, bisognerebbe mettere a budget circa 100 mila Euro. A questo va aggiunto che il personale, da sempre, non "digerisce" bene i cambiamenti, creando tensioni e problemi che influiscono inesorabilmente sulla produttività personale, risolvibili in un lasso di tempo variabile che va dai sei ai dodici mesi.

VOIP: I componenti BASE dell'infrastruttura

iniziamo a vedere quali sono i componenti indispensabili per poter mettere in piedi un Sistema Integrato:

Il Centralino PBX tradizionale deve supportare il protocollo Qsig/S0 ETSI (PRI/BRI)
Il Centralino VOIP deve supportare il protocollo Qsig/S0 ETSI (PRI/BRI)
WAN (VPN) tra la sede master e le sedi periferiche

QSIG
Il Qsig è un protocollo indispensabile per mettere in comunicazione (Trunk) il centralino tradizionale con il centralino Voip.

S0 ETSI
Non supportato da tutte le schede ISDN BRI, puo’ essere una valida alternativa a QSIG.

PRI ISDN Card
La scheda PRI, viene usata per la connessione dei flussi telefonici, ed è in grado di gestire 30 canali contemporanei.

BRI ISDN Card
La scheda BRI, viene usata per la connessione delle linee digitali, ed è in grado di gestire 2 canali contemporanei.

Alcuni vendor, propongono soluzioni alternative per la connessione tra un PBX tradizionale e uno Voip, che prevedono l’uso di schede analogiche (FXO/FXS). Tranne che per casi eccezionali, se ne sconsiglia l’utilizzo, perché i problemi e le limitazioni ne impediscono un utilizzo efficace.

VOIP: I componenti della soluzione

Sede Master

Centralino tradizionale Avaya I55
Centralino Voip Avaya Ip Office 406 v2
Centralino Voip Asterisk

Sedi periferiche

Centralino Avaya Ip Office 406 v2

OSS: Con i componenti presentati in VOIP: I componenti dell'infrastruttura è possibile realizzare numerosi progetti di integrazione con qualsiasi hardware/software si voglia adottare.

Note sui componenti della soluzione:

PBX 155 Tradizionale
nessuna nota al riguardo, era un componente esistente della infrastruttura.

Ip Office 406 v2
La scelta di utilizzare avaya Ip Office come partner è legata a diversi fattori, uno dei fondamentali è che integrando in un unico prodotto sia la telefonia tradizionale che ip, nelle sedi periferiche con pochi interni e nelle sedi nuove, conviene installare/sostituire direttamente con Ip office, riciclando sicuramente tutti i telefoni\cordless BCA (Analogici), alcuni telefoni digitali, lasciando inalterati tutti i servizi presenti sul vecchio PBX. In questo modo possiamo evitare l’installazione di PC/Server aggiuntivi, evitanto tutti i problemi che cio’ comporterebbe.

Asterisk
La scelta di asterisk viene fuori dalla necessità di integrare nel nostro sistema anche altri protocolli Voip quali SIP e AIX, dando la possibilità anche attraverso internet di essere sempre raggiungibili e di poter effettuare chiamate.
La Ip Office a livello Voip lavora con il protocollo H323, e nella versione 4.0 ha aggiunto il supporto SIP (a pagamento) ma solo come trunk .

Quindi riassumendo avremo in tutte le sedi una Ip Office, in connessione Trunk H323 tra di loro; avremo dove il numero di interni non giustifica la sostituzione, un centralino tradizionale interfacciato con la Ip Office in Qsig; in una sola sede (la master) avremo anche un server Asterisk in Trunk H323 verso la Ip office e con il Sip e Aix attivato.

Nella figura seguente è riportato lo schema generale del nostro sistema:

fare clic sull'immagine per ingrandirla

Prima di procedere è necessario ed indispensabile chiarire alcuni aspetti:

Le sedi periferiche DEVONO essere connesse tra loro in VPN
Se la VPN non è gestita da ISA server, è indispensabile informare il server ISA della loro esistenza e di come raggiungerle, usando le route permanenti.
Per quanto riguarda internet la scelta consigliata resta la VPN (Client-Server), ma cercheremo di analizzare con i pro e i contro anche altri scenari.

La prima parte del nostro lavoro consisterà nel mettere in comunicazione tra loro i PBX IP Office sparsi nelle diverse sedi.

Rete IP Office

I punti base per mettere in connessione tra di loro le Ip Office sono:
1) Creazione delle Linee Ip (Trunk H323) tra le varie macchine
2) Creazione dei Codici Funzione che permettano l’indirizzamento delle chiamate interne in base al numero selezionato

Linee IP

Ogni linea Ip identifica una macchina remota, quindi se ho due macchine Ip da mettere in trunk tra di loro, dovro’ creare su entrambe un linea Ip che punti alla controparte.
Se le macchina Ip Office aumentano, lo scenario si complica e posso scegliere tra due modalità di configurazione possibili:

La prima configurazione (Non consigliata)
prevede la connessione diretta tra ogni macchina Ip Office e le altre presenti nella rete, più aumentano le macchine, più lo scenario diventa complesso e difficile da gestire. L’unico vantaggio che si avrebbe, è che in caso di rottura di una delle Ip Office, le altre continuerebbero a parlare tra loro.

fare clic sull'immagine per ingrandirla

La seconda configurazione
prevede l’individuazione di un centro stella (Es. la sede Master) che sia in grado di vedere tutte le macchine remote, e le macchine remote in grado di vedere solo il centro stella. In questo modo avremo una gestione più semplice della infrastruttura.
Lo svantaggio e che se la Ip Office della sede master muore, la comunicazione Voip tra tutte le sedi sarà OUT.

fare clic sull'immagine per ingrandirla

Noi useremo la seconda configurazione, usando come centro stella la Ip Office della sede Master che avrà tante linee Ip quante sono le Ip Office periferiche.

fare clic sull'immagine per ingrandirla

Nella configurazione della linea Ip bisognerà indicare l’indirizzo Ip della Ip Office remota e viceversa.

Codici Funzione
Grazie ai codici funzione, siamo in grado di indirizzare le chiamate su una Ip Office piuttosto che su un’altra, discriminando le route tramite il numero interno digitato. Nell’esempio riportato, avremo un codice funzione che indirizza tutte le chiamate interne che iniziano con 40, verso la Linea Ip che ha ID 40. L’id della linea Ip puo’ essere un valore numerico qualsiasi che viene definito in fase di creazione della stessa; nell’esempio ho usato un ID che rappresenta gli interni interessati.

fare clic sull'immagine per ingrandirla

Trunk IP Office

Una volta messe in rete le Ip Office, e abilitata la comunicazione tra di loro, passiamo al passo successivo che è quello di mettere in comunicazione la Rete Ip Office con il Pbx tradizionale e con il centralino Ip Asterisk.

Per realizzare questo avremo bisogno di creare due trunk:
1) Trunk digitale QSIG verso il PBX tradizionale
2) Trunk H323/SIP verso Asterisk

Trunk PBX Tradizionale
La connessione tra il PBX tradizionale e il PBX Voip (Ip Office), verrà fatto utilizzando delle schede di accesso primario (PRI) connesse tra loro in Qsig.

fare clic sull'immagine per ingrandirla

Realizzata la connessione Qsig, sarà necessario impostare l’instradamento delle chiamate. Per le chiamate da Ip Office verso PBX tradizionale useremo i codici funzione come nella figura seguente:

fare clic sull'immagine per ingrandirla

Fatto questo, il nostri sistemi (Voip e tradizionale) sono in connessione tra di loro, e sarà possibile chiamare da e per qualsiasi interno della WAN telefonica.

Trunk H323/SIP verso Asterisk
Prima di passare ad analizzare i passaggi fondamentali per la realizzazione del trunk, dobbiamo fare qualche considerazione.
Abbiamo usato H323, perché sulla Ip Office con versione software 3.xx il SIP non è implementato. Dalla versione software 4.x è stato aggiunto il supporto SIP ma solo come trunk, e tra l’altro a pagamento per connessioni contemporanee.
E’ chiaro che un trunk SIP, per tanti aspetti, è più performante del trunk H323, e sicuramente nelle prossime release di questo documento lo analizzeremo.

Asterisk in maniera nativa, prevede solo SIP e IAX. Il supporto H323 puo’ essere aggiunto in fase di compilazione di asterisk, linkando la libreria ooh323.so.

La libreria h323 fornita con gli add-on di asterisk, ha diversi limiti, ma per realizzare quello che ci server è più che sufficiente. Per chi desiderasse mettere in produzione un sistema simile, si consiglia di utilizzare delle librerie h323 per asterisk più complete.

Sulla Ip office dobbiamo creare un linea IP che punti al server asterisk come nella figura seguente:

fare clic sull'immagine per ingrandirla

Come si può notare dalla figura nel cerchio evidenziato in rosso, sono stato costretto a forzare la compressione su G711 uLaw 64K, questo per sopperire ad una prima limitazione della libreria ooh323 di asterisk, che non supporta per questo genere di trunk la scelta automatica della compressione.

Lato Asterisk il file ooh323.conf, che si trova nella dir /etc/asterisk dovrà essere modificato in questo modo:

[general]
faststart=yes
h425inSetup=yes
h245Tunnelling=yes
port=1720
bindaddr = 0.0.0.0
gateway=no
gatekeeper = DISABLE
;UserByAlias=no
Context=INTERNO
;----------------------------------------
; La parte che segue è fondamentale
; per il funzionamento del Trunk.
; Bisogna abilitare solo una codifica
; che potra essere ulaw/alaw
disallow=all
Allow=ulaw
;-----------------------------------------
musiconhold=default
;
;
; Qui definiamo il Trunk vero è proprio 
; con la Ip Office
[ipoffice]
type=peer
context=INTERNO
host=192.168.65.240
port=1720
ip=192.168.65.240
allow=ulaw
canreinvite=no
dtmfmode=rfc2833

Realizzato il trunk andremo a dire sia ad Ip Office che ad Asterisk per quali numerazioni ruotare le chiamate sul trunk, andando a modificare il file /etc/asterisk/extensions.conf aggiungendo le righe seguenti:

; definisce il contesto (vedi ooh323.conf)
; La numerazione che inizia con 9 seguita 
; da 3 digit è la numerazione SIP di asterisk
exten => _9XXX,1,Dial(SIP/${EXTEN})
; Le numerazioni che seguono sono le 
; sedi periferiche (Ip Office)
exten => _8XX,1,Dial(OOH323/${EXTEN}@ipoffice)
exten => _6XX,1,Dial(OOH323/${EXTEN}@ipoffice)
exten => _5XX,1,Dial(OOH323/${EXTEN}@ipoffice)
exten => _4XX,1,Dial(OOH323/${EXTEN}@ipoffice)
; Le numearioni che seguono sono per
; il PBX tradizionale
exten => _3XX,1,Dial(OOH323/${EXTEN}@ipoffice)
exten => _2XX,1,Dial(OOH323/${EXTEN}@ipoffice)
; Permette ai client SIP/AIX di fare 
; chiamate esterne attraverso 
; il PBX tradizionale
exten => _0.,1,Dial(OOH323/${EXTEN}@ipoffice)

A questo punto l’infrastruttura telefonica integrata di base è completa e non ci resta che estendere le funzionalità ai client SIP sparsi per il mondo, pubblicando il server Asterisk su Internet attraverso ISA server.

Microsoft ISA Server 2006

Una volta pubblicato Asterisk su internet, di fatto mettiamo a disposizione dei nostri client SIP sparsi per il mondo tutta l’infrastruttura telefonica realizzata fino ad ora.
La pubblicazione dei servizi Voip su Internet è la parte più complicata e piena di insidie. Dopo mesi di test, e nottate perse, sono arrivato alla conclusione che la soluzione migliore resta la VPN.

Prima di proseguire con la configurazione e per capire fino in fondo le scelte fatte, dobbiamo fare un po’ di teoria.

Protocollo SIP
SIP - Session Initiation Protocol - è descritto nell’RFC 3261, ed è un protocollo a livello Applicazione e non di trasporto. Questo significa, che il suo compito si ferma nel creare, modificare e terminare sessioni, mentre per tutto il resto si appoggia a protocolli specifici come ad esmpio RTP (Real-Time Transport Protocol).
Le applicazioni Voip utilizzano il protocollo RTP incapsulato in UDP. Cercando di semplificare il più possibile, focalizziamo la nostra attenzione su quelli che sono gli aspetti e gli elementi fondamentali per far si che la comunicazione avvenga con successo.
Due client per poter comunicare tra di loro, devono conoscere i reciproci indirizzi Ip e porte utilizzate per la connessione. Tutto questo in una WAN/LAN è possibile senza inconvenienti perché il traffico è di tipo routed, che fa si che i due client siano direttamente visibili l’uno dall’altro.

NAT - RFC 4008
Spostando lo scenario su Internet, come si puo ben comprendere le cose si complicano. Infatti l’elemento minimo che permette la navigazione è appunto il NAT (Network Address Translator) che si preoccupa di tradurre l’indirizzo ip privato del nostro client nell’indirizzo Ip pubblico del router e viceversa.

Possiamo dividere i tipi di NAT in 4 categorie fondamentali:

Full Cone

Questo tipo di NAT prevede una corrispondenza precisa IP+PORTA del client e IP+PORTA del router sia in uscita che in entrata. Questo significa che in uno scenario :Client A<= = Full Cone NAT = => Internet < = = Full Cone Nat = = > Client B è quasi come se il traffico tra client A e B fosse di tipo Routed. In questo caso, riusciremmo ad effettuare una conversazione VOIP.

Restricted Cone

Questa modalità prevede che il traffico in ingresso verso un determinato client della rete interna passa solo ed esclusivamente se la connessione è stata inizializzata dal client interno.

Port Restricted Cone

In questa modalità viene operata una ulteriore limitazione legata alla porta. Il traffico in ingresso verso un client potrà passare, solo ed esclusivamente se la richiesta è stata generata dal client interno sulla stessa porta della richiesta in ingresso.

Symmetric

Il symmetric è identico al Full Cone, quindi la combinazione IP+Porta del client interno viene replicata lato router.
La differenze sono due :

1) Ogni volta che cambia l’IP o la PORTA di destinazione viene generato un nuovo mapping

2) Solo l’host che ha ricevuto il pacchetto potrà rispondere su quella connessione

Microsoft ISA Server è un Symmetric NAT!!!

Chiariti questi aspetti, è evidente come in uno scenario con uno o più NAT tra il client ed Internet, rispettare la logica di comunicazione Voip diventa quasi impossibile.
Nella migliore delle ipotesi, si riuscirà a fare la chiamata, ma uno o entrambi gli interlocutori non riusciranno a sentire nulla.

Per risolvere questi problemi esistono diverse tecniche e strumenti, di seguito ne elenco qualcuno:
STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators
Il protocollo STUN prevedere un lato client - es. Il telefono Voip - e una parte Server che deve essere esposta direttamente su internet. Il server passerà al client messo dietro NAT, tutte quelle informazioni utili fare in modo che la comunicazione possa avvenire nelle logiche descritte sopra.
Il protocollo STUN funziona con tutti i tipi di NAT tranne che con il symmetric, e inoltre non supporta i firewall per le chiamate in ingresso.

TURN - Trasversal Using Relay NAT
E’ molto simile a STUN, risolve il problema dei NAT simmetrici. Non supporta i firewall per le connessioni in ingresso

ALG - Application Layer Gateway
E’ di fatto un firewall/NAT, e provvede ad intercettare e quindi riscrivere i pacchetti in transito.
Ad esempio ISA server potrebbe fare da ALG inserendo un application filter SIP. Per l’h323 ISA puo fare da ALG, solo che il filtro applicazione H323 ha un problema nella riscrittura degli header RTP(UDP) per i pacchetti in ingresso.

B2BUA - Back-to-Back User Agent
Intercetta tutte gli Invite SIP e agisce da vero e proprio endpoint.

Cercheremo di testare la maggior parte di questi sistemi, ma per completare questo documento e per avere un sistema sicuramente funzionante e monitorato approfondiremo lo scenario con delle VPN Client-Server.

fare clic sull'immagine per ingrandirla

Microsoft ISA Server VPN VOIP

[Creazione Vpn (Server)]

Isa server 2006 si appoggia ad RRAS per la gestione delle VPN. La configurazione deve essere fatta usando gli snap-in messi a disposizione dalla mmc di ISA.

fare clic sull'immagine per ingrandirla

Come si puo’ notare dalla immagine, vengono elencati in ordine tutti i passaggi da compiere per abilitare le VPN lato server.

Di seguito i passaggi fondamentali.

Abilitazione della VPN :

fare clic sull'immagine per ingrandirla

Oltre ad abilitare la VPN è possibile selezionare il numero massimo di connessioni contemporanee.

Gruppi Utenti abilitati :

fare clic sull'immagine per ingrandirla

In una struttura con Active Directory, in cui ISA server è un server membro di AD, è possibile specificare gruppi appartenenti appunto ad Active Directory. Nel caso in cui ISA non fosse un server membro di AD, andranno specificati Gruppi locali con la penale di non avere accesso alle risorse e alle politiche create in AD, oppure utilizzare l’autenticazione Radius.

Scelta dei protocolli:

fare clic sull'immagine per ingrandirla

I protocolli disponibili in una VPN Client-Server sono 2 :

PPTP (RFC: 2637)

Point to Point Tunneling Protocol , è stato sviluppato da Microsoft. Usa la porta TCP 1723 e il protocollo 47-GRE (RFC: 1701 e 1702). Non è uno standard riconosciuto dall’ IETF.

E’ considerato poco sicuro, non essendo in grado di garantire l’integrità dei dati.

Per approfondimenti : http://www.sans.org/resources/malwarefaq/pptp-vpn.php

L2TP(RFC:2661,3193) + IPSEC(RFC: 3931)

Layer 2 Tunneling Protocol , è uno standard riconosciuto, e usa la porta UDP 1701. Non implementa sistemi sicuri di autenticazione, e quindi se ne consiglia l’uso con IpSec.

IP Security è una suite di protocolli che provvedono ad autenticare e criptare ogni pacchetto IP.

Riepilogo Porte e Protocolli :

PPTP -> TCP porta 1723
PPTP -> Protocollo 47 (GRE) General Routing Encapsulation

L2TP -> UDP porta 1701
IpSec IKE -> UDP porta 500 to 500
IpSec NAT-T -> UDP porta 4500 to 4500
IpSec ESP -> Protocollo 50
IpSec AH -> Protocollo 51

Dominio :

fare clic sull'immagine per ingrandirla

Questa configurazione è importante in tutti quei casi dove il client non è in grado di fornire il nome del dominio di appartenenza.

VPN Listener :

fare clic sull'immagine per ingrandirla

Come si vede dalla figura, la scheda di rete external accetterà le connessioni in ingresso dei Client.

VPN IP Address:

fare clic sull'immagine per ingrandirla

In questo TAB è possibile gestire la classe IP da assegnare ai client in VPN. E’ possibile fare in modo che sia RRAS ad assegnare l’ip ai client della VPN, oppure tramite server DHCP interno. In tutti e due i casi è buona norma usare una classe ip diversa da quella/e assegnate alla LAN/WAN interna.

Metodi di Autenticazione :

fare clic sull'immagine per ingrandirla

MS-ChapV2 (RFC: 2759 )

E’ la versione Microsoft del protocollo Challenge Handshake Authentication , esegue l’autenticazione sia lato server che lato client, criptando i dati usando chiavi diverse per la ricezione e la trasmissione.

EAP (RFC: 3748)

Extensible Authentication Protocol, è considerato tra i più sicuri meccanismi di autenticazione, ed utilizza circa 40 metodi differenti di autenticazione.

MS-Chap (RFC:2433 )

E’ la prima versione Microsoft del protocollo Challenge Handshake Authentication , permette l salvataggio delle password in modalità irreversibile ed usa la criptatura dei dati.

Chap (RFC: 1994)

Challenge Handshake Authentication, tipicamnte usato nelle connessioni PPP, usa il modello three-way handshake per confermare l’autenticità del client.

SPAP

Shiva Password Authentication Protocol . Invia una password crittografata e reversibile al server di autenticazione. Una nota Microsoft avverte che l’uso del modello di autenticazione SPAP impedisce l’uso della crittografia MPPE del PPTP.

PAP

Password Authentication Protocol è il modello più semplice e meno sicuro di autenticazione e prevede l’invio in chiaro del nome utente e della password.

Pre-Shared Key

Prevede l’uso di un segreto condiviso da entrambi i lati. Abbassa notevolmente la sicurezza e se consiglia l’uso solo in casi estremi e per VPN Site-To-Site. Viene usato nelle connessione WiFi per l’autenticazione WEP, e da L2TP/IPSEC

Certificati

I certificati sono il sistema più sicuro, e microsoft mette a disposizione una CA di certificazione totalmente gratuita ed integrata nei sistemi operativi SERVER. E’ necessario installare un certificato computer usando il modello Administrator ed importarlo nei certificati trust del server ISA. Lato client sarà possibile richiedere sia certificati computer che utente, a seconda del livello di protezione e sicurezza desiderato.

[Creazione Vpn (Client)]

Lato client, per i dettagli sulla configurazione dei certificati e della VPN vi rimando a questo articolo : http://www.isaserver.it/articoli/20061118-GM02.htm

Invece vorrei focalizzare la vostra attenzione su due aspetti :

MS-CHAPv2 puo’ essere usato solo da client con Win2000, WinXP e Vista
Per la VPN L2TP/IPSEC in NAT, sul client è necessario fare le verifiche segnalate qui https://support.microsoft.com/?id=818043

Un volta configurata la VPN su ISA, verrà creato un oggetto network chiamato VPN-Client. Questo oggetto rappresenta tutti i client connessi in VPN al nostro server ISA. Per distinguere un client VPN da un altro, useremo i vantaggi di AD, e di ISA come server membro di AD, distinguendo i client in base all’utente connesso. In sostanza quello che faremo sarà di creare due access rule:

Access Rule limitata solo per traffico SIP
Access Rule che abilita tutto il traffico interno e internet

Chiaramente questo rappresenta solo un esempio sul quale costruire scenari più complessi in base alle esigenze, e serve per far vedere come disciplinare i permessi in base all’utente che si collega in VPN.

Prima access rule

Definizione del protocollo SIP
Definizione del protocollo RTP
Definizione del Server Asterisk
Definizione del gruppo AD UtentiVoipVPN

Definizione Protocollo SIP

fare clic sull'immagine per ingrandirla

Definizione Protocollo RTP

fare clic sull'immagine per ingrandirla

Definizione Asterisk

fare clic sull'immagine per ingrandirla

Definizione Gruppo Utenti Solo VOIP

fare clic sull'immagine per ingrandirla

Access Rule solo VOIP
Una volta definiti gli elementi necessari, possiamo creare la nostra access rule, che consenta solo traffico SIP tra il client VPN ed asterisk.

General	VPN Client SIP Only
Action	Allow
Protocols	SIP, RDP
From	VPN Client
To	Asterisk
User	Utenti_VPN

fare clic sull'immagine per ingrandirla

A questo punto tutti gli utenti che fanno parte del gruppo selezionato che entreranno in VPN potranno fare solo ed esclusivamente traffico SIP tra il loro client e il server Asterisk. IN questo modo, anche nella condizione estrema in cui il client fosse invaso da virus, la nostra rete sarebbe sicura per tre motivi fondamentali:

La regola consente solo i protocolli selezionati
La regola nega tutto il traffico verso gli altri host della LAN/WAN
Il server Asterisk se installato su Linux senza Samba e/o NFS (Network File System), non consentirà la propagazione di alcun virus, data la differenza del file system, e anche dove ci fosse un buffer overflow, essendo il server fuori dominio, di fatto sarebbe un guest e quindi potenzialmente molto poco pericoloso.

Per verificare che effettivamente la access rule funzioni, dal client in VPN con utente ristretto basta fare due ping:

Primo ping verso un host esterno per verifica di non avere accesso ad internet

fare clic sull'immagine per ingrandirla

Secondo Ping verso un il server asterisk:

fare clic sull'immagine per ingrandirla

Ora verifichiamo che il client SIP (nell esempio abbiamo usato X-Lite) si connetta al server Asterisk e faccia le chiamate:
Registrazione

fare clic sull'immagine per ingrandirla

Registrato

fare clic sull'immagine per ingrandirla

Chiamata in corso

fare clic sull'immagine per ingrandirla

Chiamata in conversazione

fare clic sull'immagine per ingrandirla

Seconda Access Rule:

General	VPN Client
Action	Allow
Protocols	*<Protocolli Desiderati>*
From	VPN Client
To	*Internal*
User	*Utenti_VPN_Full*

La seconda access rule serve per dare un accesso avanzato ad utenti particolari in VPN. Rispetto alla prima access rule andranno modificati solo i campi della seconda colonna evidenziati.

To Do

Nei prossimi mesi andremo ad analizzare nei dettagli, i seguenti scenari :

[Integrazione con Provider SIP Esterni]

Con l’ausilio di ISA server, vedremo come integrare nella nostra infrastruttura telefonica, i provider di telefonia SIP.

fare clic sull'immagine per ingrandirla

[Integrazione con LCS 2005]

Installeremo e configureremo LCS2005 e vedremo se e come è possibile integrarlo nel sistema di telefonia, e come pubblicarne i servizi tramite ISA server.

fare clic sull'immagine per ingrandirla

[Avaya]

Analizzeremo la nuova versione software (4.0) , integrando il tutto con AD tramite Ldap.

fare clic sull'immagine per ingrandirla

Conclusioni

In questo documento abbiamo esaminato per grandi linee, una parte degli aspetti legati alla comunicazione Voip, in LAN/WAN/INTERNET. In seguito cercheremo di esaminare anche altri scenari, in modo da avere una prospettiva a 360° degli scenari, dei problemi riscontrati e di come affrontarli.