Az előző cikket ott fejeztem be, hogy a projektek megjelenése az NSX-ben eléggé üdvözlendő és régóta várt lehetőséget ad. Engedjétek meg, hogy én tenant szóval helyettesítsem a projekt szót. Tehát a tenant hatóköre egészen a T0-ig terjed, azaz minden az alatti entitást és az azokhoz kapcsolódó vagy kapcsolható funkciót is jelenti.
Oké a T0 a határ azonban a következő fontos:
- egy projekthez egy T0 tartozhat
- egy T0 tartozhat több projekthez
Nem újdonság az a következő szabályrendszer sem:
- egy Edge Cluster-ben lehet több T0.
- egy edge node-on csak egy T0 lehet.
- kvázi T0-ra lehetőség van ez a VRF. Egy edge node-ban több VRF lehet.
Tehát ha valaki erre a tenant/projekt módú kiépítésre hajtja a fejét, az még nem jelenti azt, hogy akkor több T0-ra van szüksége. Nyugodtan el lehet kedzeni a környezet multitenant működésének bevezetését T1 alapon, úgy hogy mindenki azonos T0-t használ. Korábbi NSX verziókban a VRF örökölte a parent T0 AS számát, de a 4.1-ben ez már nincs így, lehet saját AS-e minden T0-nak ami VRF-ben realizált. Tehát el tudok képzelni egy olyan kiépítést, hogy két szép nagy edge node és abban több VRF lite, mind saját AS-sel és nyilván saját uplink tranzit VLAN-okkal.
Ennél jobb nézetet mutat a network map. Látszik hogy a Tenant2-Tier1-01 és a Tenant3-Tier1-01 is a Tenant2-VRF T0-t használja.
GW és DFW tűzfal(ak) projekt alapon
Egy friss és még nem beállított projektben a security tab így néz ki. Rögvest ott a két tűzfal, a Gateway firewall – ami a T1-en kerül érvényesítésre – és a DFW, ami pedig a kernel szintjén, minden VM vNIC-jén.
Gateway tűzfal
A gateway szabályrendszer eléggé egyszerű és már első ránézésre is látszik, hogy tényleg ott érvényesül. A default_rule két ponton módosítható, mégpedig az action mezőben, ahol lehet accept/drop és reject, illetve a fogaskerék mögötti ablakban, ahol a naplózást, kommentet és log label-t lehet beállítani.
Ha felveszek egy új policy-t és abba egy új rule-t, akkor abban már módosítható bármely másik mező. A source és destination oldalon egyébként használható bármilyen általunk létrehozott csoport és IP, de van egy csoport ami alapból létrejön és tartalmaz minden szegmenst, ami a projekten belül fellelhető.
Ha például minden befelé, azaz a T1-en kívülről érkező kommunikációt tiltani akarok és csak az TCP/3389-et ráadásul L7 szabállyal be akarom engedni az összes T1-en belül lévő szegmensre és ezáltal – ha ütköző DFW szabály nincs – akkor azt így tudom megtenni.
Distributed tűzfal
Ez az érdekesebb, mert mikor először láttam, nem hittem a szememnek. Nézzük meg a szabályokat és szerintem mindenki számára világos lesz. Az felső három sor könnyen felfogható, de a negyedik…..
Személy szerint én elég sokat téptem a számat korábbi cikkekben, webinar-okon és ügyfeleknél, hogy az applied to mező miért lényeges. Többek szerint egyáltalán nem fontos, mert gondolom ők úgy fogják fel hogy biztos gyorsabb és kevesebb CPU/RAM-ot igényel végigmenni 3200 szabályon, ráadásul olyan szabályon minden alkalommal, minden VM esetén, mikor az adott szabálynak köze sincs az adott VM-hez csak az applied to mezőben DFW van beállítva.
Mindegy is, szóval ez a negyedik szabály azt jelenti hogy akárhonnan, akárhová, mindenféle kommunikáció eldobásra kerül. Hogy mi? És ezt a tenant be tudja állítani? Akkor ez kihatással lehet a teljes NSX telepítésre? Nem lesz! Mielőtt megnézzük a miértet, ugorjunk át az “All projects” nézetbe és nyissuk ki a szabályokat, hogy mindent egy ablakban láthassunk.
Megtanultuk, hogy a tűzfal fentről lefelé és balról jobbra értékelődik ki. Ha van illeszkedő szabály a forgalomra, akkor a kiértékelés véget ér. Akkor a fenti ablakban látható három – igazából négy, mert az egyik tenant-ot nem nyitottam ki – szabály egymással ütközik. Azt kell mondjam, csak ránézésre ütköznek, valójában a Tenant3 szabályai nem befolyásolódnak a Tenant1 szabályrendszere által és senki sem fenyegeti a default tenant biztonságát sem. Azonban a default szabályai érvényesülnek – ha nincs a tenant szintjén más illeszkedő szabály – a projektek szintjén is.
Mindenképpen kell T0 a tenantnak?
Nem. A tenant létrehozásakor nem kötelező megadni T0-t. Szóval amennyiben az a cél, hogy egy izolált környezetet adjunk ki, aminek a T1-en kívül nem létezik világ, akkor az minden további nélkül lehetséges.
Ilyen esetben a tenant alatt szabadon hoztható létre bármi, T1-ek és szegmensek – a quota határain belül – azonban az mivel a T1-nek nincs T0 irányba kapcsolata, nem lesz ilyen formán északi irányba kapcsolatuk.
Mit nem lehet?
Előző cikkben már volt szó róla, mi minden osztható ki, mi mindenhez rendelhető kvóta. Nem szabad elmenni azon képességek mellett, amiket nem lehet delegálni. Véleményem szerint egy fájdalmasabb képesség van, amit nem lehet, a lenti felsorolásban félkövérrel szedtem.
- VLAN szegmens
- L2 bridge
- L2 és L3 VPN
- Load balancer – úgyis deprecated ugye
- Distributed IDS/IPS
- Gateway IDS/IPS
- Malware Prevention
- TLS Decryption
- Identity Firewall
- FQDN Filterning
- FQDN Analysis
- TLS Instepcion
Abban biztos vagyok, hogy a distributed IDS/IPS valamilyen módon delegálhatóvá válik a jövőben – de semmiféle bennfentes információm nincs róla – hiszen pont mint a DFW, legalább annyira fontos eszköze a biztonságos rendszernek. A gateway szinten konfigurált eszközöknél tippjeim szerint az a hiány oka, hogy ezek bekapcsolása egy T1-en, edge cluster-en néha globális, ugyanakkor jelentős többletterhelést okozhat az edge node-okon, ami pedig kihatással lehet más tenant-okra mind routing/switching szempontból, mint minden másféle értelmezésben.
