Table des matières
2023/04/10 (maintenance ispng)
Heure de début : 10h30
Présences :
- HgO
- Tharyrok
- Célo
Météo
Moment informel durant lequel on exprime en peu de mots comment on se sent et si on a une attente forte pour la réunion.
Ce n'est pas un moment de discussion mais d'expression individuelle et ce n'est pas obligatoire 
Attente(s) forte(s)
Si l'une ou l'autre personne exprime une attente forte, merci de vous en occuper en priorité ou de la noter dans le hub ou dans un point approprié.
Précédemment… dans une galaxie lointaine
Comment va-t-on procéder ? On avait fait pas mal de modifs… on peut peut-être repartir du snapshot que l'on avait fait.
Apparemment, on passe par Gandi pour les mails lors de la création d'un VPN. Cela ne marche pas avec le nouveau serveur.
À faire :
- Nouvelle CA
- Config keystore ispng
- Merge les 2 CA pour OpenVPN
- Config HAproxy · Certbot let's encrypt
- Bascule des IPs
- Scripts de nettoyage du VPN (après la bascule)
À tester :
- Connexion d'une brique avec nouveau compte VPN
- Connexion avec ancien compte VPN
- Renouvellement certificat
- HAProxy 2.x
- Serveur mail neutri.net
- Redémarrer la VM ispng pour voir le temps de latence
Débug de la nouvelle configuration
La nouvelle configuration testée n'a pas marché. A priori, c'est l'ancien certificat qui pose problème parce que dans les logs on voit :
ERIFY ERROR: depth=1, error=self signed certificate in certificate chain: C=BE, ST=Brussels Capital Region, L=Brussels, O=Neutrinet, OU=VPN, CN=vpn.neutrinet.be, name=VPN, emailAddress=contact@neutrinet.be
En fait, les briques ont besoin de connaître à la fois l'ancien et le nouveau CA du serveur VPN. C'est le fichier /etc/openvpn/keys/ca-server.crt sur les briques. Ce fichier est poussé par le serveur VPN à chaque fois qu'on crée un compte ou qu'on renouvelle un certificat. Il faut donc placer les deux CA dans le fichier /opt/ispng/dist/ca.crt sur le serveur VPN.
On rajoute l'ancien CA avec:
- snippet.bash
cat /path/to/old-ca.crt >> /opt/ispng/dist/ca.crt
On va faire nos tests sur une brique de… test:
ssh 172.16.3.55 -l admin
Mot de passe : neutrinet
On voit que la brique arrive à monter son VPN avec un ancien compte dont le certificat a été renouvellé.
On doit encore tester un nouveau compte VPN qui a été créé avant-hier sur le nouveau serveur, et voir si la brique peut se connecter.
Mais pour le moment, la brique n'a pas accès à internet… Actuellement, la route par défaut utilisée par la brique est un /128 et ça n'est pas ce qu'il faut. Pourtant la config semble bonne.
Le mssfix doit aussi être corrigé (il est à 1420 pour le moment). → On l'a corrié en mettant 1400 partout où ça apparait dans la config (redémarrage d'openVPN après)
Dans la config du client VPN de Yunohost, la manière dont on récupère l'IP du serveur VPN pose problème. On va indiquer l'ip a la place du domaine comme on avait déjà fait sur certaines briques problématiques. On le fait avec :
- snippet.bash
yunohost app setting vpnclient server_name -v 80.67.181.132
Ensuite, on coupe le client VPN:
- snippet.bash
systemctl stop openvpn@client.service
Et on le relance:
- snippet.bash
systemctl start ynh-vpnclient-checker
Mais ça ne fonctionne pas comme il faudrait. On arrive à monter le VPN mais le traffic passe tout de même par l'interface locale de la brique. La brique est néanmoins accessible par le VPN. Bref, c'est un peu différent de tout à l'heure, où on arrivait pas du tout à accéder à internet depuis la brique.
Il est probable que certains paramètres dans /etc/openvpn/public-1195-udp.conf ne sont plus compatibles.
Actuellement, on a :
down /etc/openvpn/interface-down.sh | management 127.0.0.1 9524 | management-client-auth | ca /etc/openvpn/keys/ca.crt | cert /etc/openvpn/keys/server.crt | key /etc/openvpn/keys/server.key # This file should be kept secret | dh /etc/openvpn/keys/dh4096.pem | learn-address /etc/openvpn/learn-ip.sh | push "redirect-gateway def1 bypass-dhcp" | push "route-ipv6 0::/0" keepalive 10 120 comp-lzo persist-key persist-tun log-append /var/log/openvpn/public-1195-udp.log status /var/log/openvpn/status-1195-udp.log verb 4 mute 20
C'est probablement les push qui ne sont plus corrects.
On a commenté push "route-ipv6 0::/0"
On essaie de redémarrer le service openVPN
Sur la brique, le VPN s'est reconnecté. C'est toujours la même chose en IPv4. En IPv6, ça semble passer, mais il ne ping pas…
Donc on est dans une situation où le VPN se monte, mais on n'a pas de trafic dedans. C'est un peu embêtant.
En IPv4, on a :
root@cube:~# ip r s | default via 172.16.3.254 dev eth0 default via 172.16.3.254 dev eth0 proto dhcp metric 100 80.67.181.128/25 dev tun0 proto kernel scope link src 80.67.181.183 172.16.0.0/22 dev eth0 proto kernel scope link src 172.16.3.55 172.16.0.0/22 dev eth0 proto kernel scope link src 172.16.3.56 metric 100
En IPv6 :
root@cube:~# ip -6 r s ::1 dev lo proto kernel metric 256 pref medium 2001:913:1fff:ffff::/64 dev tun0 proto kernel metric 256 pref medium 2a0e:e701:118b:10::84eb dev eth0 proto kernel metric 100 pref medium 2a0e:e701:118b:10::/64 dev eth0 proto ra metric 100 pref medium 2a0e:e701:118b:10::/64 dev eth0 proto kernel metric 256 expires 84833sec pref medium 2000::/3 dev tun0 metric 1024 pref medium fe80::42:acab dev eth0 proto kernel metric 256 pref medium fe80::/64 dev eth0 proto kernel metric 256 pref medium fe80::/64 dev tun0 proto kernel metric 256 pref medium default via fe80::2e0:67ff:fe1f:f238 dev eth0 proto ra metric 100 pref medium default via fe80::2e0:67ff:fe1f:f238 dev eth0 proto ra metric 1024 expires 233sec hoplimit 64 pref medium
La partie BGP fonctionne, c'est déjà ça.
On le voit si on affiche toutes les routes dans bird, avec le filtre de ce qui est envoyé aux edges. Pour entrer dans le terminal de bird, on fait birdc ou birdc -r pour être en lecture seule :
bird> show route filter internal_direct_connect_edge_01_export_v4
Table master4: |
10.0.20.0/24 unicast [direct1 2023-03-02] (240)
dev ens19
80.67.181.48/28 unicast [internal_bra_01_v4 2023-03-12] * (100) [i]
via 10.0.20.85 on ens19
unicast [internal_bra_02_v4 2023-03-22] (100) [i]
via 10.0.20.86 on ens19
80.67.181.132/32 unicast [direct1 2023-03-02] (240)
dev lo
80.67.181.183/32 unicast [kernel_v4 10:04:43.338] (10)
dev tun9524
Table master6:
2001:913:1000:20::/64 unicast [direct1 2023-03-02] (240)
dev ens19
2001:913:1fff:ffff::b:d1dd/128 unicast [kernel_v6 10:00:12.757] (10)
dev tun9524
2001:913:1e01:50::/60 unicast [internal_core_03_v6 2023-03-12] * (100) [i]
via 2001:913:1000:20::73 on ens19
unicast [internal_core_04_v6 2023-03-12] (100) [i]
via 2001:913:1000:20::74 on ens19
Ici, on voit que 80.67.181.183/32 est bien envoyée sur dev tun9524.
Du côté du routage est ok aussi sur la machine VPN.
Le problème se situe entre la brique et le serveur VPN. On voit avec un traceroute sur la brique qu'on atteint même pas le premier saut.
traceroute -I -6 ffdn.org traceroute to ffdn.org (2a0c:e300::13), 30 hops max, 80 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 *^C
On a trouvé une liste de changement OpenVPN qui est plus ou moins lisible : https://github.com/OpenVPN/openvpn/blob/master/Changes.rst#overview-of-changes-in-24
Une fois le VPN monté, on remarque qu'on arrive plus à se connecter au serveur VPN :
traceroute to 80.67.181.132 (80.67.181.132), 30 hops max, 60 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 *^C
Dans Yunohost, il y a une config pour le client VPN de base, et on ne peut pas tout modifier comme on veut:
# [WARN] Edit this raw configuration ONLY IF YOU KNOW # what you do! # [WARN] Continue to use the placeholders and # keep update their value on the web admin (they # are not only used for this file). remote __SERVER_NAME__ proto __SERVER_PROTO__ port __SERVER_PORT__ pull nobind dev tun tun-ipv6 keepalive 10 30 comp-lzo adaptive resolv-retry infinite # Authentication by login __LOGIN_COMMENT__auth-user-pass /etc/openvpn/keys/credentials # UDP only __UDP_COMMENT__explicit-exit-notify # TLS tls-client __TA_COMMENT__tls-auth /etc/openvpn/keys/user_ta.key 1 remote-cert-tls server ns-cert-type server ca /etc/openvpn/keys/ca-server.crt __CERT_COMMENT__cert /etc/openvpn/keys/user.crt __CERT_COMMENT__key /etc/openvpn/keys/user.key # Logs verb 3 mute 5 status /var/log/openvpn-client.status log-append /var/log/openvpn-client.log # Routing route-ipv6 2000::/3 redirect-gateway def1 bypass-dhcp
On peut juste modifier les variables en majuscule et rajouter des options tout à la fin, en fonction de ce qu'on indique dans le fichier .cube
On retire topology subnet dans /etc/openvpn/client.conf et dans /etc/openvpn/client.conf.tpl
On le retire parce qu'on est pas dans ce mode-là. C'est un mode d'openVPN, normalement c'est le serveur qui devrait le pousser.
Ce qui se passe, c'est qu'on a une route, vers le serveur VPN, qui devrait passer par eth0.
Il s'agit de ceci dans les logs :
023-04-10 10:29:00 us=321770 UDP READ [65] from [AF_INET]80.67.181.132:1195: P_DATA_V2 k id=0 DATA len=64
Ca devrait venir au début dans les défauts :
root@cube:~# ip r s default via 172.16.3.254 dev eth0 default via 172.16.3.254 dev eth0 proto dhcp metric 100 80.67.181.128/25 dev tun0 proto kernel scope link src 80.67.181.183 172.16.0.0/22 dev eth0 proto kernel scope link src 172.16.3.55 172.16.0.0/22 dev eth0 proto kernel scope link src 172.16.3.56 metric 100
Là, du coup, on a une boucle de routage détectée. Dans l'ancienne version d'OpenVPN, cela ne posait pas de problème car c'était écrasé d'une autre façon.
Dans /etc/openvpn/client.conf.tpl, on ne peut modifier que ce qui est ajouté avec le .cube. Les autres parties sont gérées automatiquement par l'app Neutrinet.
Pause MIAM \o/
Pendant la pause miam, on s'est dit qu'une bonne méthode était de tester le VPN sur une machine sans Yunohost, juste avec la config de base d'OpenVPN. Ca va nous permettre d'identifier si la surcouche Yunohost a un impact. Ce n'est pas qu'on n'aime pas Yunohost, c'est juste qu'il fait beaucoup de trucs !
On crée donc une petite VM sur Jimmy, le proxmox du Caldarium. Mais on a le même genre d'erreurs. C'est un peu comme si ISPng ne parvenait pas à envoyer certaines choses qu'il doit envoyer. On a notamment un message d'erreur comme quoi le client ne reçoit pas de redirect-gateway, pourtant, c'est bien dans la config…
Dans /etc/openvpn/learn-ip.sh, on va changer les loggers en echo pour voir ce quiu se passe.
On redémare openVPN et ISPng.
C'est peut-être le script-security qui a changé.
On identifie ce blog dans les logs sur le serveur VPN :
Mon Apr 10 13:04:03 2023 us=317247 raoulzecat@batato.be/80.67.181.49:43831 Options error: Unrecognized option or missing or extra parameter(s) in [CONFIG-STRING]:1: push (2.4.7) Mon Apr 10 13:04:03 2023 us=317306 raoulzecat@batato.be/80.67.181.49:43831 Options error: Unrecognized option or missing or extra parameter(s) in [CONFIG-STRING]:1: push (2.4.7) Mon Apr 10 13:04:03 2023 us=317343 raoulzecat@batato.be/80.67.181.49:43831 Options error: Unrecognized option or missing or extra parameter(s) in [CONFIG-STRING]:1: push (2.4.7) Mon Apr 10 13:04:03 2023 us=317386 raoulzecat@batato.be/80.67.181.49:43831 Options error: Unrecognized option or missing or extra parameter(s) in [CONFIG-STRING]:1: push (2.4.7) Mon Apr 10 13:04:03 2023 us=317447 raoulzecat@batato.be/80.67.181.49:43831 Options error: Unrecognized option or missing or extra parameter(s) in [CONFIG-STRING]:1: push (2.4.7) Mon Apr 10 13:04:03 2023 us=317492 raoulzecat@batato.be/80.67.181.49:43831 Options error: Unrecognized option or missing or extra parameter(s) in [CONFIG-STRING]:1: push (2.4.7) Mon Apr 10 13:04:03 2023 us=317546 raoulzecat@batato.be/80.67.181.49:43831 Options error: option 'setenv-safe' cannot be used in this context ([CONFIG-STRING]) Mon Apr 10 13:04:03 2023 us=317628 raoulzecat@batato.be/80.67.181.49:43831 Options error: Unrecognized option or missing or extra parameter(s) in [CONFIG-STRING]:1: push (2.4.7) Mon Apr 10 13:04:03 2023 us=317704 raoulzecat@batato.be/80.67.181.49:43831 Options error: Unrecognized option or missing or extra parameter(s) in [CONFIG-STRING]:1: push (2.4.7)
OpenVPN a une interface de management. Dans notre cas, on en a une. C'est le port 9524 pour le port 1195, 9424 pour le port 1194 (enfin Tharyrok croit qu'il a fait une convention à l'époque)
Dans la configuration de OpenVPN, on retrouve bien la ligne de management. Ceci permet a un programme externe de piloter la liaison de configuration du VPN. Quand un client se connecte, il établi donc 2 tunnels, un tunnel de liaison configuration, et un tunnel de data.
C'est ISPng qui va se connecter à la liaison de configuration pour pousser les bonnes configs.
Dans la version 2.4, ils demandent de mettre le paramètre set-env safe. Mais ISPng n'y arrive pas, il n'arrive donc pas à envoyer les configs au serveur, qui devrait les transmettre au client.
On trouve la sortie des logs de ISPng dans systemctl status.
systemctl status ispng.service -n5000
On voit les push et on constate que l'adresse 80.67.181.129 est poussée comme gateway… mais d'où ça vient ? 
Apr 10 13:34:11 ispng java[15535]: push route 80.67.181.129 255.255.255.255 net_gateway Apr 10 13:34:11 ispng java[15535]: push redirect-gateway def1 Apr 10 13:34:11 ispng java[15535]: push route-gateway 80.67.181.132 Apr 10 13:34:11 ispng java[15535]: push tun-ipv6 Apr 10 13:34:11 ispng java[15535]: ifconfig-ipv6-push 2001:913:1fff:ffff::b:d1dd/64 2001: Apr 10 13:34:11 ispng java[15535]: push route-ipv6 2000::/3 Apr 10 13:34:11 ispng java[15535]: push route-ipv6 2001:913:1f00::/40 2001:913:1fff:ff00: Apr 10 13:34:11 ispng java[15535]: iroute-ipv6 2001:913:1fff:fd15::/64 Apr 10 13:34:11 ispng java[15535]: setenv-safe DELEGATED_IPv6_PREFIX 2001:913:1fff:fd15:: Apr 10 13:34:11 ispng java[15535]: push ping 10 Apr 10 13:34:11 ispng java[15535]: push ping-restart 60 Apr 10 13:34:11 ispng java[15535]: END
On regarde comment la machine résoud vpn.neutrinet.be avec hosts vpn.neutrinet.be (pour cela il faut installer bind9-hosts), et elle résoud en effet vers l'IP 80.67.181.129…
Chez Gandi, on va créer un sous-domaine temporaire pour le VPN : the-best-vpn-ever.neutrinet.be (on a décidé d'être modeste et humble, comme les gens sur le forum d'OpenVPN).
On configure la zone DNS pour ce domaine, ainsi que le fichier /etc/hosts d'ISPng.
On modifie le nom de domaine dans la conf d'ISPng et tant qu'à faire dans la config d'OpenVPN où on avait mis l'IP (comme on a un joli nom de domaine, autant l'utiliser !)
On a toujours des erreurs de boucle de routage, mais là, les options qui sont envoyées vers le client sont correcte. Mais le problème persiste, on a toujours une mauvaise gateway 
On va commenter les push dans la configuration du serveur et dans le client (même dans la partie non-éditable de Yunohost, c'est pour tester). On le fait parce qu'on voit que dans ce qui est pusher, on a un push reset qui reset tous les push qui ont eu lieu.
Mais là aussi, on a encore le recursing routing.
La question, dans ces différentes options, qu'est-ce qui n'est plus compatible avec la nouvelle version d'OpenVPN ?
Apr 10 14:01:10 ispng java[16464]: client-auth 0 0 Apr 10 14:01:10 ispng java[16464]: push-reset Apr 10 14:01:10 ispng java[16464]: ifconfig-push 80.67.181.183 255.255.255.128 Apr 10 14:01:10 ispng java[16464]: push route 80.67.181.128 255.255.255.128 80.67.181.132 Apr 10 14:01:10 ispng java[16464]: push route 80.67.181.132 255.255.255.255 net_gateway Apr 10 14:01:10 ispng java[16464]: push redirect-gateway def1 Apr 10 14:01:10 ispng java[16464]: push route-gateway 80.67.181.132 Apr 10 14:01:10 ispng java[16464]: push tun-ipv6 Apr 10 14:01:10 ispng java[16464]: ifconfig-ipv6-push 2001:913:1fff:ffff::b:d1dd/64 2001: Apr 10 14:01:10 ispng java[16464]: push route-ipv6 2000::/3 Apr 10 14:01:10 ispng java[16464]: push route-ipv6 2001:913:1f00::/40 2001:913:1fff:ff00: Apr 10 14:01:10 ispng java[16464]: iroute-ipv6 2001:913:1fff:fd15::/64 Apr 10 14:01:10 ispng java[16464]: setenv-safe DELEGATED_IPv6_PREFIX 2001:913:1fff:fd15:: Apr 10 14:01:10 ispng java[16464]: push ping 10 Apr 10 14:01:10 ispng java[16464]: push ping-restart 60
Sur le serveur VPN actuel, on voit qu'il râle uniquement sur setenv-safe, donc ce n'est pas lui le coupable.
Tous les push passent sur le serveur VPN actuel… Donc le problème doit venir de là.
On va essayer avec une option plus ancienne d'OpenVPN. On va installer la 2.3. Sauf qu'il manque des librairies pour compiler.
Alors, à ce stade on pourrait mettre OpenVPN dans docker, mais on va pas le faire parce que Tharyrok est en PLS rien qu'à l'idée.
TODO: Voir comment builder OpenVPN 2.3.4 sur une buster ou bullseye
Plan B - Installation du certificat sur l'ancien serveur
Comme il est déjà plus de 16h30, on va s'arrêter ici et faire notre plan B : installer le nouveau certificat sur l'ancienne VM, sans faire la migration. Ca permettra aux briques d'avoir le nouveau certificat lors du renouvellement. Et on pourra continuer à tester ultérieurement la migration.
Sur la clé USB, on suit les indications du README.md qu'on avait rédigé la fois dernière en pour lire le contenu.
Pour rappel, on avait différents CA :
- root-x1 : le root CA de Neutrinet Corp
- vpn-r1 : le sous-CA pour le serveur VPN
Sauf que ISPng n'aime pas les sous-CA… On va devoir remplacer le vpn-r1 par quelque-chose comme vpn-x1, qui sera donc un autre root CA (d'où le suffixe x1). Lors du renouvellement, on le nommera vpn-x2, etc.
On copie root-x1/vars vers vpn-x1/vars, et on va modifier les variables pour avoir du RSA partout.
On génère le certificat.
On fait un snapshot de la machine VPN avant de faire des modifications dessus.
Dans OpenVPN, on renomme le certificat ca.crt actuel en ca-old.crt (on fait un backup de ce CA car il contient aussi un historique d'autres CA, on ne souhaite pas les garder dans la config mais juste en backup.).
On copie la config depuis /opt/ispng/ca.crt dans /etc/openvpn/keys/ca.crt pour avoir le ca actuellement utilisé par ISPng. Puis on ajoute à ce fichier le nouveau CA (il contient donc les 2 certificat):
cat /path/to/new/ca.crt >> /etc/openvpn/keys/ca.crt
Dans ISPng, on copie ce fichier ca.crt pour écraser /opt/ispng/ca.crt.
En gros /etc/openvpn/keys/ca.crt doit contenir les 2 CA (l'ancienne et la nouvelle) pour savoir faire confiance à l'ancien certificat et au nouveau certificat futur.
/opt/ispng/ca.crt doit contenir les 2 ca car c'est ce qui est envoyé au client et comme pour l'instant le serveur a un certifcat généré avec l'ancienne ca mais on compte renouvelement le certificat du serveur dans un an avec la nouvelle ca.
On copie la clé privée du CA dans un dossier temporaire. On va créer un nouveau keystore java qui contiendra uniquement le nouveau CA.
On doit d'abord générer un fichier P12:
openssl pkcs12 -export -inkey new-ca.key -in new-ca.crt -out /tmp/tmp.OMacaRubju/ca.p12 -name "ca"
Ensuite, on peut transformer ce P12 en keystore java:
keytool -importkeystore -srckeystore ca.p12 -srcstoretype pkcs12 -destkeystore ca.jks -deststoretype jks
Et on copie ce ca.jks dans /opt/ispng/ca/ca.jks
Mais dans ce dossier ca, on a en fait aussi le keystore pour api.neutrinet.be.
Depuis un des HAProxy, on prend de letsencrypt, la fullchain et la private key pour le domaine *.neutrinet.be.
root@haproxy-02:~# cp /etc/letsencrypt/live/neutrinet-be/fullchain.pem /tmp/ root@haproxy-02:~# cp /etc/letsencrypt/live/neutrinet-be/privkey.pem /tmp/ root@haproxy-02:~# chown hgo: /tmp/fullchain.pem root@haproxy-02:~# chown hgo: /tmp/privkey.pem
Ensuite, on génère le keystore avec ce certificat:
openssl pkcs12 -export -in fullchain.pem -inkey privkey.pem -name neutrinet.be -out neutrinet.p12 keytool -importkeystore -deststorepass PasswordUltraSecure -destkeystore neutrinet.keystore -srckeystore neutrinet.p12 -srcstoretype PKCS12 -deststoretype JKS
Et on le place dans /opt/ispng/neutrinet.keystore
À tester : on pourrait voir pour utiliser un ancien keystore.
Maintenant, on casse tout \o/
On redémarre les différents services d'openVPN.
On regarde ce qui se passe avec supervisorctl tail -f ispng. A une époque, c'était une manière plus simple de gérer les processessus
On voit que les clients commencent à faire des push request, ça veut dire qu'a priori, le double CA fonctionne.
On en a profité pour mettre java11 sur l'ancien serveur… et ça marche ! Du coup ça met beaucoup moins de temps à redémarrer \o/
La suite ?
On va devoir faire une réunion pour se débarrasser d'ISPng et le jeter dans le canal.
Tharyrok avait déjà fait pas mal de boulot là-dessus, il reste encore de grosses questions à résoudre, avec des questions pour le hub-admin. Mais on n'est pas obligé d'attendre le hub-admin pour faire la réunion, car il y aura également des trucs techniques. Par exemple, possibilité de proposer un serveur Wireguard en plus du serveur OpenVPN… Pour Wireguard, il n'y a pas de notion d'expiration du certificat, donc c'est Ketupa (le nouveau futur ISPng) qui devra gérer si oui ou non garde la configuration de ce membre (un client = un certificat). Et donc il faut des critères pour dire au bout de combien de temps une IP peut être libérée délivrée.
Prochaine réunion
Prochaine réunion : 2/07 à 14h
Lieu : À définir
Météo de fin
Moment informel durant lequel on exprime en peu de mots comment, à titre personnel, la réunion a été vécue que ce soit positif ou négatif. Si une ou plusieurs tensions est née durant la réunion, il est peut-être nécessaire d'envisager l'une ou l'autre réunion pour y remédier.