{"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\/no\/blog\/vmware-nsx-dlya-samyh-malenkih-chast-1","title":{"rendered":"VMware NSX for de minste. Del 1","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"VMware
\n
\nHvis du ser p\u00e5 konfigurasjonen til hvilken som helst brannmur, vil du sannsynligvis se et ark med mange IP-adresser, porter, protokoller og subnett. Slik implementeres nettverkssikkerhetspolicyer klassisk for brukertilgang til ressurser. F\u00f8rst pr\u00f8ver man \u00e5 opprettholde orden i konfigurasjonen, men deretter begynner ansatte \u00e5 flytte fra avdeling til avdeling, servere \u00e5 mangedoble seg og endre roller, og det oppst\u00e5r tilgang for forskjellige prosjekter der det vanligvis ikke skal v\u00e6re, noe som resulterer i hundrevis av ukjente stier.<\/p>\n

Kring visse regler, hvis man er heldig, er det skrevet kommentarer som \u00abBa Vasja gj\u00f8re dette\u00bb eller \u00abDette er en vei til DMZ\u00bb. Nettverksadministratoren slutter, og alt blir helt uforst\u00e5elig. Deretter bestemmer noen seg for \u00e5 rydde opp i konfigurasjonen til Vasja, og SAP faller ned, fordi Vasja en gang ba om denne tilgangen for drift av SAP.<\/p>\n

\"VMware
\n
\nI dag vil jeg snakke om VMware NSX, som hjelper med \u00e5 presist anvende nettverksinteraksjons- og sikkerhetspolicyer uten forvirring i brannmurkonfigurasjoner. Jeg vil vise hvilke nye funksjoner som har kommet i forhold til det VMware hadde tidligere p\u00e5 dette omr\u00e5det. <\/a><\/noindex><\/p>\n

VMware NSX er en plattform for virtualisering og sikring av nettverkstjenester. NSX tar seg av oppgaver som ruting, switching, lastbalansering, brannmur og kan mye annet spennende. <\/p>\n

NSX er etterf\u00f8lgeren til VMware sitt eget produkt vCloud Networking and Security (vCNS) og det ervervede Nicira NVP.<\/p>\n

Fra vCNS til NSX<\/h3>\n

\nTidligere hadde kunden en egen virtuell maskin vCNS vShield Edge i skyen bygget p\u00e5 VMware vCloud. Den fungerte som en grensegateway, hvor man kunne konfigurere mange nettverksfunksjoner: NAT, DHCP, brannmur, VPN, lastbalanserer osv. vShield Edge begrenset interaksjonen mellom den virtuelle maskinen og omverdenen i henhold til reglene fastsatt i brannmuren og NAT. Inne i nettverket kommuniserte de virtuelle maskinene fritt seg imellom innenfor subnettene. Hvis man virkelig \u00f8nsker \u00e5 skille og kontrollere trafikken, kan man opprette et eget nettverk for forskjellige deler av applikasjoner (forskjellige virtuelle maskiner) og angi tilsvarende regler i brannmuren for deres nettverksinteraksjon. Men dette er tidkrevende, komplisert og uinteressant, spesielt n\u00e5r du har flere titalls virtuelle maskiner.<\/p>\n

I NSX har VMware implementert konseptet mikrosegregering ved hjelp av en distribuert brannmur (distributed firewall) som er integrert i hypervisorens kjerne. Sikkerhetspolicyer og nettverksinteraksjoner kan defineres ikke bare for IP- og MAC-adresser, men ogs\u00e5 for andre objekter som virtuelle maskiner og applikasjoner. Hvis NSX er distribuert innen en organisasjon, kan objekter som bruker eller grupper av brukere fra Active Directory ogs\u00e5 bli inkludert. Hver slik enhet blir til en mikrosegregering innen sitt sikkerhetskontur, i den n\u00f8dvendige undernett, med sin egen koselige DMZ :). <\/p>\n

\"VMware
\nTidligere var det kun \u00e9n sikkerhetsperimeter for hele ressursbassenget, beskyttet av en grensesnittbryter, men med NSX kan man isolere et enkelt virtuelt maskin fra un\u00f8dvendige interaksjoner selv innenfor ett nettverk. <\/i><\/p>\n

Sikkerhetspolicyer og nettverksinteraksjoner tilpasser seg n\u00e5r et objekt flytter til et annet nettverk. For eksempel, hvis vi flytter en database-maskin til et annet nettverkssegment eller til og med en annen tilknyttet virtuell datacenter, vil reglene som er angitt for denne virtuelle maskinen fortsatt gjelde uavhengig av dens nye beliggenhet. Applikasjonsserveren vil fortsatt kunne samhandle med databasen.<\/p>\n

Den gamle grensesnittsgatewayen vCNS vShield Edge har blitt erstattet med NSX Edge. Den har hele dets funksjonalitet pluss flere nye nyttige funksjoner. Om disse vil bli det neste emnet.<\/p>\n

Hva er nytt med NSX Edge?<\/h3>\n

\nFunksjonaliteten til NSX Edge avhenger av utgave<\/a><\/noindex> av NSX. Det finnes fem utgaver: Standard, Professional, Advanced, Enterprise, Plus Remote Branch Office. Alt nytt og interessant kan kun ses fra og med Advanced. Inkludert det nye grensesnittet, som f\u00f8r den fullstendige overgangen til vCloud p\u00e5 HTML5 (VMware lover sommeren 2019) vil \u00e5pnes i en ny fane.<\/p>\n

Brannmur.<\/b> Som objekter som reglene skal gjelde for, kan man velge IP-adresser, nettverk, gateway-grensesnitt og virtuelle maskiner. <\/p>\n

\"VMware
\n
\n\"VMware
\n
\nDHCP.<\/b> I tillegg til \u00e5 konfigurere IP-adresseomr\u00e5det som vil bli tildelt automatisk til virtuelle maskiner i dette nettverket, har NSX Edge f\u00e5tt funksjoner tilgjengelig. Binding<\/b> og Relay<\/b>.<\/p>\n

In the tab Bindings<\/b> man kan knytte MAC-adressen til en virtuell maskin til en IP-adresse hvis man \u00f8nsker at IP-adressen ikke skal endre seg. Det viktigste er at denne IP-adressen ikke er inkludert i DHCP Pool.<\/p>\n

\"VMware
\n
\nIn the tab Relay<\/b> DHCP-meldingar blir no rutet til DHCP-serverar som ligg utanfor organisasjonen din i vCloud Director, inkludert DHCP-serverar i den fysiske infrastrukturen. <\/p>\n

\"VMware
\n
\nRuting.<\/b> I vShield Edge kunne ein berre konfigurere statisk ruting. Her har vi f\u00e5tt dynamisk ruting med st\u00f8tte for OSPF- og BGP-protokollar. Det har ogs\u00e5 blitt tilgjengeleg \u00e5 konfigurere ECMP (Active-active), som betyr at failover av typen \u00abaktiv-aktiv\u00bb til fysiske rutarar no er mogleg.<\/p>\n

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

\"VMware
\nBGP-konfigurasjon<\/i><\/p>\n

End\u00e5 ein ny funksjon er rutingoverf\u00f8ring mellom ulike protokollar,
\nruteroverf\u00f8ring (route redistribution). <\/p>\n

\"VMware
\n
\nL4\/L7 Lastbalanserer.<\/b> X-Forwarded-For st\u00e5r no tilgjengeleg for HTTPs-headeren. Uten den klaga alle. For eksempel, dersom du har ein nettside som du lastbalanserer. Uten \u00e5 vidareformidle denne headeren fungerar alt, men i statistikken til webserveren s\u00e5g du ikkje IP-adresser til bes\u00f8kande, men IP-adressa til lastbalanseraren. No er alt korrekt. <\/p>\n

I tillegg kan ein no legge til skript i fanen Application Rules som direkte kan styre lastbalansering av trafikk.<\/p>\n

\"VMware
\n
\nVPN. <\/b>I tillegg til IPSec VPN st\u00f8ttar NSX Edge:<\/p>\n