GuiGui's Show

@Zeseb :

La météo juste pour le lendemain en général c'est assez fiable. Et en général la tendance au niveau des températures est assez bonne.

Je ne partage pas du tout ce constat. Même quelques heures avant un changement drastique, le site web de Météo France est souvent aveugle aux phénomènes courants (je ne parle pas d'une tempête). :O

Le réveil matin, difficile de sauter la pas !!

Comme je l'ai écrit dans ma réponse à Sammy, ça se fait petit à petit et encore plus facilement en fonction des situations (pas d'enfants, emploi tolérant aux horaires, activité prévue stimulante, etc.). Je conseille de commencer à pratiquer le sans réveil-matin en printemps / été (la lumière qui traverse les volets de bonne heure et la chaleur donnent envie de se bouger). Go go go ? :)

@Mydjey :

Idem, même retour, j'ai demandé à ma banque que le NFC soit désactivé sur ma carte et il l'est.

Ben, pas ici (Banque Popu). Liste des événements :

• Fin 2015, dans le cadre du renouvellement trisannuel, je reçois ma première carte bancaire siglée NFC. J'en demande la désactivation par LRAR. Pas de réponse ;
  
  
• Début 2018, on me vole ma carte bancaire. J'en demande une nouvelle. Sur le moment, j'oublie NFC, donc je reçois une carte NFC ;
  
  
• Début 2019, ma banque m'annonce qu'elle va remplacer ma carte bancaire en application du règlement européen 2015/751 (les catégories changent et une carte à débit différé se nomme désormais une carte de crédit, donc il faut changer son sigle qui dit carte de débit… Le droit rattrape enfin la réalité, mais le changement de sigle au motif d'information du consommateur est inutile… Joli gaspillage de plastique et d'électronique. On notera que ce règlement européen est entré en application en juin 2016, donc ma banque aurait pu me fournir une carte conforme dès début 2018… Gaspillage, bis). Par courrier simple, je demande à ma banque d'être vigilante sur l'adresse postale qu'elle utilisera puisqu'en 2018 la carte a été envoyé à la bonne adresse, mais pas le code. Pas de réponse. Plus d'un mois après, une carte est marquée comme expédiée dans mon espace personnel sur le site web de ma banque, mais je ne la recevrai pas. Deux mois plus tard, j'envoie une LRAR à ma banque afin d'indiquer que je n'ai pas reçu la carte. J'en profite pour demander la désactivation de NFC. Ma banque fait durer le plaisir en voulant re-vérifier mes données personnelles (adresse postale, etc.) tout en rejetant mon justificatif de domicile. À chaque LRAR en réponse, je rappelle l'intégralité de ma demande afin qu'elle ne soit pas oubliée dans la réponse à leurs questions, qui inclue la désactivation du NFC. Début septembre 2019, un courrier de ma banque blablate « À la réception de la nouvelle carte, avec l’option sans contact désactivée, […] ». En toute logique, fin septembre 2019, je reçois une carte… avec le NFC activé. Je le signale par LRAR début octobre 2019 et mi-novembre 2019 (LRAR qui traitent également d'autres sujets, pas fou ;) ) ;
  
  
• Après un échange téléphonique à la mi-décembre 2019 (pour traiter d'autres sujets), je reçois ENFIN une carte dont la banque m'informe que le NFC est désactivé, ce dont je doute (voir paragraphe suivant) mais je n'ai pas encore vérifié.

Il me semble même que je peux l'activer et le désactiver moi-même dans les paramètres quand je met ma carte dans une borne de ma banque (borne de dépôt ou borne de retrait je ne sais pas).

Selon la manière dont s'est implémenté, ça peut me poser problème. La carte dite « NFC désactivée » comporte le sigle NFC et le circuit NFC (j'ai vérifié). Si le circuit NFC peut être activé / désactivé à la demande, ça veut dire qu'il est fonctionnel. Comment être sûr qu'il n'est pas """"en écoute"""" (façon de parler, en NFC, c'est le lecteur qui fourni l'énergie), dans l'attente d'une séquence qui permet de réactiver le circuit NFC ? Est-on sûr que la réactivation est seulement possible depuis un appareil en contact avec la carte / puce électronique ? Renaud Lifchitz, le gus qui a publiquement exposé la fuite des données persos stockées sur les cartes bancaires via NFC disait, en 2012, que le protocole / formatage des données et les fonctionnalités (EMV) sont environ identiques, que l'on communique avec la puce avec ou sans contact…

@OpenNews :

La boite à troll anti-bio est recouverte sur la river grâce à nos amis "le hollandais volant" et "GuiGui's Show"

Plaît-il ? J'imagine que je me retrouve cité pour mon article Mes notes concernant le numéro 151 des Dossiers du Canard enchaîné « Tout n'est pas vert dans le bio » + référendum qui date de la veille. Reste à savoir pour quelles raisons.

J'ai parcouru les ressources proposées. J'aurais bien lu, mais je ne me sens pas concerné. Les bienfaits du bio ? Ça prêche un converti. L'opportunisme et les pressions de la grande distribution générale ? C'est un point de mon shaarli. L'émission de radio qui rappelle les bases (définition, définition du label AB, premières années de conversion délicates, productivité variable en fonction de ce qu'on cultive qui ne dit rien de la rentabilité à cause du coût des pythos, etc.) ? C'est aussi dans mon shaarli. Même chose pour les articles scientifiques sur productivité / rentabilité / passage à l'échelle / (ré)apprendre le métier de paysan / changement des pratiques de consommation : j'étais au courant, merci bien.

