View
270
Download
20
Category
Preview:
Citation preview
Université HASSAN 1er – Settat
Ecole Nationale des Sciences Appliquées-Khouribga
Année universitaire : 2013/2014
Mise en place d’une solution ToIP OpenSource
avec :
Asterisk
Réalisé par :
Seddik DAYA
Abdessamad CHBICHEB
Khalid BENAYAD
Didi OUELD ELMOUSTAPHA
Encadré par :
Pr. Mohammed MOUGHIT
Remerciements
Nous remerciements s’orientent vers Monsieur MOUGHIT qui nous a proposé ce sujet
sur la ToIP. Il nous a guidés tout au long de notre projet afin de nous orienter sur les points
essentiels à étudier. Nous le remercions donc pour sa disponibilité et les précisions apportées
aux différentes étapes de notre projet.
Sommaire
Lexique 07
Introduction 06
1. Présentation 07
1.1. La téléphonie IP 07
1.1.1. Fonctionnement 07
1.1.2. Intérêts 09
1.1.3. Différence PABX / IPBX 09
1.2. Les protocoles 11
1.2.1. SIP / H323 11
1.2.2. RTP / RTCP 14
1.2.3. IAX 16
2. Asterisk 18
2.1. Généralités 18
2.1.1. Présentation 18
2.2.2. Fonctionnalités 18
2.2. Mise en place du serveur 19
2.2.1. Carte FXO / FXS 19
2.2.2. Installation et configuration du serveur et Clients SIP 20
3. Applications 33
3.1. Architecture locale 33
3.1.1. Schéma du réseau 33
3.1.2. Configuration du serveur 33
3.1.3. Configuration des clients 35
3.1.4. Transfert d’appels 39
3.2. Architecture étendue 41
3.2.1. Freephonie 41
3.2.2. Sécurité : Avec Firewall 42
3.3.3. Sécurité avec tunnel VPN IPSec 45
Conclusion 49
Lexique
ASCII : (American Standard Code for Information Interchange) est la norme de codage
de caractères en informatique la plus connue et la plus largement compatible.
Chipset : jeu de composants électroniques intégré dans un circuit intégré
préprogrammé permettant de gérer les flux de données numériques entre le ou les
processeur(s), la mémoire et les périphériques.
Codecs : désigne un procédé capable de compresser ou de décompresser un signal,
analogique ou numérique.
Firewall : élément du réseau informatique, logiciel et/ou matériel, qui a pour fonction
de faire respecter la politique de sécurité du réseau, celle-ci définissant quels sont les
types de communication autorisés ou interdits.
Freephonie : un service téléphonique de l'opérateur Free, c'est une offre de téléphonie
sur IP.
FXO : l’interface Foreign eXchange Office est un port qui reçoit la ligne téléphonique.
FXS : l’interface Foreign eXchange Subscriber est un port qui raccorde la ligne
téléphonique de l’abonné.
HTTP : HyperText Transfer Protocol, est un protocole de communication client-serveur
développé pour le World Wide Web.
IP : Internet Protocol, est un protocole de communication de réseau informatique.
IPBX : système utilisé en entreprise qui assure l'acheminement de toute ou partie des
communications en utilisant le protocole internet (IP), en interne sur le réseau local
(LAN) ou le réseau étendu (WAN) de l'entreprise.
LAN : Local Area Network, désigne un réseau informatique d'échelle géographique
restreinte.
PABX : Private Automatic Branch Exchange est un Multiplexeur Téléphonique privé.
RTC : Le réseau téléphonique commuté est le réseau du téléphone fixe et mobile.
TCP : Transmission Control Protocol, est un protocole de transport fiable, en mode
connecté.
UDP : User Datagram Protocol est un des principaux protocoles de télécommunication
utilisé par Internet. Contrairement au protocole TCP, il travaille en mode non-
connecté.
WAN : Wide Area Network, est un réseau informatique couvrant une grande zone
géographique, typiquement à l'échelle d'un pays, d'un continent, voire de la planète
entière. Le plus grand WAN est le réseau Internet.
Introduction
L'évolution des télécommunications fait que les centraux téléphoniques ont subi de
nombreuses évolutions, notamment l'arrivée des IPBX qui a permis l'interconnexion du réseau
téléphonique avec le réseau de données. Ceci permet aux entreprises de réduire les coûts et
de faciliter l'administration. Notre but a donc été de mettre en place un IPBX dans un
environnement « Open Source », c'est-à-dire qu’aucun investissement financier n’est
nécessaire pour le fonctionnement de la maquette basique.
Durant la réalisation du projet, nous avons appris à maitriser le logiciel et ainsi s’en
servir de la façon la plus optimale. Le test de certaines fonctionnalités indispensables comme
la messagerie ou le transfert d’appel a été réalisé et validé. La compatibilité avec des
téléphones IP Cisco a aussi été approuvée. Au niveau de la sécurité, qui est un point
fondamental, nous avons utilisé plusieurs méthodes telles qu’un firewall, VPN IPSec afin de
protéger des attaques notre installation.
Nous avons décidé de diviser notre rapport en 3 parties distinctes. Dans un premier
temps, nous allons vous parler de la téléphonie IP en la définissant et en présentant la
différence avec la téléphonie classique. Les protocoles associés à la ToIP comme SIP et RTP
seront ici aussi présentés. La seconde partie du document va présenter l’application qui nous
a permis de réaliser notre projet. En effet, nous allons décrire le serveur Asterisk en détaillant
son installation, sa configuration ainsi que ses fonctionnalités. La présentation des clients
utilisés dans la maquette sera abordée dans cette partie. Pour terminer, la troisième partie va
décrire les différents types d’architecture que nous avons pu tester. Il s’agit par exemple de
l’utilisation de la freephonie, la simulation en entreprise avec firewall ou encore la topologie
locale simple.
1. Présentation
1.1. La téléphonie sur IP
1.1.1. Fonctionnement
La téléphonie sur IP est un service de transport de la voix afin d’effectuer des
appels sur réseaux IP au lieu d’utiliser une ligne téléphonique traditionnelle. Ainsi la
voix circule sur un réseau unique (voix, données, vidéos) permettant de réduire
considérablement les coûts d’investissement.
La téléphonie sur IP est une transmission de la voix en mode paquets au format
TCP/UDP.
Fig. 1 : Le traitement de la voix
Lorsqu’un utilisateur veut entrer en communication avec un autre, une connexion est
alors établie entre les deux terminaux. L’utilisateur peut alors émettre un son par le biais d’un
micro (signal analogique) qui est ensuite numérisé et compressé par la machine (signal par
synthèse). Une fois les données encapsulées dans un paquet, il est envoyé au destinataire qui
procèdera aux opérations inverses assurant ainsi la mise en forme d’un message audible.
Les différentes étapes sont :
La numérisation : Les signaux de la voix (analogiques) doivent être convertis sous
forme numérique suivant le format PCM (Pulse Code Modulation) à 64kbit/s. La
modulation d’impulsion codée est une technique d’échantillonnage quantifiée sur
une série de symbole dans un code numérique (binaire). L’ordinateur ne comprend
que le code binaire, la numérisation est donc primordial.
La compression : Lors de la numérisation, le codage PCM se contente de mesurer
des échantillons indépendamment des uns des autres. Un échantillon du signal
n’est pas isolé, mais corrélé avec d’autres (précédent ou suivant).
En tenant compte des informations, il est possible de prévoir la valeur du nouvel
échantillon et donc de transmettre qu’une partie de l’information. C’est ce qu’on appelle la
prédiction. Cela permet de réduire la taille du paquet pour optimiser la bande passante.
Il existe deux grands types de compressions : le codage différentiel et le codage par
synthèse. La norme de compression est variable selon les codecs utilisés.
Les codecs sont des chipsets qui font office de codeurs/décodeurs. Certains terminaux
IP-PHONES n'acceptent qu'une partie ou même un seul codec, tout dépend du modèle de
terminal et du constructeur. Les principaux taux de compression de la voix sont les codecs
officiels suivants :
Méthode de compression Débit en Kbits/s
G.711 PCM 64
G.726 AD PCM 32
G.728 LD CELP 16
G.729 CS ACELP 8
G.729 x 2 Encodings 8
G.729 x 3 Encodings 8
G.729a CS ACELP 8
G.723.1 MPMLQ 6,3
G.723.1 ACELP 5,3
Les différents codecs et taux de compression
Le transport : L’information voyage dans des datagrammes UDP ne garantissant
pas la livraison car il n’effectue aucune vérification concernant la perte de paquet
et ne transmet aucune information sur les configurations utilisés. Il a donc fallu
définir un nouveau protocole fournissant plusieurs fonctionnalités :
Le numéro de séquence pour la remise en ordre des paquets ;
Un champ horodatage (timestamp) pour la restauration de la base de temps ;
Détecte la perte de paquets pour informer la source dans des délais
compatibles avec le service ;
Identifier le contenu des données et permettre leur transmission ;
Intègre des solutions pour traverser des passerelles de certains réseaux locaux
Ce protocole est appelé RTP (Real-Time Transport Protocol) qui se complète par un
protocole de contrôle qui transmet des rapports de réception RTCP (Real-Time Transport
Control Protocol). Par exemple lors d’une conférence regroupant plusieurs participants, RTCP
permet d’identifier différentes sources d’émissions contribuant à la session, mais il n’est
cependant pas obligatoire.
L’établissement de la connexion : Avant de pouvoir communiquer directement, les
membres de la discussion doivent établir un protocole pour la démarrer.
Les principaux protocoles utilisés pour l’établissement de la communication sont :
H323 ;
SIP ;
IAX (SIP amélioré, issu du projet de PABX Asterisk) ;
1.1.2. Son utilisation (Intérêts)
La convergence des services de communications données, vidéos et voix offre de
nombreux avantages. En effet, le téléphone et le PC partagent le même câble Ethernet, les
frais de câblage sont réduits, les frais d'administration du réseau sont également minimisés. Il
est ainsi possible de réaliser des économies à court et à long terme sur de nombreux postes :
administration d'un seul réseau, fournisseur d'accès unique, unique contrat de maintenance,
câblage commun, gratuité des communications interurbaines, réduction de la complexité de
l'intégration d'applications. Enfin, la migration de la solution actuelle vers la Téléphonie sur IP
s'effectue en douceur. Les solutions de téléphonie sur IP sont conçues pour dégager une
stratégie de migration à faible risque à partir de l'infrastructure existante. De plus, en
positionnant la voix comme une application supplémentaire sur le réseau IP, l’entreprise ne
va pas uniquement substituer un transport opérateur RTC à un transport IP, mais simplifié la
gestion de la voix, des données et vidéo par ce seul transport.
Aujourd’hui la position des opérateurs est menacée par l’arrivée massive de la
téléphonie sur IP, dont la tarification tend vers la gratuité.
1.1.3. Différence PABX / IPBX
Dans une architecture avec PABXs, il est nécessaire d’avoir deux infrastructures différentes. La premières constituées du réseau de PABXs où sont reliés physiquement les téléphones. Ce réseau est ensuite connecté au Réseau Téléphonies Commuté (RTC) permettant de communiquer avec l’extérieur.
Réseau de PABXs
Il y a ensuite le réseau de données classiques constitué d’ordinateurs, serveurs et
firewall connecté au WAN / Internet.
Réseau IP
Ces deux réseaux sont donc reliés afin de fournir un service complet de téléphonie et
de données. C’est notamment pour cela que le coût d’une infrastructure comme celle-ci est
plus élevée et l’administration plus complexe. Elle a par contre l’avantage d’une fiabilité plus
élevée car les deux réseaux sont séparées, par exemple si le réseau IP ne fonctionne plus, les
utilisateurs pourront continuer à utiliser la téléphonie.
Infrastructure générale
Dans une architecture avec un IPBX, il y a une unique infrastructure, où l’on intègre
directement les téléphones IP et l’IPBX sur le réseau IP existant. Ce réseau peut ensuite être
relié au Réseau Téléphonique Commuté en rajoutant une carte FXO / FXS sur le serveur de
téléphonie. Mais ceci est facultatif car le grand avantage de ce type de communication est
justement de pouvoir sortir sur le réseau Internet.
Infrastructure IPBXs
1.2. Les protocoles
1.2.1. SIP / H323
Session Initiation Protocol (SIP) est un protocole standardisé et normalisé par l'IETF
(RFC 3261). Il est de plus en plus utilisé actuellement dans le monde de la voix sur IP.
Son but principal est d’établir, modifier et terminer des sessions multimédias. SIP n’a aucune
connaissance concernant les détails d’une session ouverte. C’est grâce à lui que l’on va pouvoir
authentifier et localiser des multiples participants dans une session. Pour toutes actions au
niveau d’une session, SIP va utiliser le port 5060 via le protocole UDP qui offre une rapidité
d’échange du fait qu’il n’y est pas l’établissement de la connexion contrairement à TCP.
SIP ne s’occupe pas du transport des données échangées durant la session comme la voix ou
la vidéo. Il est indépendant de la transmission des données, c’est en cela que tout type de
données et de protocoles peut être utilisé pour cet échange. Cependant le protocole RTP
(Real-time Transport Protocol) assure le plus souvent les sessions audio et vidéo. Dans notre
cas c’est RTP qui se charge du transport de la voix. SIP est un protocole d'égal à égal (Peer-to-
Peer).
Dans une session, on appelle les extrémités des agents utilisateurs (User Agents). Un
agent utilisateur peut avoir un des rôles suivants:
User-Agent Client (UAC) - Une application cliente qui initie une requête SIP.
User-Agent-Server (UAS) - Une application serveur qui contacte l'utilisateur quand une
requête SIP est reçue et qui retourne une réponse à la demande de l'utilisateur.
Typiquement, une extrémité SIP est capable de fonctionner dans les modes UAC et
UAS, mais fonctionne dans l'un ou l'autre mode.
Les Clients SIP :
Des Soft phones.
Des téléphones IP.
Les Serveurs SIP :
Proxy Server : Il reçoit les requêtes SIP d'un client et les achemine vers l'autre
client.
Redirect Server : Il fournit au client l'information sur le ou les prochains sauts
qu'un message doit atteindre. Ensuite le client contacte le serveur du prochain
saut ou l'UAS directement.
Registrar Server : Il traite les requêtes des UACs pour l'enregistrement de leur
localisation courante. Les serveurs d'enregistrement sont très souvent localisés
avec le redirect server ou le proxy server.
Un utilisateur veut entrer en communication avec un autre via SIP. L’application
qu’utilise ce client fait donc appel au protocole SIP en précisant la nature des échanges. SIP va
par la suite définir le nombre de session à ouvrir et les ouvrir. (Pour échanger de la vidéo par
exemple, l’ouverture de 2 sessions est nécessaire : une session pour l’image et une autre pour
le son). SIP partage de nombreuses similitudes avec le protocole HTTP comme le codage en
ASCII et les codes de réponse. Le client envoie des requêtes au serveur, qui lui renvoie une
réponse.
SIP utilise des requêtes et des réponses pour établir des communications parmi les divers
composants d'un réseau.
Les méthodes de bases utilisées par SIP afin d’établir une session sont :
REGISTER : UAC authentifié
au niveau du serveur
INVITE : Initiation de la
session
ACK : confirmation
l’établissement de la session
CANCEL : annule un INVITE
en suspens
BYE : Fin de la session
On rencontre plusieurs types de communication utilisant le protocole SIP :
Mode Point à point : on parle dans ce cas-là « d’unicast » qui correspond à la
communication entre 2 machines.
Mode diffusion : on parle dans ce cas-là de « multicast ». Communication intégrant
plusieurs participants.
Combinatoire : combine les deux modes précédents.
Il existe également un autre protocole de signalisation nommé H323 englobant un
ensemble de normes utilisées pour l'envoi de données audio et vidéo sur Internet. Il existe
depuis 1996 et a été initié par l'ITU (International Communication Union), un groupe
international de téléphonie qui développe des standards de communication.
H323 est un protocole assez daté qui est actuellement dépassé par le SIP. Un des avantages
du SIP est sa simplicité et sa ressemblance aux protocoles HTTP. C’est pourquoi la plupart du
matériel VoIP disponible aujourd’hui répond aux normes SIP. L’équipement plus ancien par
contre suivra les normes du protocole H323.
1.2.2. RTP / RTCP
Real-Time Transport Protocol (RTP) est un protocole de communication informatique.
RTP offre un moyen d’échanger de bout en bout, via le protocole IP, des données
possédant des contraintes de temps réel (audio, vidéo, ...). Bien que ce protocole possède
dans son acronyme le terme « transport », on ne peut pas réellement parler de protocole de
transfert car RTP utilise un protocole de niveau 4 (transport) afin de véhiculer les données. En
effet, il utilise le protocole UDP (User Datagramme Protocol). UDP est préféré à TCP car ce
dernier ne peut pas utiliser la fonction multicast et ne permet pas un envoi immédiat de
données. RTP peut donc être utilisé pour la diffusion de contenus vidéo en direct (multicast),
pour des applications multimédia et dans notre cas pour la Voice Over IP utilisée par
téléphonie sur Internet.
Le protocole RTP ajoute aux paquets un en-tête fournissant les informations
nécessaires à la synchronisation du flux temps réel et du type son et vidéo.
L’entête RTP contient des champs spéciaux comme :
Le champ padding P : indique si le paquet contient des octets additionnels de bourrage.
Le champ extension X : précise si l'en-tête est suivi d'un paquet d'extension.
Le champ CSRC count CC : contient le nombre de CSRC qui suivent l'entête.
Le champ payload type PT : identifie le type du payload (audio, vidéo, image, texte, html,
etc.)
Le champ séquence number : sa valeur initiale est aléatoire et il s'incrémente de 1 à chaque
paquet envoyé, il peut servir à détecter des paquets perdus.
Le champ timestamp : 32 bits, reflète l'instant où le premier octet du paquet RTP à été
échantillonné.
Le champ SSRC : identifie de manière unique la source, sa valeur est choisie de manière
aléatoire par l'application.
Le champ CSRC : 32 bits, identifie les sources contribuant.
Capture wireshark visualisation d’une trame RTP
Le protocole SRTP (acronyme de Secure Real-time Transport Protocol) est le pendant
sécurisé (chiffré) de RTP. Nous ne l’avons pas mis en place ni étudier durant ce projet. Il doit
être intéressant de l’implémenté dans une architecture requérant un fort niveau de
confidentialité.
Le protocole RTP fonctionne en étroite collaboration avec RTCP (Real-Time Transport
Control Protocol). C'est un protocole de contrôle des flux RTP, permettant de véhiculer des
informations basiques sur les participants d'une session, et sur la qualité de service. Il
fonctionne grâce à l’envoi périodique de paquets de contrôle par tous les participants dans la
session. RTCP est situé au-dessus du protocole de transport UDP. Ce « feedback » apporté par
RTCP, peut par exemple informer la source sur les propriétés temps-réel du canal, l'état du
tampon du récepteur.
Par contre il n'offre pas de garantie de transfert… En effet, pour une transmission correcte, il
faut bien s'assurer dès le départ, que les liens de communications utilisés sont correctement
dimensionnés par rapport à l'utilisation qui en est faite.
Fig. 2 : Fonctionnement de RTP et RTCP
L’utilisation simultané des protocoles SIP, RTP et RTCP est la base d’une
communication en ToIP dans le cas de l’utilisation d’Asterisk. En effet, SIP permettra d’établir
la session entre l’appelant et l’appelé via le serveur ; RTP entrera en jeu afin de transporter le
« flux voix » entre les deux participants, RTCP lui fournira un contrôle ; SIP pourra intervenir à
tout moment pour modifier la session (rajout d’un participant) et dans tous les cas clôturera
la session lors de la fin de l’appel.
Il est nécessaire d’identifier les deux types de protocoles. SIP est un protocole de signalisation
il entre en jeu entre les clients et le serveur pour établir la session, tandis que RTP/RTCP est
un protocole qui va servir au transport de la voix et opérera toujours entre les participants
d’une session, jamais via le serveur.
Etablissement d’une communication (SIP RTP)
1.2.3. IAX
Inter-Asterisk Exchange est un protocole qui permet la communication entre client et
serveur ainsi qu'entre serveurs. Le nom IAX est souvent utilisé pour parler de la version 2 du
protocole en effet la première version n'est pratiquement plus utilisée. Il est plus puissant que
SIP car il a été conçu pour le contrôle et la transmission de flux multimédia avec un débit plus
faible. IAX utilise le protocole UDP et le port 4569 pour la signalisation et les données.
IAX supporte les authentifications de type PKI et le trunking. L’avantage qu’offre IAX est dans
l’utilisation du trunking, en effet la bande passante allouée correspond exactement à celle
utilisée.
Le trunking permet à plusieurs flots de données vocales de partager un seul "trunk"
avec un autre serveur, réduisant ainsi les congestions induites par le trafic IP.
IAX est en train de rattraper son retard, de plus en plus d’opérateurs supportent ce protocole
et de nombreux équipement commencent à faire leur apparition.
Ce succès grandissant d’IAX n’est pas une réelle menace pour SIP de la manière que SIP l’a été
pour H323.
Ayant étudié le principe de la ToIP, la comparaison avec une installation téléphonique
standard ainsi que les différents protocoles utilisés comme SIP et RTP nous avons pu
comprendre le fonctionnement de cette nouvelle technologie.
Nous allons maintenant décrire le serveur et les clients utilisés pour la mise en œuvre
d’une solution ToIP. Le serveur Asterisk ainsi que les différents matériels associés seront
présentés dans cette partie.
2. Asterisk
2.1. Généralités
2.1.1. Présentation Asterisk
Asterisk est un commutateur téléphonique privé à part entière mais d’implémentation
logicielle, compatible linux, qui s’interconnecte avec quasiment tous les équipements de
téléphonie de base standard et peu coûteux. C’est un logiciel « Open Source », qui a été
développé par Mark Spencer à l’origine, de l’entreprise Digium, (anciennement Linux Support
Services Inc.) et qui continue, grâce à de nombreux contributeurs, à évoluer régulièrement.
Ce logiciel a été conçu pour une flexibilité maximale et reste un système ouvert à de nouvelles
applications. Il fournit par exemple, des services de messagerie vocale, permet la conférence
à plusieurs, l’identification de l’appelant, etc.
Asterisk fournit donc toutes les fonctionnalités attendues d’un PABX mais aussi la voix
sur IP et n’a besoin d’aucun matériel supplémentaire pour l’assurer. Dans l’interconnexion
avec les équipements de téléphonie numériques et analogiques, Asterisk reconnaît une large
gamme de dispositifs matériels, et notamment ceux fabriqués par ses sponsors, tels que
digium, ou encore Quicknet.
Digium propose une gamme de cartes d’interfaçage autorisant une à quatre liaisons
de type T1 et/ou E1, permettant l’interconnexion à des liaisons de type PRI, ou à des banques
de canaux, comme à un port unique d’une carte de type FXO, ou l’un des quatre ports de la
carte modulaire FXS.
2.1.2. Fonctionnalités
Les solutions téléphoniques de base d’Asterisk offre une gamme importantes de
fonctionnalités. Asterisk offre à la fois les fonctionnalités d’un PABX classique et des
fonctionnalités innovantes.
Messagerie vocale ;
Transfert d’appel ;
Conférence téléphonique ;
Standard automatique ;
Renvoi d’appel ;
Mise en attente ;
La mise en place de ces fonctionnalités est relativement intuitive, nous allons détailler la
configuration du standard automatique qui nous a demandé un peu plus de réflexion.
Cette fonctionnalité est très appréciée des entreprises, elle permet à l’appelant de choisir et de
s’orienter vers le service qu’il désire. Ceci est pratique dans des grandes entreprises avec différents
services. Nous avons donc testé cette fonctionnalité en décomposant comme présenté ci-dessous :
Standard automatique
Lors de l’appel du numéro, un 1er message vocal est diffusé, il s’agit du Message Vocal
de Bienvenue. Il accueille les personnes et introduit un autre message qui va permettre de
choisir le service vers lequel on veut s’orienter (Message Vocal de choix des services). Ce
message annonce donc qu’en tapant la touche 1 ,2 ou 3 l’utilisateur va être respectivement
dirigé vers le service Comptabilité, le service Informatique et pour finir au service Production.
Selon la touche pressée, l’utilisateur va être orienté vers le poste 5555, 5545, 5556.
2.2. Mise en place du serveur
2.2.1 Carte FXO / FXS La carte TDM 400P permet d’interconnecter le serveur Asterisk avec le réseau LAN (IP)
et le réseau RTC (Réseau Téléphonique Commuté). Cette carte est distribuée par la société
« Digium ». Nous avons choisi une carte possédant un module FXO et un module FXS afin de
connecter une ligne et un téléphone analogique.
C’est une carte PCI qui se présente comme ceci :
On utilise les termes FXS et FXO pour nommer les ports utilisés par des lignes
téléphoniques analogiques (Réseau Téléphonique Commuté (RTC) en français, Plain Old
Telephone Service (POTS) en anglais).
FXS (Foreign Exchange Station) : permet le branchement de téléphones
analogiques.
L’utilisation des téléphones analogiques nécessite la génération d’une tonalité. Pour la
tonalité il faut donc un courant de sortie. C’est pour cela que l’on branche la carte sur un
connecteur 12V de l’alimentation. Le module FXS est VERT sur la carte.
FXO (Foreign Exchange Office) : permet la connexion au RTC France Télécom
donc pas de tonalité à générer. Le module FXO est ROUGE sur la carte.
Selon les besoins ressentis, on peut rajouter des modules. Par exemple, un module
FXO pour connecter une nouvelle ligne RTC ou le module FXS pour la connexion d’un nouveau
téléphone analogique.
Cette carte n’est pas nécessaire au fonctionnement d’Asterisk. L’installation peut
fonctionner sans cette carte mais les utilisateurs n’accèderont pas au RTC. Le moyen pour
accéder au RTC sans cette carte est d’utiliser le service freephonie.net que l’on expliquera par
la suite.
2.2.2 Asterisk-current-11.5.1 :
Nous avons choisi d’utiliser Asterisk-current qui est une légère d’Asterisk qui s’installe
sur une distribution Linux par contre les autres versions comme AsteriskNOW conçue
spécialement pour être un serveur de téléphonie indépendant. Pour l’OS on choisit la
distribution CentOS 6.4 d issue d’un projet gratuit de RedHat et qui est dédiée pour les
serveurs.
Structure des fichiers :
La table en dessous contient les différents chemins d’installations des fichiers et bibliothèques
Asterisk. Cette liste n’est pas exhaustive, seulement les composantes essentielles pour une
installation de base sont listées :
Chemin Description
/etc/asterisk Fichiers de configuration
/usr/sbin Chemin pour les fichiers binaires d’exécution
/var/log/asterisk Fichier d’erreurs et CDR (rapports)
/usr/lib/asterisk/modules Bibliothèques des composantes des modules
Ports par défaut :
Protocole Port Transport
SIP 5060/5061 TCP/UDP
IAX2 4569 UDP
MGCP 2727 UDP
SCCP 2000 TCP
RTP 1000-20000 UDP
Manager 5038 TCP
H.323 1720 TCP
DUNDI 4520 UDP
Unistim 5000 UDP
Dépendances et pré-installation :
Téléchargement :
Le paquet source d’Asterisk-current peut être téléchargé par la commande « wget » et
disponible sur le lien suivant :
Prérequis :
Pour que Asterisk s’installe correctement il faut que les paquets suivants soient
installés, pour CentOS/RedHat on utlise la commande « yum » pour Ubuntu/Debian « apt-
get » :
Compilation et installation :
Extraction du paquet :
Compilation et installation :
Configuration serveur Asterisk :
Commandes d’exécution :
yum install autoconf.noarch corosync.x86_64 corosynclib.x86_64 cyrus-sasl-
devel.x86_64 elfutils-devel.x86_64 elfutils-libelf-devel.x86_64 expat-devel.x86_64 file-
devel.x86_64 gnutls-devel.x86_64 libgcrypt-devel.x86_64 libgpg-error-devel.x86_64
libibverbs.x86_64 libidn-devel.x86_64 librdmacm.x86_64 lm_sensors-devel.x86_64
postgresql.x86_64 rpm-devel.x86_64 tcp_wrappers-devel.x86_64 unixODBC.x86_64
root@localhost:/usr/src/#wget http://downloads.asterisk.org/pub/telephony/asterisk/asterisk-11-current.tar.gz
root@localhost:/usr/src/#tar –zxvf asterisk-11-
current.tar.gz
root@localhost:/usr/src/asterisk-
11.5.1/#./configure
root@localhost:/usr/src/asterisk-11.5.1/#make
root@localhost:/usr/src/asterisk-11.5.1/#make
install
Diagnostique :
Le serveur Asterisk permet d’interagir directement avec le système sans avoir à
modifier les fichiers de configuration avec la CLI« Interface de ligne de commande ». Nous
utiliserons cette interface uniquement pour afficher et vérifier la configuration et l’état des
téléphones. Cette CLI est exécutée en tapant la commande suivante :
Ou bien :
Une fois la CLI ouverte nous pouvons afficher l’état des téléphones avec la commande
suivante :
Nous pouvons également afficher l’état des lignes quand le serveur Asterisk se
comporte comme un client SIP avec la commande suivante :
root@localhost~: /etc/init.d/asterisk stop
root@localhost~: /etc/init.d/asterisk start
root@localhost~: /etc/init.d/asterisk restart
root@localhost:/etc/asterisk#asterisk –r
root@localhost:/etc/asterisk#rasterisk
Configuration :
Fichiers de configuration :
Sip.conf :
Le fichier sip.conf est utilisé pour configurer les logins et mots de passe de tous les
périphériques. Ces périphériques peuvent être des téléphones, des passerelles analogiques
ou encore d’autres serveurs. Ce fichier est organisé en différentes zones appelées «context ».
Context general
Le context general définit :
Le context par défaut des comptes créés.
les paramètres TCP/IP du serveur.
le langage des messages vocaux.
Voici un exemple opérationnel :
Contexte utilisateur
Plusieurs options permettent de définir et de paramétrer un client (utilisateur) :
type : Type de client (peer, user ou friend)
defaultuser: Identifiant de l'utilisateur
secret : Mot de passe de l'utilisateur
host : Méthode pour trouver le client (dynamique, nom d'hôte ou adresse IP)
callerid : Identité de l'utilisateur
[general]
context= local ; contexte par défaut pour les utilisateurs
bindport= 5060 ; port UDP pour le protocole SIP
bindaddr= 0.0.0.0 ; @IP de l’interface sur laquelle asterisk va
;écouter le trafic 0.0.0.0 pour toutes les interfaces
language= fr ; langue par défaut des messages vocaux
language : Langue par défaut pour l'utilisateur Pour chacun des paramètres précédents,
plusieurs valeurs sont disponibles selon la configuration désirée.
Type :
peer : Client SIP auquel Asterisk pourra envoyer des appels
user : Client SIP qui pourra passer des appels via Asterisk
friend : Client qui sera à la fois en mode 'peer' et 'user'
Host :
dynamic : Le client s'enregistre auprès du serveur
nom d'hôte : Nom d'hôte du client
adresse IP : Adresse IP du client
Language :
us : Langue par défaut
fr : Langue française
D’autres contextes sont utilisés pour créer des comptes utilisateur. Les paramètres des
comptes peuvent êtres :
le login
le mot de passe
context, ce paramètre permet de gagner de la souplesse dans le routage des appels
mailbox, ce paramètre est utile pour la messagerie vocale
c’est avec les paramètres nat et cannreinvite que l’on peut contrer le problème du
routage NAT.
Contexte pour les passerelles
Il existe différentes passerelles. Ces passerelles permettent les communications vers le réseau
analogique ou numérique mais aussi GSM. Pour pouvoir fonctionner, ces passerelles doivent
avoir des comptes. Ces comptes se configurent de la même façon que les comptes utilisateurs,
exemple :
extensions.conf :
[1001] ; login SIP (obligatoire)
secret= s1001 ; mot de passe SIP (obligatoire)
callerid= ensak1001 ; facultatif, nom afficher sur le post de l’appelé
context= asterisk ; les appelles effectués par l’utilisateur seront gérés
;dans le contexte locale du ficher «extensions.conf »
mailbox= 1001@default ; facultatif, compte de messagerie vocale, voir
;« voicemail.conf »
type= friend ; obligatoire, autorise les appels entrants et sortants
host= dynamic ; @IP du client
nat= yes ; facultatif, résout le problème d’enregistrement SIP
;quand le post est derrière un NAT
[SPA-3102-PSTN]
secret=azerty
context=asterisk
type=friend
host=dynamic
Le fichier extension.conf est utilisé pour router les appels vers un utilisateur ou vers
sa messagerie. Par exemple, les appels provenant de comptes SIP dont le context est «
asterisk» seront traités dans l’extension « asterisk » du fichier extension.conf.
Les instructions exten sont utilisées comme suit :
Numéro
composé
Ordre
d’instructions
Action à éffectuer Durée avant de passer à
linstruction suivante (s)
Exten=> 200, 1, Dial(SIP/1001, 20)
Description des paramètres :
exten : permet de définir une nouvelle extension :
200 : numéro d’appel (ou d’extension) du serveur vocal ;
1 : ordre de priorité pour l’exécution ;
Dial : Commande à exécuter.
La configuration du fichier extensions.conf est interprétée comme suit :
Si un appel arrive au numéro 200 par exemple, Asterisk va premièrement appeler celui qui
s’est logé en user 1001 pendant 20 secondes et va s’arrêter si le 1001 ne décroche pas pendant
ce temps.
Au niveau de ce fichier, on peut implémenter beaucoup de scénarios comme la mise
en attente, accepter l’appel directement, mettre un message automatique … ou bien faire une
combinaison de toutes ces actions.
Routage d’appel vers un utilisateur:
Dans l’exemple suivant, les appels arrivant sur le serveur Asterisk à destination du
numéro 200 sont envoyés vers le téléphone de 1001 pendant 20 secondes puis sont envoyés
sur la messagerie de 1001.
[asterisk]
exten => 200, 1, Dial(SIP/1001, 20)
exten => 200, 2, VoiceMail(200)
Routage d’appel vers un groupe d’utilisateurs:
Dans l’exemple suivant, les appels arrivant sur le serveur Asterisk à destination du
numéro 205 sont envoyés vers le téléphone de 1001 puis vers le téléphone de 1002.
Remarque : l’instruction Goto() permet de renvoyer l’appel où l’on veut dans le fichier
extension.conf.
Dans notre cas, l’appel basculera du téléphone de 1001 au téléphone de 1002 jusqu’à
ce qu’un des deux décroche.
Routage vers plusieurs téléphones en même temps:
L’exemple suivant montre comment faire sonner deux téléphones en même temps.
Quand on compose le 206, les téléphones de 1001 et de 1002 sonnent.
Accès à la messagerie vocale:
Voici deux exemples d’accès à la messagerie. Dans le premier cas, l’utilisateur doit
composer sur son clavier numérique son login et son code pin. Dans le second exemple, le
login correspond au numéro de l’appelant. L’utilisateur doit juste composer son code pin.
Routage d’appel vers une passerelle analogique:
[asterisk]
exten => 200, 1, Dial(SIP/1001, 20)
exten => 200, 2, VoiceMail(200)
[asterisk]
exten => 206, 1, Dial(SIP/1001&SIP/1002, 20)
exten => 298, 1, VoiceMailMain() exten => 299, 1, VoiceMailMain(${CALLERIDNUM})
Dans l’exemple suivant, tous les appels commençant par quatre cent sont envoyés vers
la passerelle. La passerelle va composer le numéro sur la ligne analogique.
Dans l’exemple suivant, les appels commençant par 01, 02, 03, 04 ou 05 composés de
10 chiffres sont envoyés vers la passerelle. La passerelle va composer le numéro sur la ligne
analogique.
Dans l’exemple suivant, quand on compose le zéro, l’appel est envoyé vers la passerelle
et l’on obtient la tonalité. Nous pouvons ensuite composer le numéro vers l’extérieur.
Standard automatique:
Le standard automatique permet à un utilisateur d’écouter un message lui indiquant
les choix possibles. Après, il lui suffit de presser une des touches pour effectuer l’action voulue.
Il est possible de combiner les menus pour développer une architecture plus complexe.
Dans l’exemple suivant, quand l’utilisateur compose le 210, il entend un message vocal
qui l’invite à taper 1, 2 ou 9 sur son clavier. S’il tape 1, l’appel est envoyé à 1001. S’il tape 2,
l’appel est envoyé à 1002. S’il tape 9, Asterisk raccroche. Si l’utilisateur ne fait rien, le message
est joué en boucle.
exten => _4xx, 1, Dial(SIP/SPA-3102-PSTN/${EXTEN})
exten => _0[1-5]xxxxxxxx, 1, Dial(SIP/SPA-3102-PSTN/${EXTEN})
exten => 0, 1, Dial(SIP/SPA-3102-PSTN)
Astuce : pour enregistrer le message vocal au bon format, il vous suffit de laisser un message
sur la boîte vocal d’un utilisateur et de copier le fichier dans le répertoire /var/msg/ avec la
commande suivante.
Horloge parlante:
Dans l’exemple suivant le serveur Asterisk décroche, annonce la date et l’heure, attend
3 secondes et recommence.
[asterisk]
exten => 210, 1, Goto(Menu,s,1) ; appel du standard automatique
[Menu] ; standard automatique
exten => s, 1, Background(/var/msg/Menu) ; le message audio enregistré
;/var/msg/Menu.gsm et joue
exten => s, 2, WaitExten(2) ; on attend 2 sec
exten => s, 3, Goto(Menu,s,1) ; on recommence le tout
exten => 1, 1,SayNumber(1)
exten => 1, 2, goto(asterisk,1001, 1) ; 1 Appel 1001
exten => 2, 1, SayNumber(2)
exten => 2, 2, Goto(asterisk,1002, 1) ; 2 Appel 1002
exten => 9, 1, SayNumber(9)
exten => 9, 2, Hang up() ; 9 On raccroche
cp /var/spool/asterisk/voicemail/default/200/INBOX/msg0000.gsm
/var/msg/Menu.gsm
Outil de test de flux:
Dans l’exemple suivant Asterisk décroche et joue un message expliquant le
fonctionnement de la fonction de test. C’est ensuite à l’utilisateur de parler dans le combiné
et de vérifier que le serveur Asterisk renvoie le son vers le combiné avec un petit décalage.
voicemail.conf :
Le fichier voicemail.conf permet de configurer la messagerie vocale d’Asterisk. Nous
pourrons y paramétrer la notification par email des messages et les logins des utilisateurs de
la boîte vocale.
Contexte general
Le context general permet de spécifier :
Le format des fichiers audio enregistrés
Si l’on veut attacher le fichier audio à l’email
L’objet de l’email
Le corps de l’email
exten => 211, 1, Answer ; horloge parlante
exten => 211, 2, SayUnixTime(,CET,AdbY \'digits/at\' kM)
exten => 211, 3, Wait(3)
exten => 211, 4, Goto(local,211, 2)
exten => 212, 1, Answer ; permet de tester les flux entrant et sortant
exten => 212, 2, Playback(demo-echotest)
exten => 212, 3, Echo()
[general]
format=gsm
attach=yes
emailsubject=Nouveau message vocal provenant de ${VM_CIDNAME}
Voici une liste des variables utilisables dans l’objet et le corps des emails :
VM_NAME nom d'utilisateur
VM_DUR durée du message
VM_MSGNUM numéro du message
VM_MAILBOX numéro de l'utilisateur
VM_CIDNUM numéro du l'appelant
VM_CIDNAME nom de l'appelant
VM_DATE date du message
\n retour à la ligne
\t tabulation
Contexte default
Voici un exemple de context default, on y retrouve
Le numéro de boîte vocale
Le code pin de la boîte vocale
Le nom de l’utilisateur
L’adresse email de l’utilisateur
Le nom des contextes utilisateurs n’est pas important. Il faut toutfois faire attention à
utiliser le même nom dans les extensions utilisateurs du fichier sip.conf et le fichier
voicemail.conf.
emailbody=\n\tBonjour ${VM_NAME},\n\n\t Tu as un message de la part de
${VM_CIDNAME} d'une durée de ${VM_DUR} datant du ${VM_DATE}
[default]
200 = 123, ensa, ensa@toto.ma
201 = 456, uh1
202 = 789, fpk
Notification par email :
Pour qu’Asterisk puisse envoyer les emails aux utilisateurs, il faut installer un serveur
SMTP sur le serveur Centos.
sip.conf
[ensa]
mailbox=200@default
3. Applications
3.1. Architecture locale : 3.1.1. Schéma du réseau :
Dans le schéma en dessus on dispose d’un serveur Asterisk sous une machine linux
virtuelle et 3 client x-lite 2 virtuelles et le troisième représenté par l’OS de notre machine.
Pour avoir le tous dans le même réseau locale on doit choisir une carte de type « host only »
ou « local network » (sur VirtualBox) pour les machines virtuelles plus l’attribution des
adresses IP appartenant au même réseau 192.168.130.xx dans notre cas.
3.1.2. Configuration du serveur :
Fichier sip.conf :
On commence la configuration par configurer le serveur Asterisk sous linux (dans notre
cas le système est CentOS) : En accède au dossier /ect/asterisk puis en lance le nano pour
modifier le fichier sip.conf.
On ajoute ce texte dans le fichier sip.conf, afin de configurer 3 clients SIP qui sont 1001,1002
et 1003.
Fichier extensions.conf :
On lance nano pour configurer le fichier extensions.conf, afin de créer les scenarios
des appels.
# cd /etc/asterisk
# nano sip.conf
[1001]
type=friend
context=asterisk
defaultuser=1001
secret=s1001
host=dynamic
callerid="1001"
[1002]
type=friend
context=asterisk
defaultuser=1002
secret=s1002
host=dynamic
callerid="1002"
[1003]
type=friend
context=asterisk
defaultuser=1003
secret=s1003
host=dynamic
callerid="1003"
Après cette modification, on a configuré les scénarios des appels, par exemple, si un
client SIP veut appeler le 1001, le téléphone 1001 va sonner pendant 20 seconde, après il va
passer au 2éme processus, c’est de couper l’appelle avec la commande Hangup().
Après on redémarre le serveur Asterisk pour prendre ces configurations en
considération.
3.1.3. Configuration des clients:
Client SIP 1 :
En premier lieu on lance sous Windows le logiciel X-lite, après on clique sur le triangle
inversé qui est en haut, puis on clique sur SIP Account Settings.
[asterisk]
exten => 1001,1,Dial(SIP/1001,20,Tr)
exten => 1001,2,Hangup()
exten => 1002,1,Dial(SIP/1002,20,Tr)
exten => 1002,2,Hangup()
exten => 1003,1,Dial(SIP/1003,20,Tr)
exten => 1003,2,Hangup()
# rasterisk
> core reload
Puis on clique sur le bouton « add » pour ajouter un nouveau compte SIP.
Les champs du compte SIP :
Name Display : le nom qui va s’afficher sur ce spftphone.
User Name : nom du compte comme il est configurer dans sip.conf
Password : mot de passe du compte dans le fichier sip.conf
Domain : Adresse du serveur qui contient Asterisk
Dans la partie Domain Proxy on coche le bouton radio « Domain » puis on ne change
rien. Si le compte est bien configurer le softphone va être en état Ready.
Pour tester on va essayer d’appeler le « 1001 » à partir de « 1002 » et dans la figure
suivante on voit que la communication a été établit :
3.1.4. Transfert d’appels :
Si on n’a pas de touches pour effectuer un transfert d’appel sur notre téléphone SIP on
peut configurer une touche de raccourcis pour effectuer un transfert d’appel aveugle ou
supervisé vers un autre poste.
Transfert d’appels aveugle :
Le transfert d’appel dit aveugle est le fait de transféré un appel directement à une
autre personne.
Exemple de transfert aveugle:
1. 1 appel 2
2. 1 et 2 sont en communication
3. 2 transfère à 3 (transfert aveugle)
4. 1 et 3 sont en communication
5. 2 est raccroché
Transfert d’appels supervisé :
Le transfert d’appel dit supervisé est le fait d’appeler le destinataire du transfert avant
de lui transférer l’appel.
Exemple transfert supervisé:
1. 1 appel 2
2. 1 et 2 sont en communication
3. 2 appelle 3 (transfert supervisé)
4. 1 est en attente
5. 2 et 3 sont en communication
6. 2 raccroche
7. 1 et 3 sont en communication
Configuration et mise en place du transfert d’appels :
Dans le fichier « features.conf » se trouvant dans le repertoire « /etc/asterisk », on
repère les lignes suivantes :
Ces lignes permettent de configurer une ou plusieurs touches pour transférer un appel.
Pour notre part on a dans ce fichier de configuration mis comme touches ## pour le transfert
aveugle et ** pour le transfert supervisé, donc au final les lignes ressemblent à ceci :
Puis dans le fichier extensions.conf on rajoute l’option tT à l’application Dial ().
Donc la ligne:
exten => 1001, 1, Dial(SIP/1001,20)
;blindxfer => #1 ;
;atxfer => *2 ;
blindxfer => ## ;
atxfer => ** ;
Devient:
exten => 1001, 1, Dial(SIP/1001,20,tT)
Maintenant, après avoir fait un reload d’Asterisk on peut au cours d’un appel appuyer
sur les touches ## pour un transfert aveugle ou ** pour un transfert supervisé, une voix dira
« Transfert » on n’aura qu’alors qu’à taper le numéro de téléphone de la personne à qui on
souhaite transférer l’appel.
3.2. Architecture étendue : 3.2.1. Freephonie
Interconnexion freephonie
Afin de pouvoir passer des appels vers le RTC, l’utilisation d’un fournisseur SIP est une
méthode de plus en plus utilisée. Nous avons choisi d’utiliser le service du fournisseur d’accés
Free qui propose sur la freebox le service freephonie.net. Cette option est supplémentaire
mais son activation n’est pas payante. Les appels émis sont facturés de la même manière que
les appels normaux via la freebox.
La freephonie nous a donc permit de faire le lien entre notre installation et le RTC et
ainsi tester la compatibilité et valider son fonctionnement. Ce service va permettre la
convergence entre la téléphonie classique (RTC), le réseau GSM et le réseau IP.
Les utilisateurs présents sur le réseau local ont donc pu passer des appels vers l’extérieur. Il
a suffi de connecter notre serveur Asterisk à Internet afin que celui-ci puisse accéder au
serveur freephonie.net.
3.2.2. Sécurité : Avec Firewall
Pour simuler une situation en entreprise, nous avons réalisé notre maquette en y
insérant un firewall réalisé avec une distribution Linux Ubuntu ;
En effet de nos jours toutes les entreprises possédant un réseau local disposent aussi
d’un accès à Internet, afin d’avoir à portée, toutes les informations nécessaires, et pouvoir
communiquer avec l'extérieur. Cette ouverture vers l'extérieur est dangereuse. Ouvrir
l'entreprise via Internet signifie aussi laisser l’accès aux étrangers qui essayent de pénétrer le
réseau local de l'entreprise. Cette action est considérée comme une attaque et peut se définir
comme ceci :
« Accomplir des actions douteuses, parfois gratuites, de destruction, vol d'informations
confidentielles… »
Il a donc fallu mettre en place une architecture sécurisée pour parer à ces attaques. Pour cela,
on utilise un firewall. Cet outil va essayer au maximum de sécuriser le réseau local de
l'entreprise. Il va dans un premier temps, « filtrer » le trafic arrivant à partir d’internet sur le
réseau local.
Interconnexion avec un firewall
De plus, il peut permettre de restreindre l'accès interne vers l'extérieur. En plaçant
un firewall limitant ou interdisant l'accès à des services, l'entreprise peut donc avoir un
contrôle sur les activités se déroulant dans son enceinte.
La politique par défaut de l’utilisation d’un firewall est de bloquer tout le trafic et
autoriser seulement les protocoles et surtout les ports que l’on souhaite et sur des
interfaces précises. Avant d’écrire les iptables qui vont nous servir à restreindre le trafic, il
faut s’assurer qu’aucune ne soit déjà renseignée en vidant toutes les tables et supprimant
les règles utilisateurs.
• Réinitialisation des tables :
• Blocage de tout le trafic :
Pour notre maquette de test, nous avons voulu valider l’utilisation du port 5060 par
le protocole SIP. Nous avons dans un premier temps bloqué tout le trafic entre notre réseau
local et l’extérieur. Pour cela, on ignore tous les paquets transitant via le pare-feu. Il faut
donc ignorer dans les 3 cas possible de traitement des paquets :
INPUT : paquets entrant dans un processus local
OUTPUT : paquets sortants d’un processus local
FORWARD : paquets traversant la machine
En affichant les tables de notre firewall via la commande iptables -L, nous visualisons
bien que toutes les tables sont vides et que le trafic et bloqué (policy DROP).
Visualisation des iptables avant les règles
> iptables –P INPUT DROP
> iptables –P OUTPUT DROP
> iptables –P FORWARD DROP
> iptables –F –t filter
> iptables –F –t nat
> iptables -X
En bloquant tout le trafic, même le ping (protocole ICMP) vers internet ne fonctionnait pas.
Le test d’un appel vers l’extérieur était aussi négatif. En interne les appels fonctionnaient
correctement vu que le firewall n’a pas à traiter ces paquets. Le serveur étant sur le réseau
local l’échange s’effectuait localement.
• Natage :
Nous avons aussi réalisé aussi une opération de translation d’adresse pour toutes les
machines en 192.168.200.0 /24 qui traversent le firewall vers internet en sortant par eth0.
• Ouvrir le port 5060 SIP:
Pour terminer, nous avons ouvert le port 5060 et vérifié que les communications
fonctionnaient. En effet, le protocole SIP fonctionnait correctement mais il a aussi fallu ouvrir
une plage de port afin que le protocole RTP puisse transmettre la voix. Pour notre test nous
avons ouvert une plage assez grande (10000 à 20000). En réalité, il faudrait restreindre cette
plage pour ne pas avoir une faille importante dans notre pare-feu.
Visualisation des iptables après les règles
> Iptables –A FORWARD –p udp –dport 5060 –j ACCEPT
> Iptables –A FORWARD –p udp –dport 10000:20000 –j ACCEPT
> Iptables –t nat –A POSTROUTING –s 192.168.200.0/255.255.255.0 –o eth0 –j MASQUERADE
3.2.3. Sécurité avec Tunnel VPN IPSec :
La configuration du VPN IPSec se fait au niveau des deux routeurs passerelles entres
les sites distants afin de sécuriser le trafic entre les deux réseaux locaux comme le montre le
schéma suivant :
Configuration du tunnel VPN IPSec (192.168.55.0/30):
Création de tunnel :
R1:
interface Tunnel 12
ip address 192.168.55.1 255.255.255.252
tunnel source FastEthernet0/0
tunnel destination 192.168.2.2
R2:
On transforme le tunnel à un tunnel IPSec IPv4 sur les deux routeurs :
Le tunnel va passer en mode DOWN car les paramètres IPSec ne sont pas
encore configurés.
Création de mécanisme d’échange IKE via le protocole ISAKMP sur les deux
routeurs :
Configuration d’une clé pré-partagée « ENSAK » :
R1 :
R2 :
interface Tunnel 12
ip address 192.168.55.2 255.255.255.252
tunnel source FastEthernet0/0
tunnel destination 192.168.1.2
tunnel mode ipsec ipv4
crypto isakmp policy 10
encryption aes 256
authentication pre-share
group 5
exit
crypto isakmp key 0 ENSAK address 192.168.2.2
crypto isakmp key 0 ENSAK address 192.168.1.2
Création d’un jeu de traitement « transform-set » avec les paramètres
suivants :
ESP (Encapsulatiing Security Payload)
Encryption: AES 256
Hashing: SHA-HMAC
Affectation du transfom-set à un profile IPSec :
Vérification de configuration VPN avec la commande « show crypto ipsec
transform-set »
R2 :
crypto ipsec transform-set MYTRANS esp-aes esp-sha-hmac
crypto ipsec profile PROTECT
set transform-set MYTRANS
exit
int tunnel 12
tunnel protection ipsec profile PROTECT
Conclusion
La téléphonie n’a jamais été une application simple. Les contraintes temps réel et de
synchronisation pèsent lourdement sur sa mise en œuvre, et la téléphonie par paquet ne fait
que compliquer le transport.
Cependant, plusieurs raisons expliquent le succès de la téléphonie par paquet, et plus
spécifiquement de la téléphonie sur IP :
Convergence ;
Optimisation des ressources ;
Coût de transport quasiment nul ;
Disparition des commutateurs locaux ;
L’unicité de l’administration ;
La mobilité ;
La maintenance centralisée ;
L’autonomie de l’entreprise ;
Recommended