6515
Commentaire: du module SIP dans Linux...
|
6008
c'est /moi/ qui ait écrit cette page ???? j'y crois pas.... pffff....
|
Texte supprimé. | Texte ajouté. |
Ligne 19: | Ligne 19: |
* '''ê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) ; | * '''ê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 RTP (ports udp de 61000 à 62000, selon les indications du fichier `rtp.conf` que vous pouvez adapter si besoin) ; |
Ligne 23: | Ligne 23: |
* '''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`). | * '''recevoir des appels SIP depuis 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`). |
Ligne 25: | Ligne 25: |
Si votre DMZ est en IP privée (à éviter si possible) : ajoutez un DNAT vers la machine pour le protocole IAX (4569/udp). Il est possible de le faire aussi pour SIP, avec un noyau disposant des modules netfilter `nf_conntrack_sip` et `nf_nat_sip`. Il suffit alors de faire du SNAT sur 5060/udp et 5060/tcp. /* T'as testé avec des noyaux récent ? car j'ai testé avec un 2.6.20 et ça ne marchait pas... -- ProgFou */ Mais cela rendra certainement délicat certaines liaisons SIP avec des clients "non standard" et vous privera sans doute de fonctionnalités futures telles que SIP+TLS. | /* ici, bientôt, un schéma... */ |
Ligne 27: | Ligne 27: |
/* ici, bientôt, un schéma... */ | Si votre serveur Asterisk est en IP privée : 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` et d'un noyau récent (typiquement ''backport.org''). Cependant, étant donné que différentes implémentations de SIP existent, il n'est pas certain que cela fonctionne toujours. Nous vous conseillons donc, si c'est possible, de placer votre serveur Asterisk sur une IP publique. |
Ligne 33: | Ligne 33: |
On a alors deux solutions, la «simple-pas-très-regardante» et la «jolie-mais-qui-marche-pas-toujours». | On a alors deux solutions, la «simple-pas-très-regardante-mais-efficace» et la «jolie-mais-pas-garantie-à-100%». |
Ligne 35: | Ligne 35: |
Solution simple et efficace : forcer les ports UDP pour le procole RTP:: | Solution simple et efficace : forcer une plage de ports UDP spécifique pour le procole RTP:: |
Ligne 38: | Ligne 38: |
Solution plus élégante mais moins garantie:: | Solution plus élégante mais moins garantie (nécessite un firewall avec noyau récent type backport.org):: |
Ligne 44: | Ligne 44: |
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 ? ;) |
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 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) ;
recevoir des appels SIP depuis 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 serveur Asterisk est en IP privée : 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 et d'un noyau récent (typiquement backport.org). Cependant, étant donné que différentes implémentations de SIP existent, il n'est pas certain que cela fonctionne toujours. Nous vous conseillons donc, si c'est possible, de placer votre serveur Asterisk sur une IP publique.
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-mais-efficace» et la «jolie-mais-pas-garantie-à-100%».
- Solution simple et efficace : forcer une plage de ports UDP spécifique 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 !