Guide de l’infrastructure

Modifié par Clément AUBIN le 2021/04/03 21:31

Bonjour !

Ce guide a pour but, avec le moins de prétention possible, de faire état du fonctionnement général du système d’information d’ATILLA. En théorie, ce guide devrait suivre les évolutions de l’infrastructure et s’adapter en conséquence … mais bon, faire de la doc, ça n’a jamais été très intéressant ^^.

Nous espérons qu’avec ce guide et les ressources qui lui sont attachées, le SI d’ATILLA pourra continuer à évoluer au fil des ans et des bureaux.

By the way, comme l’exercice consistant à créer un guide totalement objectif semble pour nous quelque chose d’impossible, soyons bien d’accord : il y aura des endroits ou nous donnerons nos avis, aussi nuls soit-il ; deal with it.

Bisous,

Les admins <3

Prérequis

Faire de l’administration système à ATILLA peut se résumer à trois points :

  • Installer des machines (virtuelles ou non)
  • Déployer et maintenir les services de l’association
  • Résoudre des problèmes simples en matière d’architecture réseau

Il faut donc pour cela disposer d’une bonne connaissance du fonctionnement d’un système Linux ainsi que du fonctionnement des réseaux IPv4. Le principal défi est de pouvoir apprendre cela en parallèle des cours dispensés au sein de l’EISTI (à la date d’écriture de ce guide, nous ne disposons que d’un module sur le fonctionnement des réseaux au S2 d’ING2 qui touche de plus ou moins loin ce que nous traiterons ici).

Se former

Du coup, comment apprendre ? Plusieurs moyens s’offrent à vous, choisissez celui qui vous va le mieux emoticon_smile !

  • Utiliser la littérature à votre disposition en CY106 : vous trouverez quelques livres décrivant le fonctionnement de Linux en général. Attention : il est possible que certaines commandes présentes dans ces ouvrages soient obsolètes.
  • Demander aux personnes en place : vous pouvez joindre les administrateurs système d’ATILLA IRL ou bien par mail aux adresses suivantes : admins[you know what]lists.atilla.org, admin[you know what]atilla.org ou bien root[you know what]atilla.org. Notons que les administrateurs système (et ingénieurs réseau) de l’EISTI ne rechignent généralement pas à répondre à vos questions (il suffit de dire que vous venez pour ATILLA ^^).
  • Internet
  • Apprendre sur le tas : en terme de pédagogie, ce n’est pas le top, mais ça s’applique parfaitement au sein d’ATILLA : il y a toujours des choses à changer et à améliorer. À vous d’amadouer un admin pour qu’il vous fournisse un accès sur un ou plusieurs serveurs :p.

L’état d’esprit

Ce n’est pas quelque chose dont on parle souvent, mais je pense que cela compte beaucoup. Travailler au sein de l’administration système d’ATILLA, c’est évidemment pouvoir tester de nouvelles choses, mais aussi (et surtout) fournir un ensemble de services sur lesquels le reste de l’association peut se reposer (pour développer des projets, pour diffuser des talks et des conférences, …). Pour moi, avoir accès aux serveurs de l’association, c’est un énorme privilège mais aussi une énorme responsabilité. À partir du moment ou vous disposez d’un accès à un serveur, vous devenez automatiquement garant de son bon fonctionnement.

Réseau

Parlons dans un premier temps du réseau. Comme ATILLA se trouve au sein de l’EISTI, nous ne disposons que de très peu de marge de maneuvre pour ce qui est de choisir nos plages IP. On peut distinguer deux réseaux au sein de l’association :

  • Un réseau ATILLA dédié aux serveurs et aux services de l’association. Il dispose de la plage IP 192.168.10.0/24.
  • Un réseau ATILLA-CY106 pour gérer l’ensemble des équipements présents dans la salle CY106. Il dispose de la plage IP 192.168.253.0/24.

