2023/04/10 (maintenance ispng)

• Réunion précédente
• Pad de la réunion

Heure de début : 10h30

Présences :

• HgO
• Tharyrok
• Célo

Jitsi: https://conf.domainepublic.net/neutrinet

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

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é.

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

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

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/

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 : 2/07 à 14h

Lieu : À définir

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.