fr:rapports:2020:11-14 []

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
# 2020/11/14 (Hub infra)

## Présences

 * HgO
 * Celo
 * JMG
 * Tierce
 * Tharyrok
 * nino
 * hugo
 * ptr_here
 * ko


## Météo

Moment informel. 

## Informel (10h à 13h)

### Point sur Chez Mémé (en avance sur l'après-midi) :

Ça n'est plus d'actualité avec Nubo mais Petites Singularités serait intéressés. Aussi peut-être "Nos oignons", qui seraient intéressés par avoir des serveurs en Belgique mais actuellement on a pas les ressources humaines.

### Point sur Neutrinet, les humains et l'infra

Problème : actuellement on fait surtout du technique, moins d'humain.

Proposition de Tharyrok : faire un hub spécifique pour Chez Mémé, car pas les mêmes tâches techniques.

Il y a aussi les questions administratives qui vont surgir pour Chez Mémé.

Lancer un appel plus large ? Mais même si bcp seront intéressés, peu risquent de vraiment vouloir s'impliquer.

Gitoyen : beaucoup de personne se reposent dessus, les gens font peu la partie réseau et ne veulent pas s'imppliquer. Si ils veulent le faire, on les envoie là-bas. 

Peut-être faire des réunions mensuelles chez Mémé ?

Projets techniques : fonctionnent souvent avec de petits noyaux. Chez Neutrinet, culture de l'ouverture -> cherche à s'adresser à tous·tes. Mais c'est presque deux métiers différents entre la vulgarisation et accompagner les gens dans l'auto-hébergement, pas le même projet que d'interconnecter des machines et des associations.

Peut-être une prise de conscience pour neutrinet de savoir si on veut être comme Gitoyen ou si on veut au contraire des ressources pour des install party, être proche de Monsieur et Madame Michu.

Ce deuxième aspect est une valeur ajoutée de Neutrinet.

Tierce a plus envie pour le moment de se tourner plus vers de l'humain et de l'administratif.

Mais des aspects pas forcément incompatibles.

Actuellement Neutrinet, en la personne de hgo, tierce & tharyrok ont l'avantage de vivre sous le même toit et donc ça facilite les discussions pour Neutrinet.  Mais on est bien conscient qu'il faut faire un effort pour tenir d'autres personnes dans nos boucles de conversation.

Faut dire aussi que le confinement n'aide pas à se voir en présentiel et l'énergie à fournir pour « faire en ligne » est assez grande comparée à ce qu'on vit au quotidien qui est très facile et confortable.

Pourtant, quand on reprends le marathon du déménagement, on a pris des notes (cf. wiki et les notes de célo), on pourrait prendre le temps de revisiter ces notes et d'améliorer le contenu du wiki à ce propos.

Ça pourrait aider d'autres personnes à « maîtriser » l'existant et se sentir plus légitime pour « rentrer dans l'infra ».  Par exemple, il est de coutume que la maintenance, les reverses dns, ou d'autres « petites » choses sont un bon point d'entrée.  Cela nous permettrait de réfléchir et documenter « comment on donne des accès et comment on gère la confiance ».  Et tant qu'on y est aussi se demander comment on retire ces accès.

Célo aimerait pouvoir se familiariser avec les serveurs de Neutrinet. Par exemple, configurer le rdns pour sa brique.

### Rdns … exemple

```
~ ᐅ ping godfraind.eu
64 bytes from dynamic-2001-0913-1fff-ffff-0000-0000-0006-98af.v6.reverse.neutri.net (2001:913:1fff:ffff::6:98af): icmp_seq=1 ttl=57 time=15.1 ms

~ ᐅ ping4 godfraind.eu
64 bytes from dynamic-80-67-181-247.reverse.neutri.net (80.67.181.247): icmp_seq=1 ttl=57 time=15.4 ms

Et en fait on devrait faire tourner notre script qui fait en sorte que notre serveur DNS réponde que c'est godfraind.eu et pas dynamic-80-67-181-247.reverse.neutri.net .

~ ᐅ ping tierce.nohost.me
64 bytes from tierce.nohost.me (2001:913:1fff:ffff::b:d0fe): icmp_seq=1 ttl=57 time=34.0 ms

~ ᐅ ping4 tierce.nohost.me
64 bytes from tierce.nohost.me (80.67.181.227): icmp_seq=1 ttl=57 time=40.4 ms
```

## Formel (14h à 18h)

### Tâche accomplie

