Método de reestruturação de rede para rede com NAT duplo

Devido a uma série de más decisões de design de rede (na maioria) tomadas há muitos anos para economizar alguns dólares aqui e ali, eu tenho uma rede que é decididamente arquitetada de maneira subótima. Estou procurando sugestões para melhorar essa situação menos do que agradável.

Somos uma organização sem fins lucrativos, com um departamento de TI baseado em Linux e um orçamento limitado. (Observação: nenhum dos equipamentos Windows que temos em execução faz nada que fale com a Internet nem temos administradores do Windows na equipe.)

Pontos chave:

• Temos um escritório principal e cerca de 12 sites remotos que essencialmente duplicam suas sub-redes NAT com switches fisicamente segregados. (Sem VLAN e capacidade limitada de fazê-lo com os switches atuais)
• Esses locais têm uma sub-rede "DMZ" que é NAT em uma sub-rede 10.0.0 / 24 atribuída de forma idêntica em cada site. Essas sub-redes não podem falar com DMZs em nenhum outro local, porque não as roteamos para lugar nenhum, exceto entre o servidor e o "firewall" adjacente.
• Alguns desses locais têm várias conexões ISP (T1, Cabo e / ou DSLs) que roteamos manualmente usando as Ferramentas IP no Linux. Todos esses firewalls são executados na rede (10.0.0 / 24) e são na maioria firewalls "pro-sumer" (Linksys, Netgear etc.) ou modems DSL fornecidos pelo ISP.
• A conexão desses firewalls (por meio de comutadores não gerenciados simples) é um ou mais servidores que devem estar acessíveis ao público.
• Conectados à sub-rede 10.0.0 / 24 do escritório principal, estão servidores para email, VPN de tele-comutador, servidor VPN de escritório remoto, roteador principal para as sub-redes 192.168 / 24 internas. Eles devem ter acesso a partir de conexões ISP específicas, com base no tipo de tráfego e na origem da conexão.
• Todo o nosso roteamento é feito manualmente ou com instruções de rota OpenVPN
• O tráfego entre escritórios passa pelo serviço OpenVPN no servidor principal 'Router', que possui seu próprio NAT envolvido.
• Os sites remotos têm apenas um servidor instalado em cada site e não podem pagar por vários servidores devido a restrições de orçamento. Esses servidores são todos os servidores LTSP, de 5 a 20 terminais.
• As sub-redes 192.168.2 / 24 e 192.168.3 / 24 são principalmente, mas NÃO inteiramente, nos switches Cisco 2960 que podem executar VLAN. O restante são comutadores DLink DGS-1248 nos quais não tenho certeza se confio o suficiente para usar com VLANs. Também há alguma preocupação interna remanescente sobre as VLANs, pois apenas a equipe sênior de rede entende como isso funciona.

Todo o tráfego regular da Internet passa pelo servidor do roteador CentOS 5, que transforma NATs nas sub-redes 192.168 / 24 nas sub-redes 10.0.0.0/24, de acordo com as regras de roteamento configuradas manualmente que usamos para apontar o tráfego de saída para a conexão adequada à Internet com base em Instruções de roteamento '-host'.

Quero simplificar isso e preparar a virtualização All Of The Things para ESXi, incluindo esses serviços públicos. Existe uma solução de baixo ou nenhum custo que se livraria do Double-NAT e restauraria um pouco de sanidade nessa bagunça, para que minha futura substituição não me caçasse?

Diagrama básico para o escritório principal:

Estes são meus objetivos:

• Servidores voltados para o público com interfaces na rede 10.0.0 / 24 do meio a serem movidos para a sub-rede 192.168.2 / 24 nos servidores ESXi.
• Livre-se do NAT duplo e obtenha toda a nossa rede em uma única sub-rede. Meu entendimento é que isso é algo que precisamos fazer no IPv6 de qualquer maneira, mas acho que essa bagunça está no caminho.

1.) Antes de qualquer outra coisa, conserte seu plano de endereçamento IP. É doloroso renumerar, mas é o passo necessário para chegar a uma infraestrutura viável. Separe super-redes confortavelmente grandes e facilmente resumidas para estações de trabalho, servidores, sites remotos (com IPs únicos, naturalmente), redes de gerenciamento, loopbacks, etc. Há muito espaço RFC1918 e o preço é justo.

2.) É difícil ter uma noção de como distribuir L2 na sua rede com base no diagrama acima. As VLANs podem não ser necessárias se você tiver um número suficiente de interfaces em seus vários gateways, bem como um número suficiente de comutadores. Uma vez que você tenha uma noção do número 1, pode fazer sentido reaproximar a pergunta L2 separadamente. Dito isto, as VLANs não são um conjunto de tecnologias especialmente complexo ou novo e não precisam ser tão complicadas. Uma certa quantidade de treinamento básico está em ordem, mas, no mínimo, a capacidade de separar um switch padrão em vários grupos de portas (ou seja, sem entroncamento) pode economizar muito dinheiro.

3.) Os hosts DMZ provavelmente devem ser colocados em suas próprias redes L2 / L3, não mescladas com as estações de trabalho. Idealmente, você teria seus roteadores de borda conectados a um dispositivo L3 (outro conjunto de roteadores? Switch L3?) Que, por sua vez, conectaria uma rede contendo suas interfaces de servidor voltadas para o exterior (host SMTP, etc.). Esses hosts provavelmente se conectariam novamente a uma rede distinta ou (menos otimizada) a uma sub-rede de servidor comum. Se você organizou suas sub-redes adequadamente, as rotas estáticas necessárias para direcionar o tráfego de entrada devem ser muito simples.

3a.) Tente manter as redes VPN separadas de outros serviços de entrada. Isso facilitará as coisas, como monitoramento de segurança, solução de problemas, contabilidade etc.

4.) Antes de consolidar suas conexões com a Internet e / ou rotear uma única sub-rede através de várias operadoras (leia-se: BGP), você precisará do salto intermediário antes dos roteadores de borda para poder redirecionar o tráfego de entrada e saída adequadamente (como Eu suspeito que você está fazendo no momento). Parece uma dor de cabeça maior que a da VLAN, mas suponho que seja tudo relativo.