GuiGui's Show

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

Des collègues se plaignent que les modifications qu'ils effectuent dans notre IPAM (interface web de gestion des adresses IP et de la conf' DHCP et DNS ‒ quelle IP est utilisée ? À qui est-elle attribuée ? Dans quel VLAN ? Etc. ‒) maison ne deviennent pas effectifs dans le DNS. Un collègue diagnostique l'usage d'un underscore dans le nom d'une machine, caractère qui serait invalide dans le DNS et bloquerait nos serveurs de noms BIND.

Je tique. À l'école Bortzmeyer, on a appris que le DNS impose une seule limitation concernant les noms, c'est leur taille. De plus, de nos jours, l'underscore est utilisé dans plein de noms DNS. DKIM (signature électronique de l'entête des emails afin d'authentifier le domaine d'émission), DANE TLSA (réparer l'énorme faille conceptuelle des certificats x509 utilisés pour authentifier les parties d'un échange chiffré ‒ TLS, par exemple ‒, voir un exemple d'utilisation ici). Jabber (protocole de messagerie instantanée textuelle libre et fédéré). Tous utilisent l'underscore, et ça se passe très bien.

Je regarde le journal de notre serveur DNS (BIND) : « nom-de-machine_a_suppr.mon-organisation.example: bad owner name (check-names) ». C'est donc vrai. Whaaat ?! :O Il y a donc une contradiction entre la théorie et la pratique.

Un essai me montre que, sur un BIND récent (9.10, packagé dans Debian Stretch), on peut ajouter un nom contenant un underscore si son type est SRV ou TXT, mais pas si son type est A ou AAAA. Cela met en exergue un comportement qui va au-delà de la norme, qui est sans doute spécifique à une implémentation.

L'école Bortzmeyer nous a aussi appris qu'il y a une différence entre un nom de machine et un nom de domaine et que les caractères autorisés pour un nom de machine sont beaucoup plus restreints que pour un nom de domaine. Mais… ça ne change rien, BIND manipule bien un nom de domaine, donc il devrait autoriser l'underscore, qui est un caractère valide pour un nom de domaine (mais pas pour un nom de machine).

Il devrait, oui, mais, par défaut, BIND vérifie que les noms associés à un type A ou AAAA respectent la syntaxe d'un nom de machine. L'idée est de dire que, 99 % du temps, l'administrateur voudra associer une IP à un nom de machine, car ce nom sera manipulé par des programmes qui manipulent des noms de machines et l'admin voudra que ça fonctionne. On peut débrayer ce comportement avec les directives de configurations « check-names ».

Un essai avec nsd 4, autre implémentation d'un serveur DNS qui fait autorité, montre aucun problème : il est parfaitement possible d'associer un nom de domaine avec un underscore à une adresse IP.

Si l'on résume : un nom de domaine a bien aucune limite concernant les caractères qui le composent, mais une implémentation de serveur DNS comme une autre, BIND, a fait le choix de bloquer les noms DNS qui ne respectent pas la syntaxe d'un nom de machine (lettres + chiffres + tiret) quand ils sont associés à un type A ou AAAA ou MX. D'après la doc', BIND vérifie également la syntaxe de la valeur d'un nom de domaine (le RDATA) pour les types SOA, NS, MX, SRV et PTR.

Un autre point m'échappe. Avant de pousser en production le fichier de zone généré par notre IPAM, nous utilisons un script de contrôle maison qui se repose, entre autres, sur named-checkzone. Il s'agit d'un outil livré avec BIND. Pourquoi a-t-il rien détecté ?

Le contrôle de la syntaxe des noms a été introduit dans la version 9.2 de BIND 9, mais il n'est pas activé par défaut. Sur les serveurs DNS maîtres, il est activé par défaut depuis la version 9.3.

named-checkzone vérifie la syntaxe des noms à partir de la version 9.3 de BIND 9, mais il se contente d'émettre un avertissement. C'est toujours le cas dans la dernière version stable (9.14).

Donc, forcément… Vu qu'il écrit tout sur stdout, si named-checkzone ne sort pas en erreur, notre script considère que tout est OK et met le fichier de zone en production. Tout s'explique.

Solutions ? Soit débrayer le contrôle de la syntaxe des noms dans la conf' de BIND, soit forcer named-checkzone à sortir en erreur si le contrôle de la syntaxe des noms échoue en utilisant son option -k fail, soit utiliser une autre implémentation de serveur DNS (BIND veut assurer les deux grands services distincts du DNS ‒ serveur qui fait autorité et serveur récursif ‒ + il veut implémenter toutes les fonctionnalités à la mode + il est monolithique = il est plus difficile à sécuriser).

Pour moi, ce contrôle de la syntaxe des noms de domaine est illégitime en cela qu'il n'est pas conforme à la norme, même s'il évite des prises de tête aux administrateurs (mais il en donne à d'autres, comme moi…).

