3071
Commentaire: il faut que j'ajoute un dessin
|
6008
c'est /moi/ qui ait écrit cette page ???? j'y crois pas.... pffff....
|
Texte supprimé. | Texte ajouté. |
Ligne 1: | Ligne 1: |
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. |
|
Ligne 17: | 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 RTP (ports 61000 à 62000/UDP, selon les indications du fichier `rtp.conf` que vous pouvez adapter si besoin) ; * '''accéder directement aux téléphones IP''', toujours 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, c'est à étudier ; * '''recevoir et envoyer des paquets IAX vers Internet''' : il suffit d'ouvrir 4569/UDP, dans les deux sens ; |
* '''ê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 ; |
Ligne 21: | Ligne 23: |
* '''recevoir des appels SIP''' : 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. | * '''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 23: | 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. 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... */ 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. Solution plus élégante mais moins garantie (nécessite un firewall avec noyau récent type backport.org):: . 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 : * [[http://fr.wikipedia.org/wiki/Session_Initiation_Protocol|SIP]] pour la négociation de la session et [[http://fr.wikipedia.org/wiki/Real-time_transport_protocol|RTP]] pour les flux de données (voix, image, etc.) * [[http://fr.wikipedia.org/wiki/IAX|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 ! |
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 !