En interne, dans un VPN routé sans NAT, tu devais jamais avoir besoin de STUN. Déjà que même avec du NAT, c’est pas nécessaire avec un SBC « intelligent » .
Tu veux pas juste essayer Zoiper gratuit ou autre, parce que perdre du temps sur un Linphone qui est peut-être une grosse bouze…. Opensource n’est pas synonyme de qualité. > Le 17 mars 2020 à 13:32, Guillaume LUCAS <[email protected]> a > écrit : > >> ----- Mail original ----- >> De: "Michel Py" <[email protected]> >> À: "Daniel" <[email protected]>, "frnog" <[email protected]> >> Envoyé: Mardi 17 Mars 2020 01:19:26 >> Objet: RE: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il >> vraiment autant de bugs que ça dans les implémentations SIP ?!) > >> Je ne vois pas pourquoi. Si le VPN marche, tout devrait se passer avec >> RFC1918, donc l'adresse du softphone est bien celle du lien physique. >> Je ne comprends pas pourquoi tu t'enquiquines avec STUN, si tu as un VPN il >> ne devrait pas y avoir de NAT donc aucun besoin d'avoir STUN. > > Raisonnement : > 1) Notre PABX n'est pas joignable en IP depuis Internet ; > > 2) D'où il faut le VPN pour s'enregistrer sur le PABX et plus si affinité ; > > 3) Donc l'ordi sur lequel est installé un softphone a au moins deux > interfaces : eth0|wlan0 et vpn0 ; > > 4) Notre VPN n'installe pas de route par défaut, juste les routes vers nos > réseaux internes ; > > 5) Sur vpn0, il y aura une IP 10.30.x.x/16, réseau de tous nos clients VPN ; > > 6) Sur eth0|wlan0, il aura l'IPv4 RFC1918 attribuée par le DHCP de sa box > genre 192.168.0.14/24 ; > > 7) Lors de l'enregistrement sur le PABX, le softphone va émettre un SIP > REGISTER avec ip dst=<IP_PABX>. Le VPN offre une route /24 pour le réseau qui > contient le PABX, donc ça passe forcément par le VPN, donc le système > d'exploit' va sélectionner l'IP sur l'interface vpn0 pour la mettre dans ip > src du paquet IP ; > > 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… > > 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… > > >> 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 ! :) > > >> 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). > > > 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. > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
