Projet

Général

Profil

Actions

LIR » Historique » Révision 333

« Précédent | Révision 333/350 (diff) | Suivant »
youpi, 17/09/2020 14:42


LIR

Activité de LIR Aquilenet

Pour tous les contrats faire signer le document https://atelier.aquilenet.fr/attachments/download/582/Aquilenet_LIR-Stolon-Convention-20180927.odt

Ajouter un admin sur les objets RIPE

Il suffit d'ajouter un champ auth sur
https://apps.db.ripe.net/db-web-ui/#/lookup?source=ripe&key=fr-aquilenet-1-mnt&type=mntner

Fourniture d'un ASN


https://lirportal.ripe.net/

https://www.ripe.net/manage-ips-and-asns

https://apps.db.ripe.net/db-web-ui/#

whois -i mnt-by fr-aquilenet-1-mnt

# Préféré, car retour d'erreur immédiat:
gpg --clearsign updates.txt (will produce updates.txt.asA c)
curl --data-urlencode DATA@updates.txt.asc http://syncupdates.db.ripe.net

# Sinon, par mail:
gpg --clearsign updates.txt (will produce updates.txt.asc)
mail -s 'Bulk inetnum update' auto-dbm@ripe.net < updates.txt.asc
# ou alors juste coller dans un mail qu'on signe normalement

blabla

Kazar ferme ses portes, on doit donc trouver un autre LIR. Dans les associatifs, il y a

  • Gitoyen, qui est LIR pour pas mal d'autres assos de la fédé
  • Tetaneutral, qui prône pour la création de nouveaux LIRs
  • Web4all, qui n'a pas répondu à nos demandes.

On a demandé sur la liste membres@ffdn, certaines assos pourraient être intéressées:

  • Ilico
  • AIL-Network (mais plus maintenant: sont en train de se constituer LIR avec CARBODEBIT et WIFI SAINT JULIEN)
  • SamesWireless
  • tetaneutral peut prendre des parts s'il y a besoin

Par ailleurs, il y a des discussions en cours au RIPE sur la diminution du préfixe attribué aux LIR, on passerait d'un /22 à un /24:

https://www.ripe.net/ripe/mail/archives/address-policy-wg/2017-September/012087.html

On a finalement décidé de devenir LIR

Déroulement chronologique

Objets RIPE

Liste de nos objets:

whois -i mnt-by fr-aquilenet-1-mnt

Tout se passe maintenant sur https://lirportal.ripe.net https://www.ripe.net/manage-ips-and-asns https://apps.db.ripe.net/db-web-ui/#