Je ne me serais pas pris une balle perdue ou un tir groupé maladroit ?

@Liandri / Libox :

N'oublie pas de le modifier dans /etc/vzdump.cfg.

Ho ! Bonne idée. Merci. Reste l'éternel débat implicite versus explicite.

P.-S. : merci pour la rivière, j'avais pas fait le rapprochement avec toi. J'avais même pas capté que c'était une instance de shaarli-api. Je n'ai pas encore capté comment un nouveau shaarli sera ajouté à la rivière (enfin, si, d'après le code source c'est soit une instance qui l'ajoute et ça se réplique partiellement, soit il faut que le shaarli soit dans l'une des importations OPML / JSON indiqués dans la conf', soit faut ajouter un OPML / JSON dans la conf').

@Orangina Rouge :

T'as fait ça tout tout seul ?

Qu'entends-tu par « ça » ?

Comme je l'ai écrit, les données géographiques (coordonnées géographiques des stations d'atterrissement et tracés des câbles), c'est le travail d'autres personnes. Le fond de carte géographique, c'est le travail d'autres personnes bien que j'y contribue parfois. Le logiciel qui permet de créer des cartes, c'est encore le travail d'autres personnes.

J'ai juste écrit un script qui converti les données géographiques de leur format actuel vers le format pour umap et qui y ajoute un peu de fioriture / mise en forme perso.

Comment ça se fait que personne n'y a pensé avant ? Est-ce que des initiatives auraient pu avoir eu lieu dans d'autres pays, d'autres milieux ?

Parce qu'on avait déjà des cartes des câbles sous-marins d'Internet basées sur Google Maps (les données géographiques viennent de là) et qu'en moyenne, on s'en fiche d'utiliser OpenStreetMap plutôt que Google Maps ? L'initiative a déjà eu lieu : sur Wikipedia, on trouve l'image d'une carte OSM des câbles sous-marins basée sur les mêmes données que la mienne, par exemple.

Ça mérite d'être pérénisé !

Les données géographiques, des instances de logiciel de cartographie, le script pour faire l'essentiel du boulot et les instructions pour construire une carte identique à la mienne sont disponibles. Go, go, go ! ;)

Résumé : état des lieux du flicage sur le web et réflexion : jusqu'où aller pour limiter son flicage web ? Bloquer la pub et les traqueurs / pisteurs ? Facile avec uBlock Origin. Ne pas laisser son navigateur communiquer à des tiers la page web précise sur laquelle on se trouve (tel article de journal, tel profil sur un site web de rencontres, etc.) ? Facile avec Smart Referer (mais il y a des fuites malgré tout). Éviter le téléchargement automatique d'une partie des contenus tiers auprès des géants du web ? Facile avec LocalCDN (qui remplace la défectueuse Decentraleyes), mais le trou dans la raquette est énorme. Bloquer tous les scripts et les frames / inclusions externes sur un site web ? Faisable avec uBlock Origin (encore faut-il le savoir) ou uMatrix, mais c'est chiant et il faut s'impliquer lourdement (débloquer des contenus externes sur nos sites favoris). Bloquer tous les contenus tiers et autoriser les indispensables site web par site web ? Faisable avec uBlock Origin ou uMatrix, mais c'est totalement invivable, même quand on est motivé. La guerre technique étant asymétriquement en notre défaveur, je pense que le retrait des contenus tiers de nos sites web favoris passe par le dialogue. Contacter l'éditeur du site web. Dialoguer avec nos collègues développeurs web / administrateurs systèmes afin de les informer des conséquences de leur choix / travail de piètre qualité. Ça ne fera pas tout (genre sur les sites web internationaux), mais ça sera déjà ça.

Ce shaarli s'adresse à un public avancé. J'entends par là des personnes qui ont l'envie et le temps de comprendre et qui acceptent le risque de rendre leur navigation web plus ou moins invivable (je préciserai à chaque étape et un retour en arrière facile est toujours possible).

Si tu ne te reconnais pas, dans leur configuration par défaut, les extensions pour Mozilla Firefox uBlock Origin et Smart Referer fonctionnent très bien sans déranger l'utilisateur. Elles sont déjà une bonne base pour défendre ta vie privée. Tu peux y adjoindre Privacy Badger et LocalCDN. Le gain n'est pas flagrant, mais la probabilité d'emmerdements est très faible.

Commençons par un rappel.

Le contenu d'un site web se décompose en plein de morceaux (texte, images, mise en forme, police de caractères, etc.). Chaque morceau peut être stocké (et diffusé) indépendamment des autres.

• Certains morceaux sont stockées au sein du domaine du site web. Exemple : sur ce site web, la mise en forme (style CSS) est stockée sur la machine dont le nom est « shaarli.guiguishow.info », le même domaine que celui de la page web consultée, donc. Autre exemple : les images du site web « example.com » peuvent être stockées sur « img.example.com », un sous-domaine. On nomme cette catégorie « contenus first-party » = 1st-party = contenus du domaine de la page = contenus du site = contenus internes ;
  
  
• Certains morceaux sont stockés hors du domaine. Exemple : les images affichées sur Wikipedia sont stockées sur « upload.wikimedia.org », un domaine différent de celui de la page web. Le fait que les deux domaines (« fr.wikipedia.org » et « upload.wikimedia.org ») appartiennent tous deux à Wikimedia n'a pas d'importance d'un point de vue technique. On nomme cette catégorie « contenus third-party = 3rd-party = tierce partie = contenu tiers = contenus externes ;
  
  
• Évidemment, les choses ne sont pas aussi simples et certains contenus tiers sont camouflés en contenus provenant du domaine de la page. Exemple : « medias.liberation.fr » se nomme en réalité « medias.liberation.fr.wtxcdn.com ». Ce n'est pas le même domaine que « liberation.fr », donc il s'agit de contenus tierce partie.