Pour rappel on a le salon privé #ops : https://chat.neutrinet.be/neutrinet/channels/ops sur Mattermost pour quand on fait des trucs dans l'infra.

- Mise a jours de Nextcloud
- IPv6 Spoofing Vulnerability AS204059 : c'est fait (ticket 8760115 sur Zammad)
- Verixi (notre DC) et Gitoyen (Notre LIR) se parlent directement maintenant https://lg.gitoyen.net/prefix_bgpmap/whiskey/ipv4?q=109.69.216.22
  les deux liens co-existent, et si un se casse l autre est tjs là
- Nos Oignons … n'ont pas les ressources juridiques pour la législation belge … donc un jour faudra faire un Nos Oignons Belgique
- Remise en ordre au prêt du ripe https://apps.db.ripe.net/db-web-ui/query?searchtext=%2080.67.181.0%2F24
 ( query RIPE data : `whois 80.67.181.0/24` )

`whois -B Neutrinet-MNT` query les donnees d'authentication sur qui peut changer les data au RIPE (cle gpg thary)

### Réflexion sur chez mémé

#### Nouveau Hub

Tu es hébergé où ? … chez mémé \o/ of waar zijn je gegevens … bij oma \o/ :)

Si c'est Neutrinet asbl qui doit « porter » les aspect contractuels avec Verixi pour avoir 1 seul interlocuteur (demande de Verixi) du coup #hub-admin est aussi nécessaire.

Créer le salons public "collocation datacenter" ou alors Chez-Mémé-DC ? Question : comment les nouveaux savent qu'on parle d'un DC ?

Votes:
```
#chez-meme
#chère-meme
#hub-dc
#datacenter
#shared-DC +1+1+1+1
#shared-datacenter +1
#hub-dc_shared
#hub shared-DC
```

Description: projet de collocation du rack dans le DC de Verixi loué par Neutrinet asbl

todo : créer #shared-dc -> done
todo : fixer une première date de réunion
todo : invite hellekin (has an account on our mattermost) -> done, peut-être lui en parler pour qu'il soit au courant

### Planification du travail de la nouvelle infra

#### Nouvelle structure réseau (point n° 0)
https://wiki.neutrinet.be/_media/fr/rapports/2020/config-network-neutrinet-network.svg

