ESXi gonbidatu VPN: bideratzea edo zubia, erabaki ataka-taldearen aurretik
Bideratutako TUN batek itzulera-bideak behar ditu; zubitutako TAP batek 2. geruzaren irismena eta ataka-taldeko politika zabalagoa. Finkatu rola promiscuous modua zabaldu aurretik.
Bideratu paketeak edo zabaldu Ethernet domeinua: ataka-taldearen aldaketa aukera horren ondoren dator. Helbide pribatua duen aplikazio batetik emaitzak berdinak dirudite, hipervisorearen eskakizunak erabat desberdinak diren bitartean. Horregatik zabaltzen da ataka-taldea lehenik eta diseinu-galderari bigarrenik erantzuten zaio, normalean broadcast ekaitz baten ondoren. Egin egiaztapen hauek ordenan eta gelditu eskakizuna oraindik lausoa den bitartean, inongo ataka-taldeko ezarpenek ez baitu inoiz aukeratu ez zen diseinu bat konpontzen.
Erabakia zerbitzuaren jabearena da; hipervisorearen konfigurazioak gauzatu egin behar du, ez ustekabean zehaztu.
Egiaztatu urruneko muturrak benetan zer behar duen
Zerrendatu urruneko bezeroek iritsi behar dituzten zerbitzuak eta erabiltzen dituzten protokoloak. Zerrenda prefijo ezagunetan dauden TCP zerbitzu gutxi batzuk bada, bideratzeak estaltzen du. Zerbait benetan 2. geruzako albokotasuna behar badu — broadcastaren mende dagoen aurkikuntza, IP ez diren protokoloak, ataka onartzen ez duen gailua — bideratzeak ezin du hori imitatu eta goiz esan behar da. Izan zintzoa zerrenda horretako IP ez diren sarrerekin, han huts egiten baitu isil-isilik bideratutako diseinuak astebete geroago.
Gero egiaztatu bezeroen multzoa. Bideratutako diseinuak helbide-barruti bat eta itzulera-bide esplizitua behar ditu urruneko aldean; zubitutako diseinuak Ethernet domeinu zabalduak helbide-esleipena eta isolamendua edukitzea behar du. Edozein aukeratuta ere, VM honetatik kanpoko norbaitek onartu behar du.
Zer eskatzen dion diseinu bakoitzak sare birtualari
Bi diseinuak sare birtualak zer jasan behar duen bereizten dira, eta taula da hori ikusteko modurik laburrena:
| Diseinua | Gonbidatu aldeko rola | Sare birtualak zer hartu behar duen | Hautapen okerraren hutsegite-modua |
|---|---|---|---|
| Bideratutako TUN | Bideratzailea prefijo bereizien artean | Bideratutako bezero-multzoa eta itzulera-bideak urruneko aldean | Bezeroak atakara iristen dira eta ez dira inoiz haren atzeko zerbitzura iristen |
| Zubitutako TAP | 2. geruzako zubia bat egiten duten bezeroentzat | Ethernet identitate gehigarriak, broadcast trafikoa eta VLAN arauak | vSwitch-ek markoak botatzen ditu, edo diseinuak inork onartu ez duen promiscuous modua behar du |
Bideratzeak broadcast domeinua bere lekuan uzten du eta ataka zeharkatzen duten zerbitzuak mugatzeko leku naturala ematen dizu. Zubiak muga mugitzen du: bezeroak Ethernet domeinu zabalduko partaide bihurtzen dira, eta helbide-esleipena, isolamendua eta 2. geruzako edozein politika haiei aplikatzen zaizkie orain. Idatzi hautatutako errenkada aldaketa-erregistroan. «Bideratutako TUN, bezero-multzoa 10.90.0.0/24, itzulera-bidea nukleoan» bezalako esaldi batek hurrengo ingeniariak ataka-taldeko ezarpenetatik diseinua berriz eztabaidatzea eragozten du.
Nork ikusi behar ditu nori dagozkion markoak
Egin galdera bat plataformaren jabeari ataka-taldera ukitu aurretik: diseinuak VM honek beste partaideei zuzendutako markoak jasotzea eskatzen al du? Erantzuna ez bada, atal honetako ezer ez da aplikatzen, bideratutako TUN batek ez baitu inoiz ikusgaitasun hori behar. Erantzuna bai bada, Broadcom-en promiscuous moduaren gida da irakurgai garrantzitsua: VMak vSwitch-etik zenbat gehiago ikus dezakeen azaltzen du eta politika hori ataka-talde bakarrera mugatzea gomendatzen du.
Hartu hau eskakizun-egiaztapen gisa, ez baimen gisa. Piztu ezarpena atxikimendu dedikatu bakarrerako zubitze-beharra idatzita dagoenean, eta utzi itzalita beste leku guztietan. Beste zubi-adibide batetik kopiatutako VLAN trunk zabala inork kentzea gogoratzen ez duen zatia da, eta VLAN bakarreko diseinuak VLAN bakarreko izan behar du.
Erregistratu zein ataka-talde aldatu zen eta zergatik, diseinuaren errenkada idatzi zenuen leku berean. Bikote horrek egiten du hurrengo auditoria posible.
Mantendu gonbidatuaren objektuak esplizitu
Linuxen barruan, zubiko kidetza eta helbide-jabetza objektu bereiziak dira, eta horiek nahasteak erdi-funtzionatzen duen egoera nahasia sortzen du. Esleitu helbideak zubiaren interfazeari edo bideratutako tunelari, ez bide beraren bi aldeei, eta mantendu kide diren atakak IP konfiguraziorik gabe.
Saihestu azpisare bat modu independentean bideratutako TUN batean eta erlazionik gabeko Ethernet interfaze batean jartzea. Konfigurazio horrek prefijo bererako bi bide sortzen ditu, erantzun asimetrikoak eta flapping-ari buruzko laguntza-haria, bi bideak aipatzen ez dituena. Gonbidatuak edukiontziak edo hipervisore lokal bat ere ostatatzen baditu, egiaztatu ez direla dagoeneko uplink berera zubitzen ari. NIC batean bi zubi diseinua da, ez aldaketa-leiho batean aurkitu nahi duzun istripua.
Egiaztatu pakete-bide batekin, ez ping batekin
Egiaztatu benetako bidea, ez soilik irisgarritasuna. Bezero batetik, egiaztatu zein iturburu-helbide iristen den urruneko zerbitzura, eta gero erantzuna bide beretik itzultzen dela. Gonbidatuan, egiaztatu fluxu zehatzaren birbidaltze-kontagailuak, eta ataka-taldean egiaztatu ez dela hautatutako diseinuak behar duenaz gaineko ikusgaitasunik gaitu.
Azkenik, probatu hutsegitearen noranzkoa. Gelditu tunela edo deskonektatu bezeroa eta egiaztatu trafikoak ez duela isil-isilik erabiltzen ez zela uste zenuen bideratutako bide batera erortzen, erorketa hori baita zubitutako diseinua isil-isilik nahi gabeko bideratzaile bihurtzeko modua.