> ----- Mail original ----- > De: "Michel Py" <mic...@arneill-py.sacramento.ca.us> > À: "Daniel" <t...@tootai.net>, "frnog" <frnog@frnog.org> > 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/
