Miért nem mindegy az “Applied To” mező az NSX-T DFW-ben?

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.