Om du tittar på konfigurationen av en brandvägg, kommer vi troligen att se ett ark med en massa IP-adresser, portar, protokoll och subnät. Det är så här nätverkssäkerhetspolicyer för användaråtkomst till resurser implementeras klassiskt. Först försöker de upprätthålla ordning i konfigurationen, men sedan börjar anställda flytta från avdelning till avdelning, servrar förökar sig och ändrar sina roller, åtkomst för olika projekt dyker upp där de vanligtvis inte är tillåtna och hundratals okända getvägar dyker upp.
Bredvid vissa regler, om du har tur, finns det kommentarer "Vasya bad mig att göra det här" eller "Detta är en passage till DMZ." Nätverksadministratören slutar, och allt blir helt oklart. Sedan bestämde sig någon för att rensa Vasyas konfiguration, och SAP kraschade, eftersom Vasya en gång bad om denna åtkomst för att köra strids-SAP.
Idag kommer jag att prata om VMware NSX-lösningen, som hjälper till att exakt tillämpa nätverkskommunikation och säkerhetspolicyer utan förvirring i brandväggskonfigurationer. Jag ska visa dig vilka nya funktioner som har dykt upp jämfört med vad VMware tidigare hade i den här delen.
VMWare NSX är en virtualiserings- och säkerhetsplattform för nätverkstjänster. NSX löser problem med routing, switching, lastbalansering, brandvägg och kan göra många andra intressanta saker.
NSX är efterträdaren till VMwares egen vCloud Networking and Security (vCNS) produkt och den förvärvade Nicira NVP.
Från vCNS till NSX
Tidigare hade en klient en separat vCNS vShield Edge virtuell maskin i ett moln byggt på VMware vCloud. Den fungerade som en gränsgateway, där det var möjligt att konfigurera många nätverksfunktioner: NAT, DHCP, brandvägg, VPN, lastbalanserare, etc. vShield Edge begränsade den virtuella maskinens interaktion med omvärlden enligt reglerna som anges i Brandvägg och NAT. Inom nätverket kommunicerade virtuella maskiner med varandra fritt inom subnät. Om du verkligen vill dela upp och erövra trafik kan du skapa ett separat nätverk för enskilda delar av applikationer (olika virtuella maskiner) och ställa in lämpliga regler för deras nätverksinteraktion i brandväggen. Men det här är långt, svårt och ointressant, speciellt när du har flera dussin virtuella maskiner.
I NSX implementerade VMware konceptet med mikrosegmentering med hjälp av en distribuerad brandvägg inbyggd i hypervisorkärnan. Den specificerar säkerhets- och nätverksinteraktionspolicyer inte bara för IP- och MAC-adresser, utan även för andra objekt: virtuella maskiner, applikationer. Om NSX distribueras inom en organisation kan dessa objekt vara en användare eller grupp av användare från Active Directory. Varje sådant objekt förvandlas till ett mikrosegment i sin egen säkerhetsloop, i det nödvändiga subnätet, med sin egen mysiga DMZ :).
Tidigare fanns det bara en säkerhetsperimeter för hela resurspoolen, skyddad av en kantswitch, men med NSX kan du skydda en separat virtuell maskin från onödiga interaktioner, även inom samma nätverk.
Säkerhets- och nätverkspolicyer anpassas om en enhet flyttar till ett annat nätverk. Till exempel, om vi flyttar en maskin med en databas till ett annat nätverkssegment eller till och med till ett annat anslutet virtuellt datacenter, så kommer reglerna som skrivs för denna virtuella maskin att fortsätta att gälla oavsett dess nya plats. Applikationsservern kommer fortfarande att kunna kommunicera med databasen.
Själva edge-gatewayen, vCNS vShield Edge, har ersatts av NSX Edge. Den har alla gentlemannaegenskaper från den gamla Edge, plus några nya användbara funktioner. Vi kommer att prata om dem vidare.
Vad är nytt med NSX Edge?
NSX Edge-funktionalitet beror på NSX. Det finns fem av dem: Standard, Professional, Advanced, Enterprise, Plus Remote Branch Office. Allt nytt och intressant kan bara ses från och med Advanced. Inklusive ett nytt gränssnitt, som, tills vCloud helt går över till HTML5 (VMware lovar sommaren 2019), öppnas i en ny flik.
Brandvägg. Du kan välja IP-adresser, nätverk, gateway-gränssnitt och virtuella maskiner som objekt som reglerna ska tillämpas på.
DHCP. Förutom att konfigurera intervallet av IP-adresser som automatiskt kommer att utfärdas till virtuella maskiner på detta nätverk, har NSX Edge nu följande funktioner: Bindning и Relä.
I fliken Bindningar Du kan binda MAC-adressen för en virtuell maskin till en IP-adress om du inte behöver ändra IP-adressen. Huvudsaken är att denna IP-adress inte ingår i DHCP-poolen.
I fliken Relä relä av DHCP-meddelanden konfigureras till DHCP-servrar som är placerade utanför din organisation i vCloud Director, inklusive DHCP-servrar för den fysiska infrastrukturen.
Routing. vShield Edge kunde bara konfigurera statisk routing. Dynamisk routing med stöd för OSPF- och BGP-protokoll dök upp här. ECMP (Active-active) inställningar har också blivit tillgängliga, vilket innebär aktiv aktiv failover till fysiska routrar.
Konfigurera OSPF
Konfigurera BGP
En annan ny sak är att sätta upp överföringen av rutter mellan olika protokoll,
omfördelning av rutt.
L4/L7 Load Balancer. X-Forwarded-For introducerades för HTTPs-huvudet. Alla grät utan honom. Du har till exempel en webbplats som du balanserar. Utan att vidarebefordra den här rubriken fungerar allt, men i webbserverstatistiken såg du inte IP-adressen för besökarna utan balanserarens IP-adress. Nu är allt rätt.
Även på fliken Application Rules kan du nu lägga till skript som direkt styr trafikbalanseringen.
VPN. Förutom IPSec VPN stöder NSX Edge:
- L2 VPN, som låter dig sträcka ut nätverk mellan geografiskt spridda platser. Ett sådant VPN behövs till exempel så att den virtuella maskinen förblir i samma subnät och behåller sin IP-adress när den flyttas till en annan plats.
- SSL VPN Plus, som tillåter användare att fjärransluta till ett företagsnätverk. På vSphere-nivå fanns en sådan funktion, men för vCloud Director är detta en innovation.
SSL-certifikat. Certifikat kan nu installeras på NSX Edge. Detta kommer återigen till frågan om vem som behövde en balanserare utan certifikat för https.
Gruppera objekt. På den här fliken anges grupper av objekt för vilka vissa regler för nätverksinteraktion kommer att gälla, till exempel brandväggsregler.
Dessa objekt kan vara IP- och MAC-adresser.
Det finns också en lista över tjänster (protokoll-port-kombination) och applikationer som kan användas när du skapar brandväggsregler. Endast vCD-portaladministratören kan lägga till nya tjänster och applikationer.
Statistik. Anslutningsstatistik: trafik som passerar genom gateway, brandvägg och balanserare.
Status och statistik för varje IPSEC VPN och L2 VPN-tunnel.
Skogsavverkning. På fliken Edge Settings kan du ställa in servern för inspelning av loggar. Loggning fungerar för DNAT/SNAT, DHCP, brandvägg, routing, balancer, IPsec VPN, SSL VPN Plus.
Följande typer av varningar är tillgängliga för varje objekt/tjänst:
– Felsöka
-Varna
-Kritisk
- Fel
-Varning
- Lägga märke till
- Info
NSX Edge Dimensions
Beroende på vilka uppgifter som löses och volymen av VMware skapa NSX Edge i följande storlekar:
NSX Edge
(Kompakt)
NSX Edge
(Stor)
NSX Edge
(Quad-Large)
NSX Edge
(Extra stor)
vCPU
1
2
4
6
Minne
512MB
1GB
1GB
8GB
Disk
512MB
512MB
512MB
4.5GB + 4GB
Tidsbeställning
Ett
applikation, test
datacenter
liten
eller genomsnitt
datacenter
Lastad
brandvägg
balansering
laster på nivå L7
Nedan i tabellen finns driftsmått för nätverkstjänster beroende på storleken på NSX Edge.
NSX Edge
(Kompakt)
NSX Edge
(Stor)
NSX Edge
(Quad-Large)
NSX Edge
(Extra stor)
Gränssnitt
10
10
10
10
Undergränssnitt (trunk)
200
200
200
200
NAT -regler
2,048
4,096
4,096
8,192
ARP-inlägg
Tills Skriv över
1,024
2,048
2,048
2,048
FW-regler
2000
2000
2000
2000
FW prestanda
3Gbps
9.7Gbps
9.7Gbps
9.7Gbps
DHCP-pooler
20,000
20,000
20,000
20,000
ECMP-vägar
8
8
8
8
Statiska rutter
2,048
2,048
2,048
2,048
LB Pooler
64
64
64
1,024
LB virtuella servrar
64
64
64
1,024
LB Server/Pool
32
32
32
32
LB Health Checks
320
320
320
3,072
LB Ansökningsregler
4,096
4,096
4,096
4,096
L2VPN Clients Hub till Spoke
5
5
5
5
L2VPN-nätverk per klient/server
200
200
200
200
IPSec-tunnlar
512
1,600
4,096
6,000
SSLVPN-tunnlar
50
100
100
1,000
SSLVPN privata nätverk
16
16
16
16
Samtidiga sessioner
64,000
1,000,000
1,000,000
1,000,000
Sessioner/sekund
8,000
50,000
50,000
50,000
LB Throughput L7 Proxy)
2.2Gbps
2.2Gbps
3Gbps
LB-genomströmning L4-läge)
6Gbps
6Gbps
6Gbps
LB Connections/s (L7 Proxy)
46,000
50,000
50,000
LB samtidiga anslutningar (L7 proxy)
8,000
60,000
60,000
LB-anslutningar/s (L4-läge)
50,000
50,000
50,000
LB samtidiga anslutningar (L4-läge)
600,000
1,000,000
1,000,000
BGP rutter
20,000
50,000
250,000
250,000
BGP grannar
10
20
100
100
BGP-rutter omfördelas
Ingen gräns
Ingen gräns
Ingen gräns
Ingen gräns
OSPF-rutter
20,000
50,000
100,000
100,000
OSPF LSA Entries Max 750 Typ-1
20,000
50,000
100,000
100,000
OSPF Adjacencies
10
20
40
40
OSPF-rutter omfördelas
2000
5000
20,000
20,000
Totalt antal rutter
20,000
50,000
250,000
250,000
→
Tabellen visar att det rekommenderas att organisera balansering på NSX Edge för produktiva scenarier endast med utgångspunkt från storleken Large.
Det är allt jag har för idag. I följande delar kommer jag att gå igenom i detalj hur man konfigurerar varje NSX Edge-nätverkstjänst.
Källa: will.com