Ce qui me fait dire que c'est de l'intox, c'est que je le vois revenir avec l'argument du : "si ça se paye pas, ça tue le business". C'est tendancieux et généralement faux, non ?
Malgré de bonnes solutions libres (et souvent gratuites), je ne vois pas de domaine ou le business ne peux plus jouer le game. Au contraire même peut-être. (c'est un ressenti j'ai pas fait d'étude de marché lol).
Je ne discuterai pas des non arguments "pas sûr, pas pro", etc. : ils ont été démontés trouzemille fois.
Considérer que libre = gratuit, c'est partir sur de mauvaises bases, de toute façon. J'essaye de financer mes logiciels libres, même si c'est souvent impossible pour les petits logiciels qui n'ont pas de mécanismes de collecte de fonds et pour les logiciels piliers / cachés (FreeBSD / PF pour PFSense, par exemple. Le fait de payer une prestation + licence PFSense ne fait pas automatiquement remonter du pognon à FreeBSD -> il faut demander / faire pression sur la société commerciale éditrice de PFSense pour qu'elle le fasse systématiquement). J'essaye que mon employeur en fasse autant : BIRD, Proxmox, OpenVPN, PFSense, Asterisk, etc. tu peux acheter du support ou des licences à la société commerciale éditrice. Donc, oui, le libre, ça rogne potentiellement des parts de marchés aux autres solutions, mais comme autre tout produit ou service, libre ou non, quoi, ça n'empêche pas le business. Ça vit de modèles économiques différents (don, vente de support / prestations intellectuelles, mutualisation par la demande, licences, fonctionnalités supplémentaires, etc.). Donc, là encore, ce n'est pas le sujet, et encore moins pour les salariés puisque l'argent ne sortira pas de leur poche.
ça n'a pas tardé avant d'avoir des demandes auprès des managers... sans réponses. (alors qu'on nous casse les couilles toute l'année pour "se former"). Faut se former mais faut pas que ça coûte, surtout en temps, la ressource qui vaut plus cher que ton petit cul de travailleur. Bref, nos managers ne se mettent pas au niveau qu'il nous impose (comment les respecter à terme ?)...
J'ai aussi entendu ça : "il faut se former afin de continuer à produire de la valeur qui sera captée par l'employeur, mais ça serait bien de ne pas s'absenter pour autant parce que sinon la société commerciale perd du fric". Tu le sens, le bel avenir des MOOC et autres formations continues à distance que tu pourras faire en dehors du temps de travail ? :))))
Je rejoins le râlage de seb (ou de Framasoft, April, LQDN, ...) sur la priorité : que les pouvoirs publics ne soient pas sur ce registre affectif, certains fonctionnaires ont une responsabilité pour proposer de nouvelles solutions et ils doivent avoir les moyens en conséquences ! Le discours officiel est aussi une priorité : valoriser équitablement les solutions et LAISSER UNE MARGE aux utilisateurs.
Personnellement, je préfère m'attaquer aux serveurs de la fonction publique et à leurs logiciels : il y a énormément plus de données personnelles et d'intelligence de ce côté-là que sur le PC de Ginette qui, soit se connecte aux logiciels distants, soit saisit des documents qui seront par nature publics (compte-rendu du Conseil d'Administration, acte de nomination, etc.). En situation de sous-effectif voulu (on dégrade le service en privant de ressources ceux qui le font tourner -> le citoyen râle -> on impose l'externalisation en expliquant que ça va résoudre tous les problèmes), ça me semble plus pertinent de prioriser cet aspect-là. Laisser une marge, ça consiste aussi à ne pas râler en permanence, à ne pas vouloir imposer le libre dans le public (ce qui était la position de l'April sur la loi pour une République numérique), et à accepter qu'un utilisateur te dise "je ne veux pas de ta merde, même si c'est dans le référentiel bidule du ministère machin".
Résumé : les logiciels de téléphonie indiquent souvent une mauvaise adresse IP à leur interlocuteur, surtout quand ils sont utilisés avec un VPN partiel / split tunnel / VPN sans route par défaut. Les VPN peuvent bricoler les paquets SIP contre la volonté de l'administrateur systèmes et réseaux. La fonctionnalité d'apprentissage RTP du commutateur téléphonique Asterisk est plutôt chatouilleuse aux interférences. Certaines versions de logiciels de téléphonie résistent plus ou moins bien aux magouilles d'un VPN. Pour toutes ces raisons, si tu dois fournir de la téléphonie d'entreprise à des personnels en télétravail et que ça foire de manière aléatoire, ajoute les lignes nat=force_rport,comedia
et directmedia=no
dans la définition de chaque ligne SIP dans le fichier sip.conf
d'Asterisk ou dans les paramètres (paramètres avancés pour « directmedia ») d'une ligne SIP dans XiVo. La première réécrit l'adresse IP contenue dans le paquet SIP/SDP avec l'adresse IP source de ce paquet, garantissant ainsi que l'IP est la bonne. La deuxième fait circuler les flux audio via le commutateur téléphonique plutôt qu'en pair-à-pair, ce qui évite les ratés de l'apprentissage RTP, les bidouilles d'un VPN et la sensibilité des softphones.
Rappel sur le fonctionnement de la téléphonie sur Internet. D'un côté, il y a la signalisation (je veux appeler untel, il a décroché, il met en attente, il reprend l'appel, etc.) avec le protocole SIP. Cet échange se fait via un commutateur téléphonique. La voix transite via le protocole RTP (et son protocole de contrôle RTCP). Il y a un flux audio par interlocuteur. Les flux audio sont échangés en pair-à-pair, sans passer par le commutateur téléphonique. L'adresse IP, le port UDP ("envoie ton flux RTP ici") et les codecs à utiliser sont négociés via le protocole SDP lui-même relayé par SIP, donc via le commutateur.
J'ai déjà exposé notre architecture de téléphonie. Notre commutateur téléphonique est donc un Asterisk empaqueté dans produit avec interface web, API, etc. nommé XiVo. On dira qu'il a l'adresse IP 192.0.2.1 avec une seule route par défaut vers le routeur global de notre organisation. Nous avons des téléphones IP de la marque SNOM. Ils sont dans le réseau 198.51.100.0/24. Il y a donc du routage / du niveau 3 entre nos téléphones et le commutateur téléphonique. Nous avons également quelques rares softphones / logiciels de téléphonie Linphone (choisi car un des seuls logiciels libres encore maintenus + interface agréable depuis la version 4.X). On utilise ça depuis des années sans problème.
Depuis environ six mois, nous avons quelques logiciels de téléphonie utilisés depuis l'extérieur (mise en place progressive du télétravail) à travers un VPN, car notre XiVo n'est pas joignable depuis l'extérieur (filtrage volontaire). Il s'agit d'un VPN partiel / split tunnel : il ne donne pas accès à Internet, seulement aux réseaux internes de l'organisation. Il n'installe donc pas une route par défaut sur le client, mais une route pour chacun de nos réseaux internes. Tous les clients sont dans un même réseau, disons 203.0.113.0/24. Notre VPN ne fait ni filtrage ni NAT. Donc, le commutateur téléphonique voit l'IP VPN d'un client. Exemple : « Registered SIP 'bczhcigi' at 203.0.113.42:62633 ». 203.0.113.42 est bien l'IP que le client VPN a sur son interface réseau VPN. Nos clients VPN peuvent se parler entre eux : un netcat
TCP et UDP entre deux clients VPN fonctionne. Notre VPN est un Cisco ASA. Ces personnels en télétravail ne nous ont pas signalé de problème.
Avec le Covid-19, il a fallu généraliser le télétravail, donc fournir une ligne de téléphone et un logiciel de téléphonie à chaque personnel. Et là ça ne fonctionne plus. Enfin, si, mais pas pour tout le monde ni tout le temps ! On est donc sur un problème aléatoire, les plus chiants à diagnostiquer…
Entre un poste téléphonique SNOM du bureau (ou un numéro externe 0[1-9]) et un Linphone à domicile, l'appel a lieu mais la personne à domicile entend rien. Entre deux Linphones, chacun dans un domicile différent, personne s'entend.
Ça, c'est le signe classique d'un filtrage ou d'un NAT. Mais, comme écrit ci-dessus, notre VPN ne NAT pas et il ne filtre pas. Il n'y a pas d'autres filtrages en interne. Il n'y a pas de filtrage aux extrémités puisqu'on a désactivé les pare-feux.
Si l'on effectue une capture réseau avec tcpdump
(sur le commutateur téléphonique) et wireshark
(sur l'ordinateur de télétravail), on constate que, dans la négociation SDP, Linphone ne communique pas l'adresse IP de l'interface réseau VPN (vpn0, disons), mais celle de l'interface eth0 (ou wlan0), c'est-à-dire celle sur le réseau local du domicile du personnel (genre 192.168.0.X). Forcément, l'interlocuteur ne peut pas émettre un flux audio vers cette destination.
Parfois, Linphone communique la """"bonne"""" adresse IP, celle de l'interface réseau VPN, et dans ce cas-là, tout fonctionne. Cela peut, en partie, expliquer pourquoi nos personnels en télétravail depuis six mois ont rien signalé.
On pourrait penser qu'il suffit de lancer Linphone après avoir établi le VPN, mais non, car, parfois, Linphone échoue même quand il a été démarré après l'établissement du VPN. De plus, on ne peut pas attendre de nos personnels qu'ils se préoccupent de lancer tel logiciel après tel autre.
On peut configurer Linphone pour forcer la communication de l'adresse IP de l'interface réseau VPN. C'est l'option « nat gateway ». Les appels fonctionnent alors dans 100 % des cas. Mais cette option a disparu dans la version 4.X, celle que l'on utilise (parce que son interface est agréable). De toute façon, tous les logiciels qui permettent de configurer l'adresse IP (microSIP, Linphone, etc.) ne conviennent pas : sur notre VPN, nous distribuons des IPs de manière dynamique : à chaque connexion, l'adresse IP du client VPN change. On ne peut pas demander à nos personnels de configurer leur téléphone à chaque fois.
On notera que, dans le cadre de webRTC, les navigateurs web sont mieux équipés que les logiciels de téléphonie ! Dans la config' avancée de Firefox, la clé « media.peerconnection.ice.force_interface » permet de sélectionner l'interface à utiliser, par exemple. Donc ça fonctionnerait impec avec les IP dynamiques de notre VPN. Ça a aussi ses inconvénients : quelqu'un qui voudrait faire de la téléphonie professionnelle (supposons avec VPN) et personnelle (sans VPN) devrait en changer la valeur en permanence…
On peut utiliser ICE, une méthode qui consiste à échanger tous les couples IP+port possibles lors de la négociation SDP et à les tester un par un. J'ai activé ICE dans Linphone et sur le commutateur (même si ça a aucun sens puisqu'il a une seule adresse IP) : ça ne fonctionne pas. D'après mes connaissances, c'est très curieux, mais c'est ainsi.
On peut utiliser STUN, un serveur qui se contente de répondre "voici l'adresse IP source du paquet IP avec lequel tu viens de me causer". On ne peut pas utiliser l'un des serveurs STUN public, car il retournerait l'adresse IP publique de la box Internet du personnel. En revanche, si l'on installe un serveur STUN en interne, la communication avec ce serveur sera contrainte, par le routage, de passer par le VPN. Donc l'adresse IP retournée sera toujours celle de l'interface réseau VPN.
Je ne veux pas trop toucher à notre commutateur téléphonique afin de rien casser (surtout qu'avec le confinement, on ne reviendra pas au bureau avant longtemps, donc on ne saura pas que l'on a cassé l'existant). De plus, nous avons un contrat d'assistance (support) et de maintenance pour notre commutateur et on n'a pas envie de l'invalider avec des modifications trop conséquentes. Pour installer un serveur STUN, j'ai utilisé le logiciel coturn
. Avec Debian GNU/Linux, un simple sudo apt-get install coturn ; sudo systemctl start coturn
suffit.
STUN fonctionne parfaitement. Mais il y a des limites.
Une meilleure solution est de demander au commutateur téléphonique, Asterisk, de réécrire l'adresse IP contenue dans les messages SDP avec l'adresse IP source des paquets IP (on est sûr qu'il s'agit de celle de l'interface réseau VPN car elle a été choisie par le système d'exploitation en fonction de l'interface de sortie).
Avec Asterisk, cela se fait en ajoutant une ligne nat=force_rport,comedia
pour chaque ligne téléphonique de télétravail dans le fichier sip.conf
. Dans XiVo, cela se fait dans l'onglet « Général » de chaque ligne de télétravail (note : XiVo recharge automatiquement la configuration d'Asterisk quand on modifie une ligne ;) ). On peut aussi appliquer cette option sur l'ensemble du parc, mais je ne le fais pas pour les raisons sus-mentionnées : ne pas casser l'existant et ne pas invalider notre contrat d'assistance / maintenance.
Des personnels continuent de ne pas entendre leur interlocuteur. wireshark
/ tcpdump
montre des messages SDP parfaitement valables qui contiennent la """"bonne IP"""" de l'interlocuteur (celle sur l'interface réseau VPN, donc). Si l'on regarde, il y a le début de l'appel (SIP INVITE, SIP TRYING, SIP RINGING, SIP ACK, etc.) puis un premier message SDP est émit par le commutateur téléphonique contenant son adresse IP, donc Linphone émet un flux audio RTP à destination du commutateur puis il reçoit le SDP émis par l'interlocuteur (et réécrite par le commutateur, voir chapitre précédent). Il cesse alors d'émettre le flux RTP. Pourquoi Linphone ne respecte-t-il pas la dernière négociation SDP ?
Je précise que changer la destination des flux RTP en cours de route est parfaitement normal. C'est comme ça que fonctionne la mise en attente ou le fait de se rendre muet : en renégociant en SDP.
Activons le journal de Linphone. Menu -> « Préférences » -> « Avancé » -> « Logs activés ». Le dossier qui contiendra le journal peut également être consulté / changé.
Lisons ce journal. Linphone reçoit bien le dernier SDP, l'analyse et le consigne : « Change audio stream destination: RTP=203.0.113.1:7078 RTCP=203.0.113.1:7079 ». L'adresse IP est la """"bonne"""". Pourquoi Linphone l'ignore-t-il ? Je n'aurai pas la réponse.
Dans le journal du commutateur, Asterisk, je remarque qu'à chaque fois que le problème constaté côté Linphone survient, l'apprentissage RTP ne va pas à son terme. L'apprentissage RTP ou RTP learning ou RTP autolearning est une tambouille interne d'Asterisk qui fait un peu de la magie dans le but d'identifier la """"bonne"""" IP à utiliser.
Quand tout fonctionne bien, le journal consigne une ligne « Strict RTP learning after remote address set to 203.0.113.1:7078 » pour chaque IP de chaque interlocuteur puis une unique ligne « Strict RTP learning complete - Locking on source address 203.0.113.1:7078 » pour chaque interlocuteur.
Quand l'un des interlocuteurs ne s'entend pas et qu'un Linphone n'émet plus de flux RTP en contradiction avec le dernier SDP, je remarque que, soit il n'y a pas de « Strict RTP learning complete […] », juste des « Strict RTP learning after remote address set […] » pour chaque interlocuteur, soit il y a un seul « Complete », pour un seul des interlocuteurs.
Pourquoi l'apprentissage RTP d'Asterisk échoue-t-il ? Comment le désactiver afin d'être sûr qu'il est bien l'origine du problème ? Aucune idée.
Quand les deux interlocuteurs s'entendent, il est possible qui cela coupe après 32 ou 36 secondes de communication. Cela dépend de qui téléphone. Si A téléphone à B, ça peut couper alors que ça ne coupera pas si c'est B qui téléphone à A. Ce point est constant : c'est toujours dans le même sens que cela foire. Cela semble dépendre de la version de Linphone. Si une 4.1.1 téléphone à une 3.11 / 3.12, alors ça coupera. Pas l'inverse.
Avec wireshark
, on voit un message SIP BYE avec un entête « X-Asterisk-HangupCause: no user responding » destiné au Linphone 3.X. Dans le journal d'Asterisk, on lit « Packet timed out after 32000ms with no response ».
Ajouter session-timers=refuse
dans la définition d'une ligne téléphonique dans sip.conf
ou dans l'onglet « Avancé » des paramètres d'une ligne téléphonique dans XiVo, n'aide pas.
Qui peut bien être responsable de tout ce qui précède ? Le seul qu'on n'a pas encore remis en cause est le VPN ASA.
Dès le début du diagnostic, nous avons désactivé son ALG (« no inspect sip ») et constaté que les timeouts UDP et SIP étaient déjà de plusieurs minutes. Pour savoir ce qu'est un ALG et les emmerdes pratiques que cela pose parfois, je te renvoie vers cet article : Le lulz de la VOIP - Tome 3 : Numericable.
Dans un coin, j'ai un PFSense (routeur, pare-feu, VPN, etc. en logiciel libre pour lequel on peut acheter des appliances, de la prestation d'intégration, de l'assistance, etc.) de test avec un OpenVPN de test déjà configuré. Niveau 3 (TUN). Tous les clients dans un même réseau /24. Aucun filtrage. Pas de NAT. Il a donc la même architecture que notre VPN ASA.
Je décide de tester. Ça fonctionne moyen. D'un côté, certains couples de testeurs qui ne s'entendaient pas s'entendent, ce qui est un gain. De l'autre côté, la coupure après 32 / 36 secondes d'appel en fonction des clients demeure. De même, le RTP autolearning d'Asterisk continue de foirer quelques fois. Mais, quand ça arrive, la communication pair-à-paire fonctionne systématiquement.
Du coup, le VPN ASA est en cause sur l'un des trois problèmes (communication pair-à-pair dysfonctionnelle). Néanmoins, ce n'est pas lui qui fait parfois échouer le RTP autolearn ni qui provoque une coupure après 32 / 36 secondes d'appel.
Ne sachant pas désactiver le RTP autolearn d'Asterisk, j'ai décidé de faire transiter les flux audio par le commutateur téléphonique. Ainsi, le résultat de l'apprentissage RTP aura peu d'importance, donc il n'y aura pas de bascule vers une communication pair-à-pair qui pose parfois problème avec notre VPN Cisco ASA.
Pour ce faire, il faut ajouter une ligne directmedia=no
dans la définition de chaque ligne SIP de télétravail dans le fichier sip.conf
d'Asterisk ou dans l'onglet « Avancé » d'une ligne téléphonique dans XiVo. Comme le reste, on peut activer ça pour tous les clients SIP, mais on ne le veut pas afin de ne pas détraquer le reste du parc qui fonctionne très bien et de ne pas rendre caduc notre contrat d'assistance / maintenance.
Ça fonctionne parfaitement. Tous les appels aboutissent. Aucun se termine après 32 / 36 secondes.
VICTOIRE \o/
Si tu ne veux pas charger ton commutateur téléphonique (d'après les pros de FRnOG, c'est relatif, c'est """"juste"""" de la copie de paquets RTP ) tout en obtenant le même résultat, tu peux le décharger en faisant transiter tes flux audio via un serveur TURN interne.
Que retenir de tout ça ?
nat=force_rport,comedia
et une autre ligne directmedia=no
dans la définition de chaque ligne SIP dans le fichier sip.conf
d'Asterisk ou dans les paramètres (onglet « Avancé » pour directmedia=no) d'une ligne dans XiVo. La première réécrit l'IP contenue dans le paquet SDP avec l'adresse IP source de ce paquet, garantissant ainsi que l'IP transmise à l'interlocuteur est la bonne. La deuxième fait circuler les flux audio via le commutateur téléphonique plutôt qu'en pair-à-pair, ce qui évite les ratés de l'apprentissage RTP, les bidouilles de l'ASA et la sensibilité de certains softphones.Lors d'un diagnostic de VoIP, ne prend pas les problèmes un par un, séparément, sinon tu ne vas pas t'en sortir. Si tu commences à noter que telle version de tel logiciel de téléphonie ne fonctionne pas ou que telle version a un comportement différent sous winwin et GNU/Linux ou que tel logiciel fonctionnait et ne fonctionne plus, tu ne vas pas t'en sortir car il y a trop d'éléments variants. Essaye de penser global, de revenir aux bases de la VoIP.
Soit vigilant à l'environnement de test : un testeur qui lance deux instances du VPN et, vlam, la """"mauvaise"""" IP se retrouve dans le paquet SDP ; un testeur qui ré-active le pare-feu winwin et, pouf, tes conditions de test changent ; un testeur lance un appel entre deux Jitsi sur deux ordinateurs situés dans le même LAN et constate que ça fonctionne très bien… car le flux ne passe pas par le VPN, mais par le LAN, etc.
Merci aux gens qui fréquentent FRnOG, une liste de discussion entre opérateurs de réseaux / téléphonie, pour leurs coups de main. :)
XiVo est une solution de téléphonie complète en logiciel libre (GPL, LGPL) développée en France. Elle est basée sur l'autocommutateur téléphonique Asterisk (je me suis déjà un peu amusé avec). XiVo propose une surcouche comme une interface web bien foutue et des API (pour changer les droits d'appel ‒ appels nationaux, internationaux, vers des numéros surtaxés, etc. ‒, pour changer le nom d'une ligne, etc.).
XiVo sait faire toute la téléphonie d'entreprise habituelle : appels, interception d'appel, renvoi d'appel (tout ou conditionné), filtrage d'appel (dit patron/secrétaire), files d'attente, messagerie vocale, diffusion d'un message éventuellement conditionné à un calendrier, salon de conférence, etc. Je crois que le seul truc que ça ne fait pas, c'est des rapports de facturation genre agréger la consommation des lignes téléphoniques d'un service afin de faire de la refacturation interne (le service informatique paye l'intégralité de la facture de téléphone et refacture leur consommation aux autres services) et de présenter aux chefs la consommation de leurs sous-fifres sous une forme kikoo-jolie.
Nous utilisons cette solution depuis 5 ans. Nous avons deux machines virtuelles Debian GNU/Linux + XiVo en failover sur deux sites géographiques pour la partie commutation, deux lignes téléphoniques T2 avec deux passerelles T2<>IP XiVo, des téléphones IP, des téléphones analogiques avec des rocades analogiques et des passerelles analogique<>IP Patton et Realtone, des logiciels de téléphonie (softphones) + XiVo client (qui permet des recherches dans l'annuaire, de voir qui nous appelle, de transférer simplement un appel, etc.), et des saloperies automatiques qui nécessitent une ligne de téléphone (ascenseurs, interphones, etc.) soit un total de 850-900 lignes.
L'éditeur de XiVo, Avencall, propose des prestations d'intégration et de support pour tout le périmètre sus-cité, une liste de matériels totalement compatibles (genre un téléphone IP avec les touches de fonction ‒ intercepter l'appel d'une autre ligne, par exemple ‒ fonctionnelles, genre des casques audio avec les boutons de fonction ‒ muet, sourd, etc. ‒ fonctionnels) et de la revente de matos (genre des téléphones IP, des cordons de téléphone, etc.). D'autres prestataires / revendeurs existent sur le marché, mais nous avons été déçu par le précédent.
Merci Seb' d'avoir monté et entretenu tout ça toutes ces années. :)
Il y a quelques années, j'ai installé et configuré un serveur VOIP Asterisk sans prétention. L'ennui, c'est que des robots essayent en permanence de trouver un couple identifiant+mdp valide dans l'objectif de dénicher des appels nationaux / internationaux. Il suffit ensuite à leur propriétaire de souscrire à une offre de fourniture d'un numéro surtaxé puis de faire téléphoner ses robots au numéro ainsi obtenu afin d'encaisser de l'argent. Asterisk consigne toutes ces tentatives dans un fichier de log… qui grossit et sature notre espace disque (le conteneur LXC qui héberge ce serveur Asterisk est dimensionné pour juste ce qu'il faut).
Soit on réduit la verbosité d'Asterisk, soit on ajuste la politique de conservation du log Asterisk, soit on filtre les pénibles. Je refuse la première solution, mais j'ai appliqué les deux autres.
La configuration de logrotate fournie par le paquet Debian contenant Asterisk ne compresse pas les logs. Changeons ça :
On évite que dpkg nous informe de la modification du fichier et nous demande ce que nous souhaitons faire à chaque mise à jour :
sudo dpkg-divert --add --rename --divert /etc/logrotate.d/asterisk.dpkg-dist /etc/logrotate.d/asterisk
sudo cp /etc/logrotate.d/asterisk.dpkg-dist /etc/logrotate.d/asterisk
Puis, on active la compression en ajoutant les lignes suivantes dans /etc/logrotate.d/asterisk :
compress
delaycompress
La compression du log Asterisk a résolu mon problème à elle seule : l'espace disque n'est plus jamais saturé. Mais ça n'empêche pas de vouloir dégager les pénibles.
Puisqu'on peut repérer une tentative pour trouver un couple identifiant+mdp depuis le log Asterisk, fail2ban est l'outil idéal : il va analyser ce fichier avec des regex et il bannira temporairement les pénibles avec iptables. Le paquet fail2ban fournit par Debian contient déjà un jeu de règles pour identifier quelques attaques contre un serveur VOIP.
sudo apt-get install fail2ban
Activer les règles de filtrage Asterisk de fail2ban en créant un fichier /etc/fail2ban/jail.d/asterisk.conf
contenant :
[asterisk]
enabled = true
Désactiver l'envoi d'un mail à root à chaque fois qu'une IP est bloquée en commentant la ligne %(mta)s-whois[name=%(__name__)s, dest="%(destemail)s"]
dans la section [asterisk]
du fichier /etc/fail2ban/jail.conf
:
sudo dpkg-divert --add --rename --divert /etc/fail2ban/jail.conf.dpkg-dist /etc/fail2ban/jail.conf
sudo cp /etc/fail2ban/jail.conf.dpkg-dist /etc/fail2ban/jail.conf
sudo $EDITOR /etc/fail2ban/jail.conf # commenter « %(mta)s-whois[name=%(__name__)s, dest="%(destemail)s"] » dans la section « [asterisk] »
Désactiver l'envoi d'un mail à root à chaque fois qu'un jeu de règles de filtrage est activé ou désactivé en créant un fichier /etc/fail2ban/action.d/sendmail-common.local
contenant :
[Definition]
actionstart =
actionstop =
Par défaut, fail2ban insère des règles netfilter qui envoient un message ICMP au robot spammeur bloqué (« -j REJECT »). On peut changer ce comportement :
sudo dpkg-divert --add --rename --divert /etc/fail2ban/action.d/iptables-common.conf.dpkg-dist /etc/fail2ban/action.d/iptables-common.conf
sudo cp /etc/fail2ban/action.d/iptables-common.conf.dpkg-dist /etc/fail2ban/action.d/iptables-common.conf
sudo sed -i -e 's#blocktype = REJECT --reject-with icmp-port-unreachable#blocktype = DROP#' /etc/fail2ban/action.d/iptables-common.conf
On peut aussi désactiver le jeu de règles de filtrage pour sshd :
sudo dpkg-divert --add --rename --divert /etc/fail2ban/jail.d/defaults-debian.conf.dpkg-dist /etc/fail2ban/jail.d/defaults-debian.conf
sudo cp /etc/fail2ban/jail.d/defaults-debian.conf.dpkg-dist /etc/fail2ban/jail.d/defaults-debian.conf
sudo sed -i -e 's#enabled = true#enabled = false#' /etc/fail2ban/jail.d/defaults-debian.conf
[asterisk]
du fichier /etc/fail2ban/jail.conf
, on ajoute une ligne : banaction = iptables-ipset-proto4
;sudo systemctl restart fail2ban
;sudo tail -f /var/log/asterisk/messages /var/log/fail2ban.log
et sudo iptables -t filter L -n -v
(et sudo ipset list f2b-asterisk-udp
si l'on a activé l'utilisation des ipset).En attendant d'avoir le temps de me pencher sur fail2ban pour la première fois, j'ai utilisé cette règle de filtrage :
sudo iptables -A INPUT ! -s $SUBNET_RESEAU -d $IP_SERVEUR/32 -p udp -m udp --dport 5060 -m hashlimit --hashlimit-above 5/min --hashlimit-burst 10 --hashlimit-mode srcip --hashlimit-name RL-SIP-GLOBL-v4 --hashlimit-srcmask 24 -m comment --comment "RL SIP QUERIES 5/min burst 10/min" -j DROP
Elle autorise 5 paquets par minute destinés au port UDP 5060 du serveur VOIP en vitesse de croisière et 10 paquets/minute par à-coups. Les utilisateurs membres du réseau ont la garantie de ne pas être filtrés grâce à « ! -s $SUBNET_RESEAU ».
Je rends cette règle de filtrage résistante à un redémarrage avec le logiciel netfilter-persistent.
Si cette règle de filtrage n'est pas idéale, elle a le mérite de calmer le jeu. Elle n'empêche pas le trunk SIP avec notre fournisseur de fonctionner normalement en vitesse de croisière, mais il ne faut pas effectuer plusieurs tentatives d'appel en une minute. Bref, cette règle fonctionne uniquement parce que je connais la plage IP des usagers de ce serveur VOIP, qu'ils sont très peu nombreux, et qu'ils n'utilisent pas compulsivement le téléphone.
En environ 3 mois d'utilisation, cette règle de filtrage a produit le résultat suivant :
Chain INPUT (policy ACCEPT 13M packets, 1285M bytes)
pkts bytes target prot opt in out source destination
83M 31G DROP udp -- !$SUBNET_RESEAU $IP_SERVEUR/32 udp dpt:5060 limit: above 5/min burst 10 mode srcip srcmask 24
Elle a filtré 31 Go (!!!) de merde, mais elle en a aussi laissé passer 1,2 Go. Bref, pas idéal.
On a reçu ça au boulot il y a quelques temps (oui, je l'ai caviardé). Je ne savais pas à quoi ressemble cette déclaration, maintenant je sais.
Je constate que, si l'on utilise des musiques libres de droit, il faut fournir un justificatif… Ce qui en décourage l'utilisation puisque les artistes engagés dans cette voie-là signe rarement un bout de papelard depuis l'autre bout du ternet… Dans notre cas, nous utilisons une solution commerciale qui intègre le logiciel libre Asterisk, XiVo, ainsi que l'une des "musiques" livrées par défaut avec Asterisk. La société qui vend cette solution nous a signé un papier pour satisfaire la SCPA.
Je ne sais pas comment est calculée l'estimation du nombre de lignes… En cherchant dans l'annuaire ? En demandant le routage aux opérateurs téléphoniques ? Dans notre cas, c'est erroné. De plus, chez nous, toutes les lignes peuvent être jointes de l'extérieur (juste, ce n'est pas publié dans l'annuaire) et une musique d'attente peut être jouée sur chaque ligne. Ben oui, même si tu me téléphones sur ma ligne directe, je peux te mettre en attente. Il me semble que c'est un comportement standard… Donc la facturation est illogique.
Chaque année, la SCPA nous envoie cette déclaration… Avec une estimation du nombre de lignes erronée… Sans tenir compte qu'on a déjà répondu xx fois qu'on utilise de la musique libre de droit… Tout ce papier gaspillé… Toute l'énergie humaine gaspillée pour taxer une niche (non mais sérieux, qui savoure une musique d'attente téléphonique ?!)… Tout cet argent qui nourrit des intermédiaires inutiles… Tout cet argent qui n'est pas redistribué aux artistes, aux interprètes et aux producteur⋅rice⋅s car les organismes de collecte ne font même pas l'effort de rechercher ces personnes afin de leur filer leur chèque…
Après avoir vu la présentation « Wake up the geek way! » de Gaël Pasgrimaud à PSES 2015 dans laquelle il nous présente son logiciel-réveil configurable via IRC et qui ne sonne pas si Gaël a causé sur IRC avant l'heure programmée, j'ai eu l'idée de me faire un réveil aléatoire.
Aléatoire sur une plage d'horaire définie. L'idée derrière, c'est est de privilégier un réveil naturel (sommeil léger, tout ça, on est toujours un peu réveillé inconsciemment dans une plage horaire autour de l'heure de réveil que notre cerveau assimile par habitude) sur un réveil en force comme le fait généralement un réveil. Tout ça sans utiliser de capteurs et des bidules connectés cheppaquoi. Alors oui, si je me couche plus tard (ou plus tôt), ça n'empêchera pas le réveil de me réveiller brutalement. Forcément, y'a des jours où l'aléatoire tombe pas au bon moment.
À la différence de Gaël, je n'ai pas dev' un bout de python qui a la classe (simplement parce que la lib panoramisk n'est pas packagée dans Debian et que j'ai pas trouvé d'équivalent potable) mais j'ai choisi de le faire en mode adminsys et crade. Et vu que j'ai appris des choses sur le fonctionnement d'Asterisk bah ça m'a bien plu.
Asterisk, le serveur VOIP standard, est capable d'exécuter des appels téléphoniques tout seul simplement en lui fournissant un fichier texte qui décrit l'appel à effectuer dans /var/spool/asterisk/outgoing . Mieux que ça, Asterisk ce sert du mtime (date de dernière modif') de ce fichier pour déterminer la date et l'heure à laquelle l'appel doit être effectué ! Bref, tout simple. On notera que tout ce mécanisme repose sur inotify. Voir https://wiki.asterisk.org/wiki/display/AST/Asterisk+Call+Files
L'idée est donc la suivante : placer un script en cron.daily (qui sera exécuté tous les jours à 6h25) qui placera un fichier dans /var/spool/asterisk/outgoing avec un mtime tiré au sort. Asterisk me téléphonera sur mon 06. Évidemment, sur mon 06, je configure une sonnerie différente pour le numéro de la ligne SIP utilisée par Asterisk histoire d'être réveillé en douceur. Si je décroche, Asterisk raccroche et considére qu'il a terminé son boulot. Si je ne réponds pas ou que je rejette l'appel, on a l'équivalent d'un snooze : Asterisk me téléphonera à nouveau dans 15 minutes (paramètrable).
La première étape, c'est la configuration d'Asterisk (je pars du principe qu'Asterisk est déjà configuré / en état de marche sinon, voir ici : http://shaarli.guiguishow.info/?vHS3rA )
Vu que c'est Asterisk lui-même qui passera l'appel, il est inutile de créer un nouveau compte utilisateur dans sip.conf ;
Dans extensions.conf, il faut créer une nouvelle extension qui décrit le déroulement de l'appel. Le fichier dans /var/spool/asterisk/outgoing demande un appel mais ne dit pas ce qu'il faut faire ensuite, lorsque l'interlocuteur répond : jouer un son, raccrocher, dire quelque chose avec la synthèse vocale, proposer plusieurs choix, etc. ? Perso, je veux juste qu'Asterisk raccroche :
[Wake-Up]
exten => s,1,wait(1) ; On attend 1 seconde.
exten => s,2,Hangup(16) ; On raccroche. 16 est le code de retour qui, en SIP, indique que l'appel s'est terminé normalement, comme attendu
sip reload
depuis la console Asterisk ou sudo systemctl reload asterisk
;
La deuxième étape, c'est de créer notre cronfile (/etc/cron.daily/reveil ):
#!bin/bash
cat<<EOF > /tmp/reveil.call
Channel: SIP/<utilisateur_sip.conf OU numero_tel@ligne_SIP_sip.conf>
Callerid: WakeUpCall ; Le nom qui s'affichera si l'appel est effectué en SIP (sinon c'est le numéro de la ligne SIP…)
MaxRetries: 3 ; Combien de fois Asterisk doit essayer de re-téléphoner si l'appel est rejetté ou si pas de réponse ? En plus de l'appel initial.
RetryTime: 900 ; Combien de temps entre chaque re-essai ? Ici 15 minutes. Ce qui nous fait un snooze de 15 minutes.
WaitTime: 45 ; Combien de temps Asterisk doit-il attendre avant de déclarer que l'appel est un échec ? Ici 45 secondes. Attention : si le numéro appelé à un répondeur, il faut une durée d'appel inférieure au déclenchement du répondeur sinon l'appel sera considéré comme un succès même si c'est votre répondeur qui répond. ;)
Context: Wake-Up ; Contexte, extension et priorité dans l'extension. Ce que l'on a défini dans extensions.conf. On peut remplacer tout ça par « Application / Data » pour exécuter une application tiers.
Extension: s
Priority: 1
EOF
# Asterisk a besoin de modifier mtime pour programmer le retry
# du call. chmod 777 + proprio = root ne fonctionne pas…
chown asterisk:asterisk /tmp/reveil.call
# On veut que le réveil sonne entre 8h00 et 9h59
touch -d "$(shuf -i8-9 -n1):$(shuf -i0-59 -n1):00" /tmp/reveil.call
# mv pour garder datetime + proprio
mv /tmp/reveil.call /var/spool/asterisk/outgoing/
Dans mon cas, l'appel s'effectue en VOIP, en utilisant CSIPSimple sur mon ordiphone. L'appel ne passe jamais par le réseau commuté donc ça ne coûte rien.
Voilà pour un usage bateau. On peut aller plus loin et créer une extension qui, quand elle est déclenchée via un appel, supprime l'alarme pour la journée. Ainsi, si vous êtes réveillé avant l'heure programmée, vous désactivez le réveil en un appel. :D