C'est dans ce genre de moments que je me réjouis d'avoir une monoculture de serveurs DNS (d'utiliser que du BIND au sein d'une même architecture) : si l'on avait eu une diversité de serveurs de noms, certains auraient accepté le fichier de zones et d'autres non, ce qui aurait causé quelques instabilités sur le réseau et aurait rendu la mise en exergue du problème compliquée (le diagnostic n'aurait pas changé : un coup de check-soa, on aurait vu un numéro de série différent, on aurait analysé les journaux, etc.).

Je voudrais savoir si les utilisateurs de notre Wi-Fi 802.1X (WPA2-EAP / WPA2-Enterprise) indiquent leur identifiant complet, c'est-à-dire avec le realm. Comment journaliser ce dernier avec freeRADIUS ?

Dans le protocole réseau RADIUS, un realm joue le rôle d'un domaine. Il désigne une organisation, une entité. Ainsi, un identifiant est composé d'une partie locale, d'un (ou plusieurs) délimiteur, et d'un (ou plusieurs) realm. Ça ressemble à l'email ou à Jabber, hein ? Le principe est le même. Dans l'email, la partie à droite de l'arobase désigne l'organisation dans l'Internet et la partie de gauche, un identifiant unique au sein de cette organisation. Ce realm permet de transmettre une requête d'authentification à un RADIUS plus compétent.

Exemple concret ? Eduroam est un service Wi-Fi qui permet à un membre d'une université (étudiant, enseignant, personnel, etc.) de se connecter en Wi-Fi depuis une autre université. C'est ce qu'on nomme itinérance. Comment ça fonctionne ? Le contrôleur Wi-Fi de l'université d'accueil reçoit la demande de connexion d'un client Wi-Fi (ordinateur, ordiphone, etc.). Il transmet la requête d'authentification aux serveurs RADIUS de l'université. Ceux-ci analysent un realm qui n'est pas le leur. Ils transmettent la requête aux serveurs RADIUS nationaux (en France, ils sont gérés par RENATER, le fournisseur d'accès à Internet ‒ et bien plus ‒ des entités d'enseignement supérieur et de recherche, par exemple). Ceux-ci analysent également le realm. Si l'université d'affectation est française, la requête est transmise à ses serveurs RADIUS. Sinon, on remonte à la racine d'eduroam, et on redescend jusqu'à l'université d'affectation en passant par le pays. C'est donc l'université d'affectation qui autorise (ou non) la connexion sur le Wi-Fi de l'université d'accueil. L'université d'accueil n'a pas a connaître le mot de passe de l'utilisateur. Mieux, elle ne le voit pas passer puisque l'on utilise PEAP ou EAP-TTLS, c'est-à-dire des tunnels chiffrés entre le client Wi-Fi et le serveur RADIUS de l'entité d'affectation.

C'est aussi comme cela que fonctionnent les accès à Internet (ADSL, fibre, etc.) quand on est chez un Fournisseur d'Accès à Internet qui ne dispose pas de machines dans chaque répartiteur téléphonique. Exemple : l'opérateur associatif FDN utilise une offre de l'opérateur commercial Liazo qui loue les lignes à Orange ou SFR. Un identifiant imaginaire "toto/fdn@liazo.sfr" (notons la présence de deux realms, chaque opérateur, Liazo et SFR, utilisant un séparateur différent, « / » pour Liazo, « @ » pour SFR) permet aux RADIUS de SFR (qui répondent aux équipements réseaux de SFR qui sont à l'autre bout de la ligne de l'abonné, dans le central téléphonique) d'envoyer la requête d'authentification vers les serveurs RADIUS de Liazo qui enverront à FDN pour validation et pour savoir où envoyer le trafic de l'abonné. Ainsi SFR n'a pas à enregistrer les clients de Liazo dans son système d'information et encore moins les abonnés de FDN.

Bref, on nomme proxy RADIUS cette fonctionnalité de renvoi des requêtes.

Je pense que tu auras compris pourquoi nous voulons journaliser temporairement l'identifiant complet saisi par nos utilisateurs : certains ne mettent pas le realm et se plaignent que "Internet marche pas quand je suis en déplacement !!! c'est un scandale d'envergure internationale !!! J'exige que…". Forcément, sans realm, le RADIUS de l'organisation d'accueil croit que l'identifiant est local, donc il cherche dans ses bases de données locales (LDAP, etc.), trouve rien et envoie bouler. L'idée est donc d'avoir des statistiques sur le nombre d'utilisateurs concernés, leur type, etc. afin d'envisager (ou non) des campagnes de prévention ciblées plus ou moins automatisées.

Par défaut, RADIUS journalise ce genre de message : « Auth: Login OK: [guigui] ». Il reste donc que la partie locale, plus le realm.

On pourrait ajouter l'option nostrip dans la définition de notre realm ? Erreur, car, alors, notre RADIUS cherchera, dans notre annuaire LDAP, un utilisateur dont l'identifiant sera identifiant + realm. Notre annuaire LDAP ne trouvera pas un tel objet et l'authentification sera refusée.

Ce qu'on va faire, c'est journaliser les attributs contenus dans la requête RADIUS d'authentification (Access-Request) émise par le contrôleur Wi-Fi (ou un proxy RADIUS connu) avant son traitement.

Pour ce faire, on va se reposer sur le module « detail » de freeRADIUS, l'implémentation libre la plus connue d'un serveur RADIUS.

Si l'on le souhaite, on peut modifier la configuration du module « detail », mais ce n'est pas obligatoire. La conf' qui nous intéresse est dans le fichier /etc/freeradius/3.0/mods-enabled/detail.log (dans les vieilles versions de freeRADIUS, c'est dans modules/detail.log). Perso, je change :

• Dans le bloc « detail auth_log », je commente « detailfile = ${radacctdir}/%{Client-IP-Address}/auth-detail.log » et j'ajoute une ligne « detailfile = ${logdir}/realm.log ». Motif : je n'ai pas envie d'avoir un dossier par utilisateur, ça va être ingérable. Je veux un unique journal pour tous mes utilisateurs et tous mes NAS ;

• Dans le sous-bloc « Suppress » qui prévoit déjà de ne pas journaliser l'attribut « User-Password », j'ajoute les lignes suivantes afin de supprimer tous les attributs sauf le User-Name et ainsi de maîtriser l'occupation disque de mon journal :

  Packet-Type
  FreeRADIUS-Proxied-To
  EAP-Message
  MS-CHAP-Challenge
  MS-CHAP2-Response
  State

Il nous reste à déclencher la journalisation là où nous en avons besoin. Le commentaire dans la conf' nous indique que ça se passe dans le bloc authorize. Oui, mais dans quel serveur virtuel ? Default ou inner-tunnel ?

