{"id":30009,"date":"2019-10-31T21:33:10","date_gmt":"2019-10-31T18:33:10","guid":{"rendered":"https:\/\/prohoster.info\/blog\/vmware-nsx-dlya-samyh-malenkih-chast-1\/"},"modified":"2019-10-31T21:33:10","modified_gmt":"2019-10-31T18:33:10","slug":"vmware-nsx-dlya-samyh-malenkih-chast-1","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/vmware-nsx-dlya-samyh-malenkih-chast-1","title":{"rendered":"VMware NSX per i pi\u00f9 piccoli. Parte 1","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"VMware
\n
\nSe guardiamo la configurazione di qualsiasi firewall, vedremo probabilmente un elenco di indirizzi IP, porte, protocolli e sottoreti. Questo \u00e8 il modo classico in cui vengono implementate le politiche di sicurezza di rete per l'accesso degli utenti alle risorse. All'inizio, si cerca di mantenere ordine nella configurazione, ma poi i dipendenti iniziano a spostarsi da un dipartimento all'altro, i server si moltiplicano e cambiano ruolo, vengono concessi accessi per diversi progetti dove normalmente non dovrebbero, e si ottengono centinaia di percorsi sconosciuti.<\/p>\n

Intorno a determinate regole, se si \u00e8 fortunati, ci sono commenti come \u00abHa chiesto di farlo Vasya\u00bb o \u00abQuesto \u00e8 un passaggio nella DMZ\u00bb. L'amministratore di rete si dimette, e tutto diventa incomprensibile. Poi qualcuno ha deciso di pulire la configurazione da Vasya, e SAP \u00e8 andato in crash, perch\u00e9 in passato Vasya aveva richiesto quell'accesso per lavorare con SAP in produzione.<\/p>\n

\"VMware
\n
\nOggi parler\u00f2 della soluzione VMware NSX, che aiuta ad applicare in modo mirato le politiche di interazione e sicurezza di rete senza confusione nelle configurazioni dei firewall. Mostrer\u00f2 quali nuove funzionalit\u00e0 sono state introdotte rispetto a quanto era disponibile in precedenza per VMware in questo ambito. <\/a><\/noindex><\/p>\n

VMWare NSX \u2013 una piattaforma di virtualizzazione e sicurezza per i servizi di rete. NSX affronta le sfide di routing, switching, bilanciamento del carico, firewall e offre molte altre funzionalit\u00e0 interessanti. <\/p>\n

NSX \u00e8 il successore del prodotto VMware vCloud Networking and Security (vCNS) e dell'acquisito Nicira NVP.<\/p>\n

Da vCNS a NSX<\/h3>\n

\nIn precedenza, il cliente aveva nel cloud, costruito su VMware vCloud, una macchina virtuale separata vCNS vShield Edge. Questa fungeva da gateway di confine, dove era possibile configurare molte funzioni di rete: NAT, DHCP, Firewall, VPN, bilanciamento del carico, e altro. vShield Edge limitava l'interazione della macchina virtuale con il mondo esterno secondo le regole stabilite nel Firewall e nel NAT. All'interno della rete, le macchine virtuali comunicavano liberamente tra di loro all'interno delle sottoreti. Se si desidera controllare il traffico, si pu\u00f2 creare una rete separata per diverse parti delle applicazioni (diverse macchine virtuali) e definire nel firewall le regole appropriate per la loro interazione di rete. Ma tutto ci\u00f2 richiede tempo, \u00e8 complicato e poco interessante, specialmente quando si dispone di diverse decine di macchine virtuali.<\/p>\n

In NSX, VMware has implemented the concept of micro-segmentation through a distributed firewall integrated into the hypervisor kernel. Security and network interaction policies are defined not only for IP and MAC addresses but also for other objects like virtual machines and applications. If NSX is deployed within an organization, such objects can include users or groups from Active Directory. Each of these objects becomes a micro-segment within its security perimeter, in the appropriate subnet, complete with its cozy DMZ :). <\/p>\n

\"VMware
\nPreviously, there was a single security perimeter for the entire resource pool, which was protected by a border switch. With NSX, you can isolate a separate virtual machine from unnecessary interactions even within the same network. <\/i><\/p>\n

Le politiche di sicurezza e interazione di rete si adattano se un oggetto si sposta in un'altra rete. Ad esempio, se trasferiamo una macchina con un database in un altro segmento di rete o addirittura in un altro data center virtuale correlato, le regole definite per questa macchina virtuale continueranno a essere valide indipendentemente dalla sua nuova posizione. Il server delle applicazioni sar\u00e0 ancora in grado di interagire con il database.<\/p>\n

Il gateway di confine vCNS vShield Edge \u00e8 stato sostituito da NSX Edge. Quest'ultimo include tutto il pacchetto del vecchio Edge, oltre a alcune nuove funzionalit\u00e0 utili. Di queste parleremo in seguito.<\/p>\n

Cosa c'\u00e8 di nuovo in NSX Edge?<\/h3>\n

\nLe funzionalit\u00e0 di NSX Edge dipendono dalla versione<\/a><\/noindex> NSX. Ce ne sono cinque: Standard, Professional, Advanced, Enterprise, Plus Remote Branch Office. Tutte le novit\u00e0 interessanti sono disponibili solo a partire da Advanced. Compreso il nuovo interfaccia, che, fino al completo passaggio di vCloud a HTML5 (VMware promette estate 2019), si aprir\u00e0 in una nuova scheda.<\/p>\n

Firewall.<\/b> Come oggetti a cui si applicheranno le regole, \u00e8 possibile selezionare indirizzi IP, reti, interfacce del gateway e macchine virtuali. <\/p>\n

\"VMware
\n
\n\"VMware
\n
\nDHCP.<\/b> Oltre alla configurazione dell'intervallo di indirizzi IP che verranno automaticamente assegnati alle macchine virtuali di questa rete, le funzioni sono diventate disponibili in NSX Edge. Binding<\/b> e Relay<\/b>.<\/p>\n

Nella scheda Bindings<\/b> \u00c8 possibile associare l'indirizzo MAC della macchina virtuale a un indirizzo IP se \u00e8 necessario mantenere invariato l'indirizzo IP. \u00c8 importante che questo indirizzo IP non rientri nel pool DHCP.<\/p>\n

\"VMware
\n
\nNella scheda Relay<\/b> Si configura il relay dei messaggi DHCP ai server DHCP situati al di fuori della tua organizzazione in vCloud Director, inclusi i server DHCP dell'infrastruttura fisica. <\/p>\n

\"VMware
\n
\nRouting.<\/b> In vShield Edge era possibile configurare solo il routing statico. Qui \u00e8 stata introdotta la routing dinamica con supporto per i protocolli OSPF e BGP. Sono inoltre disponibili impostazioni ECMP (Active-active), il che significa anche failover di tipo 'attivo-attivo' verso router fisici.<\/p>\n

\"VMware
\nConfigurazione OSPF<\/i><\/p>\n

\"VMware
\nConfigurazione BGP<\/i><\/p>\n

Tra le novit\u00e0, la configurazione del trasferimento di percorsi tra protocolli diversi,
\nredistribuzione delle rotte (route redistribution). <\/p>\n

\"VMware
\n
\nL4\/L7 Load Balancer.<\/b> \u00c8 stata aggiunta la X-Forwarded-For per l'intestazione HTTPs. Senza di essa, tutti piangevano. Ad esempio, se hai un sito che stai bilanciando. Senza il passaggio di questa intestazione, tutto funziona, ma nelle statistiche del server web vedevi non gli IP dei visitatori, ma l'IP del bilanciatore. Ora \u00e8 tutto corretto. <\/p>\n

Inoltre, nella scheda Application Rules ora puoi aggiungere script che gestiranno direttamente il bilanciamento del traffico.<\/p>\n

\"VMware
\n
\nVPN. <\/b>Oltre a IPSec VPN, NSX Edge supporta:<\/p>\n