[RESEAU][TOIP] Telephonie SIP deriere un prxy ISA 2004

Tech
1

Voila j’ai un petit soucis, je suis a l’ecole derriere un proxy ISA 2004 et j’aimerai bien pouvoir utiliser mon compte SIP de chez free pour pouvoir telephonner depuis mon PC.

Nos aimables formateurs nous ont deja ouverts le ports 5060 (SIP) en sortie en TCP et UDP et le port 8000 (RTP) en sortie en TCP et UDP sur ISA, mais aparement cela ne suffit pas :stuck_out_tongue:

Quelqn sait t’il les ports utilisé pour la telephonie SIP et plus particulierement avec Xlite…

Merchi :stuck_out_tongue:

/edit : je precise que ca marche tres bien depuis chez moi deriere mon router

2

Je présume que ISA fait NAT ?

3

:stuck_out_tongue:
oui en effet NAT, Firewall, proxi et tout l’toutim…

4

Arf… épineux problème…

Un NAT “classique” ne sera pas suffisant.
Un NAT modifie les adresses dans les paquets au niveau 2 (routage).

Or, SIP écrit l’adresse IP des parties en conversation au niveau 4 (applicatif)… Ce ne sera donc pas l’adresse publique qui y sera inscrite, mais ton adresse privée, d’où le malaise.

En milieu pro., on utilise des “ALG” pour Application Layer Gateway. Ils rentrent à l’intérieur des paquets (jusqu’au niveau 4) pour modifier les adresses (un peu comme le fait un NAT au niveau 2). Et encore, ça reste bancal.

Le truc, c’est que les protocoles ne sont généralement pas très normalisés et que chaque constructeur y va de sa sauce dans ce niveau 4…

Par ailleurs, si la négociation SIP à proprement parler passera via le port 5060 (et donc ton firewall), les sessions media (trames RTP) passent généralement par des ports UDP dynamiques difficiles à identifier (surtout si tu n’as aucun contrôle sur la config, vu qu’elle est chez Free).

Bref, good luck.

-Kif.

5

[quote=« Kif, post:4, topic: 29100 »]Arf… épineux problème…

Un NAT « classique » ne sera pas suffisant.
Un NAT modifie les adresses dans les paquets au niveau 2 (routage).

Or, SIP écrit l’adresse IP des parties en conversation au niveau 4 (applicatif)… Ce ne sera donc pas l’adresse publique qui y sera inscrite, mais ton adresse privée, d’où le malaise.

En milieu pro., on utilise des « ALG » pour Application Layer Gateway. Ils rentrent à l’intérieur des paquets (jusqu’au niveau 4) pour modifier les adresses (un peu comme le fait un NAT au niveau 2). Et encore, ça reste bancal.

Le truc, c’est que les protocoles ne sont généralement pas très normalisés et que chaque constructeur y va de sa sauce dans ce niveau 4…
Par ailleurs, si la négociation SIP à proprement parler passera via le port 5060 (et donc ton firewall), les sessions media (trames RTP) passent généralement par des ports UDP dynamiques difficiles à identifier (surtout si tu n’as aucun contrôle sur la config, vu qu’elle est chez Free).

Bref, good luck.

-Kif.[/quote]

Heu du calme, hein.
Le NAT, sapue, c’est clair. Mais on arrive généralement à se démerder, surtout en UDP.

Le problème du NAT est, comme tu le dis, que le client passe son adresse dans les paquets SIP.
Sauf que les clients ne sont pas si cons, et savent généralement détecter qu’ils sont derrière un NAT, puis détecter automatiquement les mappings effectués par le NAT.
Un protocole à même été standardisé pour effectuer cette tache : STUN.
STUN distingue 4 types de NATs, selon leur niveau de chianitude. Et seul un est vraiment génant (nats symétriques, qui ne permettent pas la detection des mappings).

Les problèmes ne viennent donc pas, a mon sens, du NAT, mais plutot du firewall.
Les solutions, donc :

  • Commencer par autoriser STUN (deux ports UDP), et l’activer dans le client (on trouve pas mal de serveurs stuns public via google).

  • verifier le comportement d’ISA. Si ISA n’est pas symétrique, ca devrais suffire (dans le cas symétrique, c’est juste plus emmerdant si le correspondant est dans le même cas, ici, pour utiliser la téléphonie free, cela ne devrait arriver que pour des appels IP SIP->IP SIP).

Note à Kif : dans le milieu pro, on va plutot utiliser un Proxy SIP, qui va soit faire proxy RTP/RTCP, soit faire le nécessaire au niveau du firewall, ce qui est une solution beaucoup plus propre qu’une « simple » ALG. (on note d’ailleurs que les ALG font un peu n’importe queud, et que ca marche de toutes facons plus sur du secure SIP).

6

Tiens un thread sur les problèmes de NAT avec SIP… ça tombe bien je suis en plein dedans pour un projet.

Alors je confirme, SIP avec un NAT c’est vraiment de la m… mais il existe des solutions.

Déjà, la première chose à faire c’est de déterminer le type de NAT que tu as sur ton ISA. Pour ce faire, le meilleur moyen est de télécharger un client STUN qui est capable d’effectuer les tests de la RFC 3489. Un qui fonctionne très bien c’est celui là : sourceforge : stun.

Ensuite, tu suis ce schéma, en regardant les paquets qui sont en retour avec un analyser genre Ethereal.

Le client les numérote comme dans la RFC. Afin de garder les tests cohérents, il faut changer le port source de votre client à chaque série de tests (voir les options du client).