Chacun de ces deux réseaux dispose de son accès internet propre, en ce qui concerne le réseau ATILLA, nous disposons de trois IP publiques que nous répartissons sur nos serveurs. A la date d’écriture de ce guide, notre passerelle est Laïka avec l’IP publique 193.48.70.11. Il est à noter que ces trois adresses IP se trouvent sur le réseau EISTI DMZ-RENATER : l’accès internet à ce réseau se fait donc par le biais du FAI … Renater !

D’un autre côté, le réseau ATILLA-CY106 se sert d’Hydra comme passerelle. L’accès internet est fourni par un NAT sur le FAI Level3.

Par convention, nous définissons notre passerelle sur l’IP privée 192.168.XXX.1. Ainsi, Laïka dispose de l’IP privée 192.168.10.1 ; par ailleurs, Hydra dispose de l’IP privée 192.168.253.1.

Réseau ATILLA-CY106

Comme dit précédemment, on trouve sur ce réseau à peu près tout ce qui se trouve en CY106. Le routage est assuré par Hydra (192.168.253.1). Notons qu’Hydra assure également les services de DHCP et de DNS.

ATTENTION :  La configuration DHCP et DNS d’Hydra est semi-automatique ; en effet, nous exportons une partie de ces configurations à partir de la plateforme members.atilla.org (plus d’informations sont disponibles sur l’article Members).

Conservation des données de connexion

Depuis octobre 2016, nous avons obligation de logguer l’ensemble du trafic transitant sur le réseau ATILLA-CY106 … principalement pour savoir sur qui taper en cas de téléchargement illégal. Pour ce faire, nous utilisons deux ressources :

  • Les fichiers de log du serveur DHCP : ils nous permettent de faire correspondre une adresse MAC à une adresse IP ; voici un exemple de logs : 
Jan 30 22:02:30 hydra dhcpd: DHCPREQUEST for 192.168.253.XXX from 00:00:00:00:00:00 via eth1
Jan 30 22:02:30 hydra dhcpd: DHCPACK on 192.168.253.XXX to 00:00:00:00:00:00 via eth1
  • Nous enregistrons également les en-têtes des paquets IP transitant par Hydra à l’aide d’Ulogd2. Ce stocke ses informations dans une base de données Postgresql logs directement sur Hydra.

Notons qu’il nous est possible de faire correspondre une adresse MAC à un nom d’utilisateur en utilisant les mécanismes d’authentification RADIUS présents sur le réseau ATILLA-CY106.

Gestion des points d’accès au réseau

Pour pouvoir se connecter au réseau ATILLA-CY106, il existe deux moyens principaux :

  • Se brancher à une prise murale lié à un des deux switchs de la salle
  • Passer par le réseau wifi ATILLA

Les deux switchs switch-b1 (192.168.253.4) et switch-b2 (192.168.253.5) sont accessibles via telnet, via une interface web, ou bien via un port série au dos du switch.

Le réseau wifi est diffusé par un routeur situé à proximité de la baie réseau : ap-wifi (192.168.253.3) accessible via ssh ou bien via une interface web.

ATTENTION :  En ce qui concerne le routeur wifi, il est déconseillé d’utiliser l’interface web pour modifier les paramètres du routeur : en effet, nous utilisons une configuration wifi ne pouvant pas être affichée sur l’interface web ; vous risquez de casser des paramètres sans vous en rendre compte.

Gestion de la connexion au réseau

Afin de pouvoir faire correspondre une adresse MAC à un nom d’utilisateur, nous avons mis en place un système d’authentification 802.1x au sein du réseau ATILLA-CY106. Le détail de ce système est expliqué dans l’article Authentification_RADIUS.

Évidemment, le serveur RADIUS loggue toutes les tentatives d’authentification, pour information, voici un exemple de logs pour une connexion :

Sat Jan 28 19:47:42 2017 : Auth: (3636)   Login OK: [aubincleme] (from client ap_wifi port 0 via TLS tunnel)
Sat Jan 28 19:47:42 2017 : Auth: (3636) Login OK: [aubincleme] (from client ap_wifi port 6 cli XX-XX-XX-XX-XX-XX)

