157 lines
5.1 KiB
Markdown
157 lines
5.1 KiB
Markdown
# Réunion du Collège Technique
|
|
|
|
* Date : Mercredi 16 mai 2018
|
|
* Lieu : Kfet
|
|
* Début : 19h00
|
|
* Fin : 20h40
|
|
* <<Pad>>
|
|
|
|
## Présents
|
|
|
|
* Grizzly
|
|
* Chirac
|
|
* Charlie
|
|
* Boudy
|
|
* Blupon
|
|
* Mikachu
|
|
* Esum
|
|
* Poult
|
|
* 20-100
|
|
* Pollion
|
|
* Fardale
|
|
* Gasnier (19h21)
|
|
|
|
## Ordre du jour
|
|
|
|
### Devis
|
|
|
|
On a un devis pour le nouveau serveur, la ram pour ft et les disques de la
|
|
baie, à valider.
|
|
|
|
On valide le devis pour le nouveau serveur 4900€ TTC, 600€ TTC de RAM pour ft.
|
|
|
|
Pour les disques, il faut du SAS v2 2To, Anne peut pas les prendre, on les
|
|
prends sur ldlc. On commence par en prendre un.
|
|
|
|
### Multicast wifi
|
|
|
|
Le Multicast wifi pose des problèmes de perf, il faut envisager de bloquer le
|
|
multicast entre WLAN/LAN.
|
|
<https://help.ubnt.com/hc/en-us/articles/115001529267-UniFi-Managing-Broadcast-Traffic>
|
|
<https://sysctl-explorer.net/net/ipv4/proxy_arp_pvlan/>
|
|
|
|
On commence par le mettre à la Kfet pour tester, et on passe à l'échelle si ça
|
|
marche.
|
|
|
|
### Parefeu
|
|
|
|
Présentation et plan d'attaques.
|
|
|
|
* Le pare feu génère un set de règle indifférement v4/v6, puis traite ce qui
|
|
doit être particulier.
|
|
* Le parefeu de Nit devait rattraper plein d'erreur, par construction et à
|
|
cause d'ipset, qui était notamment nécéssaire pour le filtrage mac/ip.
|
|
Aujourd'hui, on a le dhcp snooping et le radius qui check le mac/ip, on est
|
|
plus sur que ça vaille le coup de le faire dans le parefeu.
|
|
* Il y a des vieilles blackliste paiement qui traine, c'est par très pertinent.
|
|
Le pb est qu'il y a la période de blacklist paiement
|
|
* Sur zamok, les blacklist hard sont bloqué en input, on peut le retirer.
|
|
|
|
Vu qu'il n'y as plus de filtrage mac/ip, on peut juste régénerer quand on ouvre
|
|
des ports. Il y a un fonction delinblacklisthard dans le parefeu, qu'il
|
|
faudrait appeller quand on retire une bl. On peut aussi regen le parefeu plus
|
|
régulièrement.
|
|
|
|
Attention, le pare feu a laissé "parfois" passer la note de test. C'est chelou,
|
|
et on sait pas d'où ça vient...
|
|
|
|
Deux grosse étapes:
|
|
|
|
* Il faut faire un cahier des charges sur le wiki. Chirac propose un premier
|
|
cahier des charges.
|
|
* Debuguer la partie v4 du nouveau pare feu, et unifier. Ça peut-être pertinent
|
|
de faire des tests sur sable avec le nouveau pare feu.
|
|
|
|
### Fin de la migration des ipv4 ?
|
|
|
|
Il y a encore 27 machines fixes avec des ip Crans-ENS.
|
|
|
|
* Il faut poker OSM (esum), federez (?) et respo-info (Grizzly) pour finir.
|
|
|
|
### Problèmes de VLAN
|
|
|
|
Actuellement les switches ne peuvent détaguer qu'un seul vlan sur leurs prises,
|
|
ce qui posent des problèmes lorsqu'un adhérent ou un club branche à la fois des
|
|
machines à ip publique et des machines à ip privée dans sa chambre/local.
|
|
|
|
Chirac propose d'utiliser une fonctionnalité des switches pour détager
|
|
plusieurs
|
|
vlan (<http://h22208.www2.hpe.com/eginfolib/networking/docs/switches/RA/15-18/5998-8151_ra_2620_asg/content/ch06s13.html>)
|
|
mais cela casse plus ou moins le broadcast (qui pose problème pour les ip v6),
|
|
mais cela n'a pas fonctionné lors de la mise en prod (ou bien ça n'était pas
|
|
activé ?).
|
|
|
|
* une possibilité serait de mettre les ip privées et publiques sur le même vlan.
|
|
* une autre de mettre des switchs manageables à servens, etc (mais là on doit
|
|
le faire pour toutes les chambres)
|
|
|
|
Options :
|
|
|
|
1. fusion des vlans
|
|
1. switchs manageable à la Kfet et a servens, et par défault un personne qui a
|
|
une machine publique a toutes ses machines publiques
|
|
1. dhcpv6
|
|
1. vlan tagged sur les prises
|
|
|
|
On envoie le vlan ip publique en tagged
|
|
|
|
### Certificat wildcard
|
|
|
|
Benjamin propose d'utiliser un certificat wildcard pour les services webs,
|
|
c'est possible d'utiliser un challenge
|
|
DNS (voir <https://certbot.eff.org/docs/using.html#manual>) en tirant le
|
|
paquet (<https://packages.debian.org/stretch-backports/certbot>) depuis
|
|
stretch-backports et d'écrire un script pour l'automatiser.
|
|
|
|
On le garde en tête, re2o ?
|
|
|
|
### Mise à jour des serveurs
|
|
|
|
#### Mise en prod de kiwi ?
|
|
|
|
On met kiwi en prod, (il faut vérifier que la création de compte wiki
|
|
fonctionne en ip pub et privé), on migre juste le wiki en laissant tourner
|
|
niomniom. On annonce un downtime une semaine à l'avance avec un bandeau sur le
|
|
wiki. Il faudra aussi remettre en place le rsync vers soyouz pour wiki2.
|
|
|
|
#### Mise à jour de redisdead
|
|
|
|
Maintenant que le feu de la migration est passée, on aura peut-être du temps
|
|
pour terminer les upgrade. Faut-il prévoir une interruption de service ?
|
|
|
|
Il faut le faire, et prévenir les gens. On est pas particulièrement pressé, on
|
|
essayera de prévoir une maintenance, ptet faire en même temps que odlyd2 et
|
|
owl, omnomnom, zephir.
|
|
|
|
### Problèmes de connexion
|
|
|
|
Des gens ont fait remonter des pb de connexions. On ne sait pas pourquoi, il
|
|
faut trouver des moyens de diagnosatiquer. On parle de pb de pings, de pb de
|
|
paquets perdus.
|
|
On a déjà augmenté les coeurs de ipv6-zayo, ça a amélioré un peu le ping en v6.
|
|
|
|
La limite de débit retiré pourrait être une piste, mais l'uplink serait saturé
|
|
en GB, ce qui n'est pas le cas.
|
|
|
|
Des questions de QOS, etc.
|
|
|
|
Bref, on sait pas ce qu'il se passe, il faut trouver des moyens d'investiguer.
|
|
|
|
### Questions re2o
|
|
|
|
* Mot de passe unique (cf mails @nounous)
|
|
* problème du .forward
|
|
* créer compte wiki
|
|
|
|
Repoussé à la prochaine fois.
|