Le 17/03/2020 à 13:32, Guillaume LUCAS a écrit :
[...]
8) Lors d'un appel, je constate, avec wireshark/tcpdump, que le softphone met
parfois l'IP de vpn0 (10.30.x.x) dans le paquet SDP et donc, là, ça marche de
base (comme ça semblait fonctionner depuis 6 mois pour les quelques
utilisateurs), car c'est du routage de base. Mais, souvent, il met l'IP de
eth0. Forcément, l'interlocuteur à l'autre bout ne peut pas envoyer de RTP avec
ip dst=192.168.0.14…
Et cela te parait normal? Il y a déjà un problème au départ, Linphone ou
autre.
Une solution serait de mettre le réseau 192.168.0/24 dans localnet et de
faire une route sur le PABX qui enverrait le trafic vers l'interface
VPN. C'est du bricolage
9) Avec un serveur STUN sur le réseau local, la requête STUN sera contrainte, par le routage, de passer dans le VPN
(comme le SIP vers le PABX, voir point 7) donc retournera toujours l'IP RFC1918 de vpn0. Et donc les flux RTP
monteront. Et c'est ce qui se passe quand les softphones ne """"choisissent""""
pas d'ignorer la réponse qu'ils ont eu du serveur STUN et/ou qu'ils n'ignorent pas la dernière SDP reçue et/ou…
Je sais qu'il ne faut plus utiliser seulement STUN, que ICE c'est mieux. Mais
avant d'installer un serveur STUN à l'arrache, j'ai testé ICE et ça ne
fonctionnait pas. Dans mes souvenirs, ICE est une méthodo qui consiste à
s'échanger, dans SDP, tous les couples IP+port possibles, qu'on nomme
candidats. On a activé ça sur les softphones et c'est activé de base dans XiVo.
Quand j'analyse les SDP avec tcpdump, je vois qu'une seule proposition dans
SDP, l'IP RFC1918 de eth0…
Comme dit par d'autres STUN ou ICE ne devriaent pas être nécessaires
Faire marcher SIP à travers NAT çà a toujours été une galère, mais au travers
d'un VPN je ne vois pas pourquoi çà ne marcherait pas.
Idem ! C'est bien ce qui me prend la tête ! :)
As tu fais les modifs au niveau localnet ?
Exactement ! Daniel a raison de dire que les problèmes que tu as sentent NAT a
plein nez, ceci dit.
Si t'es sur qu'il n'y a pas de NAT (faire un traceroute) çà sent le pare-feu.
Je donne les """"preuves"""" suivantes :
* Dans le journal de mon Asterisk, j'ai bien des « chan_sip.c: Registered
SIP 'bczhcigi' at 10.30.1.175:62633 ». 10.30.X.X est bien une IP VPN. Je vois
bien une IP 10.30/16 différente par softphone ;
* Quand ils fonctionnent, les flux RTP circulent bien entre deux IP
10.30.x.x, et c'est bien les IPs attribuées, par le VPN, aux deux clients VPN ;
* mtr depuis mon ordi+VPN vers un de nos serveurs : un seul saut, le serveur
lui-même. mtr entre le serveur et mon ordi+VPN : un seul saut, mon IP VPN
(10.30.1.175).
Ca c'est de l'IP, pas du SIP. Le routage IP est bon puisque les paquets
partent et arrivent la ou ils doivent. Le problème est avec SIP
Pare-feu, je commence à y croire vu le merdier dans nos ACL Cisco ASA… Mais
comment expliquer que, sans y toucher, nos tests soient concluants de temps en
temps avec Linphone GNU/Linux ? Là, pour moi, ça échappe à toute rationalité.
Soit tu bloques constamment, soit tu laisses passer, mais pas les deux.
Soit tu as 2 problèmes, Pare-Feu et Softphone
--
Daniel Huhardeaux
+33.368460...@tootai.net sip:8...@sip.tootai.net
+41.445532...@swiss-itech.ch tootaiNET
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