Réseau ATILLA

Sur le réseau ATILLA, les choses fonctionnent un peu différemment : comme nous considérons que les personnes ayant accès aux serveurs de ce réseau sont des personnes de confiance, nous ne conservons pas de données de connexion ; il n’y a également pas d’authentification RADIUS sur ce réseau.

Il est à noter qu’ATILLA dispose à l’heure de la création de ce guide de 5 serveurs physiques :

  • bill.atilla.org
  • laika.atilla.org
  • idefix.infra.atilla.org
  • snoopy.infra.atilla.org
  • touffu.infra.atilla.org

Les serveurs bill.atilla.org et laika.atilla.org sont les deux seuls serveurs physiques à disposer d’une adresse IP (publique) sur le réseau DMZ-RENATER.

Pour donner plus de flexibilité à la gestion de l’infrastructure, nous utilisons massivement les capacités de virtualisation de nos serveurs. Ainsi, la plupart de nos services fonctionnent sur des machines virtuelles (VMs) dédiées. Ces machines virtuelles sont stockées sur nos trois serveurs les plus récents : Bill, Laïka ou Touffu.

Découpage du réseau

Depuis février 2016, afin de rendre l’organisation de notre infrastructure plus cohérente, nous avons décidé de découper le réseau ATILLA (192.168.10.0/24) en 6 «sous-réseaux». Il est à noter que ces sous-réseaux n’ont de réseau que le nom : il s’agit simplement d’une convention entre les admins pour que nous sachions qu’un serveur dédié à la production se trouve forcément entre les adresses IP X et Y.

Voici le découpage IP actuellement en place :

  • 192.168.10.0/27 - *.infra.atilla.org : Réseau dédié aux serveurs et équipements physiques (comme les EisTV) ;
  • 192.168.10.32/27 - *.vps.infra.atilla.org : Réseau dédié aux serveurs privés virtuels (VPS) de l’association. Ce réseau n’est plus utilisé depuis septembre 2016 car nous n’acceptons plus l’hébergement de VPS ;
  • 192.168.10.64/26 - *.prod.infra.atilla.org : Réseau dédié aux services utilisés en production ;
  • 192.168.10.128/26 - *.test.infra.atilla.org : Réseau dédié aux services utilisés en test ;
  • 192.168.10.192/27 - *.preprod.infra.atilla.org : Réseau dédié aux services utilisés en pré-production ;
  • 192.168.10.224/27 - *.dev.infra.atilla.org : Réseau dédié aux services utilisés en développement.

Serveur DHCP

Une grande majorité des serveurs du réseau ATILLA prennent leur adresse IP via un serveur DHCP installé sur un de nos serveurs physiques (actuellement, il s’agit de Bill). Toute la configuration DHCP de l’infrastructure est disponible aux membres de l’association via ce dépôt Git par souci de transparence. Nous découpons la configuration DHCP selon les 6 réseaux présentés précédemment ; on notera que ce serveur ne propose aucune range dynamique pour l’accueil de nouveaux équipements réseau, il faut donc modifier la configuration DHCP à l’ajout de toute nouvelle machine.

Serveur DNS

Tout comme le serveur DHCP, le serveur DNS de notre infrastructure se trouve sur Bill. De même, par souci de transparence, nous publions l’ensemble de notre configuration DNS sur ce dépôt Git, accessible à tous les membres de l’association et de gitlab.atilla.org.

On distingue deux configurations DNS distinctes :

  • Une configuration external pour toutes les adresses externes à l’EISTI ;
  • Une configuration internal pour toutes les requêtes provenant de l’intérieur de l’EISTI.
Configuration external

