Je suis en train de réviser notre réseau, le problème auquel je reviens toujours est: essayer d'amener la couche 3 au cœur, tout en ayant un pare-feu centralisé.
Le principal problème que j'ai ici est que les commutateurs «mini-cœur» que j'ai examinés ont toujours de faibles limites ACL dans le matériel, que même à notre taille actuelle, nous pourrions rapidement atteindre. Je suis actuellement sur le point d'acheter (espérons-le) une paire d'EX4300-32F pour le noyau, mais j'ai examiné d'autres modèles et d'autres options de la gamme ICX de Juniper et Brocade. Ils semblent tous avoir les mêmes limites ACL basses.
Cela est parfaitement logique car les commutateurs principaux doivent être en mesure de maintenir le routage à vitesse filaire, donc ne voulez pas trop sacrifier le traitement ACL. Je ne peux donc pas faire tout mon pare-feu sur les commutateurs principaux eux-mêmes.
Cependant, nous faisons surtout des serveurs entièrement gérés, et avoir un pare-feu centralisé (avec état) aide beaucoup à cette gestion - car nous ne pouvons pas laisser les clients parler directement entre eux. Je voudrais que cela reste le cas si nous le pouvons, mais j'ai l'impression que la plupart des réseaux ISP ne feraient pas ce genre de chose, d'où pourquoi dans la plupart des cas, il serait simple de faire le routage dans le cœur.
Pour référence, voici la topologie que j'aimerais idéalement faire (mais je ne sais pas où installer le FW évidemment).
Solution actuelle
À l'heure actuelle, nous avons une configuration de routeur sur un bâton. Cela nous permet de faire du NAT, du pare-feu avec état et du routage VLAN tout au même endroit. Très simple.
Je pourrais continuer avec (à peu près) la même solution en étendant L2 jusqu'au «sommet» de notre réseau - les routeurs frontaliers. Mais je perds alors tous les avantages du routage à vitesse filaire que le cœur peut m'offrir.
IIRC les commutateurs principaux peuvent faire 464 Gbps de routage tandis que mes routeurs frontaliers pourront offrir peut-être 10 ou 20 Gbps si j'ai de la chance. Ce n'est pas techniquement un problème en ce moment, mais plutôt un problème de croissance. J'ai l'impression que si nous ne concevons pas l'architecture pour tirer parti de la capacité de routage principale maintenant, il sera difficile de tout refaire lorsque nous serons plus grands et que nous devons tirer parti de cette capacité. Je préfère bien faire les choses la première fois.
Solutions possibles
Couche 3 pour accéder
J'ai pensé que je pourrais peut-être étendre L3 aux commutateurs d'accès, et ainsi diviser les règles de pare-feu en segments plus petits qui correspondraient alors aux limites matérielles des ACL des commutateurs d'accès. Mais:
- Pour autant que je sache, ce ne seraient pas des ACL avec état
- La L3 à Access, pour moi, semble beaucoup plus rigide. Les mouvements de serveur ou les migrations de VM vers d'autres armoires seraient plus douloureux.
- Si je veux gérer un pare-feu en haut de chaque rack (seulement six d'entre eux), je veux probablement une automatisation de toute façon. À ce stade, il ne s'agit donc pas d'un bond en avant pour automatiser la gestion des pare-feu au niveau de l'hôte. Évitant ainsi tout le problème.
Pare-feu pontés / transparents sur chaque liaison montante entre accès / cœur
Cela devrait impliquer plusieurs boîtes de pare-feu et augmenter considérablement le matériel requis. Et pourrait finir par coûter plus cher que d'acheter de plus gros routeurs de base, même en utilisant de vieilles boîtes Linux simples comme pare-feu.
Routeurs de base géants
Pourrait acheter un appareil plus grand qui peut faire le pare-feu dont j'ai besoin et a une capacité de routage beaucoup plus grande. Mais je n'ai vraiment pas de budget pour cela, et si j'essaie de faire faire à un appareil quelque chose pour lequel il n'est pas conçu, je devrai probablement aller à une spécification beaucoup plus élevée. que je ne le ferais autrement.
Pas de pare-feu centralisé
Puisque je saute à travers des cerceaux, cela ne vaut peut-être pas la peine. Cela a toujours été une bonne chose d'avoir, et parfois un argument de vente pour les clients qui veulent un pare-feu "matériel".
Mais il semble qu'avoir un pare-feu centralisé pour l'ensemble de votre réseau est irréalisable. Je me demande, alors, comment les plus grands FAI peuvent offrir des solutions de pare-feu matériel aux clients avec des serveurs dédiés, alors qu'ils ont des centaines voire des milliers d'hôtes?
Quelqu'un peut-il penser à un moyen de résoudre ce problème? Soit quelque chose que j'ai complètement raté, soit une variation sur l'une des idées ci-dessus?
MISE À JOUR 2014-06-16:
Sur la base de la suggestion de @ Ron, je suis tombé sur cet article qui explique assez bien le problème auquel je suis confronté et un bon moyen de résoudre le problème.
À moins qu'il n'y ait d'autres suggestions, je dirais que c'est maintenant un type de problème de recommandation de produit, donc je suppose que c'est la fin.
http://it20.info/2011/03/the-93-000-firewall-rules-problem-and-why-cloud-is-not-just-orchestration/