Problème de configuration RTP

[mamas]

Bonjour à tous,


Je possède un serveur Asterisk sur lequel mes clients s’y connectent de n’importe où dans le monde en identification SIP se serveur est précédé d’un firewall IPTABLES pour limiter les accès et lutter contre les attaques.

Donc nous leur recommandons pour se connecter d’ouvrir les ports 5060 (Port SIP pour la connexion) et les ports 10000 à 20000 (RTP pour le transport de la voix).

Le problème est que certains clients ne veulent pas ouvrir la plage de port (10000 à 20000) par mesure de sécurité ce qui pose problème pour le transport de la voix et malheureusement ce refus est de plus en plus récurrent.

Face à cela, j’ai 2 idées mais je ne sais pas si elles sont réalisables et je n’ai pas les compétences pour les mettre en place.

1/ Est-il possible de mettre un place un NAT de port afin que les clients se connecte sur un seul port (Ex : 8080) pour le transport de la voix (RTP) et que ce port distribue les connexions entre les ports 10000 à 20000) pour chaque session ? Si c possible comment faire ?

2/ Existe-t-il des PROXY RTP à travers lesquelles le clients se connecteront et utiliseront un seul ports pour le transport de la voix mais le proxy lui-même fera de la translation de port pour associés le port unique d’entré aux ports RTP définie dans rtp.conf (10000 à 20000).

Dans le cas échéant, connaissez-vous une autre solution permettant le transport de la voix sur un seul port coté client afin de ne plus rencontrer de problème de connexion et de sécurité coté client ?

Dans l’attente de vos réponses.


Bien cordialement

[jean]

il n'est pas nécéssaire pour un client d'ouvrir les ports rtp sur le firewall dans le sens wan-lan - l'ouverture doit être possible dans le sens lan-wan - en effet; asterisk lance des paquets rtps, ainsi que le client et cela perfore le firewall client

[mamas]

il n'est pas nécéssaire pour un client d'ouvrir les ports rtp sur le firewall dans le sens wan-lan - l'ouverture doit être possible dans le sens lan-wan - en effet; asterisk lance des paquets rtps, ainsi que le client et cela perfore le firewall client

Bonjour,

Merci pour votre retour et votre réactivité.

Cependant votre réponse n'est pas très explicite. Concrètement même si j'ouvre les flux dans le sens LAN => WAN si les ports ne sont pas ouverts coté Firewall client, le téléphone va sonner mais on entendra pas les voix des interlocuteurs.

Donc je renouvelle ma demande ci-dessous :

1/ Est-il possible de mettre un place un NAT de port afin que les clients se connecte sur un seul port (Ex : 8080) pour le transport de la voix (RTP) et que ce port distribue les connexions entre les ports 10000 à 20000) pour chaque session ? Si c possible comment faire ?

2/ Existe-t-il des PROXY RTP à travers lesquelles les clients se connecteront et utiliseront un seul ports pour le transport de la voix mais le proxy lui-même fera de la translation de port pour associer le port unique d’entré aux ports RTP définie dans rtp.conf (10000 à 20000).

Dans le cas échéant, connaissez-vous une autre solution permettant le transport de la voix sur un seul port coté client afin de ne plus rencontrer de problème de connexion et de sécurité coté client ?

Dans l’attente de vos réponses.


Bien cordialement

[jean]

j'ai bien compris vos questions, mais de mon expérience, il n'est pas nécéssaire pour le client de régler son firewall, s'il autorise le trafic sortant de manière générique.

lors de l'établissement de la comm, s'échangent via les messages INVITE les adresses IP et ports sur lesquels communiquer. le client enovie des paquets, depuis client:port vers asterisk:5060 => le firewall ouvre le port en entrant pour la réponse. pareillement, et sans attendre que les paquets clients arrivent, asterisk envoie des paquets vers le client, depuis l'@ asterisk:port vers client:port - le firewall est censé les laisser passer.

j'ai plusieurs dizaines de clients connectés de cette façon, et je n'ai jamais touché un firewall client (sauf quand ils bloquent l'entrée ET la sortie).

C'est aussi applicable au port 5060. Il n'est même pas garanti que le client utilise ce port comme port source, et il n'est pas nécessaire de l'ouvrir coté client. Il est obligatoire coté serveur.

donc, ma réponse est : plutôt que de monter une usine à gaz, cherchez ce qui ne va pas dans votre config, et vous aurez, de mon expérience, plus à toucher au firewall de vos clients

[mamas]

j'ai bien compris vos questions, mais de mon expérience, il n'est pas nécéssaire pour le client de régler son firewall, s'il autorise le trafic sortant de manière générique.

lors de l'établissement de la comm, s'échangent via les messages INVITE les adresses IP et ports sur lesquels communiquer. le client enovie des paquets, depuis client:port vers asterisk:5060 => le firewall ouvre le port en entrant pour la réponse. pareillement, et sans attendre que les paquets clients arrivent, asterisk envoie des paquets vers le client, depuis l'@ asterisk:port vers client:port - le firewall est censé les laisser passer.

j'ai plusieurs dizaines de clients connectés de cette façon, et je n'ai jamais touché un firewall client (sauf quand ils bloquent l'entrée ET la sortie).

C'est aussi applicable au port 5060. Il n'est même pas garanti que le client utilise ce port comme port source, et il n'est pas nécessaire de l'ouvrir coté client. Il est obligatoire coté serveur.

donc, ma réponse est : plutôt que de monter une usine à gaz, cherchez ce qui ne va pas dans votre config, et vous aurez, de mon expérience, plus à toucher au firewall de vos clients

Après lecture de votre message, me permettez-vous que je vous envoie en message privé la configuration de mon firewall IPTABLES au format TXT ?

[jean]

Je suis un fervent croyant dans les forums... et le fait de poster publquement permettra d'aider qqun d'autre (peut être même pour un soucis qui n'a rien à voir !)

Je préférerais que le contenu soit anonymisé et posté sur le forum.

Pour ce pbm de rtp, que regarder ?

1/ faire un rtp set debug on
(il ne faut pas qu'il y ait trop de trafic, notamment d'autres appels, sinon c'est illisible)
taper la commande sans la valider: rtp set debug off

dans une autre fenetre, avec le package ngrep (installé par apt-get pr debian ou google ngrep sur centos), faire un ngrep -O monfichier.pcap port 5060 and host x.y.z.t
w.y.z.t étant l'ip du client

revenir sur l'autre fenêtre
lancer l'appel
une fois que l'écran de la console ast* defile à fond, on peut faire entree pour arrêter le debug

2/ que regarder ?
- sur le rtp debug, asterisk doit dire qu'il a envoyé des paquets à telle adresse, et reçu des paquets - s'il a pas reçu, effectivement, pbm dans le sens client / serveur
- analyser les trames en copiant le fichier.pcap sur une machine avec wireshark, et regarder les adresses dans l'invite (il indique l'@ du media) - est ce de l'ip publique, ou du lan ?
- vérifier les couples ip destinations / port

3/ si ca ne suffit pas, il faut aussi regarder les trames coté client (un pc windows avec un softphone et un wireshark le permet) et voir à quelle adresse est effectivement envoyé les trames rtp


voila, avec l'ensemble de ces infos, ca permet normalement de voir ce qui ne va pas !