Dans cette configuration, on ne trouve que deux zones : *.atilla.org et *.eistiens.net. Il n’y a pas grand-chose à spécifier sur ces dernières, si ce n’est qu’elles ne servent qu’à rediriger un utilisateur vers notre frontal web, on trouvera donc souvent ce genre d’enregistrement : random-vhost IN CNAME frontal-web

Comme il s’agit des zones DNS accessibles depuis l’extérieur de l’EISTI, ces dernières contiennent nos enregistrements SPF pour les domaines atilla.org et eistiens.net et les enregistrements DKIM et DMARC pour le domaine atilla.org.

Configuration internal

La configuration internal est bien plus intéressante, en effet, c’est dans cette dernière que nous définissons les résolutions internes de toutes nos machines. Cette configuration est scindée en trois types de fichiers : 

  • Les fichiers de zone *.eistiens.net et *.atilla.org : ils ont peu ou prou le même objectif que ceux de la configuration external : rediriger un utilisateur venant du réseau de l’EISTI et souhaitant se connecter à un service vers notre frontal web ;
  • Le fichier de reverse-dns : db.10.168.192.in-addr.arpa ; il nous permet (comme son nom l’indique) de publier les enregistrements reverse-dns des serveurs du réseau 192.168.10.0/24 et ainsi de pouvoir faire correspondre à une adresse IP un FQDN ;
  • Les 6 autres fichiers restants sont les suivants :
    • db.infra.atilla.org
    • db.vps.infra.atilla.org
    • db.prod.infra.atilla.org
    • db.test.infra.atilla.org
    • db.preprod.infra.atilla.org
    • db.test.infra.atilla.org
Ces fichiers servent à publier les enregistrements DNS des serveurs se trouvant dans les «sous-réseaux» que nous avons définis auparavant. Dans chacun de ces fichiers, on retrouve le subnet ID du réseau correspondant, ainsi que deux enregistrements DNS gateway et broadcast correspondant tous les deux aux adresses IP de début et de fin du réseau.

Politique de nommage des machines virtuelles

Nous avons tendance à en rire, mais au premier coup d’œil, la manière dont nous nommons nos machines virtuelles peut paraître invraisemblable.

Je m’explique. Prenons par exemple une machine virtuelle actant comme un serveur MySQL utilisé en environnement de test. Le nom (hostname) de la machine sera mysql-test et cette dernière se trouvera dans le réseau test.infra.atilla.org. Le FQDN de cette machine sera donc : mysql-test.test.infra.atilla.org

… mais, mais, mais … pourquoi diable suffixer le nom des machines virtuelles par leur environnement associé alors que ce dernier est également présent dans le nom du réseau auquel la machine appartient ?

À cette question, nous avons deux réponses :

  1. Une machine peut se retrouver (par mégarde) sur le mauvais réseau ; il devient ainsi difficile de la différencier d’une machine virtuelle semblable appartenant à un environnement différent ;
  2. La configuration actuelle des prompt Bash ($PS1) de nos machines virtuelles n’affiche que le nom de la machine et non son FQDN. Sans suffixer le nom de la machine, il est impossible de distinguer du premier coup d’œil une machine virtuelle dans un environnement de production de son homologue dans un environnement de développement.

Liens utiles

Vous trouverez ci-après un ensemble (plus ou moins structuré) de liens vers des documentations & tutoriels vous permettant d’en apprendre un peu plus sur l’admiminstration système.

Réseau

(Network) Bridges

Domain Name System (DNS)

Dynamic Host Configuration Protocol (DHCP)

Preboot Execution Environment (PXE)

Théorie

Parfois, ça ne fait pas de mal de revenir aux fondamentaux ^^.

Virtual LANs (VLANs)

Serveurs

N’oubliez pas, le man est votre ami : https://en.wikipedia.org/wiki/Man_page !

Cheatsheets

Logical Volume Manager (LVM)

Virtualisation

Puppet

Puppet, c’est avant tout beaucoup de pages de documentation, sortez une nouvelle fenêtre de votre navigateur préféré, préparez un café et plongez : https://docs.puppet.com/puppet/ !