Az NSX-V és az NSX-T egyik fő képessége mindig a mikroszegmentáció volt, az hogy akár két, egyébként egy szegmensben, egy hoszton lévő virtuális gép – sőt fizikai gép – között is képes szabályokat alkalmazni. Az overlay, az automatizálhatóság, a VPN, a load balancer stb. az mind mind olyan képesség, amelyek mellett nem lehet elmenni szó nélkül, de kétség nem fér hozzá, a mikroszegmentáció eléggé egyedi.
De hány helyen lehet NSX-T esetén forgalmat szűrni – 3rd party nélkül?
- distributed firewall
- gateway firewall
A fentiek összege nem kettő, mert az hogy mennyi helyen lehet, nagyban függ attól, hogy mi-mivel kommunikál, illetve hogy hány tier van. Sőt mi több elég sok függ attól, hogy egyátalán van-e SR komponense egy-egy Tier 1-nek.
Minden példa során két virtuális gépet fogok használni és minden esetben kétszintű routing lesz.
1. eset: Különböző szegmenseken vannak a VM-ek, azonos T1-en – és nyilván azonos T0-n
Az alábbi topológia mentén a két VM közötti forgalom szűrésére két pont használható fel – nem beszélek kliens oldali tűzfalról – méhozzá a VM1 és a VM2 hálózati interfészei, amiket a distributed firewall (DFW) képes korlátozni.
Mikor a T1-et létrehozzuk, akkor meg lehet adni, hogy szeretnénk-e edge cluster-t vagy sem és ez erősen befolyásolja mi történik.
1.a Különböző szegmenseken vannak a VM-ek, azonos T1-en, azonos T0-n és azonos hoszton, edge klaszter nélkül
A T1 releváns beállítása alább látható.
Ellenőrzöm az Edge-eken hogy tényleg nem jött létre SR komponens a Tier1-Segment1 számára.
Látható az alábbi képen, hogy az útválasztás a hoszton lokális marad, nem jelenik meg a „kábelen”.
Tűzfalazási lehetőségek: forrás VM DFW -> cél VM DFW
Hop-ok száma: 2 – a DFW-t nem számolva.
1.b Különböző szegmenseken vannak a VM-ek, azonos T1-en, azonos T0-n, különböző hosztokon, edge klaszter nélkül
A T1 releváns beállítása alább látható.
Ellenőrzöm az Edge-eken hogy tényleg nem jött létre SR komponens a Tier1-Segment1 számára.
Alább látszik, hogy a forrás VM-et futtató ESXi kiszolgálón megtörténik az útválasztás, majd a forrás ESXi-ről a cél ESXi-re kerül a csomag, ahol a cél VM fut. Itt a két hoszt TEP interfészein keresztül megjárja a hálózatot a forgalom.
Tűzfalazási lehetőségek: forrás VM DFW -> cél VM DFW
Hop-ok száma: 4 – a DFW-t nem számolva.
1.c Különböző szegmenseken vannak a VM-ek, azonos T1-en, azonos T0-n és azonos hoszton, edge klaszterrel
Az előző két példától eltérően az egyetlen különbség, hogy a T1 konfigurációjában beállítom az edge cluster-t.
Az Edge VM-ben ilyenkor meg is jelenik a T1-hez tartozó SR komponens, mivel stateful szolgáltatások is beállíthatóak, például tűzfal.
A forgalom teljes mértékben azonos a korábban látottakkal, meg sem járja az Edge VM-et, tehát a T1-en bármiféle beállított szabály nem is alkalmazódik, mivel a T1 és T0 entitásokon edge/gateway firewall van és azon szabályok a T1/T0 uplink interfészén alkalmazódik, viszont ez a szegmensek közötti forgalom azt pont nem járja meg.
Tűzfalazási lehetőségek: forrás VM DFW -> cél VM DFW
Hop-ok száma: 2 – a DFW-t nem számolva.
1.d Különböző szegmenseken vannak a VM-ek, azonos T1-en, azonos T0-n és különböző hoszton, edge klaszterrel
Ezt le sem tesztelem, mivel teljesen azonos az 1.b példában tapasztaltakkal.
Tűzfalazási lehetőségek: forrás VM DFW -> cél VM DFW
Hop-ok száma: 4 – a DFW-t nem számolva.
2. eset: Különböző szegmenseken vannak a VM-ek, külön T1-en, de azonos T0-n
Az alábbi topológia mentén lényegében több lehetőség adódik, de mindegyikre igaz az, hogy a VM1 és a VM2-t DFW-vel el lehet választani, tehát máris kettő helyen lehet szűrni.
Viszont mikor a T1-et, T1-eket létrehozzuk, akkor meg lehet adni, hogy szeretnénk-e edge cluster-t vagy sem és ez erősen befolyásolja mi történik.
2.a A Tier 1-ek Edge Cluster nélkül – VM-ek különböző hoszton
Léterhozáskor és később is be/átállítható, hogy a T1-eknek van-e edge cluster-en realizált komponense. Ez a komponens az SR
Ezt mi sem bizonyítja jobban, mint ha belépek az egyik Edge-re, akkor nincs rajta SR komponens egyik T1-hez sem.
A VM1 és a VM2, azaz a 192.168.100.1 és a 192.168.200.1 között nézzünk egy Traceflow-t.
Nyilvánvalóvá válik az, hogy a VM1-en DFW-vel lehet szűrni és a VM2-őn szintén. A szabály megengedő a fenti esetben. Routing szempontból látszik, hogy bár külön Tier 1-hez csatlakozik a két VM által használt szegmens, mégis elosztottan történik az útválasztás, tehát meg sem járja az Edge klasztert. A példában a két virtuális gép különböző ESXi hoszton van ezért látszik, hogy miután a Tier1-Segment1 nevű T1 DR komponensén keresztül útválasztódik, majd átkerül a Tenant1-T0 T1 DR komponensére, majd a T1-Segment2 DR komponensére, még mindig a forrás VM-et futtató hoszton tartunk, de az útválasztás már megtörtént, már csak a forrás ESXi TEP-jéről kell átjuttatni a csomagot a cél ESXi TEP interfészére. Miután ez is megtörtént, a VM2 DFW-je is látszik és a csomag célba is ért.
Tűzfalazási lehetőségek: forrás VM DFW -> cél VM DFW
2.b A Tier 1-ek Edge Cluster nélkül – VM-ek azonos hoszton
A forrás és a cél ESXi természetesen azonos, ezért a T1-T0-T1 útvonal a hoszton belül járódik be, ez az elosztott multi tier routing. Tűzfalazni szintén a DFW-vel lehet, forrás és cél oldalon.
Látszik hogy sokban nem, az útválasztás lokális.
Tűzfalazási lehetőségek: forrás VM DFW -> cél VM DFW
2.c A Tier 1-ek Edge Cluster-rel – VM-ek különböző hoszton
Mielőtt ezt tesztelni lehet, a T1-eken beállítom az Edge Cluster-t.
Ezt leellenőrizve az Edge VM-ben látható a létrejövő SR komponens mindkét T1-hez.
Ezek után a trace így alakul. Mint látható a forrás ESXi-ről a forgalom az Tier1-Segement1 SR komponensét is realizáló Edge VM-be kerül – ami történetesen akár másik hoszton is lehet mint ahol a forrás van – ott az Edge firewall mentén szűrésre kerül, majd a Tenant1-T0 DR komponense kezeli tovább – ami szintén lehetne másik ESXi hoszton akár. Onnan a csomag a Tier1-Segment2 SR komponensébe kerül, ahol szintén azon a T1-en beállított Edge firewall szabályok mentén szűrődik, majd a cél VM-et futtató ESXi hosztra kerül a forgalom, ahol végül a DFW szabályok után a VM2 megkapja azt.
Tehát a lehetséges szűrési pontok: forrás DFW -> T1 Edge firewall (forrás szegmens) -> T1 Edge Firewall (cél szegmens) -> DFW
Bizony, a T0 tűzfala ebben nem is vesz részt, korábban már tapasztaltuk, hogy az uplink-en realizált és a két T1 közti forgalom azt nem járja meg.
2.d A Tier 1-ek Edge Cluster-rel – VM-ek azonos hoszton
Mielőtt ezt tesztelni lehet, a T1-eken beállítom az Edge Cluster-t.
Ezt leellenőrizve az Edge VM-ben látható a létrejövő SR komponens mindkét T1-hez.
A traceflow megmutatja, hogy a forrás VM-et a DFW szűri, majd jön a Tier1-Segment1 SR komponense, ahol a T1 tűzfala is megvizsgálja, majd onnan átkerül a T0-ra, onnan a Tier1-Segment2 SR komponensére – ami történetesen egy másik Edge VM-en aktív – kerül, ahol annak tűzfala nézi meg, maj onnan pedig visszatér a hosztra, ahol a cél is van – és a forrás is van – ahol a cél VM-re alkalmazott DFW mentén ellenőrzésre kerül.
Összefoglaló
A Tier 1 router-ek konfigurációjában nem kötelező edge cluster-t kiválasztani, de amennyiben beállítjuk, abban az esetben a default megeengedő szabályok mellett is megjárja a forgalom az Edge VM-eket.
Van pár szabály, amik mentén át kell gondolni:
- egy Edge VM-ben csak egy T0 lehet.
- egy Edge VM-ben több T1 lehet.
Ha az Edge VM-ek számukra dedikált hosztokon futnak és stateful szolgáltatásokat akarunk használni a T1/T0-kban, akkor két T1 közötti forgalom mindenképp megjárja a Edge VM-et, ezáltal a forrás ESXi és az Edge VM-et futtató ESXi közötti hálózatot és ha a célja egy másik T1-hez csatlakozó szegmens, akkor előfordulhat, hogy az adott T1 SR komponensét aktívan futtató ESXi kiszolgálót is, mielőtt a céljához érne a cél VM ESXi kiszolgálóján. Mindez dinamikusan változhat is, mivel az Edge VM-eket karban kell tartani, hiba érintheti őket, mikor az aktív/standby pár válthat.
Ennek fényében érthető az a javaslat, hogy a T0 aktív-aktív legyen, a T1-ek amennyiben szükséges a NAT/tűzfal miatt, lehetnek aktív-standby kapcsolatban. Az is jellemző, hogy egy T1, a többi T1-el és adott esetben T0-val is osztozhat a sávszélességen, mind TEP irányból, mind északi irány felé.
