Documentation d'urgence

Nam et Bour ont redémarré

Dans ce scénario, Neutrinet est hors-ligne et nous devons nous rendre au datacenter pour pouvoir déchiffrer les disques manuellement. Ne pas oublier de prendre son badge et bouton, ainsi qu'un câble rj45.

On se connecte au switch avec le câble série, que l'on branche en USB sur son laptop:

sudo screen /dev/ttyUSB0 9600

Ensuite, on fait CTRL+Y pour activer la console, puis enable.

On affiche la config du switch avec la commande:

sw-backbone# show running-config module vlan

On repère les lignes suivantes:

vlan ports 2/30 tagging unTagPvidOnly
...
vlan members 10 1/1-9,2/1-9,2/30
...
vlan ports 2/1-9,2/30,2/35 pvid 10

En gros, on cherche un port libre qui est sur le VLAN de management. Ici, on peut voir que le port 30 sur le switch 2 (= le switch du bas) est libre et se trouve bien dans le VLAN 10.

On connecte son laptop au switch, et en s'attribue une adresse IP:

On s'assure d'avoir ceci dans sa config SSH:

Host 10.0.10.111 10.0.10.112
  User neutrinet
  KexAlgorithms +diffie-hellman-group14-sha1
  HostKeyAlgorithms +ssh-rsa

Et on désactive le ProxyJump vers les pfsense, puisqu'on se trouve déjà dans le réseau de management.

On peut se connecter à l'iLo en SSH:

ssh neutrinet@10.0.10.111

On indique le mot de passe qui se trouve dans le gestionnaire de mot de passe.

On active la console:

textcons

On indique ensuite la phrase de passe pour déchiffrer le serveur. Elle se trouve également dans le gestionnaire de mot de passe.

À partir de là, on se retrouve dans la situation où au moins un des serveurs est accessible depuis internet.

Nam et Bour ne se parlent pas

Maintenant que les disques sont déchiffrés, on vérifie que les serveurs peuvent se parler. Par exemple:

ping bour

On fait pareil pour les trois serveurs et sur chacun des serveurs.

Bour a redémarré et ne parvient plus à parler avec Nam

Supposons qu'on se trouve dans le cas de figure où c'est Bour qui a redémarré. En général, cela veut dire que l'adresse locale IPv6 de Bour a changé suite au redémarrage. En temps normal, elle doit avoir comme valeur:

root@bour:~# ip -6 a
...
14: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 state UP qlen 1000
    inet6 fe80::a236:9fff:fe05:248c/64 scope link 
       valid_lft forever preferred_lft forever
16: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8996 state UP qlen 1000
    inet6 fe80::da9d:67ff:fe6e:c14c/64 scope link 
       valid_lft forever preferred_lft forever
...

Il est également possible que la route vers Bour ait été modifiée. On vérifie sur Nam que la route correspond bien à l'IPv6 locale de Bour:

root@nam:~# ip -6 r s
...
2001:913:1000:30::2 via fe80::a236:9fff:fe05:248c dev vmbr0 metric 1024 pref medium
...

Si l'IPv6 locale de Bour n'est pas la bonne, il suffit de faire ifreload -a pour reconfigurer la bonne IP.

Si c'est la route vers Bour qui n'est pas bonne, il faut d'abord supprimer les anciennes routes avant:

ip -6 route del 2001:913:1000:30::1
ip -6 route del 2001:913:1000:30::2
ip -6 route del 2001:913:1000:30::3
ifreload -a

Si Bour et Nam ne parviennent toujours pas à se parler, on doit vérifier que l'IPv6 locale de Nam n'a pas changé de son côté (voir ci-dessous).

Nam a redémarré et ne parvient plus à parler avec Bour

C'est le même problème que dans la section précédente.

L'adresse locale IPv6 de Nam doit avoir comme valeur:

root@nam:~# ip -6 a
...
9: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 state UP qlen 1000
    inet6 fe80::a236:9fff:fe04:d2f8/64 scope link 
       valid_lft forever preferred_lft forever
11: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8996 state UP qlen 1000
    inet6 fe80::da9d:67ff:fe6e:919c/64 scope link 
       valid_lft forever preferred_lft forever
...

Et on vérifie sur Bour que la route correspond bien à l'IPv6 locale de Nam:

root@bour:~# ip -6 r s
...
2001:913:1000:30::1 via fe80::a236:9fff:fe04:d2f8 dev vmbr0 metric 1024 pref medium
...

Le serveur n'est pas joignable en IPv6

Lorsque tous les serveurs peuvent se parler, on vérifie qu'ils ont tous une IPv6 sur l'interface vmrb1.10:

ip a s dev vmbr1.10

Si ce n'est pas le cas, il suffit de redémarrer l'interface réseau:

ifdown vmbr1.10; ifup vmbr1.10

Attention à bien lancer cette commande en un bloc, sinon on perd la connexion SSH.

Note: Sur topi, l'interface s'appelle bond1.10.

Le pfsense n'est pas joignable

Il est possible de se connecter à l'iLo des serveurs sans passer par le pfsense.

On se connecte à edge-01, puis on se connecte à l'iLo de Bour:

ip vrf exec management ssh -lneutrinet 10.0.10.112