Outils pour utilisateurs

Outils du site


fr:infra:doc_urgence

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision
Révision précédente
fr:infra:doc_urgence [2023/07/17 12:05] – supprimée - modification externe (Date inconnue) 127.0.0.1fr:infra:doc_urgence [2023/07/17 16:20] (Version actuelle) hgo
Ligne 1: Ligne 1:
 +# 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:
 +
 +![](https://s3.neutrinet.be/hedgedoc/uploads/292cc7eb-9256-4d77-ad82-329521cecbe5.png)
 +
 +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
 +```