Hol érdemes elindulni az mikroszegmentáció útján? A lehető legkönnyebben és leggyorsabban megtehető az első lépés, ami méghozzá fájdalommentes is. Minden ami kell az egyetlen egy NSX Manager. Igaz, hogy Distributed vSwitch is kell hozzá, de ha az már rendelkezésre áll, akkor tényleg csak egy IP-cím – és persze licensz – kérdése.
Alapvetően nem szükséges az overlay funkcionalitást használni, ahhoz hogy a DFW (distributed firewall) képességeit felmérhessük. Persze igaz, hogy ha a licenszelésben megvettünk egyéb funkciókat akkor ugyan használjuk már ki őket.
Itt érdemes megnézni, mert a Standard verzióban pont a DFW hiányzik. Pont az ami miatt szerintem egy limitáltabb költségvetéssel bíró, de biztonsági szempontból felkészült ügyfél éppen belépne az NSX-et használók körébe. Ennek ellenére ebben a verzióban csak az overlay funckionalitás, a NAT és Edge FW – ez azért nem az a tűzfal, mint amit a DFW tud, főleg mivel ez az észak-déli forgalomra képes a szabályokat alkalmazni. Szóval a DLR – Distributed Logical Router – az benne van, így ha nagyon szeretnénk elkerülni a hairpinning-et, illetve optimalizálni a szegmensek közötti útválasztást, több telephelyre kiterjeszteni a szegmenseket, akkor más nem is kell.
Pedig kell…és nagyon. Szerintem a Professional szintnél lejjebb kezdeni nem érdemes. Ebben van benne amiért a terméknek igazi létjogosultága van, azaz a DFW. Szóval, ahogyan korábban is említettem a DFW és az overlay között nem „ÉS” a kapcsolat és nem is „VAGY”. Egymáshoz közük nincs, egyiket lehet a másik nélkül megvalósítani.
Advanced-nél leheségessé válik a VPN és Load Balancer funkcionalitás, illetve itt jelenik meg a bővíthetőség, azaz a megoldás integrálható pl Palo Alto/CheckPoint-al. Az Application Rule Manager is hasznos, főleg azért mert nem lehet a mikroszegmentációt úgy kezdeni, hogy a default rule „Any-to-any Block” legyen. Előtte vagy a dokumentációra kell támaszkodni és bízni abban, hogy pontos volt, vagy használjuk az ARM-ot, ami egy futtatási intervallum alatt képes figyelni a virtuális gépeink forgalmát és ezáltal javasolni, sőt egy az egyben automatikusan létrehozni a szükséges DFW szabályokat. Ennél egy fokkal szofisztikáltabb megoldás a vRealize Network Insight, ami end-to-end képes ugyanerre, jobb vizualizációra, de megadva ugyanezt a javaslati funkciót a szabályok tekintetében. De a vRealize Network Insight csak az Enterprise Plus verzióban van benne…..
A hardware gateway még viszont lehet érdekes. Bizonyos gyártók adott switch verziói képesek az NSX-ben alapból szoftveres VTEP – hosztonként egy vagy több – átkerülhet hardveres formába, a switch jóvoltából. Ilyen gyártó például az Arista és a HPE. A Cisco nem képviselteti magát.
A Context Aware szegmentáció pedig szerintem a legérdekesebb és egyben legfelfoghatatlanabb része az egésznek. Amire ez képes, az nem más, minthogy egy RDSH szerveren – Windows Server 2012R2/2016 – felhasználónként más és más szabályt képes alkalmazni. Ezt már többször bemutattam élőben és nagyon jól működik. Azt kell mondjam, hogy egy zárt rendszerben, ahová jump kiszolgálókon keresztül lehet bejutni ez must have. Hasznos, hogy amennyiben ugyanarra az RDSH szerverre az adminisztrátor lép be, akkor elérheti például a fizikai kiszolgálók ILO/DRAC/CIMC portjait, de ha egy másik felhasználó, akkor ő nem érheti el.
Mi az a Small DC design?
Lényegében a vDS port group-ok VLAN-okon alapulnak, nincs DLR, nincs ESG. Minden amit kapunk az a kernelbe integrált DFW. Az NSX Manager-ből konfigurálhatjuk a szabályokat és körülbelül ennyi. Ebben a modellben nem kellenek NSX Controller-ek, se semmi. Ugyanakkor bármikor bővíthető az ilyen kiépítés, azaz ha később mégis szeretnénk kipróbálni a DLR-t, akkor semmi akadálya nem lesz.
Nincs szükség sok erőforrásra, bár azért ha Enterprise Plus licenszünk van és a Context Aware szegmentációt is szeretnénk kipróbálni, akkor kell majd a hosztok számával egyenlő service VM is. Hosztonként egy ilyen VM lesz, ez a Guest Introspection VM. Ezeknek is kell egy-egy IP-cím majd.
Hogyan tovább?
Nagyon egyszerű…..a következő posztban majd ismertetem is 🙂