La problématique à l'origine de ma réflexion est la suivante : je veux que des contenus provenant de « youtube.com » soient chargés automatiquement lorsque que je vais sur Youtube de ma propre initiative, mais qu'ils ne soient pas chargés quand je suis sur un autre site web, comme celui du journal Fakir ou celui de la mairie de mon bled ou mon espace personnel sur le site web de ma banque.

L'objectif principal est de préserver ma vie privée : je ne veux pas que Google Youtube sache que j'ai consulté le site web de Fakir ou celui de ma mairie ou celui de ma banque. Or c'est possible avec le nom du contenu (une liste de lecture « Fakir TV », ça se voit) et/ou avec le Referer, entre autres. J'ai expliqué ce qu'est le Referer et les problèmes de vie privée que cela pose dans un article récent.

L'objectif secondaire est d'arrêter de charger des contenus qui ne m'intéressent pas afin d'économiser des ressources et de gagner du temps. Tous les sites web modernes sont des merdes qui mettent plusieurs secondes à se charger pour un contenu réel environ nul (en proportion).

Ublock Origin, uMatrix et NoScript sont quelques extensions Firefox qui permettent de filtrer la merde des sites web. La publicité, par exemple, mais aussi les traqueurs / pisteurs / profileurs (qui cherchent à collecter le plus d'informations possible), les outils de mesure d'audience, et plein d'autres éléments souvent invisibles.

Voyons le fonctionnement principal de chaque outil dans sa configuration par défaut :

• uBlock Origin : il filtre uniquement les contenus dont le nom / l'URL apparaît dans une liste de filtrage. Dit autrement : il autorise tout, sauf ce qui apparaît dans une liste de filtrage. Ce blocage a lieu, que les contenus soient ceux du site (1st-party) ou des contenus tiers (3rd-party) ;
  
  
• uMatrix : il autorise tout ce qui provient du site sauf les frames / inclusions. Les seuls contenus tiers autorisés sont les images, les CSS et les polices de caractères (il n'autorise pas les frames / inclusions, les scripts, les médias, etc.). Dans les deux cas (contenus du site ou contenus tiers), le contenu est bloqué si son nom / URL apparaît dans une liste de filtrage ;
  
  
• NoScript : les seuls contenus (tiers ou non) autorisés sont les images, les CSS, les médias, les frames / inclusions (il n'autorise pas les scripts, les polices de caractère, etc.). Néanmoins, le contenu est autorisé si son nom / URL apparaît dans la liste blanche (elle est plutôt conséquente) ;

Chaque outil a des fonctionnalités secondaires qui lui sont propres. NoScript protège contre le vol de clic et les attaques XSS basiques. uMatrix peut masquer le Referer. uBlock et uMatrix bloquent certaines indiscrétions supplémentaires comme la fuite d'adresses IP locales en webRTC ou la surveillance des liens (attribut « ping » de la balise XHTML « a »).

On va donc obtenir un résultat différent avec chaque extension. Si je reprends mon exemple de Youtube sur le site web du journal Fakir / mairie / banque : uBlock le laissera passer car il n'apparaît pas dans une liste de filtrage, uMatrix ne le laissera pas passer car il s'agit d'une inclusion, et NoScript le laissera passer car il s'agit d'une inclusion et que Youtube apparaît dans la liste blanche (comme la plupart de l'empire Google).

Par défaut, si l'on bloque / débloque un contenu avec uBlock Origin ou NoScript, même temporairement, ça vaut pour tous les sites web (et tous les onglets). Avec uMatrix, par défaut, l'autorisation vaut pour le site en cours (j'autorise youtube.com sur le site web de Fakir et uniquement sur ce site web). Avec sa configuration par défaut, uMatrix répond mieux au fil rouge de cette réflexion.

Sans surprise, un même type d'élements peut être bloqué par défaut par plusieurs de ces extensions, mais pas toujours. Exemple : les scripts sont bloqués par NoScript (sauf ceux de la liste blanche) et par uMatrix (sauf ceux du domaine de la page web consultée).

Évidemment, il y a des équivalences.

• Pour qu'uBlock Origin fonctionne comme uMatrix fonctionne par défaut, il faut bloquer globalement les frames / inclusions et les scripts. Cela se fait à la dure dans l'onglet « mon filtrage dynamique » des préférences d'uBlock Origin. On va plutôt le faire en mode simple. On va dans les préférences -> onglet « paramètres » -> on coche « activer les fonctionnalités avancées ». À partir de là, le menu qui apparaît quand on clique sur l'icône d'uBlock Origin dans la barre d'outils s'enrichit : la liste des domaines bloqués (qui apparaît quand on clique sur « Requêtes bloquées » ou « Domaines connectés ») contient désormais deux colonnes. Celle de gauche sert à bloquer / autoriser un contenu globalement (tout site web confondu). Celle de droite sert à autoriser / bloquer un contenu sur le site web actuel. Pour bloquer les frames / inclusions, il suffit donc de cliquer sur la couleur rouge dans l'intersection entre la ligne « Cadres de tierce-partie » et la colonne de gauche (couleur verte au même endroit pour débloquer globalement). Icône cadenas pour sauvegarder et icône gomme pour effacer tous les changements récents pour ce site. Utiliser la même méthode pour bloquer les « Scripts de tierce-partie » ;
  
  
• Pour qu'uBlock Origin fonctionne comme NoScript fonctionne par défaut, il suffit de bloquer les « Scripts de tierce-partie » avec la méthode du point précédent. Attention : c'est une simplification ! NoScript protège contre le vol de clic, contre les XSS, etc. et bloque par défaut d'autres objets que des scripts, ce qu'uBlock ne fera pas ;
  
  
• Évidemment, on peut faire en sorte qu'uMatrix fonctionne comme uBlock Origin fonctionne par défaut en autorisant les cadres / inclusions et les scripts, ou comme fonctionne NoScript par défaut en autorisant les inclusions ;
  
  
• Évidemment, on peut faire en sorte que NoScript fonctionne environ comme uMatrix fonctionne par défaut en bloquant les cadres dans le préréglage « par défaut » dans l'onglet « Général » des préférences, ainsi qu'en cochant « Définir temporairement les sites de haut niveau comme FIABLES » dans le même onglet ;

À ce stade, les inclusions et les scripts tiers sont bloqués par au moins l'une de ces extensions. uMatrix étant celle qui va le plus loin par défaut et uBlock Origin le moins loin (pour moi, c'est parfaitement normal, son travail réside ailleurs).

À ce stade, la navigation web peut commencer à devenir pénible car il faut autoriser les scripts et les inclusions tiers sur nos sites web favoris. Mais une fois que c'est fait, normalement c'est OK, ça change peu. C'est donc un bon compromis vie privée / confort, je trouve.

Et si l'on allait plus loin ?

Sur tout site web moderne, le style CSS est récupéré depuis BootstrapCDN, la police de caractères depuis Google et les scripts JavaScript depuis CloudFlare (ce sont des exemples). Tout ça laisse des traces chez les quelques géants du web qui leur permettent de tracer un internaute entre les sites web qu'ils consultent (car ces acteurs sont utilisés partout) et à l'intérieur d'un site web (untel a lu tel et tel article).

Peut-on bloquer tout ça ? Peut-on bloquer ces contenus tiers ?

Depuis plus de quatre ans, j'utilisais l'extension Firefox Decentraleyes. Elle détecte l'utilisation de scripts bien connus et, plutôt que de les faire télécharger par le navigateur web, elle les injecte elle-même dans la page. Dit autrement : cette extension embarque les scripts bien connus et les remplace sur les sites web consultés. Ainsi, le fonctionnement du site web est identique, mais rien a été téléchargé depuis le site web du géant du web.

Depuis plus d'un an, je constate qu'elle est inefficace. À part pour remplacer un jquery téléchargé chez Google, elle est incapable d'agir pour un script téléchargé depuis jsdelivr.net, MaxCDN, jquery.com (!!!), cdnjs.com et autres. J'ai pourtant la dernière version, la 2.0.14 qui est sortie il y a deux semaines.

LocalCDN est une extension Firefox dérivée de Decentraleyes. D'après mes tests, tout ce que j'ai mentionné au point précédent est substitué par une version locale sauf jsdelivr.net. C'est déjà beaucoup mieux. C'est du logiciel libre. Je n'ai pas encore assez de recul afin de dire si ça ne fait pas fuiter des choses en douce et si ça casse rien.

Je ne crois pas trop à ce type de solution pourtant très simple d'utilisation : seuls quelques rares contenus tiers sont pris en charge, donc il reste beaucoup de fuites, et, surtout, la version des scripts change tellement souvent que je suis certain que l'extension est inutile sur les sites web qui suivent les versions, son temps de mise à jour étant plus long que le délai moyen d'apparition d'une nouvelle version d'un script voire celle d'un nouveau script à la mode.

On peut bloquer tous les contenus tiers d'un site web donné avec uBlock Origin. En appliquant la méthode ci-dessus (premier point de la liste « il y a des équivalences ») à l'intersection entre la ligne « Tierce-partie » et la colonne de gauche. Comme avant, il sera possible de débloquer des contenus domaine par domaine sur chaque site web en cliquant sur la couleur verte dans l'intersection entre un domaine et la colonne de droite. L'autorisation est descendante / récursive : autoriser un domaine autorise ses sous-domaines. C'est pratique avec les CDN, ça permet d'autoriser toutes les instances présentes et futures d'un seul coup. Mais, en cas de vol d'un nom ou d'une attaque, du contenu pourra être injecté sur le site web que tu consultes, d'où ne pas autoriser les scripts sur tout un domaine et ses sous-domaines peut être une bonne idée. Aucun problème pour CSS, médias, etc.

Je vois deux limites :

• uBlock Origin ne donne pas de visibilité sur le type du contenu qui est bloqué / débloqué : CSS ? images ? scripts ? ;
  
  
• En conséquence, bloquer / débloquer un domaine bloque / débloque tous les types de contenu pour ce domaine et ses sous-domaines ;

Ben, utilisons uMatrix, alors. Sa présentation matricielle nous permet de voir les types de contenus et les domaines et de bloquer / autoriser tel type de contenu (cliquer sur l'entête des colonnes), tel domaine (cliquer sur l'entête d'une ligne) ou tel type de contenu provenant de tel domaine (cliquer sur l'intersection) pour chaque site web.

Je vois deux limites.

La première est que, par défaut, uMatrix n'a pas les mêmes listes de filtrage qu'Ublock Origin, donc il laisse passer des traqueurs / pisteurs bloqués par uBlock. On peut obtenir le même comportement que celui d'uBlock en important toutes les listes de filtres dans les paramètres (onglet « Ressources ») ainsi qu'en bloquant les styles CSS (et les polices de caractères) et les images tierces. Pour ce faire, il faut cliquer sur l'icône d'uMatrix dans la barre d'outils, passer en vue globale en cliquant sur « * » (en haut, à gauche) puis cliquer sur l'entête de la colonne CSS et celui de la colonne images. Cadenas pour sauvegarder. « * » pour revenir à la vue locale. On pourra débloquer des contenus (images, CSS, police de caractères, médias, etc.) au cas par cas, site web par site web et domaine par domaine comme on l'a vu ci-dessus.

La deuxième limite d'uMatrix est qu'il ne bloque pas encore les traqueurs / pisteurs déguisés. Qu'est-ce ? Au début de ce shaarli, j'ai écrit que certains contenus tiers sont camouflés comme contenu interne au site, comme « medias.liberation.fr » qui se nomme en réalité « medias.liberation.fr.wtxcdn.com ». (Évidemment, comme l'explique l'article pointé, cela diminue le niveau de sécurité face à un contenu injecté…) Il en va de même pour les traqueurs / pisteurs. Regardons le script dont le domaine est « f7ds.liberation.fr ». Son vrai nom est en réalité « atc.eulerian.net. ». Eulerian est une société commerciale qui exerce dans le marketing. Le script est un traqueur / pisteur. Le fait qu'une liste de filtrage bloque le domaine « eulerian.net » sera inefficace puisque cette ressource se nomme « f7ds.liberation.fr ». Depuis février 2020, uBlock Origin prend en compte le nom final, mais pas la version d'uMatrix publiée sur addons.mozilla.fr (la version beta disponible dans le dépôt git le fait). Donc, pour l'instant, si l'on utilise seulement uMatrix, on perd en qualité de blocage de la vraie merde (les traqueurs / pisteurs), ce qui est un mauvais choix, à mon avis : mieux vaut filtrer le plus offensif, donc les atteintes à la vie privée certifiées.

Notons qu'on peut utiliser uBlock Origin pour le blocage et uMatrix pour la visibilité sur les contenus. Le meilleur des deux mondes. Pour cela, on peut désactiver toutes les listes de filtrage d'uMatrix. Comme ça, pas de doublon sur ce périmètre-là, donc gain de temps lors de l'analyse d'une page web. On peut également désactiver les autres protections d'uMatrix afin d'être sûr de tout centraliser dans uBlock, ce qui facilite le diagnostic d'un sur-blocage / comportement étrange. Ça sert à rien à moyen terme puisque uMatrix aura le même comportement qu'uBlock Origin.

Alors utilisons uBlock Origin en bloquant tout contenu tiers et en acceptant de perdre en visibilité sur le type de contenu bloqué (script, CSS, etc.). Ce n'est pas si simple…

Si le véritable nom qui héberge les images et/ou le CSS est en dehors du domaine (statics.liberation.fr = statics.liberation.fr.wtxcdn.com, par exemple), alors le contenu sera bloqué. Même chose si le HTML est en dehors du domaine (exemple : www.gouvernement.fr = sni.www.gouvernement.fr.c.footprint.net) : toute la mise en forme saute.

Ça se passe comme ça sur pleeeeiiiin de sites web. La navigation web devient l'enfer sur terre. Vraiment. Même pour quelqu'un de motivé.

Et ça ne va pas s'arranger. Regarde le nom suivant : www.francebleu.fr = a3d5db99c4f9f11e9bd370659f4f1e30-375828590.eu-west-3.elb.amazonaws.com. Cela identifie une instance chez Amazon AWS. T'es pas sûr de tomber sur la même instance lors de ta prochaine visite. En clair : il faudra peut-être débloquer à nouveau encore et encore France Bleu dans uBlock. C'est chiant et ça encombre la liste des règles d'uBlock Origin, ce qui va nécessairement le ralentir. Perdu.

Tu noteras que ce problème surviendra aussi avec uMatrix dès lors que la version publiée sur addons.mozilla.org bloquera aussi le nom final plutôt que le nom de façade.

Dit autrement : il va devenir très compliqué de bloquer les contenus tiers.

Au moins, ça permet de se rendre compte qu'on a vraiment merdé, que le web est devenu n'importe quoi. Mais vraiment. Tu veux aller peinard sur le site web de ton gouvernement ? Tu atterris chez un opérateur de communication États-Unien (footprint.net = Level 3). Tu veux aller sur le site web de ta radio ? Tu atterris chez Amazon. Le site web de ton journal ? Vlam le traqueur déguisé. C'est sans compter sur tous les acteurs qui seront informés lorsque ton navigateur récupérera CSS, images, police de caractères, scripts, vidéo, carte géographique, etc. d'un banal site web. J'apprécie aussi beaucoup les styles CSS et les polices de caractères qui sont chargés depuis des hébergeurs externes sans être utilisés sur le site web… … …

On pourrait demander à l'auteur d'uBlock Origin / uMatrix de ne pas considérer la page web comme du contenu tiers. Si l'utilisateur a désiré consulter tel site web, peu importe que la page web soit hébergée hors de son domaine. Afficher la page en bloquant tout le reste, c'est déjà informer le prestataire choisi par le site web (Amazon pour France Bleu et Level 3 pour le site du gouvernement). Même raisonnement pour les images et le CSS : si l'hébergeur / le nom final est le même que pour la page web, on peut laisser passer. J'imagine cependant que ce leste permettra des contournements malveillants.

Bref, bloquer les contenus tiers sur les sites web est une stratégie invivable, même pour quelqu'un de motivé.

C'est pour ça qu'il faut mettre la pression sur les éditeurs des sites web qu'on apprécie afin qu'ils internalisent les ressources (images, styles, polices de caractères) utilisées sur leur site web. C'est pour ça que j'ai écrit aux journaux que j'apprécie, par exemple. J'ai aucun doute : ça servira à rien, mais ça permet de prendre date, de dire « à partir de telle date, vous n'ignoriez plus la problématique, donc vous êtes responsable. Vous saviez et vous n'avez rien fait ».

Il faut également former les développeurs web et les administrateurs systèmes. Les premiers afin qu'ils apprennent à utiliser le framework qu'ils utilisent et qui permet d'internaliser en un clic les ressources (comme les traqueurs dans les applications mobiles qui sont activés par défaut par incompétence). Les seconds afin qu'ils apprennent à faire de la montée en charge sans recourir à des prestataires qui deviennent de plus en plus hégémoniques.

Ne vais-je pas trop loin ? Est-il vraiment utile de bloquer les contenus tiers des sites web ?

Après tout :

• uBlock Origin bloque les diffuseurs de publicité, les traqueurs / pisteurs, et les mesureurs d'audience. Uniquement ceux connus, certes ;
  
  
• Smart Referer empêche la fuite du Referer auprès des quelques hébergeurs dominants de contenus tiers. Ils voient donc une date+heure, une adresse IP et un navigateur web (User-Agent), mais ils ne savent plus quel site consulte l'internaute. Mais, parfois, le nom de la ressource récupérée en dit long ;
  
  
• Avec LocalCDN à la place de Decentraleyes (qui ne fonctionne plus), on évite la récupération d'une partie des contenus tiers, ceux les plus répandus. Ça n'apporte pas grand-chose de plus niveau vie privée (le géant du net ne sait plus qu'à telle heure, tel navigateur avec telle adresse IP fait des actions), mais c'est possible. Attention : je ne suis pas encore sûr que cette extension ne fasse pas fuiter volontairement (par malveillance) des choses ;
  
  
• On peut configurer Firefox afin qu'il ne récupère pas les polices de caractères externalisées (cette récupération fait fuiter le nom du site web sur lequel on se trouve dans l'inévitable entête HTTP « Origin: ») ;
  
  
• Si l'on utilise uMatrix ou que l'on configure uBlock Origin pour ce faire (voir ci-dessus), on bloque les scripts et cadres / inclusions tiers sans trop pénaliser sa navigation web. Là encore, des géants du web ne sauront plus qu'à telle heure, tel navigateur avec telle adresse IP fait des actions ;
  
  
• NoScript apporte des garanties côté sécurité (protection contre les attaques XSS et vol de clic, entre autres), mais environ rien côté vie privée, en comparaison de la somme des points précédents.

Alors, oui, il n'y a pas que le Referer qui informe les géants de nos lectures précises sur le web, d'autres entêtes HTTP le font (par exemple : « Origin: » pour Ajax / XMLHttpRequest, la récupération d'une police de caractère, et d'autres usages). Mais comme on bloque ces contenus (polices et scripts) avec Firefox et uMatrix / uBlock Origin aux 4e et 5e points, ça n'a pas d'importance.

Le nom du contenu est parfois bien suffisant pour identifier le contexte (quand ton navigateur demande la liste de lecture « Fakir TV » à Youtube sans rien demander au préalable, c'est qu'il est sur le site web de Fakir.

Les hébergeurs des contenus externes / tiers restants (CSS, JS, images) déposent rarement des cookies. Petite digression : on peut bloquer tous les cookies avec uMatrix et les autoriser au cas par cas pour chaque site web en utilisant la mécanique vue et revue tout au long de ce shaarli. Cela permet de remplacer l'extension Firefox Cookie Monster morte lors du changement de format des extensions et de pallier à l'absence de visibilité à laquelle nous confronte Firefox (comment sais-je que tel site web qui ne s'affiche plus a besoin de cookies ? pour quel domaine ?).

Donc, au final, faut-il se rendre la navigation web invivable pour ces contenus tiers restants ? Je n'en suis pas convaincu. On peut s'arrêter aux mesures mentionnées dans la liste de 6 points ci-dessus si l'on est motivé ou juste installer les extensions Firefox uBlock Origin, Smart-Referer (et éventuellement LocalCDN) si l'on ne veut pas se prendre la tête.

En revanche, ce dont je suis sûr, c'est qu'il faut agir à la racine du problème, c'est-à-dire du côté des sites web. Ne pas hésiter à contacter l'éditeur des sites web que t'apprécie pour lui demander de dégager un maximum de contenus tiers. Ce sont eux les responsables. Si ça peut inspirer, voici ce que j'ai écrit aux journaux que j'apprécie. De même, ne pas hésiter à sensibiliser les développeurs web dans nos taffs respectifs. : internaliser style CSS, scripts JavaScript, polices de caractères, etc., c'est ni compliqué ni chronophage. Si un échange humain ne prend pas et que tu es administrateur système, tu peux aussi déployer l'entête HTTP Referrer-Policy. Bien que ça laisse un trou conséquent dans la raquette, ça sera déjà ça de pris à moindre effort.

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.

Présentation

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…

Notes générales

• Ci-dessous, je vais essentiellement parler du logiciel de téléphonie Linphone, car c'est celui qu'on a sélectionné en amont des problèmes que je vais décrire, mais nous avons aussi essayé Jitsi, Zoiper, Blink, microSIP et d'autres, et les problèmes décrits ci-dessous se produisent aussi avec ces logiciels ;
  
  
• Pour conduire nos diagnostics, nous avons désactivé les éventuels pare-feux sur les ordinateurs de télétravail, que ce soit Netfilter Linux ou le pare-feu winwin.

Problème numéro 1

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.

• Parfois, ça cesse de fonctionner. Linphone émet bien une requête STUN, obtient bien une réponse dans les temps… mais ne l'utilise pas lors de la négociation SDP. Il faut le redémarrer, plusieurs fois, et encore, ça ne suffit pas toujours. Il semblerait que la prise en charge de STUN par Linphone échoue quand une adresse IPv6 est configurée sur l'une des interfaces de la machine, mais c'est une hypothèse ;
  
  
• Tous les logiciels de téléphonie ne permettent pas de configurer explicitement un serveur STUN (Jitsi, par exemple), donc la pérennité de cette solution est remise en question (qui dit que Linphone ne va pas retirer cette possibilité ?) et l'on dépend d'un logiciel ;
  
  
• Ce n'est pas configurable partout car l'usage exclusif de STUN est déconseillé ;
  
  
• Un serveur STUN est une brique de plus à superviser et à maintenir afin d'assurer le service de téléphonie.

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.

Problème numéro 2

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.

Conclusion

Que retenir de tout ça ?

• Les softphones / logiciels de téléphonie indiquent n'importe laquelle de leur adresse IP dans la négociation SDP et souvent pas celle d'un VPN partiel / split tunnel / VPN sans route par défaut. Il y a parfois aucune constance dans le choix ;
  
  
• La fonctionnalité magique RTP autolearn d'Asterisk est chatouilleuse. Même sans filtrage ni NAT et avec un VPN décent (OpenVPN), elle peut foirer et faire basculer une conversation en pair-à-pair (ce qui en soi n'est pas un problème sauf si des perturbateurs sont à l'œuvre sur le réseau, voir point suivant) ;
  
  
• Un VPN Cisco ASA en niveau 3 avec lequel on ne fait ni filtrage ni NAT et sur lequel on désactive le SIP ALG et l'on configure des timeouts UDP et SIP élevés pose problème. Notamment, lors de la bascule pair-à-pair après échec de l'apprentissage RTP. Ça se produit pour certains clients, sans que j'ai trouvé un discriminant ;
  
  
• Certaines versions de certains logiciels de téléphonie rattrapent des mauvais coups en douce. Exemple : Linphone 4.X gère une bascule sur le mode pair-à-pair quand le RTP learning échoue et qu'un Cisco ASA semble bidouiller le paquet alors que Linphone 3.X ne sait pas faire. De même, Linphone 4.X résiste au phénomène (qui ne peut pas être l'ASA puisque le problème se produit aussi avec un OpenVPN) qui provoque une coupure des appels 32 à 36 secondes après leur début, alors que Linphone 3.X ne sait pas faire ;
  
  
• Il y a quand même des bugs curieux dans les logiciels de téléphonie. La version winwin de Linphone ne peut pas être réduite dans la zone de notification lors d'un appel sinon le son est coupé. La version Android de Linphone utilise parfois les mauvais serveurs DNS récursifs. Linphone 4.1.1 sous winwin ne peut pas être appelé pendant quelques dizaines de secondes après avoir raccroché un appel (même si c'est lui qui raccroche) alors qu'Asterisk voit bien la fin de l'appel. Linphone ignore parfois l'adresse IP obtenue via STUN. Etc. ;
  
  
• La meilleure solution à (presque) tout ça est d'ajouter une ligne 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.

Conseils

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. :)

Un moteur de recherche pour le réseau PeerTube : https://peertube-index.net/ . Attention : les vidéos marquées avec le tag Not Safe For Work par leur auteur ne sont pas affichées. Je regrette qu'il soit compliqué de trouver un éditeur de contenus en particulier (je veux trouver toutes les vidéos publiées par machin, peu importe leur titre).

PeerTube est un logiciel libre qui permet à quiconque de publier des vidéos sur le web. Chaque installation (instance) rejoint une fédération afin de partager les vidéos et de les rendre visibles, mais elle reste autonome, elle dispose de ses propres règles, de sa propre modération, donc adieu la censure arbitraire. Ce logiciel est développé par l'association française Framasoft qui œuvre pour des services numériques éthiques et la culture libre.

Ce site web parcourt les instances PeerTube afin de découvrir les vidéos et les autres instances.

Via une liste de discussion du fournisseur d'accès à Internet FDN.

Résumé : Flatpak est un énième gestionnaire de logiciels qui, comme tous, promet monts et merveilles. Utiliser plusieurs gestionnaires (apt-get, flatpak, appimage, etc.), c'est devoir jongler entre eux pour installer et mettre à jour des logiciels. C'est chiant, comme télécharger le binaire Windows sur le site web de chaque éditeur… Sans compter la mise à jour de chaque logiciel lors d'une faille de sécurité dans une bibliothèque commune… Si Flatpak ne crée par un raccourci dans le menu des logiciels installés, il faut trouver l'identifiant du logiciel avec flatpak list (ou flatpak list -v si l'identifiant est tronqué) puis lancer le logiciel avec flatpak run <identifiant>. On peut créer un raccourci dans le menu des logiciels en remplissant le champ « commande » avec ça.

Flatpak est un gestionnaire de logiciels pour GNU/Linux. Il vient avec ses propres dépôts de logiciels. Le but est d'embarquer tout un logiciel et ses dépendances dans un environnement cloisonné du reste du système.

La distribution du logiciel serait ainsi facilitée : plus besoin de créer un paquet pour chaque système de la famille GNU/Linux et plus besoin de se demander quelle version de telle dépendance est embarquée dans tel système, etc.

Les inconvénients ? Le premier est qu'on duplique les gestionnaires de logiciels, donc on complexifie l'installation et la mise à jour des logiciels d'un système : tel logiciel se met à jour avec flatpak update, tel autre avec apt-get upgrade, etc. Comment rien oublier ?! Le deuxième inconvénient est qu'il faut mettre à jour chaque logiciel à chaque fois qu'une faille de sécurité est trouvée dans une bibliothèque de fonctions commune à plusieurs logiciels (OpenSSL, par exemple).

Bref, pour moi Flatpak est une mauvaise idée.

J'ai été amené à utiliser Flatpak pour installer la dernière version de Linphone, un logiciel de téléphonie en logiciel libre.

Je constate que, même pas un mois après, Linphone utilise AppImage, un autre moyen de distribuer des logiciels… … … Vive la stabilité des choix !

La marche à suivre pour installer Linphone était donnée sur le site web officiel de Linphone :

sudo apt-get install flatpak
flatpak --user install --from https://linphone.org/flatpak/linphone.flatpakref

À la fin de l'installation, Flatpak dit créer une entrée dans le menu des applications. J'ai bien regardé : ce n'est pas le cas avec mon menu Mate. L'origine du problème doit être de mon côté, car cela fonctionne sur des Ubuntu.

Du coup, comment démarrer un logiciel Flatpak ? Évidemment, saisir son nom dans un terminal ne fonctionne plus…
Il faut utiliser la commande flatpak run <identifiant_unique_du_logiciel>.

Comment récupère-t-on l'identifiant unique d'un logiciel Flatpak ? Colonne « Application » dans la sortie de la commande flatpak list.

Et si cet identifiant n'est pas complet ? Exemple : ça affiche « …m.belledonnecommunications.linphone ». Il faut utiliser flatpak list -v.

On récupère l'identifiant complet, « com.belledonnecommunications.linphone » que l'on peut utiliser : flatpak run com.belledonnecommunications.linphone.

Youpi !

On peut créer un raccourci dans notre menu Mate (commande = flatpak run com … ).

Merci Flatpak, mais non merci !

Résumé : L'interface de Linphone, l'un des rares téléphones en logiciel libre encore maintenu devient agréable (et unifiée sur Windows/Android/GNU/Linux) à partir de la version 4.X. La version Windows crashe parfois quand le codec Opus est utilisé, donc il faut le désactiver. Parfois, il est impossible de répondre à un appel car l'application ne réagit plus. Je déconseille la version provenant du Windows Store : si l'on réduit la fenêtre lors d'un appel, le son ne circule plus…

VOIP = téléphonie sur Internet. Toute la téléphonie (box, mobile, téléphonie d'entreprise) passe par Internet à moment donné. J'ai écrit les trois premiers volets de la série il y a bientôt cinq ans : Tome 1 : Free Mobile, Tome 2 : des implémentations bancales et Tome 3 : Numericable. Depuis, je me suis tenu à l'écart de la VOIP… jusqu'à récemment. Et là, c'est le drame.

Linphone est l'un des téléphones en logiciel libre encore maintenu. Il faut être honnête, l'interface graphique s'est bonifiée avec le temps, notamment à partir des versions 4.X. Interface plus simple à prendre en main et unifiée pour winwin / GNU/Linux / Android.

Sur Windows (winwin), il y a actuellement deux versions : celle disponibles sur le site web officiel de l'éditeur et celle disponible dans le winwin store.

La version winwin "standard" crashe parfois lorsque le codec audio libre Opus est utilisé… L'origine est souvent l'installation d'un pack de codecs (qui fait encore ça en 2020 au lieu d'utiliser VLC ?!). A priori, ce n'était pas le cas. Il faut donc désactiver, à regret (c'est un bon codec), Opus dans la rubrique audio des paramètres de Linphone.

Parfois, cette même version se met à devenir extrêmement lente genre la fenêtre de Linphone est ouverte, tu entends sonner, mais tu ne peux pas cliquer pour répondre. Soit parce que l'application est en mode « ne répond plus », soit parce qu'actionner le bouton répondre est vain.

J'ai gardé le meilleur pour la fin. Avec la version winwin store de Linphone, si, durant un appel, tu réduis la fenêtre afin qu'il reste uniquement l'icône de Linphone dans la zone de notification, alors pouf, le son ne circule plus. L'appel suit son cours, il n'est pas terminé, mais aucun interlocuteur entend l'autre. Linphone version winwin store peut être mis en arrière-plan (c'est-à-dire qu'il y a un autre logiciel au premier plan), mais pas être réduite dans la zone de notification. :D