Méthode de restructuration du réseau pour le réseau Double-NAT

En raison d'une série de mauvaises décisions de conception de réseau (principalement) prises il y a plusieurs années afin d'économiser quelques dollars ici et là, j'ai un réseau qui est décidément sous-optimisé. Je cherche des suggestions pour améliorer cette situation moins qu'agréable.

Nous sommes un organisme sans but lucratif avec un service informatique basé sur Linux et un budget limité. (Remarque: aucun des équipements Windows que nous avons ne fait quoi que ce soit qui parle à Internet ni aucun administrateur Windows au sein du personnel.)

Points clés:

• Nous avons un bureau principal et environ 12 sites distants qui doublent essentiellement NAT leurs sous-réseaux avec des commutateurs physiquement séparés. (Pas de VLAN et capacité limitée à le faire avec les commutateurs actuels)
• Ces emplacements ont un sous-réseau "DMZ" qui est NAT sur un sous-réseau 10.0.0 / 24 attribué de manière identique sur chaque site. Ces sous-réseaux ne peuvent pas communiquer avec les zones démilitarisées à tout autre endroit car nous ne les acheminons nulle part sauf entre le serveur et le "pare-feu" adjacent.
• Certains de ces emplacements ont plusieurs connexions FAI (T1, câble et / ou DSL) que nous acheminons manuellement à l'aide des outils IP sous Linux. Ces pare-feu fonctionnent tous sur le réseau (10.0.0 / 24) et sont pour la plupart des pare-feu de qualité «pro-consommateur» (Linksys, Netgear, etc.) ou des modems DSL fournis par les FAI.
• La connexion de ces pare-feu (via de simples commutateurs non gérés) est un ou plusieurs serveurs qui doivent être accessibles au public.
• Les serveurs de messagerie électronique, le VPN de télétravail, le serveur VPN de bureau distant, le routeur principal des sous-réseaux internes 192.168 / 24 sont connectés au sous-réseau 10.0.0 / 24 du bureau principal. Ceux-ci doivent être accessibles à partir de connexions FAI spécifiques en fonction du type de trafic et de la source de connexion.
• Tout notre routage se fait manuellement ou avec des instructions de route OpenVPN
• Le trafic inter-bureaux passe par le service OpenVPN dans le serveur principal «Router» qui a son propre NAT impliqué.
• Les sites distants n'ont qu'un seul serveur installé sur chaque site et ne peuvent pas se permettre plusieurs serveurs en raison de contraintes budgétaires. Ces serveurs sont tous des serveurs LTSP plusieurs terminaux 5-20.
• Les sous-réseaux 192.168.2 / 24 et 192.168.3 / 24 sont principalement mais PAS entièrement sur les commutateurs Cisco 2960 qui peuvent faire du VLAN. Les autres sont des commutateurs DLink DGS-1248 que je ne suis pas sûr de faire assez confiance pour utiliser avec des VLAN. Il existe également une certaine inquiétude interne concernant les réseaux locaux virtuels, car seul le cadre supérieur du réseau sait comment cela fonctionne.

Tout le trafic Internet régulier passe par le serveur de routeur CentOS 5 qui transforme à son tour les sous-réseaux 192.168 / 24 en sous-réseaux 10.0.0.0/24 conformément aux règles de routage configurées manuellement que nous utilisons pour pointer le trafic sortant vers la connexion Internet appropriée en fonction de des instructions de routage '-host'.

Je veux simplifier cela et préparer All Of The Things pour la virtualisation ESXi, y compris ces services accessibles au public. Existe-t-il une solution gratuite ou à faible coût qui éliminerait le Double-NAT et redonnerait un peu de raison à ce gâchis afin que mon futur remplaçant ne me traque pas?

Diagramme de base pour le bureau principal:

Ce sont mes objectifs:

• Serveurs accessibles au public avec des interfaces sur ce réseau 10.0.0 / 24 intermédiaire à déplacer vers le sous-réseau 192.168.2 / 24 sur les serveurs ESXi.
• Débarrassez-vous du double NAT et obtenez tout notre réseau sur un seul sous-réseau. Je crois comprendre que c'est quelque chose que nous devrons faire sous IPv6 de toute façon, mais je pense que ce gâchis fait obstacle.

1.) Avant tout autre chose, redressez votre plan d'adressage IP. Il est difficile de renuméroter, mais c'est l'étape nécessaire pour arriver à une infrastructure viable. Mettez de côté des supernets confortablement grands et facilement résumés pour les postes de travail, les serveurs, les sites distants (avec des IP uniques, naturellement), les réseaux de gestion, les bouclages, etc. Il y a beaucoup d'espace RFC1918 et le prix est correct.

2.) Il est difficile d'avoir une idée de la disposition de L2 dans votre réseau sur la base du diagramme ci-dessus. Les VLAN peuvent ne pas être nécessaires si vous disposez d'un nombre suffisant d'interfaces dans vos différentes passerelles ainsi que d'un nombre suffisant de commutateurs. Une fois que vous avez le sens du n ° 1, il peut être judicieux de ré-aborder la question L2 séparément. Cela dit, les VLAN ne sont pas un ensemble de technologies particulièrement complexe ou nouveau et ne doivent pas être si compliqués. Une certaine quantité de formation de base est en règle, mais au minimum, la possibilité de séparer un commutateur standard en plusieurs groupes de ports (c'est-à-dire sans jonction) peut économiser beaucoup d'argent.

3.) Les hôtes DMZ devraient probablement être placés sur leurs propres réseaux L2 / L3, et non fusionnés avec des postes de travail. Idéalement, vos routeurs frontaliers devraient être connectés à un périphérique L3 (un autre ensemble de routeurs? Commutateur L3?) Qui, à son tour, connecterait un réseau contenant vos interfaces de serveur externes (hôte SMTP, etc.). Ces hôtes se connecteraient probablement à un réseau distinct ou (de manière moins optimale) à un sous-réseau de serveur commun. Si vous avez correctement configuré vos sous-réseaux, les itinéraires statiques requis pour diriger le trafic entrant devraient être très simples.

3a.) Essayez de garder les réseaux VPN séparés des autres services entrants. Cela facilitera les choses en ce qui concerne la surveillance de la sécurité, le dépannage, la comptabilité, etc.

4.) À moins de consolider vos connexions Internet et / ou d'acheminer un seul sous-réseau via plusieurs opérateurs (lire: BGP), vous aurez besoin du saut intermédiaire avant que vos routeurs frontaliers soient en mesure de rediriger le trafic entrant et sortant de manière appropriée (comme Je soupçonne que vous faites pour le moment). Cela semble être un mal de tête plus important que celui des VLAN, mais je suppose que tout est relatif.