Pannes Renater, UBS, INSA Lyon et résilience mail/DNS/authentification

Entre jeudi 16 et vendredi 17 juin, il y a eu des coupures de service à l’INSA de Lyon (noté simplement INSA ensuite), à l’Université Bretagne Sud (notée simplement UBS ensuite) et sur Renater. Il s’avère que ce sont 3 réseaux que je fréquente régulièrement, Renater fournissant connectivité et certains services à ces 2 établissements... En pleine séquence de cours DNS/Mail, j’en ai profité pour analyser ces pannes et discuter de cela avec des étudiants.

Dans ce blogpost, je décris les interactions DNS/Mail entre Renater et ces 2 établissements, les bonnes ou mauvaises pratiques que l’on constate, les risques que l’on peut envisager et le pourquoi de tout ça. On va faire du dig et du whois pour découvrir tout ça !

Le commencement, quelle était la situation ?

Tout d’abord, les liens entre ces acteurs :

• Renater est un fournisseur d’accès réseau et de services. Il fournit l’accès réseau à des campus français et propose certains services supplémentaires.
• Les mails INSA et UBS sont ainsi gérés par la même plateforme Partage de Renater, nous utilisons aussi FileSender comme service de partage de fichiers volumineux. Ces 2 services (mail et filesender) sont authentifiés et nous utiliserons ces 2 exemples par la suite.

Et voici la timeline (partielle et non-officielle) de ce que l’on a pu constater :

• Jeudi 16 juin : coupure du lien INSA Lyon - Renater. Les serveurs et le réseau étaient up côté INSA, mais coupés d’internet. La panne était en fait plus large, c’est le campus au moins (regroupé avec l’Université Lyon 1) ou le réseau métropolitain qui était coupé. Bref, tout marchait à l’INSA mais c’était coupé...
• Entre jeudi 16 juin et lundi 20 juin : une panne sur le groupe froid dans le datacenter de l’Université Bretagne Sud a mené à la coupure radicale de la plupart des serveurs. L’accès au réseau était ok, mais la plupart des services locaux étaient donc down
• Vendredi 17 juin : une panne chez Renater a impacté une large part des services qu’ils offrent aux établissements, coupant à la fois l’accès réseau (connectivité) et l’accès à certains (tous ?) services applicatifs (service de mails "Partage" par exemple)

Nous allons maintenant essayer de comprendre dans quelles phases des différentes pannes le mail et FileSender pouvaient être fonctionnels. Au-delà des serveurs proprement-dits hébergés chez Renater, nous pouvons identifier 2 dépendances principales à ces services :

• le DNS lors de l’accès au serveur
• le mécanisme d’authentification (qui est basé sur les comptes de chaque établissement).

Évidemment, pendant la partie de panne Renater, ces services étaient down : nous allons réfléchir aux phases où Renater fonctionnait mais pas l’INSA ou l’UBS.

On se retrouve avec des dépendances rigolotes entre un prestataire (Renater, qui héberge) et des clients (les établissements, qui gèrent les comptes), avec des pannes variées de tous les côtés !

Le DNS

Commençons par le DNS pour ces 2 services.

Pour le mail (partage), les entrées DNS sont sous l’arborescence "univ-ubs.fr" et "insa-lyon.fr". En effet, pour recevoir des mails @univ-ubs.fr, l’expéditeur a besoin de trouver les MX de univ-ubs.fr et, côté usagers, nous devons nous connecter à des adresses du type "partage.univ-ubs.fr". Ainsi, même si les serveurs sont physiquement hébergés chez Renater, leur résolution par DNS dépend de l’infra DNS de l’UBS/l’INSA. Let’s dig into it !

Faisons un peu de résolution manuelle pour trouver qui sert les zones univ-ubs.fr et insa-lyon.fr. Tout d’abord, pour .fr [1] :

