Método de Reestruturação de Rede para rede Double-NAT

Question

Devido a uma série de más decisões de design de rede (principalmente) feitas muitos anos atrás para economizar alguns dólares aqui e ali, eu tenho uma rede que é decididamente arquitetada de maneira insuficiente. 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. (Nota: Nenhum dos equipamentos Windows que temos executa faz qualquer coisa que fale com a Internet nem temos administradores do Windows na equipe.)

Pontos principais:

• Temos um escritório principal e cerca de 12 sites remotos que essencialmente duplicam NAT suas sub-redes com comutadores separados fisicamente. (Não VLAN e capacidade limitada de fazer isso com switches atuais)
• Esses locais têm uma sub-rede "DMZ" que é NAT em um identicamente 10.0.0 / 24 sub-redes atribuídas em cada site. Essas sub-redes não podem falar com DMZs em qualquer outro local porque não os encaminhamos para nenhum lugar exceto entre servidor e "firewall" adjacente.
• Alguns desses locais têm várias conexões ISP (T1, Cabo e / ou DSLs) que nós roteamos manualmente usando o IP Tools no Linux. Esses firewalls são todos executados na rede (10.0.0 / 24) e são na sua maioria firewalls de grau "pro-sumer" (Linksys, Netgear, etc.) ou modems DSL fornecidos pelo ISP.
• A conexão desses firewalls (por meio de switches simples não gerenciados) é um ou mais servidores que devem ser publicamente acessíveis.
• Conectados à sub-rede 10.0.0 / 24 da matriz, há servidores para e-mail, VPN de telecomputador, servidor VPN de escritório remoto, roteador principal para as sub-redes 192.168 / 24 internas. Eles precisam ser acessados por 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 do OpenVPN
• O tráfego entre escritórios passa pelo serviço OpenVPN no servidor principal "Roteador", que tem seu próprio NAT envolvido.
• Os sites remotos têm apenas um servidor instalado em cada site e não podem pagar vários servidores devido a restrições orçamentárias. Esses servidores são todos os servidores LTSP com 5 a 20 terminais.
• As sub-redes 192.168.2 / 24 e 192.168.3 / 24 são principalmente, mas não inteiramente, de switches Cisco 2960 que podem fazer VLAN. O restante são switches DLink DGS-1248 que não tenho certeza se confio bem o suficiente para usar com VLANs. Há também alguma preocupação interna remanescente sobre as VLANs, já que apenas a pessoa da equipe sênior de rede entende como ela funciona.

Todo o tráfego normal da Internet passa pelo servidor do roteador do CentOS 5, que transforma as 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 direcionar o tráfego de saída para a Internet correta. conexão baseada em instruções de roteamento '-host'.

Eu quero simplificar isso e preparar a virtualização All Of The Things para ESXi, incluindo esses serviços voltados para o público. Existe uma solução de baixo custo que se livra do Double-NAT e restaura um pouco de sanidade a esta bagunça para que meu futuro substituto não me derrube?

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 intermediária a serem movidas 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 precisaremos fazer no IPv6, mas acho que essa bagunça está no caminho.

Answer 1

1.) Antes de basicamente qualquer outra coisa, endireite seu plano de endereçamento IP. É doloroso renumerar, mas é o passo necessário para chegar a uma infraestrutura viável. Separe supernets confortavelmente grandes e facilmente resumidos 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 configurar o 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 switches. Uma vez que você tenha uma noção de # 1, pode fazer sentido reaproximar a questão da L2 separadamente. Dito isso, 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 é necessária, 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 mesclados com estações de trabalho. Idealmente, você teria seus roteadores de borda conectados a um dispositivo L3 (outro conjunto de roteadores? L3 switch?) Que, por sua vez, conectaria uma rede contendo suas interfaces de servidor externas (host SMTP etc.). Esses hosts provavelmente se conectarão a uma rede distinta ou (menos idealmente) a uma sub-rede de servidor comum. Se você definiu 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 quanto ao monitoramento de segurança, solução de problemas, contabilidade, etc.

4) Falta 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 que os roteadores de borda possam redirecionar o tráfego de entrada e saída apropriadamente (como eu suspeito que você esteja fazendo no momento). Isso parece ser uma dor de cabeça maior do que a da VLAN, mas suponho que seja tudo relativo.