• Pad de la réunion

Heure de début : 14h

Présences :

• HgO
• Célo
• Tharyrok

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

Il a servi Neutrinet et ce fut sa joie.

Un binaire sans les sources.

Un serveur VPN basé sur OpenVPN, avec logiciel de gestion d'utilisateurs et de clients qui fait le café, écrit en Java 8 (compatible Java 11) et Angular pour la partie frontend. L'inscription ce fait sur une webapp (https://api.neutrinet.be) et la gestion sur l'inteface de gestion (https://user.neutrinet.be).

Le VPN fournit des IP fixe aux briques et autres parpaings.

Ce fabuleux (micro)soft qu'est ISPng parle via l'horrible interface de management de openvpn pour l'attribution des ip et routing. Cette interface de gestion c'est un socket binaire.

On sait attribuer de block ipv6 en plus par client. L'interface de gestion permet de renouveler son certifcat soit par la webinterface soit par api.

Les reverse ip sont géré manuellement.

On a un script de rappel de renouvellement et un script qui libère les IPs dont le certificat a expiré depuis au moins 3 mois (en se basant sur des requêtes dans la DB).

On a une app YunoHost pour géré le renouvellemnt du certificats (en utilisant l'api).

Nettoyage des clients + rappels: https://gitlab.domainepublic.net/Neutrinet/vpn/cleaning_old_certificate Gestion actuelle du VPN (pas representatif de ce qui tourne en production): https://gitlab.domainepublic.net/Neutrinet/vpn/ISP-ng App Neutrinet pour Yunohost: https://gitlab.domainepublic.net/Neutrinet/neutrinet_ynh Script qui produit le .cube pour l'installation des briques : https://gitlab.domainepublic.net/Neutrinet/scripts/-/blob/master/cubefile/faire_un_point_cube.sh Gestion des reverse DNS: https://gitlab.domainepublic.net/Neutrinet/scripts/-/blob/master/dns/dyn-reverse-dns.sh

Actuellement, nous sommes bloqués avec OpenVPN v2.3.x. Par contre, on a trouvé un hack pour installer OpenVPN 2.3.x sur bookworm.

Mais côté client, il faut accepter de vieux algorithmes pour faire fonctionner le VPN… et la version de Yunohost pour bookworm est en préparation…

Utilisation de l'interface de management de OpenVPN. Celle-ci a changé et fait qu'on est bloqué sur une ancienne version. C'est aussi problématique dans la manière dont ISPng communique avec OpenVPN pour pousser les routes. Il est difficile de faire une migration car actuellemnt on utilise peu les outils haut niveau fournis par OpenVPN.

Nous n'avons pas toutes les sources de ISPng. Beaucoup de code non utilisé ou manquant: - gestion des factures - reverse ip - vérification du mail - reset du mot de passe

Mauvaise gestion des ressource IP.

Les frontends sont bugués (autant l'inscription que la gestion du compte).

Gestion des certificats (pas de date limite): quelqu'un peut faire un certificat qui expire après le CA. On se retrouve avec une IP qui n'est plus utilisée mais avec un certificat qui expire dans 9 ans par exemple…

Nous ne respectons les besoins legaux càd que nous n'avons de verification de l'identiter du membre utilisant le service VPN.

Avoir un VPN qui permet de s'autohéberger (IP fixe, stable, IPv6) et d'héberger du mail (blocs IPv6 /64 séparés)

Pouvoir configurer le reverse DNS

Avoir autre chose que OpenVPN (pas le même public que les briques internet)

Que user.neutrinet.be fonctionne mieux. Et notamment certaines fonctionnalités : par ex. reset du mot de passe

Pouvoir changer son adresse mail

Pouvoir générer le .cube. Pour le moment, c'est un script bash et c'est pas évident pour tout le monde de pouvoir générer le .cube quand on s'y connaît pas.

Avoir les differantes lien de documentation dans l'inteface de gestion.

Besoin d'avoir un outil qu'on peut faire évoluer dans le temps

Par rapport à la facilité d'obtenir un .cube, ça pose aussi la question de : est-ce qu'on veut que les gens viennent en install party ou puisse faire ça en dehors, sans venir nous rencontrer ?

• Il y a une volonté que ce soit pas un service sans gestion humaine, mais aussi une volonté de permettre à nos membres d'être autonome.
• Oui et non. Il y a les timides de nature qui n'osent pas venir en install party et qui veulent essayer de le faire tout seul.
• Par rapport au nombre d'IP, on a envie que les IPs soient utilisées avec parcimonie.
• Si on regarde un peu comment les autres membres de la FFDN fonctionnent, la plupart du temps c'est par un mail envoyé ou lors d'une rencontre physique.

Pour couper la poire en deux, ne serait-ce pas pertinent que tout le monde puisse prendre un VPN en Ipv6, mais que l'IPv4 soit quelque chose qu'on débloque nous à la demande. Question, est-ce qu'un mail suffit ? Doit on rencontrer la personne ? Est-ce qu'on envisagerait un système de cooptation, où tout membre pourrait inviter ses ami·es à avoir une IPv4 ?

Mais selon la charte de la FFDN, on doit fournir un aspect IPv4 et IPv6… mais possible que ça évolue ? Après relecture de la charte, on ne parle que d'adresse publique, peu importe le protocole. Par contre, on ne peut pas faire de CGNAT !!!

En fait, ça rejoint aussi la question des statuts. Dans les futurs statuts, on s'oriente vers une situation où le VPN est soumis à l'adhésion (donc paiement d'une cotisation) de Neutrinet asbl.

Cela permettrait aussi de respecter la vérification d'identité plus facilement. Pour rappel, pour valider une identité il faut au choix:

• Ack SMS
• Ack Courrier papier
• Pièce d'identité (on veux pas faire)

Pourquoi ça marche ? Parce qu'on stocke le moment où on a reçu l'information, et en cas de requête judiciaire, le juge va regarder qui avait le numéro de tél à l'époque ou qui habitait là à l'époque.

En tout cas, avoir un VPN en mode self-service n'est pas faisable en l'état. Et du côté hub admin, on se dirige vers des services fournis à nos membres uniquement plus ou moins en ordre de cotisation. Sachant qu'un membre pourrait être dispensé de cotisation (le CA aura cette possibilité).

Donc au final, la question de la rareté des IPv4 se pose moins.

Une autre question : quelles sont nos attentes pour l'utilisation d'un VPN. Actuellement, sur le site, on restreint en quelque sorte le VPN à YunoHost avec un formulaire qui propose les deux. Est-ce qu'il y a une volonté d'avoir un VPN pour de l'auto-hébergement ? Un VPN pour autre chose ?

Il y a plusieurs cas d'usages:

• Les premiers membres de Neutrinet avec juste OpenVPN
• Une Olimex avec un Yunohost + app vpnclient et neutrinet
• Un parpaing (= serveur de récup) avec un Yunohost + app vpnclient et neutrinet
• Un serveur en mode YOLO sans Yunohost mais un client OpenVPN (pas officiellement supporté par Neutrinet)

Du côté Neutrinet, on fournit un support actif pour un client VPN avec YunoHost. Pour les autres, on ne fait pas de support. La question, est-ce qu'on veut faciliter cet usage-là ? Avoir une config VPN complète, en donnant plus d'info, etc…

On permet aux gens d'utiliser le VPN sans passer par YunoHost, avec une config OpenVPN qui fonctionne, une doc qui permet de gérer son client, renouveler ses certificats, etc.

Par contre, on ne veut pas faire un VPN anonymisant, et ça doit être clair.

Par exemple, on pourrait imaginer que si on a un .cube, on n'a pas de warning au téléchargement. Mais si la personne télécharge la config openVPN… alors on aurait un warning à ce sujet.

Avoir une bonne communication sur le nombre d'IPs qui restent, même si ce n'est pas un problème spécifique au VPN mais plus générique à l'usage de l'IPv4.

Utiliser des algorithmes de chiffrement récents (CHACHA20 qui permet d'améliorer les performances)

Génération des certificats pour 90 jours. Un peu comme Let's Encrypt. Pas une année comme maintenant. Au niveau des personnes qui paient après un 1 an, ce paiement serait géré par l'adhésion.

Libération de l'IP 90 jours après expiration. Sachant que c'est facile techniquement de donner une nouvelle IP après la libération de l'ancienne. C'est juste une question de configuration DNS.

Côté hub-infra, sur demande on pourrait prolonger la date de libération de l'IP, mais ça doit rester l'exception.

Pour la question du rappel de “combien coûte le VPN” et “vous avez un VPN actif”, ce ne serait pas spécifique au VPN, mais commun aux différents services de Neutrinet (compris dans l'adhésion). Donc au renouvellement annuele d'être adhérent.

Monitoring de la dernière utilisation du VPN et libéré l'IP au bout de 90 jours d'inactivité. Avec OpenVPN, c'est facile, grace au certificat, mais certains VPN n'ont pas cette mécanique.

Si l'ip n'est plus connectée depuis 8 semaines on envoie un mail, on garde l'ip encore 12 semaines, ensuite on libère.

Dans le cas de OpenVPN si le certificat va expirer dans 4 semaines on envoie un mail.

Dans l'interface de Ketupa, on pourrait générer un certificat directement. La clé privée serait stockée dans le navigateur. On pourrait alors générer le .ovpn, le .cube, en expliquant aux gens que les infos seront perdues lorsque le navigateur sera fermé (sauf si on a récupéré la clé privée).

On pourrait au moment de quitter avec une info proposant de télécharger sa clé privée. On pourrait avoir un mode full automatique, qui génère la clé privée à chaque fois que l'utilisateur le demande. Donc, l'app web va générer la clé privée.

Question, pour le .cube, il faut le user et le mot de passe de user.neutrinet.be. En fait, dans ce cas, on générerait un mot de passe random pour le VPN, mais qui serait distinct de l'accès à l'interface web. Ce qui permettrait aussi aisément pour la personne de changer son email.

On fait alors une identification soit via certificat. Soit via login / password.

Aujourd'hui, le renouvellement du certificat se fait via un login / mot de passe. Si on enlève le login / mot de passe, comment fait-on pour s'identifier à l'API du VPN ?

Donc, on conserverait un uuid / token, qui remplacerait le login / mot de passe, pour pouvoir conserver cette authentification sur l'API.

Est-ce qu'on garde l'authentication au niveau du VPN ? Non, car cela permettrait de simplifier la config pour ceux qui n'utilisent pas Yunohost.

On pourrait se passer complètement de login / mot de passe, en s'authentifiant auprès de l'API à partir de la clé privée + certificat expiré. L'app de Yunohost permettrait cela.

On doit pouvoir permettre aux gens de:

• Tout générer de manière automagique
• Envoyer un CSR, sans envoyer sa clé privée
• Envoyer sa clé privée, et le CSR est généré

Si les personnes ne veulent pas donner leur clé privée à l'app, on pourrait générer le .cube avec une mention “insérez votre clé privée ici”.

Normalement, c'est aussi prévu dans l'app vpnclient. Si l'information est manquante dans le .cube, elle est censée demander d'envoyer le fichier manquant (clé privée, certificat, etc.). Pour le moment, ça n'a pas l'air de marcher, mais si c'était le cas cela résoudrait TOUS nos problèmes.

Le DNS42 c'est le labo internet. Un internet de test.

Cela permet de s'enregistrer pour avoir un bloc IP et de s'exercer à faire du routage. Ou même d'accéder à des sites qui ne sont que sûr DN42.

Ce serait bien qu'un jour on puisse dire à nos membres que s'ils veulent expérimenter les sessions BGP, etc., ils puissent avoir accès à ce réseau-là. Ca se ferait via un VPN (à base de Wireguard et d'OpenVPN).

Avant nos membres, ce serait bien de pouvoir le faire au sein du hub infra et de s'auto-former.

Comment marche OpenVPN ? Avec des roulettes !

Le serveur a un certificat, et le client a un certificat signé par le serveur. Cela permet de valider la connexion. Grace à cette méthode l'ajout de nouveau client est dynamique, pas besoin de reload le serveur.

OpenVPN génère deux connexions/flux au moment de la connexion : un tunnel pour la config, et un tunnel pour les données. Le certificat est utilisé pour initier le tunnel de configuration, dans lequel ils s'échangent des trucs pour générer le tunnel de data.

On peux utiliser une paire de clés statiques pour limiter les client qui se connecte au VPN, ce sont les cles TA. C'est ce qu'on retrouve dans le .cube. Cela permet de dire d'ignorer la demande s'il n'y a pas la paire de clés TA.

Et donc on peut éliminer les bots qui testent le port du serveur VPN.

Pour router un bloc ipv6 on a besoin d'une ip dite de lien local qui n'est pas une fe80 car pas générée automatiquement. Dans le cas de Yunohost, on pourrait aussi donner un /64 à tout le monde… mais ça ne marche que pour Yunohost.

Donc idée : donner un /128 de base, et router un /64 dedans.

Donner un /128, c'est ce qu'on fait pour ISPng. C'était une bonne idée, sauf d'utiliser ça pour Yunohost, car pas supposé être des liens pour Yunohost. Ce n'est pas supposé être des IP qui vont sur internet.

Dans le .cube, il faut pouvoir y insérer le /64.

Il est possible d'avoir un fichier de config par client (via le client-config-dir, ou ccd). Cela permettrait d'avoir un OpenVPN en HA.

Il est aussi possible de dire au client quand le serveur redemarer ou s'arrete, et d'utiliser un autre serveur. Cela marche bien si on n'utilise pas NetworkManager (ça tombe bien, on n'est pas censé l'utiliser sur les briques).

Le mssfix permet de découper les gros paquets en petits paquets. Le MTU c'est la taille des paquets sur une interface réseau. Traditionnellement, c'est 1500 octets mais si on prend une connexion vdsl en Belgique, une partie est utilisée pour le protocole DSL. Ce qui fait qu'en pratique, le MTU est de 1492 octets. Si par dessus cela on fait un tunnel GRE, on diminue encore le MTU…

Du coup aujourd'hui, dans la conf du VPN de Neutrinet Corp, on aun mssfix de 1420 pour garantir que le tunnel se monte peu importe la connexion. C'est une config manuelle dans OpenVPN.

C'est un VPN, les performance sont meilleurs, historiquement un port un client mais cela a évolué.

La plupart d'entre-nous n'a pas expérimenté avec ce VPN.

Wireguard est un VPN récent, et implémente donc plein de principes cryptographiques modernes.

Par exemple, on a l'impression que les performences sont meilleures parce qu'il fait du multitreading sur la partie chiffrement et utilise des algo moderne comme des cles eliptiques.

Il n'y a pas de notion de PKI, car ce sont des clés statiques, avec une paire de clés par client. On a juste une paire de clé publique / privée statique. Le serveur connaît la clé publique du client. Le client connaît la clé publique du serveur. Dans le cas d'OpenVPN, c'est différent, les deux ne connaissent pas leurs clés publiques respectives… parce que la vérification se fait sur base du CA.

La gestion du MTU et mssfix est automatique.

L'ajout de client requiert de reload le serveur. Mais ça ne casse pas les connexions actives.

La configuration est ultra minimaliste par rapport à OpenVPN. On a d'office une config spécifique par client, car on y met sa clé publique.

Une config classique ressemble à ça :

[Interface]
Address = 10.0.0.1/24, fdc9:281f:04d7:9ee9::1/64
ListenPort = 51871
PrivateKey = PEER_A_PRIVATE_KEY

[Peer]
PublicKey = PEER_B_PUBLIC_KEY
AllowedIPs = 0.0.0.0/0 ::/0
Endpoint = peer-b.example:51902

Interface = côté serveur. Peer = le client. Les deux sont inversé si c'est le client. Endpoint, c'est l'adresse du bout du tunnel, mais n'est pas nécessaire.

On pourrait rajouter une ligne à cette config pour dire que la personne a tel bloc IP.

Un switch sur le réseau.

Si on a trois ordinateurs, A, B et C. Les trois ont des clés statiques. Chacun fournit un réseau privé accessible que via chaque ordinateur.

Si une communication entre A et C se casse, mais que A et B, et B et C peuvent toujours communiquer, la connexion va passer via B → A et C pourront toujours se parler.

Cela peut être utile si on veut chiffrer une communication entre plusieurs sites. Mais en vrai depuis l'arrivée de WireGuard il perd en popularité.

On n'a pas la demande dans Neutrinet pour ce type de VPN.

~~Le VPN jamais content~~

C'est pas vraiment un VPN. ~~C'est pour ça qu'il est pas content !~~

C'est un protocole de couche 4 (ICMP, TCP, UDP) et ça permet d'encapsuler un autre protocole de couche 4.

Ca requiert d'avoir une IP fixe (côté client et côté serveur) et l'intérêt de ce type de tunnel est de fournir de l'IPv6 à une connexion qui est en IPv4 only. Ou l'inverse.

L'idée, donc, ce n'est pas de chiffrer (on encapsule, ce n'est donc pas un VPN), mais ça peut être pratique dans certaines situations. En Belgique, ça peut être pertinent car beaucoup de fournisseurs ne fournissent que de l'IPv4.

Ca peut ou non être lié au VPN.

Mais il faut voir si la demande est là. C'est pour un public très techos à priori.

Le VPN du grand-père.

Ultra commun dans les réseaux d'entreprises, dans les BiduleBox propriétaires, et ultra pénible à configurer.

L2TP = protocole

IPsec = la partie qui va chiffrer à l'intérieur du protocole.

Quand on établit une connexion :

• Phase 1. Connexion en L2TP avec souvent un login / password
• Phase 2. Etablissement de la liaison IPsec.

Avec une IP pour la phase 1 différente de l'IP pour la phase 2. Et après seulement on peut faire du routage.

La partie L2TP pourrait être utile pour la collecte, mais c'est pas la même chose, car ce serait une connexion avec des IPs privées puis par dessus on aurait un VPN.

Parmis les types de VPN, on a comme candidats OpenVPN et WireGuard.

La question, c'est est-ce qu'on se limite à un seul ou on veut proposer les deux ?

Le monitoring de si l'IP est connectée dans les envies plus haut… c'est aussi en lien avec Wireguard car une fois que le client est connecté avec sa clé, la clé est valide indéfiniment. La seule manière de la supprimer est de le faire côté serveur.

Si on veut faire les deux, est-ce qu'on peut piocher dans le même bloc d'IP ? Oui.

On a déjà un bloc d'IP où l'usage est le VPN. OpenVPN et Wireguard piocheraient dans le même pool d'IPs.

Au niveau des blocs, on ne permettrait que deux blocs d'IPv6 possible : /64 et /60. Pour la collecte, ça pourrait être un découpage différent.

Ce qui risque d'être compliqué à gérer, c'est comment on automatise la mise à jour de la configuration du serveur VPN. Dans l'un ou l'autre cas, il faut rajouter la configuration quand on met à jour le serveur.

Il y a différentes pistes : - un file system partagé ? - ketupa déclenche un trigger dans semaphore qui déclenche un playbook ansible

Comment on met à jour de la configuration qui n'est pas gérée manuellement par des humains.

En premier lieu, il faut qu'OpenVPN fonctionne. Wireguard, même si c'est une demande, ça reste un bonus. Dans tous les cas, on va améliorer les performances des VPN…

Grosse question aussi pour la migration des blocs IP d'ISPng vers le nouveau VPN. La plupart ce sera des cas spécifiques, du style la personne avait pris un /56.

Il faudrait un peu structurer tout ce qui a été dit.

• Qu'est-ce qui est migrable ? Qu'est-ce qui ne l'est pas ?
• Est-ce qu'on promeut WireGuard pour YunoHost ?
  • Cela signifie de faire des tests avant
• Comment on fait le monitoring des IPs ?
• Qui on vise ?

TODO: Faire un cahier des charges

Prochaine réunion : 25/11 à 14h → Hub infra où on valide le cahier des charges

Un pad pour le cahier des charges:

• VPN: https://doc.neutrinet.be/vpn-cahier-des-charges
• Backoffice: https://doc.neutrinet.be/backoffice-cahier-des-charges

Lieu : Caldarium

Garde-Pad: Moi, plus toi, plus nous plus tout ceux qui sont Tharyrok

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