Sur cette capture, nous interrogeons un serveur racine (a.root-servers.net) pour obtenir le serveur responsable de .fr (1). Dans la réponse, nous trouvons notamment d.nic.fr comme responsable pour servir .fr (2).

Interrogeons maintenant ce d.nic.fr :

Nous demandons à d.nic.fr les serveurs responsable pour univ-ubs.fr (1). Parmi ces serveurs, nous trouvons ns-ext.univ-ubs.fr (2) à l’IPv4 54.36.120.34 (3). Creusons cette IP :

Dans la sortie de ce whois, nous trouvons des infos OVH :

Nous constatons ainsi que l’UBS a, parmi ses serveurs DNS faisant autorité, un serveur externe hébergé chez OVH [2]. Et, donc, une redondance : si l’UBS est en panne ou inaccessible, la zone univ-ubs.fr doit continuer à répondre (hypothèse de l’absence de panne simultanée chez OVH).

Côte INSA, le dig donne ceci :

En interrogeant pour insa-lyon.fr (1), on constate que les 2 serveurs DNS ont des IP proches, n’ont pas de nom mentionnant l’extérieur (ce ne sont que des indices). En creusant les IP (ou en connaissant la plage d’adresses du campus...), ce sont 2 IP appartenant au campus. Il n’y a donc pas de redondance externe et si le campus est inaccessible, alors la zone DNS insa-lyon.fr n’est plus accessible.

Enfin, concernant FileSender, il est hébergé pour tous sur filesender.renater.fr. Avec la même démarche, on trouve que renater.fr dispose d’un DNS secondaire hébergé en Allemagne, dans un autre AS : le DNS restait donc ok.

Verdict côté DNS :

• partage.univ-ubs.fr est resté ok tout au long de ces pannes
• partage.insa-lyon.fr n’était plus résolvable quand l’INSA était déconnecté (modulo les temps d’éviction de cache pour ceux qui l’avaient)
• filesender.renater.fr est resté ok côté résolution DNS

L’authentification

Ces 2 services, mail et filesender, sont authentifiés, basés sur les comptes de chaque établissement. Mais (à ma connaissance et de ce que j’en comprends) selon 2 architectures différentes :

• Miroir de la base côté Renater pour le mail (Partage)
• Service CAS hébergé par l’établissement pour FileSender

Ainsi, dans le cas du mail, l’annuaire est hébergé côté Renater et synchronisé quotidiennement avec la base de référence côté établissement. L’authentification, ensuite, ne dépend plus du bon fonctionnement du SI de l’établissement. Ainsi, le service de mail reste fonctionnel si l’établissement est déconnecté (tant que Renater fonctionne).

Dans le cas de FileSender, l’authentification passe via le CAS de l’établissement. L’utilisation de ce service Renater dépend donc du bon fonctionnement et de la joignabilité du serveur d’authentification de l’établissement.

Pour un service similaire (l’authentification), les choix et contraintes d’architecture amènent ainsi à des risques de disponibilité différents.

Verdict côté authentification :

• L’authentification du mail est restée fonctionnelle tant que Renater fonctionnait, peu importe l’état de l’établissement
• L’authentification de FileSender, et donc son usage, ne fonctionnait plus dès lors qu’un établissement était déconnecté ou que son service d’authentification était défaillant.

Conclusion : qu’est-ce qui marchait quand ?

Et du coup, si on reboucle :

• Le mail fonctionnait tout le temps où Renater était ok pour les comptes UBS, peu importe l’état du SI de l’UBS, grâce à la bonne pratique du DNS secondaire externalisé et l’authentification côté Renater
• Le mail ne fonctionnait pas pour les comptes INSA lorsque le SI de l’INSA était déconnecté, à cause de l’absence de DNS secondaire externe au campus qui rendait le serveur présent mais injoignable
• FileSender ne fonctionnait que lorsqu’à la fois Renater et l’établissement (INSA et UBS) étaient fonctionnels et connectés