Si nous journalisons dans le serveur virtuel default, nous allons récolter toutes les demandes d'authentification adressées à notre RADIUS, y compris celles émanant de notre portail captif. Or, sur ce dernier, il est normal de ne pas saisir son realm, car il n'est pas accessible en itinérance. Au contraire, saisir son realm ne fonctionne pas. Pour nos stats, nous voulons uniquement les clients WPA2-EAP.

De plus, avec EAP, il est possible d'indiquer une identité anonyme, qui sera émise avant que soit établi le tunnel chiffré qui, lui, contiendra le vrai identifiant ainsi que le mot de passe. Ce mécanisme protège d'une interception passive du trafic (bah, ouais, les ondes Wi-Fi, c'est super simple à intercepter : une interface Wi-Fi en mode monitor, un wireshark et hop). Parfois, on n'a pas envie de crier qui l'on est tout autour de soi. Notons que, dans un système d'itinérance comme eduroam, il est nécessaire indiquer a minima le realm dans l'identité anonyme (exemple : « anonymous@monUniversité.example ») afin que les proxy RADIUS intermédiaires transmettent la requête EAP jusqu'au RADIUS de l'organisation d'affectation. Il s'agit donc d'une identité anonyme toute relative.

Pour ces deux raisons, nous comprenons que nous voulons journaliser à l'intérieur du tunnel EAP. Nous modifions donc le fichier /etc/freeradius/3.0/sites-enabled/inner-tunnel. Au début du bloc authorize, nous ajoutons une ligne auth_log.

Un petit redémarrage du serveur (systemctl restart freeradius) et c'est prêt. Le journal sera créé lorsque le premier utilisateur se présentera.

Si l'on a peur que le journal occupe beaucoup d'espace disque (pour 3 000 utilisateurs réguliers, j'ai journalisé environ 3 mo/jour), on peut demander à logrotate de compresser les vieux journaux tous les jours. Pour ce faire, on ajoute les lignes suivantes dans /etc/logrotate.d/freeradius :

/var/log/freeradius/realm.log {
        copytruncate
}

Voilà.

Sources d'inspiration : freeradius-sp et freeradius-idp.

TL;DR : si t'as un boîtier VPN Cisco ASA ou Fortinet qui ne fonctionne plus (établissement du VPN bloqué à 98 %) ou qui fonctionne partiellement (quand il est établit, des sites web ne s'affichent plus, des connexions SSH ne s'établissent plus) lorsqu'il est utilisé avec un partage d'une connexion 4G Bouygues pro et que tu n'as pas déployé IPv6 sur ton réseau (côté serveur VPN, donc), alors tu as un problème de MTU lié aux mécanismes de traduction IPv6<>IPv4 (NAT64, DNS64, 464XLAT, etc.). Je n'explique pas cela puisque la traduction IPv4->IPv6 consomme seulement 20 à 28 octets supplémentaires alors qu'il m'a fallu descendre la MTU de 114 octets. Nous constaterons, sans savoir l'expliquer, que la MTU possible à l'intérieur d'un même VPN établi au-dessus d'une traduction IPv6<>IPv4 diffère entre la version 7 et la version 9 d'Android. Peut-être que tous ces problèmes résident dans la manière dont Android gère le partage de connexion (genre filtrage excessif d'ICMPv6) ? Configurer, sur un Cisco ASA, une MTU de 1288 octets à l'intérieur des VPN TLS corrige le tir. Pas d'idée pour Fortinet. OpenVPN sur UDP n'est pas impacté (TCP non testé). :)

Nous avons un boîtier VPN Cisco ASA que nous utilisons pour établir des VPN TLS. En octobre 2019, un collègue informaticien en déplacement établit une connexion VPN en utilisant le client libre openconnect sur son ordinateur GNU/Linux raccordé à Internet via le partage Wi-Fi de connexion 4G de son ordiphone professionnel. Il ne parvient pas à accéder à l'interface web de notre Mattermost (Slack-like libre et auto-hébergé) ni à d'autres sites web internes (nous ne permettons pas d'accéder à Internet à travers notre VPN). Il ne parvient pas non plus à se connecter en SSH à plusieurs de nos serveurs : il n'a pas la demande de saisie du mot de passe (le déploiement de l'authentification par clé progresse lentement…). En revanche, ça fonctionne pour d'autres serveurs. Tous les serveurs testés sont dans le même réseau et une même règle de filtrage est appliquée par notre pare-feu en ce qui concerne SSH et le web. Il peut ping les serveurs avec lesquels il ne peut pas établir de session SSH.

J'emprunte son ordiphone, j'active le partage de connexion, et je reproduis le problème avec mon ordinateur GNU/Linux. Un coup de wireshark est sans appel : il s'agit d'un problème de MTU. Je t'ai déjà expliqué ce qu'est la MTU, son origine et les problèmes associés. Quand tu essayes d'accéder à une ressource web, que la poignée de main TCP se passe bien, mais que le navigateur web ne reçoit plus de réponse du serveur web après lui avoir envoyé une requête GET, c'est très souvent un problème de MTU. Et pour le comportement de SSH ? J'ai mis du temps à comprendre. Il était possible d'établir une session SSH avec de vieux serveurs (Debian 8 ou inférieur), mais pas avec des serveurs Debian 9. Wireshark montrait un blocage dès la poignée de main SSH (quand le client et le serveur s'échangent leur bannière). Le paquet « Key Exchange Init » du serveur n'arrivait jamais au client. Normal, SSH sur Debian 9 propose plus de suites de chiffrement, donc le paquet SSH « Key Exchange Init » est plus gros (1076 octets contre 948 octets).

Comment expliquer ce changement de MTU ? Rancid montre aucun changement dans la configuration de notre boîtier VPN depuis des années. Même chose côté routage et pare-feu (mais s/années/mois/). Je suis étonné que personne se soit plaint plus tôt. Je pense à un problème partiel visant uniquement certains équipements. J'emprunte l'ordiphone d'une collègue, partage de connexion, tout ça, et là, ça fonctionne. Le client VPN est le même (openconnect sur mon ordinateur GNU/Linux), donc il est à exclure. Le boîtier VPN est identique, donc il est à exclure. Il reste le réseau entre les deux. Un des ordiphones fonctionne avec Android (marche pas), l'autre avec IOS (marche). L'un utilise un forfait Bouygues pro (marche pas), l'autre un forfait Orange perso (marche). Il y a donc quelque chose avec Android + Bouygues Pro.

Intuitivement (on verra plus loin que je bluffe), je pense au déploiement d'IPv6 sur le réseau Bouygues. Sur le moment, je trouve, sur le web, un article qui expose que, bien que Bouygues a proposé IPv6 très tôt (mi-2017), l'opérateur était en train de le forcer progressivement comme protocole réseau par défaut. Évidemment, à l'heure de rédiger ce shaarli, je ne retrouve pas ledit article, graaah. :( IPv6 n'est pas du tout déployé dans mon organisation (oui, je sais, je sais… On ne déploiera pas dans les prochaines années :( ). Donc, depuis un réseau IPv6, une connexion à notre serveur VPN utilise forcément un mécanisme de traduction IPv6<>IPv4 mis en place par l'opérateur (Bouygues, Orange, Free, SFR, etc.).

À titre de comparaison, l'ARCEP, l'autorité administrative de régulation des télécoms, nous informe que, sur les offres mobiles, Bouygues est le principal acteur a avoir activé IPv6 à la mi-2019 (configuration automatique et à distance des ordiphones par l'opérateur pour ce faire) et que la majorité des offres mobiles à mi-2019 sont uniquement IPv6, ce qui suppose un mécanisme de traduction. Dans ces documents de l'ARCEP, on lit qu'Orange a fait un effort pour activer IPv6 sur les iPhone en septembre/octobre 2019, donc que mon test Android versus IOS aurait pu échouer.

Je désactive IPv6 sur l'ordiphone : Paramètres -> Connexions -> Réseaux mobiles -> Nom des points d'accès -> cliquer sur le seul APN proposé -> Protocole APN -> Changer la valeur d'IPv6 à IPv4. Je réactive le partage de connexion, je monte le VPN ASA et… tout fonctionne. Je retire le VPN, je désactive le partage de connexion, je réactive IPv6 sur l'ordiphone, j'active à nouveau le partage de connexion et le VPN : les problèmes reviennent. La cause du changement de la MTU est donc bien liée à IPv6 et à l'utilisation d'un mécanisme de traduction IPv6<>IPv4 sur nos forfaits mobiles Bouygues Pro. C'est difficile à croire, puisque NAT64 implique une surcharge de 20 ou 28 octets seulement et uniquement dans le sens IPv4->IPv6, mais les faits sont là…

Actuellement, la MTU appliquée à l'intérieur de nos VPN ASA est de 1406 octets. J'identifie la nouvelle MTU avec ping -M do -s <taille_variante_en_octets> <destination> (avec le VPN établi, donc). La nouvelle MTU est de 1352 octets. Pour l'appliquer, il faut aller dans ASDM -> Configuration -> Remote Access VPN -> Network (Client) Access -> Group Polices -> double-cliquer sur un groupe -> Advanced -> AnyConnect client -> champ « MTU ».

Je croyais en avoir terminé, mais non. Quelques jours plus tard, un autre collègue informaticien me rapporte ne pas avoir pu se connecter à certains de nos serveurs via le VPN sur un partage de connexion 4G. Il a un ordiphone Android et le même forfait mobile Bouygues pro que le collègue précédent. Ça devrait donc fonctionner !

Je teste avec mon ordinateur et son ordiphone : en effet, ça ne fonctionne pas. J'identifie la MTU : 1288 octets. Je désactive IPv6 sur son ordiphone et ça fonctionne. Je configure cette nouvelle MTU dans notre Cisco ASA, je ré-active IPv6 sur l'ordiphone, et ça fonctionne. Puisque le forfait mobile est identique et que les ordiphones sont de même marque (Samsung), je regarde les versions d'Android : ce collègue a Android 9. Le premier a Android 7. Entre la version 7 et la version 9 d'Android, y a-t-il un réglage différent côté partage de connexion ou une implémentation différente de la traduction d'adresses IPv6<>IPv4 en lien avec l'opérateur ? Aucune idée. :- Je n'arrive pas à expliquer cette différence. J'arrive encore moins à expliquer comment l'activation d'IPv6 sur Android 9 peut faire perdre 114 octets de MTU (1406-1288).

Parallèlement à ces ennuis du quotidien, je testais un produit Fortinet avec le premier ordiphone décrit ci-dessus (Android 7, donc). Aucun souci en partage de connexion 4G avec openfortivpn (implémentation libre d'un FortiClient VPN pour GNU/Linux vu la déplorable implémentation digne d'un étudiant en première année d'informatique livrée par Fortinet). Aucun souci avec l'application mobile officielle pour Android. En revanche, impossible d'établir le VPN depuis un ordinateur winwin 7 ou 10 : FortiClient VPN reste bloqué à 98 % de l'établissement de la connexion avant de revenir au formulaire identifiant+mdp sans afficher un quelconque message d'erreur (classe pour un produit professionnel, non ?). Notre intégrateur Fortinet ne nous a pas proposé de solution.

En désactivant IPv6 sur l'ordiphone, cela fonctionne. Le VPN met longtemps à s'établir, plus de 30 secondes, mais il fonctionne. Donc, on est toujours face à la même cause. Pourquoi le client GNU/Linux fonctionne-t-il ? Probablement pas la même implémentation. L'implémentation libre utilise PPP sur TLS sur TCP. Qu'utilise la privatrice ? TCP, mais après ? En revanche, l'application officielle qui fonctionne sur Android nous oblige à constater que l'origine de tous les problèmes décrits dans ce shaarli pourrait être du côté Android, de son implémentation du partage de connexion 4G, et pas du côté de l'opérateur. Un changement de paramètre côté Android ou quelque chose du genre.

Parallèlement, je testais une solution PFSense+OpenVPN. Force est de constater qu'OpenVPN, dans une configuration UDP (TCP non testé), n'a pas bronché, même sur un partage de connexion 4G avec IPv6 activé. C'est même son journal détaillé qui m'a mis sur la piste IPv6 puisqu'il affichait un « UDP link remote » suivi d'une IPv6 fabriquée par DNS64 reconnaissable par son préfixe « 64:ff9b:: » réservé à l'IANA.

TL;DR : route <réseau> <masque> net_gateway. « net_gateway » est un mot-clé qui désigne l'IP de la passerelle par défaut du réseau local. Elle sera récupérée automatiquement dans la table de routage du système par OpenVPN.

D'habitude, quand j'utilise OpenVPN, c'est pour encapsuler tout mon trafic dans un VPN. Sur le client, j'utilise donc la directive de configuration redirect-gateway def1.

Son effet ? Lorsque le VPN est activé, elle ajoute une route vers l'IP du serveur VPN dont le prochain saut est l'IP de la passerelle par défaut du réseau auquel je suis connecté à l'instant T, puis, elle ajoute deux routes, 0.0.0.0/1 et 128.0.0.0/1, dont le prochain saut est le serveur VPN. Ces deux routes l'emportent sur la route par défaut, 0.0.0.0/0, ajoutée par le client DHCP ou à la mano, car elles sont plus spécifiques (0.0.0.0/0 = tout l'adressage IPv4, 0.0.0.0/1 = seulement la première moitié de cet adressage). Ainsi, tout le trafic est encapsulé dans le VPN sauf le flux qui le soutient qui est envoyé au serveur VPN en utilisant la route dédiée qui envoie le trafic à la passerelle par défaut du réseau.

Aujourd'hui, je ne veux pas donner un accès à Internet aux utilisateurs de mon VPN. Je veux que seuls les réseaux de l'organisation soient accessibles via le VPN. Dans la configuration d'OpenVPN, j'ajoute donc route 198.18.0.0 255.255.0.0. En vrai, j'ajoute une ligne de ce type pour chaque réseau de l'organisation. Sauf que l'IP publique du serveur VPN, 198.18.0.42 est dans le réseau 198.18.0.0/16). Donc, quand le VPN deviendra actif, la route ainsi ajoutée dirigera le flux soutenant le VPN… à l'intérieur du VPN ! Boucle. Le VPN cessera de fonctionner.

Ce qu'il faudrait, c'est ajouter une route plus spécifique vers le serveur VPN… Mais ça suppose de connaître l'IP de la passerelle par défaut du réseau local auquel l'utilisateur du VPN est connecté. Ça change en fonction du réseau ! On pourrait coder un script qui se lancerait lorsque le VPN devient actif (c'est la directive de configuration `route-up'). Mais il faudrait qu'il fonctionne sur winwin, Mac OS, GNU/Linux, Android, IOS, etc. Infaisable.

Heureusement, OpenVPN a tout prévu. Il propose le mot-clé net_gateway pour la directive de configuration route. Ce mot-clé désigne l'IP de la passerelle par défaut du réseau local. Elle sera récupérée automatiquement dans la table de routage du système par OpenVPN.

Ainsi, pour faire ce que je veux, je mets les deux lignes suivantes dans la configuration de mon OpenVPN :

route 198.18.0.0 255.255.0.0
route 198.18.0.42 255.255.255.255 net_gateway

Tout le trafic destiné au réseau 198.18.0.0/16 sera envoyé dans le VPN. Tout échange avec le serveur VPN (198.18.0.42) sera envoyé en dehors du VPN. Le flux UDP ou TCP chifffré échangé avec le serveur VPN sera donc envoyé en dehors du VPN. Il n'y a plus de problème de boucle.

Même le plus récent manuel d'OpenVPN indique que le mot-clé « net_gateway » ne fonctionne pas sur tous les systèmes. Cela me semble être exagéré. J'ai essayé et je peux affirmer que cela fonctionne sur winwin 7, winwin 10, Mac OS X 10.11, GNU/Linux Debian Stretch, Ubuntu 16.04, Android (7 ?) et IOS (version ?).

Évidemment, pour ne pas encombrer le fichier de configuration de mes clients et pour rendre facile l'ajout et la suppression de routes (sans avoir besoin de faire récupérer un nouveau fichier de configuration à tous mes utilisateurs VPN), je configure les clients depuis la configuration du serveur. Les deux lignes précédentes deviennent donc :

push "route 198.18.0.0 255.255.0.0"
push "route 198.18.0.42 255.255.255.255 net_gateway"

Notons que ce mot-clé permet également de ne pas encapsuler des destinations spécifiques dans un VPN avec route par défaut (redirect-gateway def1). Genre ne pas encapsuler Netflix (qui bloque les VPN, proxy, etc.). Genre ne pas encapsuler le trafic vers un résolveur DNS local (parfois, on peut avoir une bonne raison de ne pas utiliser les DNS du fournisseur de VPN genre continuer à pouvoir résoudre des noms locaux au réseau auquel on est connecté). Genre ne pas encapsuler le trafic vers les plages d'adresses RFC1918 (privées) utilisées sur le réseau local, etc.

J'avais entendu parler de la PFR, mais sans plus, en effet. Je débute dans l'boulot, chef. :D Merci pour cette explication et l'historique, du coup. :)

J'évite de parler du RIFSEEP, car le mot « sujétions » déclenche en moi de profondes envies de botter des culs. Ordonnance de 1946, les agents de la fonction publique ne sont pas là pour être les sujets des chefs. « C'est con comme la lune ». Haha, on explique aux gens les trouzemilles petits détails que même les services RH galèrent à comprendre et à appliquer (genre l'intégration de la PFI) ? :-

J'avais bien noté que je peux faire chier mon chef avec ce genre d'astuce, oui. Mais 0) ça me fait chier aussi ; 1) c'est pas tellement lui que je vise, mais plutôt le système d'entretien bidon en lui-même (mais d'un autre côté, il fait le choix, tout en étant fonctionnaire, de les pratiquer, même si la qualité de son rendu semble laisser à désirer du point de vue du service RH) ; 2) mon credo est justement d'affirmer que moins de temps passé en entretien pro (et autres futilités), c'est plus de temps consacré à des choses utiles pour nos usagers. Faire durer l'entretien va à l'encontre de ça.

Les syndicats qui s'accrochent à l'entretien individuel, c'est peut-être lié au fait que l'entretien pro est arrivé dans le privé (puis dans le public) via un Accord National Interprofessionnel, c'est-à-dire une causerie entre syndicats de patrons et de salariés. Tout ça pour un droit à la formation continue (y'a beaucoup à redire sur cette notion : qualité des formations, les magouilles derrière tant côté formateurs que syndicats, la notion même de former des gens afin qu'ils survivent aux fermetures de leurs usines plutôt que de botter le cul des patrons véreux, etc.).

Bah, j'aime bien trancher les choses. J'aimerai beaucoup qu'un tribunal tranche le point que je soulève. On le remplit déjà "pour moi" (pas vraiment pour moi, car même si j'y assistais, la procédure veut que ça soit le chef qui remplisse) et je signe sans relire.

Contester un entretien pro devant un tribunal c'est compliqué. Pognon et temps de dingue pour un résultat environ nul. Car les petites phrases seront interprétées dans un sens comme dans l'autre (jusque-là, c'est l'un des buts d'une justice impartiale) pour leur faire dire ce qu'on veut bien leur faire dire, et surtout dans le sens de la doxa (c'est là que je remets en question l'impartialité de la justice au motif qu'elle baigne dans son époque, dans les pensées de son époque). Vu mon langage et d'autres paramètres, c'est juste mort.
Et puis ton chef écrit ce qu'il a envie d'écrire. Oui, tu peux écrire des réserves (qui ne donnent pas lieu à contestation du chef), mais « la raison du plus fort est toujours la meilleure » (big up Jean), et, dans notre monde, et dans ce contexte, le plus fort c'est le chef. On le paye pour qu'il fasse autorité. Donner raison à un sous-fifre, c'est aller contre ça, c'est destituer le chef, donc ça n'arrivera pas.
Et c'est tellement facile de virer un CDD : il suffit de ne pas renouveler son contrat… Va prouver que y'a un lien avec le refus répété d'entretien pro (ou autre sujet, hein)…
Pour parer d'éventuelles sanctions pour refus d'entretien pro (ou autre), je préfère miser sur le fait que je suis ingénieur en informatique, donc que je retrouverai un emploi sans problème (c'est déjà du vécu). Et surtout, le privé me payait 495 € net/mois de plus que le public, donc, vu la faible probabilité d'être titularisé un jour dans mon organisation actuelle, j'ai tout intérêt à repartir dans le privé après avoir acquis des années dans le public, années qui augmentent l'écart entre ma rémunération actuelle et la future.

Je suis un contractuel de la fonction publique d'État depuis plusieurs années. J'ai donc un CDD. Après le CDD initial, mon employeur m'a toujours proposé des CDD de deux ans. J'ai toujours refusé, préférant cumuler des CDD d'un an. Pourquoi ? Pour éviter une perte de rémunération.

En fonction de ta date d'embauche, tu vas te faire carotter une partie de ta rémunération. La grille des contractuels de la catégorie A prévoit une hausse de l'indice après 1 an d'ancienneté (+ 4 points), après 3 ans (+ 8 points), après 6 ans (+ 10 points), et tous les 3 ans au-delà de 6 ans (+ 14 points). Si les contrats de ton administration vont du 01/09 d'une année (N) au 31/08 de l'année suivante (N+1) et que t'arrives en novembre N, ton premier contrat ira de novembre N au 31/08/N+1 (c'est donc un CDD de dix mois, pas d'un an, conçu pour t'aligner sur le cycle normal). Si tu choisis de le prolonger avec un contrat d'un an, ce dernier ira du 01/09/N+1 au 31/08/N+2.

Tu auras un an d'ancienneté en novembre N+1, mais, comme t'auras signé ton nouveau contrat (pour 01/09/N+1-31/08/N+2) en juin/juillet N+1, tu auras ton augmentation à partir de septembre N+2 (en supposant que t'es re-signé en juin N+2). On te carottera donc de novembre N+1 à août N+2 (10 mois). Si tu choisis un contrat de 2 ans en juin N+1, on te carottera de novembre N+1 à août N+3 (22 mois) ! Le service RH ne va pas s'embêter à te faire un avenant en novembre N+1 pour 4 points, qu'est-ce que tu crois ! Sauf que 4 points, c'est 15 € net/mois en cette saison. La perte de rémunération s'élève donc à 150 € net sur un contrat d'un an et à 330 € net sur un contrat de deux ans. Je te laisse faire les calculs pour les autres étapes de l'ancienneté. Oui, ça pique bien plus, un de mes collègues a "testé pour nous" (comme on dit). Bien sûr, un rappel de rémunération est possible, mais il faut penser à le demander (bah non, c'pas automatique, qu'est-ce que tu crois !).

Bref, un contrat annuel force un nouvel examen de ton dossier par le service RH. Oui, ça lui fait du boulot en plus mais j'estime que ce n'est pas à moi de leur courir après pour réclamer un avenant ou un rappel de rémunération !

Au début, j'avais un deuxième argument, mais il est basé sur une erreur. Je pensais que, comme dans le privé, il n'était pas possible de démissionner d'un CDD. Ni de signer une rupture conventionnelle. N'étant pas sûr d'avoir trouvé l'emploi qui me conviendrait, je me voyais mal m'engager sur 2 ans après mon CDD initial. En vrai, on peut démissionner d'un CDD de la fonction publique (c'est hallucinant… le CDD privé est précaire, donc on empêche la démission et le licenciement classique, mais pas dans le CDD public, deux poids, deux mesures…), donc cet argument est caduc.

Mais il n'est pas déplaisant de faire le point tous les ans sur sa situation professionnelle, ses envies, tout ça. Ça donne une mesure du temps qui passe pendant que tu ne bouges pas.

Il y a quelque temps, je voulais savoir si l'entretien professionnel s'imposait à moi, contractuel de l'État (réponse : pas la première année, oui mais non les années suivantes). Comme quand j'étais dans le privé, je contacte l'inspection du travail. Les coordonnées se trouvent facilement sur le site web officiel.

Réponse de l'inspection du travail :

[…]
Le service Renseignements droit du travail de l’UD XX de la DIRECCTE XXXXXXXXXX n’est pas compétent pour renseigner le droit du travail dans les 3 fonctions publiques (Etat, territoriale, hospitalière), y compris pour les contractuels travaillant dans ces secteurs. Votre relation relève de statut particulier ; seul le service du personnel de votre structure et les représentants du personnel pourraient vous apporter des réponses.
[…]

Donc l'inspection du travail ne peut pas renseigner les agents de la fonction publique.

D'un côté, c'est compréhensible, car leur interprétation irait à l'encontre de celle d'une autre administration. Le public taperait sur le public, en quelque sorte. Pas cool. ÉDIT DU 30/01/2021 : d'un autre côté, la CADA et la CNIL pour ne citer qu'elles, sont des administrations qui sont amenées à rendre des avis non contraignant concernant une autre administration. FIN DE L'ÉDIT.

D'un autre côté, **contacter le « service du personnel de ma structure » quand je suis justement en désaccord avec lui ne me semble pas être pertinent.

Les représentants du personnel de ma structure, tous syndicats confondus, roupillent**. En 2018, je les ai interrogés sur l'extension de la vidéo-surveillance dans notre structure : aucune réponse. En 2020, je les ai interrogés sur l'heure d'information syndicale : aucune réponse.

Du coup, que reste-t-il à l'agent ? Les syndicats ont des permanences juridiques gratuites. De même, les mairies ont des permanences juridiques gratuites aussi nommées point d'accès au droit, maison de la justice et du droit, conseil départemental d'accès au droit, etc. Ces structures ont toutes le même problème : elles disposent de peu de spécialistes en droit administratif (hors droit administratif commun comme les permis de construire, ce genre de choses).

L'agent de la fonction publique doit-il rester ignorant ? Doit-il sortir son chéquier pour consulter un avocat ? Cela n'est-il pas dissuasif ?

Ne peut-on pas imaginer une structure, de droit privé, qui serait l'équivalent de l'inspection du taff dans le public ? Comment mettre cela en branle puisqu'il faut que ça soit un service public (accessible à tous, gratuit, etc.) sans dépendre de l'État (une délégation de service public reste… une délégation, au privé, d'un service public) ?

Mieux : peut-on imaginer une administration publique qui puisse tirer dans les pattes d'une autre ? Après tout, la CNIL émet des avis. La CADA aussi. La Cour des comptes également (mais ce n'est pas une autorité administrative comme les deux autres). L'inspection du taff émet des avis vis-à-vis du privé quand elle est interrogée par un employé.

Bref, que faire ?

J'ai déjà mentionné ici l'analyse de Gee selon laquelle la perte de sens induite par la transformations des noms de nos services publics en marques (exemples : TGV -> inOui, ErDF -> Enedis, France Télécom -> Orange, etc.) est problématique, car elle permet d'inhiber la critique (ce n'est plus un service public, monsieur, c'est une marque) par l'absence même de sens : inOui peut bien proposer une qualité de service inférieure à celle d'un train à grande vitesse pour le prix d'un train à grande vitesse, car inOui ne signifie pas train à grande vitesse ; Le déploiement de la fibre optique peut bien délaisser les campagnes, car Orange ne signifie pas service public universel, etc. Pour rappel, la perte du sens des mots et des concepts manipulés est l'un des outils clés du pouvoir autoritaire qui est au cœur de l'œuvre de fiction 1984.

J'ai aussi rapporté que la SNCF, quand elle se présente sous le nom de son agence de voyages (Oui.sncf) """"oublie"""" de mentionner des horaires sur les lignes TER pas rentables, alors que, quand elle se présente sous son nom connoté d'une mission de service public (TER sncf.com), elle mentionne lesdits horaires.

Aujourd'hui, j'ajoute les exemples suivants :

• En 2019, TCRA, les Transports en Commun dans la Région d'Avignon sont devenus Orizo. Qu'est-ce que ça veut dire ?! Horizon ? Chorizo ? On perd en information : TCRA, ça disait quoi (transports en commun) et où (autour d'Avignon) ;
  
  
• En 2018, LER PACA, les Lignes Expresses Régionales du PACA, ont fusionné avec les TER PACA pour devenir Zou !. Qu'est-ce que ça veut dire ? Depuis quand nous exprimons-nous exclusivement avec des onomatopées ?! Là encore, on perd en information : on ne sait plus ce que c'est, ni que c'est censé être express, ni que c'est régional ;
  
  
• En 2018-2019, UAPV, l'Université d'Avignon et des Pays du Vaucluse est devenue la marque Avignon Université. Qu'est-ce donc que ce mélange de mots français avec de la grammaire anglaise ?! Après ça, on a beau jeu de critiquer nos jeunes qui ne sauraient plus parler et écrire la France ! (sic) Les Pays du Vaucluse sont mis à l'écart, très classe. Là-encore, on perd en information alors que le nom initial décrivait précisément ce qu'est cette institution (une université) et où elle opérait (Vaucluse). Mais t'inquiète, c'est pour affirmer « l’ancrage territorial » (le Vaucluse hors Avignon appréciera) et « s’ouvrir à l’international » (quel intérêt ?). C'est un nom plus siiiiiimple. Désormais, cette université a un nom « conforme au standard des grandes universités internationales à l’image de « Stanford University » ou « Harvard University » » (les citoyens auraient peut-être préféré qu'elle propose une qualité d'enseignement et de recherche « à l'image de Harvard University ») ! Je vois plutôt des centaines de milliers d'euros gaspillés (création du nouveau logo, campagne de promotion, travail pour changer le logo sur tous les supports ‒ sites web, modèles de document, cartes de visite, etc. ‒ ).

Bref, ce renommage de nos services publics en des trucs sans queue ni tête m'exaspère au plus haut point.

Récemment, j'ai eu des problèmes de santé. Des gens plus ou moins proches de moi l'ont appris. Forcément, ça cause assez vite du coût des soins (ce qui est révélateur de la merde dans laquelle nous sommes : en quoi le coût des soins devrait être un sujet de causerie prioritaire ?!). Ces gens-là ont appris que je n'ai pas de mutuelle… alors que je suis un gauchiste qui vante la mutualisation des risques de la vie à tour de bras. Comment en suis-je arrivé là ? Faites ce que je dis, pas ce que je fais ? Coût de la cotisation ? Que nenni.

Je n'ai pas de mutuelle car ça me gonfle, ça me fatigue. Vraiment. Lourdement. Sincèrement. C'est compliqué au-delà de la complexité inhérente à tout système (genre la physique quantique, la philosophie, la biologie, etc., c'est complexe, mais c'est sans artifice pour compliquer artificiellement les choses).

Jusqu'à peu, je n'avais pas non plus d'assurance habitation. Pour la même raison. Puis je me suis rendu compte que le contrat proposé par mon assurance ne comportait pas tant que ça de clauses d'exclusion absurdes, donc, j'ai plié.

Je crois toujours à la mise en commun (de pognon ou d'autre chose). Je crois toujours à la mutualisation des risques (maladie, accident, vieillesse, chômage, etc.). Je crois toujours que c'est l'organisation optimale d'une société humaine, car cela conduit à une société plus fraternelle, plus égalitaire, donc moins violente et plus agréable pour tout le monde.

Mais les implémentations actuelles de ce concept me découragent.

Le régime étudiant. Le régime général. Les autres régimes. Les conditions de remboursement imbitables. Les trouzemilles bases. Les trouzemilles taux (général ‒ 60-70 % ‒, Alsace-Moselle ‒ 80-90 % ‒, ALD ‒ 100 % ‒, pour une consultation, pour des médocs, etc.). Les soins pris en charge ou non. Les modalités, la prise en charge et le remboursement qui diffèrent pour chaque soin. La franchise. Les diverses retenues. Etc. Ce monde est sérieux ?!

Vu que les gouvernants ont sabordé la Sécu depuis 25-30 ans (arrivée de la CSG donc le financement de la Sécu glisse progressivement des mains des employés et des patrons pour aller dans les mains des gouvernants, qui ont transformé la mutualisation en prestation sociale et qui ont décidé des conditions à la place des premiers concernés), il faut compléter ce premier tas de merde par un deuxième : les complémentaires santé privées. Youpi ! Assurances aux mains d'actionnaires ou mutuelles dirigées par leurs cotisants ? Que ce choix me passionne ! Des plaquettes commerciales imbitables, quelle chance ! Là encore, des conditions de remboursements fluctuantes, des modalités, des franchises, etc. En moyenne, 22 % d'une cotisation à une complémentaire ne sert pas aux remboursements des soins. Les taxes et l'inflation ne sont pas en cause. 8 % servent à la pub (faut bien payer Chevallier et Laspalès pour qu'ils te mettent dans la tête que « la Matmut elle assure »). Les patrons se rincent également, en tout cas chez Macif, Audiens et Matmut.

Putain, mais qu'est-ce que ça peut me foutre qu'un œil n'ait pas la même complexité qu'un tibia (exemples au hasard, sans vérification de la validité médicale de cette assertion), ce qui engendre des coûts différents et donc un remboursement plus ou moins conséquent ?! Je veux être pris en charge en intégralité, point ! Je ne veux pas avoir à me demander combien, comment, pourquoi ! Je ne veux pas comparer des contrats imbitables !

Voilà ce qui me convaincrait de signer : un truc S-I-M-P-L-E. Moi + toi mettre argent dans caisse. Moi ou toi taper dans caisse pour payer totalité soins quand moi ou toi avoir besoin. S-I-M-P-L-E. Si ça fait monter le prix de la cotisation, je m'en fous. Je préfère qu'un tel système soit géré par le public, mais ce n'est pas obligatoire (genre des assos ou assimilées à une échelle locale, ça pourrait avoir de la gueule, mais ça risque d'être moins efficace car moins de cotisants, c'est moins d'argent dans la caisse) tant que ça ne va pas sur les marchés financiers. Un tel système inciterait à la solidarité, car chacun y voit bien ce qu'il va gagner en participant à ce système. C'est immédiat et compréhensible, contrairement au système actuel. C'est en partie cela qui dissuade les citoyens.

Alors on va me débiter le mythe du gars qui va trois fois par semaine chez son médecin généraliste et qui plombera nécessairement le système décrit ci-dessus. Si jamais une telle personne existait dans les statistiques, je l'inciterai à continuer, je serai heureux de payer. Pour moi, la responsabilité incombe au médecin. Et, pragmatiquement, je préfère un gus soucieux de sa santé qui se fera dépister tôt une saloperie, quand le traitement sera aisé, plutôt que trop tard, quand le traitement sera compliqué et coûtera un « pognon de dingue ».

Bref, je conchie l'organisation actuelle de l'assurance maladie. Inutilement compliquée. Décourageante. Qui ne donne pas envie d'être solidaire.