Sur la RFC, le diagramme au point 10.2 contient deux « Test 1 », le premier doit s’effectuer sur la première adresse IP du serveur STUN et le second sur sa seconde adresse IP . Elle se trouve dans les paquets que le serveur a envoyés lors des tests précédents. Il faudra donc configurer Ethereal pour qu’il mette à jour les paquets en temps réel.

Sur le même diagramme, le premier test nommé « IP Same ?» compare notre adresse IP avec celle que voit le serveur STUN. Le second test nommé « IP Same ?» compare les adresses que le serveur STUN à vues lors des deux « Test 1 ».

Pour ces tests, il faut prendre en compte l’adresse IP et le port; si l’un deux ou les deux changent, le résultat du test est négatif.

[code] ±-------+
| Test |
| I |
±-------+
|
|
V
/\ /
N / \ Y / \ Y ±-------+
UDP <-------/Resp--------->/ IP ------------->| Test |
Blocked \ ? / \Same/ | II |
\ / ? / ±-------+
/ / |
| N |
| V
V /
±-------+ Sym. N /
| Test | UDP <—/Resp
| II | Firewall \ ? /
±-------+ \ /
| /
V |Y
/\ /\ |
Symmetric N / \ ±-------+ N / \ V
NAT <— / IP <-----| Test |<— /Resp\ Open
\Same/ | I | \ ? / Internet
? / ±-------+ \ /
/ /
| |Y
| |
| V
| Full
| Cone
V /
±-------+ / \ Y
| Test |------>/Resp---->Restricted
| III | \ ? /
±-------+ \ /
/
|N
| Port
±----->Restricted

			 Figure 2: Flow for type discovery process[/code]

Si tu n’as pas un NAT Symmetric, il te suffit de trouver un SIP phone qui intègre un client STUN et d’utiliser l’un des serveurs publics ci-dessous (ou un autre):[ul]
[li]stun.fwdnet.net[/li][li]stun.fwd.org (no DNS SRV record)[/li][li]stun01.sipphone.com (no DNS SRV record)[/li][li]stun.softjoys.com (no DNS SRV record)[/li][li]stun.voipbuster.com (no DNS SRV record)[/li][li]stun.voxgratia.org (no DNS SRV record)[/li][li]stun.xten.com[/li][li]stun.noc.ams-ix.net[/li][/ul]Bon, je pense que tu as toutes les chances que ce soit un NAT du type Symmetric… et dans ce cas t’es plus dans la merde car STUN n’est pas capable de fonctionner avec un NAT Symmetric.

Si c’est ton cas, essaye de regarder du côté de TURN ou de ICE, par contre je n’ai pas encore pu vraiment voir le fonctionnement de ces derniers, donc je ne sais pas si c’est vraiment utilisable en pratique.

Enfin, je te conseille la lecture de ce document : NAT Traversal in SIP qui explique bien les problèmes et donne les fonctionnements de STUN, TURN et ICE.

7

[quote=“Gimly, post:6, topic: 29100”]Tiens un thread sur les problèmes de NAT avec SIP… ça tombe bien je suis en plein dedans pour un projet.

Alors je confirme, SIP avec un NAT c’est vraiment de la m… mais il existe des solutions.[/quote]

Copain !
Perso, c’était mon projet 2004/2005.
Si tu veux mon rapport : http://users.info.unicaen.fr/~ahoudele/files/projet.pdf

8

[quote=“Tzim, post:7, topic: 29100”]Copain !
Perso, c’était mon projet 2004/2005.
Si tu veux mon rapport : http://users.info.unicaen.fr/~ahoudele/files/projet.pdf[/quote]

Tiens, sympa un autre de la zone qui a bossé sur la VoIP. Tu bosses toujours dans le domaine maintenant ou tu es passé à autre chose?

En fait le projet sur lequel je bosse est basé surtout sur la sécurité de SIP et autre. On a dans l’idée de créer un “testeur” de réseaux VoIP et des documents Best Practices. On a aussi un projet d’IDS qui serait capable de reconnaître les différentes attaques qui peuvent être liées à la VoIP. Donc un bon gros projet… pour l’instant je n’ai malheureusement rien à donner vu qu’on vient de débuter, mais si t’es intéressé je peux te tenir au courant. On va de toute manière monter un site pour le projet.

9

[quote=“Gimly, post:8, topic: 29100”]Tiens, sympa un autre de la zone qui a bossé sur la VoIP. Tu bosses toujours dans le domaine maintenant ou tu es passé à autre chose?

En fait le projet sur lequel je bosse est basé surtout sur la sécurité de SIP et autre. On a dans l’idée de créer un “testeur” de réseaux VoIP et des documents Best Practices. On a aussi un projet d’IDS qui serait capable de reconnaître les différentes attaques qui peuvent être liées à la VoIP. Donc un bon gros projet… pour l’instant je n’ai malheureusement rien à donner vu qu’on vient de débuter, mais si t’es intéressé je peux te tenir au courant. On va de toute manière monter un site pour le projet.[/quote]

Je bosse plus ou moins dans le domaine.
Pour le moment, je bosse surtout sur l’integration d’IPv6 (y’a encore du taf), mais ca reste proche, et on rencontre des problèmatiques proches : pour pas mal d’admins, NAT = Firewall, et le filtrage par ports à une longue histoire…

Bref, après quelques coups d’ethereal, semble que la gateway VoIP free (celle qui fait la passerelle IP=>RTC) n’utilise pas le port standard 8000 (on comprends facilement pourquoi : elle n’a pas qu’une communication à gérer). Du coup, si tu n’autorise que les paquets UDP vers les ports 5060,8000, ca va pas suffire. Avec un firewall qui filtre les sorties, c’est le genre de trucs assez chaud à gérer sans proxy local.