ESXi vendég VPN: útválasztás vagy áthidalás — döntsön a portcsoport előtt
Az útválasztott TUN visszatérési útvonalakat igényel; az áthidalt TAP 2. rétegű elérést és szélesebb portcsoport-szabályt. Rögzítse a szerepet, mielőtt kiszélesíti a promiscuous módot.
Irányítsa a csomagokat, vagy bővítse az Ethernet-tartományt: a portcsoport módosítása e döntés után következik. Egy privát című alkalmazás felől az eredmény azonosnak tűnhet, miközben a hypervisor követelményei egyáltalán nem hasonlítanak. Ezért előbb a portcsoportot szélesítik, és a tervezési kérdésre utána válaszolnak, általában egy broadcast-vihar után. Végezze el ezeket az ellenőrzéseket sorrendben, és álljon meg, amíg a követelmény még homályos, mert semmilyen portcsoport-beállítás nem javít meg egy soha meg nem választott tervezést.
A döntés a szolgáltatás tulajdonosáé; a hypervisor konfigurációjának végre kell hajtania, nem véletlenül meghatároznia.
Ellenőrizze, mire van valóban szüksége a távoli végnek
Sorolja fel azokat a szolgáltatásokat, amelyeket a távoli klienseknek el kell érniük, és a protokollokat, amelyeket használnak. Ha a lista néhány TCP-szolgáltatás ismert prefixeken, az útválasztás lefedi. Ha valaminek valóban 2. rétegű szomszédosságra van szüksége — broadcastfüggő felderítés, nem IP-protokollok, olyan eszköz, amely nem fogad el átjárót —, az útválasztás nem tudja utánozni, és ezt korán meg kell mondani. Legyen őszinte a listán szereplő nem IP-bejegyzésekkel kapcsolatban, mert ott bukik el csendben egy útválasztott tervezés egy héttel később.
Ezután ellenőrizze az ügyfélkészletet. Az útválasztott tervezéshez címtartomány és kifejezett visszatérési útvonal kell a távoli oldalon; az áthidalt tervezéshez a kiterjesztett Ethernet-tartománynak kell birtokolnia a címkiosztást és az elkülönítést. Bármit választ, valakinek ezen a VM-en kívül el kell fogadnia.
Mit kíván az egyes tervezések a virtuális hálózattól
A két tervezés abban különbözik, mit kell a virtuális hálózatnak elviselnie, és a táblázat mutatja meg a legrövidebben:
| Tervezés | Szerep a vendég oldalán | Mit kell a virtuális hálózatnak befogadnia | Hibamód rossz választás esetén |
|---|---|---|---|
| Útválasztott TUN | Útválasztó különálló prefixek között | Útválasztott ügyfélkészlet és visszatérési útvonalak a távoli oldalon | A kliensek elérik az átjárót, és soha nem érik el a mögötte lévő szolgáltatást |
| Áthidalt TAP | 2. rétegű híd a csatlakozó klienseknek | További Ethernet-identitások, broadcast-forgalom és VLAN-szabályok | A vSwitch eldobja a kereteket, vagy a tervezés olyan promiscuous módot igényel, amelyet senki sem hagyott jóvá |
Az útválasztás az eredeti helyén hagyja a broadcast-tartományt, és természetes helyet ad arra, hogy korlátozza, mely szolgáltatások lépik át az átjárót. Az áthidalás elmozdítja a határt: a kliensek a kiterjesztett Ethernet-tartomány résztvevőivé válnak, és a címkiosztás, az elkülönítés, valamint minden 2. rétegű szabály most rájuk vonatkozik. Írja be a választott sort a változásnaplóba. Egy „útválasztott TUN, ügyfélkészlet 10.90.0.0/24, visszatérési útvonal a magon” mondat megakadályozza, hogy a következő mérnök a portcsoport-beállításokból vitassa újra a tervezést.
Ki láthatja kinek a kereteit
Kérdezze meg a platform tulajdonosát egy dologról, mielőtt hozzányúl a portcsoporthoz: megköveteli-e a tervezés, hogy ez a VM más résztvevőknek címzett kereteket fogadjon? Ha a válasz nem, ebben a szakaszban semmi sem érvényes, mert egy útválasztott TUN soha nem igényli ezt a láthatóságot. Ha a válasz igen, akkor a Broadcom promiscuous módra vonatkozó útmutatója az az olvasmány, amely számít: kifejti, mennyivel többet lát a VM a vSwitchből, és azt javasolja, hogy ezt a szabályt egyetlen portcsoportra korlátozzák.
Kezelje ezt követelmény-ellenőrzésként, nem engedélyként. Kapcsolja be a beállítást egyetlen dedikált csatlakozáshoz, amikor az áthidalási igény írásban szerepel, és mindenhol máshol hagyja kikapcsolva. Egy másik híd-példából másolt széles VLAN-trunk az a rész, amelyet senki nem emlékszik eltávolítani, és az egyetlen VLAN-os tervezésnek egyetlen VLAN-osnak kell maradnia.
Jegyezze fel, melyik portcsoport változott és miért, ugyanott, ahol a tervezési sort leírta. Ez a páros teszi lehetővé a következő auditot.
Tartsa a vendég objektumait explicit módon
A Linuxon belül a híd-tagság és a címbirtoklás külön objektumok, és összemosásuk okozza a zavaró félműködő állapotot. A címeket a híd-interfésznek vagy az útválasztott alagútnak adja, ne ugyanazon útvonal két oldalának, és a tagportokat tartsa IP-konfiguráció nélkül.
Kerülje, hogy egy alhálózatot önállóan helyezzen egy útválasztott TUN-ra és egy nem kapcsolódó Ethernet-interfészre. Az ilyen konfiguráció két utat hoz létre ugyanahhoz a prefixhez, aszimmetrikus válaszokat és egy flappingről szóló támogatási szálat, amely egyik utat sem említi. Ha a vendég konténereket vagy helyi hypervisort is futtat, ellenőrizze, hogy azok nem hidaltak-e már ugyanabba az uplinkbe. Két híd egy NIC-n tervezés, nem olyan baleset, amelyet egy változási ablakban szeretne felfedezni.
Erősítse meg csomagúttal, ne pinggel
Ellenőrizze a tényleges utat, ne csak az elérhetőséget. Egy kliensről erősítse meg, melyik forrás cím érkezik meg a távoli szolgáltatáshoz, majd hogy a válasz ugyanazon az úton tér vissza. A vendégen ellenőrizze az adott folyamat továbbítási számlálóit, a portcsoporton pedig erősítse meg, hogy nem engedélyeztek a választott tervezés igényein túli láthatóságot.
Végül tesztelje a hiba irányát. Állítsa le az alagutat, vagy válassza le a klienst, és ellenőrizze, hogy a forgalom nem esik-e csendben vissza egy olyan útválasztott útra, amelyet használatlannak hitt, mert ez a visszaesés az, ahogyan egy áthidalt tervezés csendben nem szándékolt útválasztóvá válik.