Metodo di ristrutturazione della rete per la rete Double-NAT

A causa di una serie di decisioni sbagliate sulla progettazione della rete (principalmente) prese molti anni fa al fine di risparmiare qualche soldo qua e là, ho una rete decisamente subottimamente progettata. Sto cercando suggerimenti per migliorare questa situazione poco piacevole.

Siamo un'organizzazione no profit con un reparto IT basato su Linux e un budget limitato. (Nota: nessuna delle apparecchiature Windows che abbiamo in esecuzione fa qualcosa che parla a Internet né abbiamo amministratori di Windows sul personale.)

Punti chiave:

• Abbiamo un ufficio principale e circa 12 siti remoti che essenzialmente raddoppiano il NAT delle loro sottoreti con switch fisicamente separati. (Nessuna VLAN e capacità limitata di farlo con gli switch correnti)
• Queste posizioni hanno una sottorete "DMZ" che sono NAT su una sottorete 10.0.0 / 24 assegnata in modo identico in ciascun sito. Queste sottoreti non possono comunicare con DMZ in nessun'altra posizione perché non le instradiamo da nessuna parte tranne che tra il server e il "firewall" adiacente.
• Alcune di queste posizioni hanno più connessioni ISP (T1, via cavo e / o DSL) che instradiamo manualmente utilizzando Strumenti IP in Linux. Questi firewall funzionano tutti sulla rete (10.0.0 / 24) e sono per lo più firewall di livello "pro-sumer" (Linksys, Netgear, ecc.) O modem DSL forniti dall'ISP.
• La connessione di questi firewall (tramite semplici switch non gestiti) è uno o più server che devono essere accessibili pubblicamente.
• Alla sottorete 10.0.0 / 24 dell'ufficio principale sono collegati server per e-mail, VPN per telelavoratore, server VPN per ufficio remoto, router primario alle sottoreti interne 192.168 / 24. Questi devono essere l'accesso da specifiche connessioni ISP in base al tipo di traffico e alla fonte di connessione.
• Tutto il nostro routing viene eseguito manualmente o con le istruzioni di route OpenVPN
• Il traffico tra gli uffici passa attraverso il servizio OpenVPN nel server principale "Router" che ha il proprio NAT coinvolto.
• Nei siti remoti è installato un solo server in ciascun sito e non possono permettersi più server a causa di vincoli di budget. Questi server sono tutti server LTSP con diversi terminali 5-20.
• Le sottoreti 192.168.2 / 24 e 192.168.3 / 24 si trovano principalmente, ma NON interamente, su switch Cisco 2960 che possono eseguire VLAN. Il resto sono switch DLink DGS-1248 di cui non sono sicuro di fidarmi abbastanza bene da utilizzare con le VLAN. Esistono anche alcune preoccupazioni interne rimanenti sulle VLAN poiché solo il personale di rete senior capisce come funziona.

Tutto il traffico Internet regolare passa attraverso il server router CentOS 5 che a sua volta NAT porta le sottoreti 192.168 / 24 alle sottoreti 10.0.0.0/24 secondo le regole di routing configurate manualmente che utilizziamo per indirizzare il traffico in uscita verso la corretta connessione Internet in base a Istruzioni di routing '-host'.

Voglio semplificare questa situazione e preparare la virtualizzazione di All Of The Things per ESXi, compresi questi servizi rivolti al pubblico. Esiste una soluzione a basso costo o che eliminerebbe il doppio NAT e ripristinerebbe un po 'di sanità mentale in questo pasticcio in modo che la mia futura sostituzione non mi dia la caccia?

Diagramma di base per l'ufficio principale:

Questi sono i miei obiettivi:

• Server rivolti al pubblico con interfacce su quella rete 10.0.0 / 24 centrale da spostare nella sottorete 192.168.2 / 24 sui server ESXi.
• Sbarazzati del doppio NAT e metti tutta la nostra rete su un'unica sottorete. La mia comprensione è che questo è qualcosa che dovremo fare comunque sotto IPv6, ma penso che questo pasticcio si frapponga.

1.) Prima di tutto, qualsiasi altra cosa chiarisce il tuo piano di indirizzamento IP. È doloroso rinumerare ma è il passo necessario per arrivare a un'infrastruttura praticabile. Metti da parte superneti di grandi dimensioni, facilmente riassumibili per workstation, server, siti remoti (con IP unici, naturalmente), reti di gestione, loopback, ecc. C'è molto spazio RFC1918 e il prezzo è giusto.

2.) È difficile avere un'idea di come disporre L2 nella rete in base al diagramma sopra. Le VLAN potrebbero non essere necessarie se si dispone di un numero sufficiente di interfacce nei vari gateway e di un numero sufficiente di switch. Una volta che hai il n. 1, potrebbe avere senso riavviare la domanda L2 separatamente. Detto questo, le VLAN non sono un insieme di tecnologie particolarmente complesse o innovative e non devono essere così complicate. È necessaria una certa quantità di addestramento di base, ma almeno la possibilità di separare uno switch standard in diversi gruppi di porte (ovvero senza trunking) può far risparmiare parecchi soldi.

3.) Gli host DMZ dovrebbero probabilmente essere collocati sulle proprie reti L2 / L3, non unite con le stazioni di lavoro. Idealmente, i router di frontiera dovrebbero essere collegati a un dispositivo L3 (un altro set di router? Switch L3?) Che, a sua volta, collegherebbe una rete contenente le interfacce del server rivolte verso l'esterno (host SMTP, ecc.). È probabile che questi host si riconnettano a una rete distinta o (in modo meno ottimale) a una sottorete del server comune. Se hai disposto le tue sottoreti in modo appropriato, i percorsi statici necessari per indirizzare il traffico in entrata dovrebbero essere molto semplici.

3a.) Cerca di mantenere le reti VPN separate dagli altri servizi in entrata. Ciò renderà le cose più facili per quanto riguarda il monitoraggio della sicurezza, la risoluzione dei problemi, la contabilità, ecc.

4.) A corto di consolidare le tue connessioni Internet e / o instradare una singola sottorete tramite più corrieri (leggi: BGP) avrai bisogno dell'hop intermedio prima dei tuoi router di frontiera per essere in grado di reindirizzare il traffico in entrata e in uscita in modo appropriato (come Ho il sospetto che tu lo stia facendo al momento). Sembra un mal di testa maggiore di quello della VLAN, ma suppongo sia tutto relativo.