Coûts, sécurité et performances dans un réseau informatique.
Introduction
L’objectif de cette étude de cas est de montrer qu’en apportant quelques modifications simples à l’architecture réseau d’une infrastructure, on peut renforcer la sécurité, éviter des investissements matériels inutiles et optimiser les performances globales de son infrastructure informatique.
Postulat de départ
Pour notre étude, partons d’une architecture simple :
- un campus avec plusieurs VLAN utilisateurs,
- un Datacenter hors-site avec plusieurs VLANs machines,
- une ligne louée reliant les deux,
- un cluster de Firewall sur le Datacenter pour la sortie Internet,
- des cœurs de réseau qui assurent le routage.
L’ensemble des VLAN sont routés sur les cœurs de réseau par souci de simplicité. La route par défaut des cœurs pointe vers les firewalls, hébergés dans le Datacenter.
Problème 1 - L'utilisation de la ligne louée
Commençons par notre problème de performance.
Un flux entre deux machines hébergées dans le Datacenter, chacune dans un VLAN différent, traverse… quatre fois la ligne louée. Oui, quatre.
Pourquoi ? Parce que ces machines ne sont pas dans le même VLAN, elles nécessitent donc un routage. Et ce routage dans notre architecture, s’effectue sur le campus (sur les cœurs de réseau).
Prenons un exemple concret d’une machine A qui envoie son trafic à la machine B, les deux machines sont situées dans le même Datacenter mais dans deux VLANs distincts:
- Machine A envoie son trafic vers sa gateway (les cœurs de réseau) car machine B n’est pas dans le même sous-réseau → la ligne louée est traversée une première fois pour rejoindre le campus.
- Les cœurs de réseau routent le paquet vers la machine B → la ligne louée est traversée une second fois pour retourner au Datacenter.
- Machine B répond et envoie son paquet vers sa gateway → troisième traversée.
- Les cœurs de réseau renvoient le paquet routé vers machine A → quatrième traversée.
Résultat : pour une communication entre deux serveurs du même Datacenter mais dans deux VLAN différents, votre flux traverse 4 fois votre ligne louée.
« Peut mieux faire » vous ne pensez pas ?
Problème 2 - La sécurité
Autre souci (et pas des moindres) : la sécurité.
Aucun flux n’est filtré entre les utilisateurs du campus et les serveurs du Datacenter. Les utilisateurs ont un accès illimité aux ressources du Datacenter et inversement. La seule sécurité réside dans le Firewall pour sortir sur Internet.
À moins de prendre un malin plaisir à maintenir des ACL sur les switches — stateless, bien sûr, donc avec autorisations entrantes et sortantes — la situation est loin d’être idéale pour la sécurité.
Solution 1 - Le firewall à la rescousse
La solution évidente, en théorie, serait donc : firewaller !
— « Le firewall est dans le Datacenter ; routons les VLAN dessus et tout reste local.«
Oui… mais non. Premièrement on ne fait qu’inverser le problème en routant le Campus cette fois sur le Datacenter. Tous les flux entre deux utilisateurs de deux VLANs distincts devront eux aussi traverser 4 fois votre ligne louée. On retrouve notre problème de performance initial que l’on va empirer si nous faisons rentrer dans l’équation les flux de backup.
Je vous laisse imaginer vos VLAN de backup routés via le firewall, vos réplications Veeam qui tirent plusieurs Gb/s, le tout saupoudré de SSL inspection parce que “c’est activé par défaut”… Vous me direz en combien de minutes vos firewall s’effondrent, et par conséquent le reste de l’infrastructure.
— « Pas grave, j’achète un plus gros firewall ! La sécurité ça n’a pas de prix ! »
C’est en effet une solution qui plaira beaucoup à votre partenaire IT mais beaucoup moins à votre CFO.
Encore une fois : « Peut mieux faire »…
Solution 2 - La vraie cette fois
Les VRF.
Les « Virtual Routing and Forwarding » sont des contextes de routage virtuels. Elles sont à la couche 3 ce que les VLAN sont à la couche 2 : de la virtualisation, tout simplement. Les VLAN évitent d’acheter un switch pour chaque type d’équipement. Les VRF évitent d’acheter un routeur pour chaque zone (Campus, Datacenter, DMZ…).
On va donc créer des VRF pour répondre à nos problèmes (et faire plaisir à notre CFO et à notre CISO en même temps) :
- Une VRF Datacenter sur les switches du Datacenter,
- Une VRF Campus sur les cœurs de réseau.
On place dans la VRF Datacenter tous les VLAN du Datacenter: ainsi, le routage inter-VLAN reste local au Datacenter. Pour sortir du Datacenter, on crée un VLAN d’interconnexion entre cette VRF et le firewall, avec une route par défaut qui pointe vers celui-ci. Sur le Firewall, on ajoute une route pour lui indiquer que nos VLANs Datacenter sont joignables à travers ce VLAN d’interconnexion. Même logique côté campus, et… bingo !
- Plus besoin d’un firewall capable d’absorber 10 fois la table BGP d’Internet (coûts ↘),
- Les flux Campus ↔ Datacenter passent enfin par le firewall (sécurité ↗️)
- Les flux Campus ↔ Campus restent locaux au Campus (performances ↗️),
- Les flux Datacenter ↔ Datacenter restent locaux au Datacenter (performances ↗️),
- Plus d’allers-retours inutiles sur la ligne louée : moins de latence, et potentiellement réduction des coûts selon le modèle de facturation (performances ↗️ et coûts ↘)
Conclusion
En utilisant intelligemment les VRF, nous avons réussi à améliorer les performances au sein de notre Datacenter, nous avons renforcé la sécurité de l’infrastructure, et tout cela sans investir dans du matériel plus performant.
Take-away
L’architecture décrite en préambule est classique. On la trouve encore dans de nombreuses entreprises qui ont grandi, mais n’ont pas été correctement accompagner par leur prestataire informatique pour suivre cette évolution.
Avant d’investir dans du matériel plus performant, ou d’augmenter la bande passante de votre ligne, contactez-nous : nous irons au bout de ce que peut faire votre infrastructure, avant de vous conseiller d’en changer.
Contactez-nous pour faire le point sur votre infrastructure.
Suivez-nous sur LinkedIn pour ne pas manquer nos prochains articles.