Az NSX-T elosztott tűzfala – distributed firewall – egy egészen elképesztő képesség, ami eddig sosem látott szűrési lehetőségeket hozott a virtuális – és fizikai – környezetekbe is.
De ez gyökeresen új felfogást is igényel, hiszen eddig a tűzfal az összes ilyen képesség központi eleme volt egy logikai blokkban az összes tűzfalakkal támasztott igénynek. Ezért minden szabályt ismerie kellett, hiszen ő alkalmazza azokat a forgalmakon, szóval mindenről, mindig tudnia kellett.
Ha pusztán így közelítjük meg az NSX DFW-jét, akkor bár működőképes rendszer kapunk, de nem biztos hogy minden kipréselünk belőle amit tud. Utóbbit az optimális felhasználásra értem, nem arra hogy majd nem tud szűrni.
Erre kicsit a VMware is rájátszik, mivel az NSX telepítését követően bármely szabály amit létrehozunk egész biztosan a nem minden esetben optimális módon jön létre.
A következő topológiában mutatom be miért nem mindegy a DFW szabályoknál az „Applied to” mezőben a beállítás.
Adott két virtuális gép:
- VM1 – 10.4.4.10/24
- VM2 – 10.4.5.10./24
Mindegyik saját T1-hez kapcsolódik, viszont ez a két T1, azonos T0-hoz tartozik.
Hozzunk létre egy teljesen értelmetlen szabályt a két VM szempontjából. Mint látható alább, az „External network” objektum a forrás és a „8.8.8.8/32” a cél. A kettő között szeretnék mindent tiltani – meg sem járja ez a forgalom az NSX-et amúgy, de ezért is mondom, hogy értelmetlen a szabály. Az „Applied To” mező az érdekes, ott DFW szerepel. Ez az alapértelmezett.
Most nézzük meg, hogy a VM1-re milyen szabályok vonatkoznak. Ehhez be kell lépni arra az ESXi hosztra, amin a VM1 fut.
Bizony. megjelent a szabály erre a virtuális gépre – sőt annak minden interfészére vonatkozóan – annak ellenére, hogy erre a szabályra illeszkedő forgalmat lehetetlenség benne vagy irányába folytatni.
Minden egyes ilyen felesleges szabály, késleltetést ad, CPU és RAM szükségletet jelent a hoszt oldalán, szóval ezektől meg kell szabadulni az olyan esetekben, mikor egyálán nem értelmezhető egy szabály, egy adott entitásra. Persze akkor természetesen használni kell a DFW beállítást a szabályokban, ha általános és minden gépre érvényes dolgot definiálunk – NTP, syslog stb.
Egy picit más megközelítésben nézzük meg azt, hogy a VM1 és a VM2 közötti forgalom szűrésében mit jelenthet az „Applied To” mező.
A fenti képen az látszik, hogy erre a szabályra az „Applied To” mezőben egy saját magam által létrehozott csoportot tettem, ami jelen esetben azt a szegmenst tartalmazza tagként, amelyhez a VM1 csatlakozik.
Az NSX traceflow képességével nézzük meg hogy mi történik ha a VM1-ből próbálunk forgalmazni a VM2 felé.
Már a VM hálózati interfészéről kilépve kapásból eldobódik a csomag, az ESXi kernelében „megállítódik” a forgalom.
Változtassuk meg az „Applied To” mezőben a VM1 szegmensét, a VM2 szegmensére.
Futtassuk le ugyanazt a trace-t. Az eredmény elképesztő mértékben más.
Szóval a forgalom bejárta a két T1 SR komponensét is, amik a példában szerencsére azonos Edge VM-ben vannak – de lehetnének külön is, sőt nem azonos hoszton – akkor még több hop kerül a forgalomba és a csomag majdnem kézbesítődik mert eljut a cél ESXi TEP interfészén keresztül az ESXi-be, de ott a kernelben a VM2 hálózati interfészén ülő tűzfalon dobódik el a forgalom.
Ez az egy mező azt jelentette az előbb, hogy ahelyett, hogy még a vezetéken sem jelent volna meg a forgalom – ahogy az első esetben – a legrosszabb esetet feltételezve, eljutott a overlay hálózatban a VM1 szegmensének T1-éig egy Edge VM-be, onnan az overlay hálózaton át átkerült egy másik ESXi kiszolgálón futtatott másik Edge VM-ig, amiben a VM2 szegmensének T1-e van, majd onnan szintén az overlay hálózaton eljut a VM2-t futtató ESXi-re.
Szóval nagyon nem mindegy az hogy mi van az „Applied To” mezőben, érdemes átgondolni.
