Admins

Inspection : les machines du local ont guarana comme résolveur dns (via configuration DHCP), et guarana a comme résolveur DNS : lui même et 172.16.0.3 (dns.cluster.april.org). La range d'IP 172.16.0.0/16 est accessible via le VPN servi par galanga. Sans VPN il n'y a plus que 127.0.0.1 comme résolveur atteignable sur guarana.

-> configurer un unbound pour résoudre localement sur guarana ?

Dans la conf bind de guarana, 172.16.0.3 est configuré comme forwarder, peut être faudrait-il désactiver ça.

Ce "forwarder" semble nécessaire pour la résolution dns de la zone locale (april.org-int)

J'ai procédé à quelques tests : l'inaccessibilité de 172.16.0.3 n'est pas le problème. Si on bloque les ports à sa destination, les rootservers sont bien interrogés.
Le problème vient plutôt du routage qui est forcé à travers le vpn qui est cassé sans galanga.

Je pense que le plus simple est probablement de coder un script cronné qui adapte la conf de bind.

• on ping -q -c 1 172.16.0.3
• en cas d'échec :
  • on averti les sysadmins
  • on bascule le forwarder sur le dns de la box
  • on restart bind (pour flusher le cache)

En théorie, une fois qu'on est sur le dns de la box, tout passe par l'extérieur et plus rien par le vpn (qui sera stuck en même temps que le ping).

• en cas de chute de vpn une sonde doit alerter. On va en ajouter une sur guarana pour être sûr de ça.
• en cas de chute de vpn icinga va voir tout rouge, ce qui va alerter les admins.

Bien sûr on fera une machine d'état, par ex. on déclenche si on n'arrive pas à pinguer 2 fois de suite à x min d'intervalle.

Cette tâche devient vraiment prioritaire car il y a de nouveau un problème de résolution de DNS au local suite au reboot de galanga, le serveur ayant pourtant redémarré correctement a priori. Il faut s'assurer qu'elle soit faite le plus rapidement possible. Vu qu'elle ne sera pas faite pendant ce sprint. Eventuellement la réattribuer si François n'a pas le temps de s'en occuper pour le moment.

14:07:32            QGuLL | madix: ça a l'air résolu : j'ai redémarré bind sur guarana : pas ok (bind hs), j'ai redémarré vpn, puis bind : pas ok (bind hs), j'ai redémarré vpn sur galanga, sur    │
                          | guarana, bind : pas ok (bind hs)                                                                                                                                        │
14:07:57            QGuLL | j'ai mis le dns de ffdn dans le resolv.conf de guarana, redémarrer bind : ok                                                                                            │
14:08:07            QGuLL | puis reviré le dns ffdn                                                                                                                                                 │
14:08:28            QGuLL | maintenant, sans ffdn bind redémarre correctement                                  

On pourrait peut être modifier la procédure de reboot de galanga : ajouter le dns de ffdn sur le resolv.conf de guarana, rebooter galanga, enlever les dns de ffdn de guarana.

Testé à l'instant, le dns ffdn a permis une continuité de service, mais n'était pas suffisant : j'ai dû restarter openvpn sur guarana et galanga pour pinger à nouveau 172.16.0.3 depuis guarana

Un point de vue radical sur la situation : séparer résolveur et serveur faisant autorité : https://www.bortzmeyer.org/separer-resolveur-autorite.html

Avec le recul, j'adhère.