vieux pour les archives: Migration de LIR & IP

  • {background:lightgreen} DONE : mise à jour bgpd.conf
  • {background:lightgreen} DONE : mise à jour bgpd blackhole
  • {background:lightgreen} DONE : mise à jour bgpd nlnog => mail
  • {background:lightgreen} DONE : mise à jour firewall
  • {background:lightgreen} DONE : mise à jour RDNS
  • {background:lightgreen} DONE : mise à jour carp cerbere
  • {background:lightgreen} DONE : mise à jour scripts Xen
  • mise à jour des machines une par une... configuration /etc/network/interfaces, firewall, conf serveurs
  • VMs Apollon
    • acaqb => mail
    • {background:lightgreen} DONE : agatas-aqui-vm1 => mail
    • DONE agatasTeT => mail
    • {background:lightgreen} DONE : alcyon [04/12/17 - 23:25]
    • ate
    • bayonnet => mail
    • bayonnet2 => mail
    • {background:lightgreen} DONE : cpprod
    • {background:lightgreen} DONE cpprod-dev
    • {background:lightgreen} DONE :dev-cortex => mail
    • dev-iidre => mail
    • {background:lightgreen} DONE :dev-sacha
    • {background:lightgreen} DONE: dionysos
    • {background:lightgreen} DONE :duniter
    • ecce-info
    • {background:lightgreen} DONE :embedded-freedom => mail
    • {background:lightgreen} DONE :f1te => mail
    • {background:lightgreen} DONE : griffith => mail
    • {background:lightgreen} DONE : guilarr => mail
    • guzel
    • {background:lightgreen} DONE hades (à finir en dernier pour garder les IPs DNS récursif disponibles)
    • {background:lightgreen} DONE :hermes
    • {background:lightgreen} DONE iidre
    • {background:lightgreen} DONE iris
    • {background:lightgreen} DONE janus
    • motv => mail
    • {background:lightgreen} DONE : natha => mail
    • {background:lightgreen} DONE neutral
    • {background:lightgreen} DONE nlnog => mail
    • {background:lightgreen} DONE : sanssoucis => mail
    • {background:lightgreen} DONE : tchaikovski => irc fx
    • {background:lightgreen} DONE : tdn => mail
    • test <= ???
    • triton
    • tyche
    • {background:lightgreen} DONE : web.openbeelab
  • VMs artemis
    • {background:lightgreen} DONE : athena (à finir en dernier pour garder la supervision)
    • {background:lightgreen} DONE : demeter
    • {background:lightgreen} DONE : eos
    • {background:lightgreen} DONE : gaia (à finir en dernier pour garder les IPs DNS récursif disponibles)
    • {background:lightgreen} DONE hera (à finir en dernier pour le ldap & such)
    • {background:lightgreen} DONE hestia
    • {background:lightgreen} DONE labx-ipmi => mail
    • {background:lightgreen} DONE persephone
    • test
  • Elidee => mail+ relance 21/12
  • {background:lightgreen} DONE : Sayanet
  • ENCOURS: Zeus
  • Guix => mail (machine pas au dc en ce moment)
  • {background:lightgreen} DONE : Poseidon
  • {background:lightgreen} DONE : L@BX
  • {background:lightgreen} DONE : PDU 7920
  • PDU 7821: pas réussi à m'y connecter: mot de passe invalide...
  • {background:lightgreen} DONE : styx
  • mise à jour des VPNs: nouvelles IPs activées, on attend les confirmations des gens avant de les basculer sur la nouvelle IP
  • {background:lightgreen} DONE : corriger doc compta IP fixe VPN
  • {background:lightgreen} DONE : mise à jour dhcp
  • mise à jour DNS au fur et à mesure, refaire une passe complète pour vérifier.
  • {background:lightgreen} DONE Prévenir les abonnés qu'on a changé le DNS: ce n'est plus 141.255.128.100 / 101, mais 185.233.100.100 / 101
  • Finir de corriger le wiki

Mise à jour d'une VM

Tout le réseau 141.255.128.0/24 devient 185.233.100.0/24 et 2a01:474::/32 devient 2a0c:e300::/32

Dans cet exemple, on travaille sur la VM gaia (141.255.128.2 -> 185.233.100.2)

Conf réseau

Pour une transition en douceur, on peut dans un premier temps juste ajouter la nouvelle IP à côté de l'ancienne. Sous Debian, on peut par exemple ajouter à /etc/network/interfaces:

auto eth0:1
iface eth0:1 inet static
 address 185.233.100.2
 #gateway 185.233.100.126
 netmask 255.255.255.128
iface eth0:1 inet6 static
 address 2a0c:e300::2
 #gateway 2a0c:e300::126
 netmask 48

et lancer ifup eth0:1 pour avoir la nouvelle IP.

Si ce n'est pas déjà fait, il faut corriger /etc/resolv.conf:

nameserver 185.233.100.100
nameserver 185.233.100.101
nameserver 80.67.169.12
nameserver 2a0c:e300::100
nameserver 2a0c:e300::101

Si ce n'est pas déjà fait, il faut corriger /etc/nagios/nrpe.d/aquilenet.cfg le allowed_hosts et lancer service nagios-nrpe-server reload

Si ce n'est pas déjà fait, il faut corriger /etc/hosts pour mettre le nom de la machine elle-même sur la nouvelle IP aussi.

Si ce n'est pas déjà fait, il faut corriger l'IP dans /etc/motd

Conf firewall

Il faut éventuellement corriger le firewall, typiquement corriger /etc/iptables/rules* et relancer netfilter-persistent start ou /etc/init.d/iptables-persistent start

Conf service

On peut alors vérifier que les services de la VM sont accessibles avec la nouvelle IP: dans /etc/hosts sur son propre ordi, on peut mettre

185.233.100.2 www.aquilenet.fr
2a0c:e300::2 www.aquilenet.fr

et vérifier que ça fonctionne bien à la fois en v4 et v6. Ça peut ne pas fonctionner si le service est bindé explicitement sur les anciennes IP (cas de bind9 par exemple), il faut alors binder sur à la fois les anciennes et les nouvelles. En général on écoute sur toutes les IPs donc pas de souci. On peut le vérifier assez facilement avec netstat:

