Cette page détaille les bonnes pratiques à l'AUF en matière de mise en place d'un serveur VoIP basé sur Asterisk et capable de gérer les protocoles IAX et SIP.
Infrastructure matérielle
Asterisk ne consomme pas excessivement de ressources. Sur une petites implantation (jusqu'à 5 employés) il peut être placé sur une machine effectuant d'autres opérations. Idéalement, il faut l'installer sur une machine virtuelle, OpenVZ étant la solution de virtualisation conseillée.
Note : si vous devez installer du matériel spécifique à Asterisk comme une carte TDM pour liaison avec la téléphonie classique, il faudra sans doute une machine physique dédiée, "non virtuelle".
Le système d'exploitation doit être Debian GNU/Linux 4.0, c'est-à-dire Etch. Comme les paquets Asterisk que nous installons sont des rétro-portages (backports), il est préférable que le système soit dédié à Asterisk et ne fasse rien d'autre.
Infrastructure réseau
Il s'agit de l'infrastructure conseillée, vous êtes libre de trouver mieux ou de faire autrement si vos pratiques ou votre configuration vous l'impose.
La machine doit disposer d'une adresse IP publique, on la place donc en générale sur la DMZ.
La machine doit :
être accessible directement par les téléphones IP, sans NAT, juste par routage. En d'autres termes, la machine doit être accessible depuis le réseau local privé 10.x.x.x sans système de NAT, au moins pour les protocoles IAX (4569/udp), SIP (5060/udp et 5060/tcp) et RTP (ports udp de 61000 à 62000, selon les indications du fichier rtp.conf que vous pouvez adapter si besoin) ;
accéder directement aux téléphones IP, sans NAT. Comme ci-dessus il s'agit que la machine puisse envoyer des paquets sur le réseau local 10.x.x.x, au moins pour le protocole IAX (4569/udp). Si vous utilisez des clients SIP, le plus simple est de permettre l'envoi de paquets vers tous les ports UDP. Certains clients SIP permettent de restreindre la page de port UDP utilisés par RTP, c'est à étudier ;
recevoir et effectuer des appels IAX depuis ou vers Internet : il suffit d'ouvrir 4569/udp, dans les deux sens ;
envoyer des appels SIP vers Internet : il faut que la machine puisse envoyer des paquets vers Internet sur 5060/udp (et aussi bientôt 5060/tcp et 5061/tcp). Il faut également qu'elle puisse envoyer des paquets UDP vers tous les ports, sachant que le port source UDP sera compris entre 61000 et 62000 (voir rtp.conf) ;
effectuer des appels SIP vers Internet : pour l'instant ce n'est pas si important, mais ça pourrait le devenir. Il faut que la machine puisse recevoir des paquets 5060/udp, 5060/tcp, 5061/tcp et tous les paquets UDP vers les ports 61000 à 62000/udp (voir rtp.conf).
Si votre DMZ est en IP privée (à éviter si possible) : ajoutez un DNAT vers la machine pour le protocole IAX (4569/udp). En théorie il est possible de le faire aussi pour SIP, avec un noyau disposant des modules netfilter nf_conntrack_sip et nf_nat_sip. Cependant en pratique nous avons constaté que cela ne fonctionne pas. Nous vous conseillons donc fortement de placer votre serveur Asterisk sur une IP publique : ne pas disposer de SIP, c'est se couper des possibilités actuelles de la VoIP.
Pourquoi le filtrage de SIP est compliqué ?
SIP n'est pas un protocole qui transfert la voix. C'est juste un Protocole d'Initiation de Session (Session Initiation Protocol) qui permet entre autre à deux machines de se mettre d'accord sur les flux qu'elles vont utiliser pour s'échanger des informations. Il ne suffit donc pas de laisser passer SIP pour que la communication passe : il faut aussi laisser passer les flux qui vont être négociés pour transporter les données. Ces flux sont en général des flux UDP, utilisant un protocole nommé RTP.
On a alors deux solutions, la «simple-pas-très-regardante» et la «jolie-mais-qui-marche-pas-toujours».
- Solution simple et efficace : forcer les ports UDP pour le procole RTP
On demande au serveur Asterisk de négocier les ports UDP dans une certaine plage, par exemple entre 61000/udp et 62000/udp. C'est le protocole RTP (Real Time Protocol) qui va gérer les flux, c'est lui que SIP va piloter par négociation. La configuration de la plage de ports se fait donc dans /etc/asterisk/rtp.conf. Au niveau du filtrage, on peut alors autoriser en entrée tous les paquets UDP pour cette plage, et en sortie (s'il y a un filtrage en sortie) tous les paquets émis par Asterisk depuis cette plage.
On peut mettre en place le suivi de connexion dédié à SIP sur le pare-feu. Le module nf_conntrack_sip va analyser les paquets SIP (5060/udp et tcp) qui transitent sur la machine et il ouvrira de façon dynamique les flux UDP en fonction des négociations en cours. Cependant, l'étude de divers client SIP montre que tout le monde ne respecte pas forcément le format de négociation et il n'est pas impossible que cette solution ne fonctionne pas avec certains clients. Néanmoins c'est une solution à tester, même si en terme de sécurité elle n'est pas vraiment beaucoup plus efficace que la solution simple ci-dessus.
Quelques détails sur les protocoles en jeu :
SIP pour la négociation de la session et RTP pour les flux de données (voix, image, etc.)
IAX, session et flux sur un seul port UDP, c'est plus simple mais mal adapté à la facturation (en cas de redirection d'appel, le premier opérateur perd la vue de la session en même temps que le flux)... donc ne gagnera pas la guerre !
Enfin, mon avis personnel (Thomas) : la sécurité en matière de VoIP c'est comme avec la messagerie. On ne filtre pas le port 25, on utilise un logiciel robuste (postfix) et on lui donne de «l'intelligence» pour lutter contre les spam et les virus. C'est surtout ça qui me fait peur avec la VoIP. En revanche ouvrir toute une plage de port UDP (voire tout UDP) sur une machine de la DMZ ne me pose pas de soucis majeur tant que la machine est bien sous contrôle... et tous nos serveurs sont sous contrôle, n'est-ce pas ? 