Introduction

Cet article est le premier d’une série sur la réfection de mon infrastructure perso (homelab). Ce dernier se veut court, je vais donc tâcher de ne pas trop m’y attarder. Au fur et à mesure des mes années passées devant un ordinateur et ces deux années en DUT Réseaux & Télécommunications, j’ai eu l’occasion de pouvoir découvrir beaucoup de choses. J’ai entres autres eu l’occasion de mieux comprendre le routage sur internet, les réseaux niveau 2, le fonctionnement des équipements professionnels ainsi que les service offerts par ses derniers. En parallèle des cours, j’ai ainsi pu mettre en place chez moi des bouts d’infrastructure tels qu’un switch manageable, routage avec RIP, serveurs en tous genres, etc. Tous ces éléments mis bouts à bouts, j’ai fini par avoir quelque chose de relativement conséquent… Quelque chose ressemblant à ceci:

Au fur et à mesure de l’avancement de mon infrastructure, divers problèmes ont commencé à émerger, dont:

• Gestion du DNS devenue difficile, pannes régulières de BIND et incohérences dans les délégations,
• MTU VPN réduisant les performances,
• Serveurs dispatchés un peu partout: Scaleway, OVH, dédiés Online, etc,
• Le provisioning des nouvelles machines se fait toujours manuellement, provoquant erreurs et incohérences,
• Gestion des clés SSH et TOTP devenue difficile (plus d’une trentaine de clés à gérer),
• Le serveur agrégateur à refaire (actuellement dans un cloud Scaleway avec leur horrible NAT),
• Pas de redondance des serveurs applicatifs et des liens VPN,
• Problèmes de connectivité avec les serveurs fonctionnant en dual-stack IPv4 et IPv6 sur certains points du réseau,
• Manque de documentation,
• etc.

Jusqu’à présent la mise en place d’une telle infrastructure relevait surtout du bricolage et de l’expérimentation. Je suis qu’un étudiant après tout ! Avec l’arrivée prochaine du projet Netisys (d’où le « BGP router » sur le schéma), il m’a paru urgent de tout remettre à plat avant.

Le projet

Le projet consistera en la mise en place de nouvelles solutions, et en l’actualisation des solutions déjà en place. Ce projet étant assez conséquent, je vais procéder en plusieurs étapes afin de ne pas tout bousculer. Chaque grosse étape fera l’objet d’un article à part. Un nouveau schéma de topologie viendra par la suite. Voici notamment la liste des tâches à faire (liste non exhaustive).

Nouveautés

• Achat d’un nom de domaine spécifique à usage interne en lieu et place de « int.pingex.net » (trop long). Il servira pour tous mes services fonctionnant en interne chez moi,
• Une solution de gestion des IP (IPAM),
• Un wiki à usage interne afin de documenter l’infrastructure,
• Création d’un LDAP et royaume Kerberos au travers de la solution FreeIPA. Ceci permettra d’unifier l’accès à mes serveurs et applications au travers d’un seul login/mot de passe et d’un système de permissions,
• Playbook Ansible pour le provisioning rapide et consistent de nouveaux hôtes et machines virtuelles,
• Système de monitoring (Nagios/Icinga) et de graphing (stack TIG),
• Liens VPN redondants,
• Mise en redondance des services « core »: MySQL, LDAP, etc,
• Utilisation plus conséquente de serveurs Proxmox,
• Service central de certificats Let’s Encrypt (à développer),
• Gestion centralisée des clés SSH (au cas où l’IPA venait à tomber).

Mises à jour

• Réfection des DNS:
  • Utilisation d’un nouveau serveur autoritaire: PowerDNS,
  • Permettre la gestion des DNS avec l’IPAM,
  • Meilleure gestion des DDNS,
  • Séparation des serveurs autoritaires et récursifs.
• Changement de convention de nommage des serveurs,
• Réattribution des VLAN @ home, nettoyage et ajouts,
• Réfection des configuration des liens VPN OpenVPN et tinc, ajustement des MTU, etc,
• Changement du protocole de routage RIP par OSPF afin de pouvoir mieux supporter les liens redondants,
• Réinstallation du serveur agrégateur,
• Remplacement du routeur domestique par un barebone avec pfSense,
• Mises à jour et remplacement des applications (ownCloud, Gitlab, etc).

A retirer

• L’ancien système de monitoring basée sur Munin,
• Les machines virtuelles toujours en fonctionnement sur le cloud Scaleway.

Pourquoi tout cela ?

L’utilisateur lambda qui vient me lire pourrait se demander pourquoi je m’amuse à faire tout cela, alors qu’on peut simplement avoir une Livebox chez soi, et quelques VM avec un mot de passe simple chez OVH, le tout passant toujours par le réseau public. Pourquoi faire compliqué lorsqu’on peut faire simple ? Je comprends tout à fait ce point de vue, mais permettez-moi de faire la lumière sur mes motivations.

Tout d’abord, je fais cela par intérêt personnel. Expérimenter et mettre en place des solutions d’entreprise (homelab) permet d’obtenir pas mal d’expérience par la suite. Donc le jour où vous serez face à un véritable environnement d’entreprise, vous aurez déjà les outils et connaissances pour faire face à ce qui peut typiquement se présenter dans ce type d’environnement (LDAP, VLAN, etc.).

Ensuite, monter ce type d’infrastructure me permet d’augmenter la sécurité globale du réseau. Par exemple, les métriques des machines (SNMP, etc) remontent systématiquement par VPN et ne transitent pas par un réseau public où il est potentiellement possible d’intercepter et analyser les données. A terme, tout ce qui est possible de faire transiter par VPN le sera. De plus, l’utilisation d’un LDAP me permet de mieux identifier les utilisateurs au travers de tout le réseau, en plus de fournir des facilités d’authentification. Je peux également attribuer des permissions en fonction de la personne, etc. De même l’utilisation des VLAN permet de donner accès à internet à des invités, sans devoir compromettre sur la sécurité.

Ou bien pour simplement répondre à la question du « Pourquoi ? »: pourquoi pas ? tout simplement.