Je me suis souvenu que j'avais un PFSense de test dans un coin avec un OpenVPN déjà tout prêt. Lui fait du NAT. Il a aucune règle de filtrage et j'ai pfctl -d. Utilisation de TUN + un même réseau pour tous les clients. Aucun pare-feu sur les clients.
Premier test : je monte ce VPN OpenVPN, je démarre Linphone, il m'enregistre sur le PABX : ip src = IP du PFSense (donc NAT). Je tél à la chambre de conférence. Je n'ai pas de son. Environ normal sauf que STUN aurait du faire le job puisque l'IP retournée par le serveur STUN était bien l'IP de NAT. Donc STUN fail. Sur mon compte SIP, je mets nat=yes. Restart Linphone. Ça fonctionne. => conclusion : nat=yes produit bien un effet quand y'a du NAT. J'en doutais pas, mais j'étais surpris que ça ne fonctionne pas hier. Deuxième test : je vire le NAT du PFSense. Je teste avec mtr, netcat, etc. que j'peux faire du client<->client. Je vire nat=yes. Appel entre collègues avec Linphone 4.1.1. Ça marche. Pas de bug des 30 secondes. Mais, avec cet interlocuteur, ça a souvent fonctionné, donc ça veut rien dire. Troisième test : Même que deuxième test, mais avec Linphone 3.11 d'un côté. On s'entend, mais coupure auto après 36 secondes (et plus 31/32 :D). => conclusion : le VPN ASA est pas le seul fautif, on dirait. J'ai analysé les captures réseau des 3 tests et le journal Asterisk. * Quand ça fonctionne avec Linphone 4.1.1 des deux côtés, l'Asterisk est en relais RTP. * Dans le journal Asterisk, je vois un « Strict RTP learning complete » pour mon collègue et pour moi. * Quand ça fonctionne durant 30 secs avec Linphone 4.1.1 d'un côté et 3.11 de l'autre, Asterisk n'est pas en relais RTP. * Dans le journal Asterisk, je vois un aucun « Strict RTP learning complete » pour qui que ce soit. Il y a bien les « Strict RTP learning after remote address set to », mais ça s'arrête là. * Quand un seul interlocuteur entend l'autre avec Linphone 3.11 (car je triche), je vois un flux RTP envoyé à Asterisk, l'autre envoyé en direct. Je vois un « Strict RTP learrning complete » pour moi, et que du « Strict RTP learning after remote address set to » avec l'IP de VPN du collègue, mais pas de « Complete ». Donc je n'entends pas le collègue et son flux RTP arrive en direct, sans passer par Asterisk et se fait probablement jeter par un contrôle d'intégrité de Linphone. J'en déduis qu'il est difficile d'accuser l'ASA. On dirait qu'il y a un fail de RTP autolearn avec Linphone 3.11, tout le reste étant identique par ailleurs. Pourquoi ? Je vais faire tester le VPN OpenVPN garanti sans NAT ni filtrage à plus de collègues. ----- Mail original ----- De: "Stéphane Rivière" <s...@genesix.org> À: "frnog" <frnog@frnog.org> Envoyé: Mardi 17 Mars 2020 20:32:09 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 ?!) > Merci pour ce diag. :) On est tous arrivé au même. > Quand la colère va me prendre, Ou la lassitude... >je vais monter un VPN OpenVPN tout neuf sur lequel je serai sûr que y'a pas >d'ACL ni rien et hop hop >hop. Pas envie de démerder un Cisco ASA. La VOIP en SIP/RTP, ça marche. Mais dans ta config (et beaucoup d'autres), c'est avec un VPN qu'on fait de la VOIP en mode KISS qui tombe en marche à tous les coups. Parce qu'à la base c'est aussi foireux qu'un FTP passif (comme déjà dit par un colistier). C'est ainsi. Et au moins, on est désormais dans une techno unique. Du temps de l'ISDN y'avait aussi des trucs pourris. -- Stéphane Rivière Ile d'Oléron - France --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
