A VMware Cloud Foundation része a VMware Cloud Director, azonban nem gondolom, hogy a VCF vásárlók túl sokan használnák, nem úgy a Cloud Provider-ek, akik ha VMware-en szolgáltatnak, akkor adódik, mint az optimális választás. Könnyen megérhető, hogy a Cloud Director felületének el kell rejtenie, a háttérben üzemelő infrastruktúra minden beszédes részletét, nem szabad elárulnia a felépítés részleteit és úgy kell működjön, hogy skálázható és biztosan üzemelő rendszert alkosson. Ebből fakadóan rengeteg megkötést is tartalmaz, mint például nem lehet több snapshot egy virtuális gépen (az újabb verziókban már lehet) pedig nyilvánvalóan a háttérben a vCenter Server és az ESXi simán megengedi.
Hasonlóan korlátozott a hálózati része is, pedig az NSX-ben a route leaking-től kezdve, a T0-k közvetlen egymással való dianmikus routing-jáig, bármit meg lehet csinálni.
A licenszelési változások következtében a szolgáltatóknál a distributed firewall – DFW – funkció rendkívül megrágult, mivel az alap NSX-ben az nincs benne, mag alapon kell a vDefend Firewall csomag, az összes olyan ESXi kiszolgálóra, ahol az NSX ilyen képességet nyújt – effektív egy klaszter összes tagjára.
Nézzünk egy olyan igényt, ami teljesen valós és érhető is: Két virtuális gép, két külön hálózatba rendezve, ne legyen képes elérni egymást.
Ha lenne DFW, akkor minden további nélkül, a tenant maga, készíthet ilyen szabályt, sőt mi több, a két virtuális gép, akár egy hálózatban is lehet, nem számít. De DFW hiányában ez lehetetlen, mivel a gateway tűzfal, a T1 – T0 esetén is, de az a szolgátatók kezelésében van – uplink vagy CSP interfészén értelmeződik. Csak egy T1-hez csatolt két hálózat közötti forgalom nem járja meg az uplink interfész, nem lehet ott szűrni. Mit lehet akkor hát tenni?
Ötletek:
- Létrehozni egy másik T1-et – Edge Gateway a VCD-ben a neve – az alá kötni a másik hálózatot és kész. Ez azért nem megvalósítható, mert ha a T0-n, amihez egy T1 kapcsolva van, azon stateful dolgot akar valaki haszálni – dinamikus routing például – akkor az a T0 dedikálását igényli, így a T1 és T0 kapcsolata 1:1 lesz. Szóval nem lehet egy T0 alatt több T1.
- VM formtáumú firewall appliance használata. Kivitelezhető, de a tenant számára ez egy újabb VM, aminek költsége van.
A megoldás az, hogy egy újabb T1-et kell létrehozni, amit CSP interfészen keresztül össze kell kötni a fenti képen látható T1-el. Itt is adódik az a probléma, hogy kell egy T0, mert T1 a VCD-ben nem lehet T0 nélkül, de az lehet egy VRF például, aminek még uplink interfészei sem lesznek.
A két T1 összekötésére használható VLAN és overlay szegmens is – de bármelyiket is valósítjuk meg – a tenant maga, ezt egyedül nem képes beállítani, egészen egyszerűen azért, mert nem hozhat létre ilyen hálózatokat. Az overlay szegmens preferált és a fenti képen is az látszik. Az overlay szegmens a példában 172.16.50.0/29, de ezen a hálózaton gateway-re nincs is szükség.
A T1-Edge-GW01 a 172.16.50.1/29, a T1-Edge-GW02 a 172.16.50.2 IP-címmel van felkonfigurálva a tranziton. A T1-ek között dinamikus routing nem valósítható meg, ezért a statikus route-okat kézzel szükséges felvenni. A T1-Edge-GW01-en így tehát az összes olyan hálózat, ami a T1-Edge-GW02 mögött van – a példában egy ilyen van, a 192.168.20.0/24 – a 172.16.50.2 felé van. A T1-Edge-GW02-n pedig gyakorlatilag a default route mutathat a T1-Edge-GW01 CSP interfésze felé, azaz a 182.16.50.1 felé. Feltűnhet az, hogy miért is kell felvenni a 0.0.0.0/1-et és a 128.0.0.0/1-et és nem a 0.0.0.0/0-át. Azért, mert a T1 és a T0 kapcsolata olyan kizárólagos, hogy előbbi routing táblájában a 0.0.0.0/0 megváltoztathatatlanul a T0 felé mutat. Ebből fakad az, hogy specifikusabb route-tal kell ráerőszakolni, hogy ne a T0 felé, hanem a másik T1 felé küldjön mindent.
A szolgáltató feladata
A tranzitra használt hálózat – overlay vagy VLAN – létrehozása, NSX-ben. Nem kell Gateway-hez csatolni, nem kell gateway IP-sem.
A következő lépés az „External Network” létrehozása a fenti NSX overlay szegmensen alapulva, Cloud Director-ban. Ennek értelmében az alábbi képen az „NSX-T Segments” opciót kell kiválasztani.
Az elnevezés bármi lehet, de érdemes elkerülni a további abszrakciós szinteket.
A következő lépésben a korábba létrehozott szegmenssel való összerendelést adjuk meg.
A következő az a pont, amikor a kívánt tranzit IP-címzés megadható, a példámban a 172.16.50.0/29. Itt érdemes előre tervezni, mivel a pool mérete befolyásolja, hogy hány T1-et lehet ilyen módon összekapcsolni.
Az összefolgaló lépésben látható, mit állítottunk be.
Tenant/Provider feladata
A következő lépés az, hogy a fenti szegmenst ténylegesen a T1-ekhez csatoljuk és IP-címet adjunk az interfészeiknek. Ez a lépés lehet a szolgáltató feladata, de a jog delegálható a tenantnak is.
A kövketkező lépést, mindkét Edge Gateway-en végre kell hajtani – vagy még többön, attól függ hány Edge Gateway-et szereténk így összekötni.
Az IP beállítását nem lehet eltéveszteni, a korábban megadott pool-ból automatikusan is képes kiszotani egyet, de manuálisan is megadható a kívánt IP. Utóbbit javaslom, hiszen static route-ot fogunk használni, bár maga az IP nem változik amúgy sem.
A másik Edge Gateway-en értelemszerűen a 172.16.50.1-es IP-t állítom be.
Statikus útvonalak beállítása
Ebben a lépésben állítjuk be a T1-EdgeGW-01-en a másik T1-hez kapcsolt hálózat elérésének útvonalát.
asda
Hasonlóan a T1-EdgeGW-02-n a két route-ot – a specifikus útvonalakat – a T1-EdgeGW-01 felé.
T1-EdgeGW-01-en a T1-EdgeGW-02 felé.
Tűzfal beállítása
Ezen a ponton a két hálózat minden bizonnyal már eléri egymást, ellenőrizzük is le. A 192.168.10.0/24-es hálózatban lévő VM-ről elérhető az internet is és a 192.168.20.0/24-es hálózatban a másik virtuális gép is.
Nézzük meg ugyanezt visszafelé is.
Ezzel megbizonyosodhattunk arról, hogy elérik egymást, de pont az volt a cél hogy ne érjék el egymást. Három lehetőség van:
- T1-EdgeGW-01-en szűrni a bejövő forgalmat
- T1-EdgeGW-02-n szűrni a kimenő forgalmat
- mindkettőn szűrni
A harmadik esetet mutatom meg. Ehhez az Edge Gateway-en kell a tűzfalat átállítani. Ehhez javaslom az IP set-ek használatát, hozzuk is létre őket. A T1-EdgeGW-02-n egy olyat, amiben a hozzá kapcsolt hálózat(ok) vannak.
Hasonlóan azokat is, amelyek a másik T1 mögött vannak.
Hozzuk létre tehát a blokkoló szabályt az T1-EdgeGW-02-n.
Ebben a pillanatban a kommunikáció meg is szakad a kettő között, de például az internet továbbra is elérhető.
Ezen a ponton a T1-EdgeGW-01-hez kötött hálózat még eléri a T1-EdgeGW-02 mögötti hálózatot, mivel az egy másik irány. Ugyanakkor állítsuk be azt – bár felesleges – hogy a T1-EdgeGW-02-es hálózatokból ne legyen elérhető a T1-EdgeGW-01-es hálózat – cél oldalon is szűrjünk.
Összefoglaló
Nem mikroszegmentáció, mert a distributed firewall-t nem váltja ki, de zónaelválasztó tűzfal nagyon egyszerűen megvalósítható. Nem Cloud Director-ban kezelt környezetben is használható megoldás, bár akkor NSX-ben kell állítgatni.