netstat -Ainet -Ainet6 -anp | grep LISTEN

Si ça indique 0.0.0.0 et :: c'est que ça écoute sur toutes les IPs. Si c'est 141.255.128.x, c'est qu'il écoute explicitement sur les IPs, et il faut configurer ça. S'il y a du 127.0.0.1 ou ::1, c'est normal, c'est les services en interne seulement. Cette même commande permet de vérifier facilement que le service écoute maintenant sur les nouvelles IPs aussi :)

On peut aussi faire un gros grep -r 141.255.128 /etc et grep -ri 2a01:474 /etc

Basculement DNS

Une fois qu'on est sûr que le service fonctionne sur la nouvelle IP, on peut basculer dans DNS: sur gaia, /etc/ns2/db.aquilenet, changer les IPv4 et v6 (chercher [:.]2$ par exemple), mettre à jour le serial, et lancer service ns2 reload . IL faut au même moment regarder l'heure: le TTL est par défaut 28800s, donc 8h, donc pendant 8h il peut y avoir des machines qui ont encore en cache l'ancien enregistrement DNS.

Bien sûr, s'il y a d'autres nom de domaines hors aquilenet.fr qui pointent sur nos IPs, il faut les mettre à jour aussi...

Supervision shinken

Sans attendre, sur athena, dans /etc/shinken/hosts/aquilenet/aquilenet.cfg, corriger l'adresse, et faire un service shinken reload

Fin conf réseau

Noter dans la liste des VMs ci-dessus la date et heure de basculement DNS

8h après le basculement DNS, le TTL est expiré, personne n'est plus censé utiliser l'ancienne IP, on peut alors la supprimer, en virant la section eth0 et en renommant eth0:1 en eth0 et en décommentant les lignes gateway et un ptit reboot est utile pour être sûr que ça fonctionne vraiment au poil.

VPN

Tout le réseau 141.255.130.0/24 devient 185.233.101.0/24 et 2a01:474::/32 devient 2a0c:e300::/32

Pour ceux qui ont des IPs fixes, on préfère éviter de leur changer la configuration de manière impromptue. On a donc pour l'instant mis (par exemple pour le VPN 42):

ifconfig-push 141.255.130.42 255.255.255.0
push route-gateway 141.255.130.254
iroute 185.233.101.42
ifconfig-ipv6-push 2a01:474:4:42:: 2a01:474:4:80::1
iroute-ipv6 2a01:474:4:42::/64
iroute-ipv6 2a0c:e300:4:42::/64

Ce qui permet de faire fonctionner à la fois l'ancienne et la nouvelle IP, même si c'est encore l'ancienne qui est configurée automatiquement par openvpn côté client (on est obligé de forcer le route-gateway car malgré le ifconfig-push cet idiot d'openvpn utilise pour route-gateway l'IP du serveur dans 185.233.101.0/24...). L'abonné peut utiliser de son côté

ip addr add dev tun0 185.233.100.42

pour activer à la main la nouvelle IP, puis vérifier que l'on peut effectivement accéder à son serveur avec la nouvelle IP. Une fois confirmé, on peut basculer sur la nouvelle IP:

ifconfig-push 185.233.101.42 255.255.255.0
iroute 141.255.130.42
ifconfig-ipv6-push 2a0c:e300:4:42:: 2a0c:e300:4:80::1
iroute-ipv6 2a01:474:4:42::/64
iroute-ipv6 2a0c:e300:4:42::/64

i.e. on bascule ifconfig-push, on enlève push route-gateway, on bascule iroute, et on bascule ifconfig-ipv6-push. On ne touche pas à iroute-ipv6: on garde les deux routes pour l'instant.

Et une fois que l'adhérent n'utilise plus l'ancienne IP (parce que le TTLS DNS de ses noms de domaine est expiré par exemple), on peut virer l'ancienne IP:

ifconfig-push 185.233.101.42 255.255.255.0
ifconfig-ipv6-push 2a0c:e300:4:42:: 2a0c:e300:4:80::1
iroute-ipv6 2a0c:e300:4:42::/64

i.e. on enlève les iroute et iroute-ipv6 vers les anciennes IPs

Mis à jour par youpi il y a plus de 3 ans · 333 révisions