Lors du déménagement on a « juste » migrer les VMs actuelles (qui sont parfois anciennes, genre jessie et a migré ISP-NG tel-quel.

Ce qu'il reste à faire :
    - Créer deux pfsense et les mettre en HA
    - Créer nos VMs derrière ces pfsense

#### Découpage des VM (point n° 2)
On a des service séparés comme web, dns, vpn et web qui fait beaucoup.

#### inventaire (point n 1)
Inventaire de l'infra actuelle : https://pads.domainepublic.net/p/inventaires <3
proposition de bouger ca dans un ethercalc

Chacune de nos VMs a une IP publique et avec la raréfaction des ipv4 on mettrait bien un ha-proxy ou autre.

#### reverseproxy (point n°3)
loadbalancing (si necessaiire)? 
Une alternative à ha-proxy (gpl2) pourrait être https://envoyproxy.io (apache) (cf. nino)
apache mod_proxy
nginx
traefik
caddy2

#### configuration management  (point n° 4)

https://gitlab.domainepublic.net/Neutrinet/infra

(déployer l'infrastructure et ses configurations, tenir l'oeil sur les changement de config etc., documenter les config )

On se pose la question de ansible, en amont et en utilisation quotidienne.
- a la main 
- ansible,
- autres...

#### Installation des VM (point n° 5)

Prendre le temps d'installer des vms après avoir « fait le découpage » et ce point est probablement redondant avec Ansible.

On a pas beaucoup de VM, donc peut-être pas nécessaire de piloter les déploiements avec du ansible-proxmox.
https://docs.ansible.com/ansible/latest/collections/community/general/proxmox_module.html

#### Monitoring (point n° 6)

Monitoring pour le moment inexistant dans Neutrinet

La VM qui s'occupera du monitoring sera hébergée en dehors de notre infra (ex: Hetzner), pour éviter qu'elle tombe aussi lorsque notre infra tombe.

#### Backup (point n° 7)

Actuellement ça se fait sur un disque en dehors du ceph

#### Fastnetmon (point n° 8)

https://fastnetmon.com/

Projet opensource de détection de ddos et d'annonce dans la black hole des adresses IPs
L'idée est de détecter l'IP malveillante et lui faire croire que notre IP n'existe plus pour elle (redirection du trafic vers une sorte de /dev/null, càd un black hole).
Gitoyen est en train de le tester, on pourrait discuter avec eux pour avoir des infos. Mais c'est possible que cet outil ne nous serve pas vraiment.

#### Comment on s'organise pour tout ces sujets ?

Mattermost https://chat.neutrinet.be

```
#neutricamp
#noeudstri-lente-temps
#neutriton +1+1 \o/
#neutrithon +1
#neutrython +1
```

Répo Git https://git.domainepublic.net/Neutrinet/

Réunions Hub-Infra (cf. prochaine date(s) si on considère un des points ci-dessus par réunion / 
neutri-camp). Pour un « ordre » d'intérêt, voir les numéros (point n° x) dans les titres ci-dessus.

*Prochaine réunion* : samedi 28 Novembre - 14h

réunion pour expérimenter sur tous les points listés, chaque 2 semaines genre
en présentiel

https://jitsi.belnet.be/neutriton

### Devenir membre du Ring de NlNog.

https://ring.nlnog.net/

Chacun héberge un VM avec un ubuntu et une clé ssh du ring et nos clés seront poussée sur les autres membres du ring pour exécuter des diagnostic réseau.

Le « prix à payer »  Ring c'est mettre un VM à disposition.

Et si tu fais des conneries t'es juste kick out et tu perds ta légitimité.

Il faut que la VM soit au sein d'un AS qu'on gère et Neutrinet a son propre AS, ce qui n'est pas le cas d'une VM qu'on mettrait chez Hetzner.

(c'est pas relate' au RIPE (qui ont des initiatives pareils, cfr. si-desous ripe-atlas etc. )

Sur leur site : 

```
The following suggestions are indicative:

    1 core or CPU
    20 gigabyte disk space
    At least 1024 megabyte RAM, but more is better
    10mbit NIC (more is fine)
```

Quels seraient les avantages / désavantages.

#### Avantage : 

- diagnostiquer notre réseau et pouvoir le mettre dans un monitoring (quand on en aura un)
- c'est trop cool quand on aime le réseau
- permet de faire de traceroute etc

#### Désavantage:

- faut le faire
- faut de la bande passante
- bouffe une ip de Neutrinet

Idée (nino):

mettre ça en lien avec le projet de monitoring (mais le monitoring risque d'être chez Hetzner donc pas dans notre infra)
 
Ring admin : le script qui gère les clés SSH du ring (mais pas d'accès sudo pour les personnes qui ont accès)
 
C'est bien une VM « à part et dédiée au ring » et pas un service sur une VM qu'on utiliserait à autre chose.

On peut parquer la question pour quand on mettra en place le monitoring.

pour être rajouté à la machine, met ta clé ssh ici:

```
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILsxhKPxz/C1t3DGdBppgbYMlFW25j/Z/uYPCfzc+K29 nino@mm.st
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGliHjUPMaxneAK6UlLSDPTA65sDpvZ0f7QTvhuyYs5G tierce@q
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAXdVHAWWKlA9pex1iHTBDy/FxcOkb1tXKVNFwFDMKxc ptr@eternit
```

tharyrok s'en occupe bientôt :)

### Avoir une sonde RIPE Atlas

https://atlas.ripe.net/about/anchors/

Atlas = petit boitier que l'on branche sur l'internet

- https://atlas.ripe.net/
- https://beta-docs.atlas.ripe.net

Ils ont aussi des formats 1U qu'ils sponsorisent. Ceux-là on peut les placer en DC.
Est-ce qu'on veut une telle sonde alors qu'on devrait payer les coûts d'hébergement (bande passante + électricité, le matériel est payé par eux) ?

Ça voudrait dire ±80€ / mois en plus aux frais de Neutrinet.

*Cela ne rentre pas dans le budget de Neutrinet.*

### Avoir plus de personnes qui savent modifier le ripe

Tharyrok a la possibilité de modifier le RIPE, après avoir soudoyé Gitoyen pour lui donner les accès.
Est-ce que d'autres personnes seraient intéressées pour aussi avoir le pouvoir de modifier le RIPE ?

https://apps.db.ripe.net/db-web-ui/query?searchtext=AS204059

- **todo**: C'est un compte Neutrinet > rajouter dans le passwordstore sur noc@neutrinet.be
- **todo**: ptr veut bien passer un peu du temps pour lire la doc (si d'autres intéressés, peut-être le faire ensemble ?)

### Proposition de renouveler notre pki lors des AG

PKI = gestion d'autorité de certificat (CA).

Par ex, Let's encrypt est un CA. Lorsqu'il va signer le certificat du site web de Tharyrok, il va donner sa confiance à ce certificat. Le navigateur va voir qu'il peut faire confiance à Let's encrypt, et donc au certificat du site web de Tharyrok.

https://en.wikipedia.org/wiki/Public_key_infrastructure

Neutrinet doit gérer sa propre PKI pour les VPNs  (c'est le ca-certificate par exemple).

Il faut pouvoir renouveler les CA régulièrement, parce que les technos cryptographiques / le niveau de sécurité augmente chaque année. 

Et donc on profiterait des AG annuelles pour renouveler les différents certificats, ce qui mettrait un peu en lumière ce travail.

Plus on le ferait, plus on augmente les risques en terme de certificats.  Mais on voit pas trop pourquoi ce serait un risque parce que « ce serait des gens de confiance ».

root cert key signing is a matter of high security in corpos with a very strict procedure

Mais l'idée dans notre proposition est de travailler avec 2 certificats en parallèle (en terme de durée de vie et d'expiration) pour qu'il y ait un « overlap » pour les clients.  Actuellement les briques (et donc les vpns) ont une durée de vie de 1 an.

Si on met en place un nouveau CA avec une durée de vie de 3 ans ou plus, les nouveaux comptes VPN l'utiliseront pour générer leur certificats.  Cela laisse aussi les certificats existants fonctionnel puisque le serveur connaît encore « l'ancien certificat » qui expirera bientôt.  Et lors de l'expiration d'un client de « l'ancien CA », c'est sur base du nouveau CA que cela se fera.

Aujourd'hui, le CA et sa clé privée sont sur le serveur du VPN.  C'est aussi pour ça qu'on aimerait revisiter ce sujet et faire apparaître aux yeux des membre (d'où les AG) que Neutrinet doit gérer une PKI.

Du coup … http://point-at-infinity.org/ssss/ ? (shamir secret sharing scheme)
Ou on met la clé privée dans un coffre dont une ou deux personnes de confiance auraient la clé ?

- **todo** : simuler combien de temps ça prendrait pour ne pas plomber une AG
- **remarque** : si ça ce fait, ça serait pas pour l'AG 2021 mais peut-être pour 2022 (c'est en février en général)

### Présentation de Ketupa

https://git.domainepublic.net/Neutrinet/ketupa

( un remplacement d'ISP-NG en cours )

x509 avec l'encodage ASN.1 DER (said ptr_)

- auth-user-pass-verify script on backend 
- acceuil membre (generer certificat a la vollee pour nouveau membre)

Questionnements OpenVPN vs Wireguard :

- Keep it simple : on va garder la migration de ISPng le plus simple possible
- Wireguard est très peu connu parmi les membres du hub infra
- La brique internet ne fournit un support que pour OpenVPN, utiliser Wireguard serait très expérimental
- Néanmoins, Wireguard serait plus rapide, avec une codebase plus petite donc plus sûre
- est-ce que le end-user peut ou pourrait choisir son algo (actuellement c'est du AES, de mémoire)

### Devenir LIR épisode 2

(juste de l'info :-)

https://www.ripe.net/participate/member-support/copy_of_faqs/isp-related-questions/pa-pi

Le RIPE et les LIR ont 2 façons d'attribuer des Ips (PA ou PI).

PA n'a pas la possibilité de specifier un contact specifique a une IP (eg. pour un 'client' comme nubo qui veut gerer sa lui meme, ou un exit-node TOR)

On se pose c question pour que, par exemple un nœud tor, it donc une IP, puisse avoir des coordonées différentes que celle de Neutrinet (le détenteur d'un bloc IP et donc un contact abuse@).

Pour rappel on avait déjà été abordé par Verixi sur l'idée de devenir LIR mais cela à un coût non négligeable (cf une ou deux réunion précédente).

Actuellement Neutrinet dispose d'un bloc IP de type PA pour les ipv4 et de type PI pour les ipv6.
Et donc pour toutes les ipv4 Neutrinet fait office de « passe plat » en cas de requête.

https://www.ripe.net/participate/member-support/payment/ripe-ncc-billing-procedure-2020

### Faire un article sur le blog

À propos de ceci : https://pads.domainepublic.net/p/ipv6
Merci de relire un peu ce pad, de le corriger, compléter etc et puis on en fera un article.

{{tag>infra}}