Elekeza pakiti au panua kikoa cha Ethernet: mabadiliko ya kikundi cha bandari yanakuja baada ya chaguo hilo. Kwa mtazamo wa programu yenye anwani ya kibinafsi matokeo yanaweza kuonekana sawa, wakati mahitaji ya hypervisor hayafanani kabisa. Ndiyo sababu kikundi cha bandari hupanuliwa kwanza na swali la muundo hujibiwa pili, kwa kawaida baada ya dhoruba ya broadcast. Pitia ukaguzi huu kwa mpangilio na simama wakati hitaji bado halijafafanuka, kwa sababu hakuna mpangilio wa kikundi cha bandari unaorekebisha muundo ambao haukuchaguliwa kamwe.

Uamuzi ni wa mmiliki wa huduma; usanidi wa hypervisor unapaswa kuutekeleza, si kuubainisha kwa bahati.

Angalia kile mwisho wa mbali unachohitaji kwa kweli

Orodhesha huduma ambazo wateja wa mbali wanapaswa kufikia na itifaki wanazotumia. Ikiwa orodha ni huduma chache za TCP kwenye viambishi vinavyojulikana, uelekezaji unatosha. Ikiwa kitu kwa kweli kinahitaji ujirani wa tabaka 2 — ugunduzi unaotegemea broadcast, itifaki zisizo za IP, kifaa kisichokubali lango — uelekezaji hauwezi kuiga hilo na ni lazima lisemwe mapema. Kuwa mwaminifu kuhusu maingizo yasiyo ya IP kwenye orodha hiyo, kwa sababu hapo ndipo muundo ulioelekezwa unashindwa kimya wiki moja baadaye.

Kisha angalia bwawa la wateja. Muundo ulioelekezwa unahitaji kiwango cha anwani na njia ya kurudi iliyo wazi upande wa mbali; muundo uliodarajiwa unahitaji kikoa kilichopanuliwa cha Ethernet kimiliki ugawaji wa anwani na utengano. Chochote utakachochagua, mtu nje ya VM hii lazima akubali.

Kila muundo unahitaji nini kutoka kwa mtandao pepe

Miwili ya miundo inatofautiana katika kile mtandao pepe unapaswa kuvumilia, na jedwali ndiyo njia fupi zaidi ya kuona hilo:

MuundoJukumu upande wa mgeniKile mtandao pepe unapaswa kuchukuaHali ya kushindwa ukichagua vibaya
TUN iliyoelekezwaKipanga njia kati ya viambishi tofautiBwawa la wateja lililoelekezwa pamoja na njia za kurudi upande wa mbaliWateja wanafikia lango na hawafikii kamwe huduma iliyo nyuma yake
TAP iliyodarajiwaDaraja la tabaka 2 kwa wateja wanaojiungaVitambulisho vya ziada vya Ethernet, trafiki ya broadcast na kanuni za VLANvSwitch hutupa fremu, au muundo unahitaji hali ya promiscuous ambayo hakuna aliyeeidhinisha

Uelekezaji unaacha kikoa cha broadcast mahali kilipo na unakupa mahali pa asili pa kupunguza huduma zipi zinazovuka lango. Udarajishaji unasogeza mpaka: wateja wanakuwa washiriki katika kikoa kilichopanuliwa cha Ethernet, na ugawaji wa anwani, utengano na sera yoyote ya tabaka 2 sasa zinawahusu. Andika safu iliyochaguliwa katika rekodi ya mabadiliko. Sentensi kama «TUN iliyoelekezwa, bwawa la wateja 10.90.0.0/24, njia ya kurudi kwenye kiini» inamzuia mhandisi anayefuata kujadili tena muundo kutoka kwa mipangilio ya kikundi cha bandari.

Nani anapaswa kuruhusiwa kuona fremu za nani

Muulize mmiliki wa jukwaa swali moja kabla ya kugusa kikundi cha bandari: je, muundo unahitaji VM hii ipokee fremu zilizoelekezwa kwa washiriki wengine? Ikiwa jibu ni hapana, hakuna chochote katika sehemu hii kinachotumika, kwa sababu TUN iliyoelekezwa haiitaji kamwe mwonekano huo. Ikiwa jibu ni ndiyo, basi mwongozo wa Broadcom kuhusu hali ya promiscuous ndiyo usomaji muhimu: unaeleza ni kiasi gani zaidi cha vSwitch ambacho VM inaweza kuona na unapendekeza sera hiyo iwekwe kwenye kikundi kimoja cha bandari.

Chukulia hili kama ukaguzi wa hitaji, si kibali. Washa mpangilio kwa muunganisho mmoja maalum wakati hitaji la daraja limeandikwa, na uiache imezimwa kila mahali pengine. Trunk pana ya VLAN iliyonakiliwa kutoka mfano mwingine wa daraja ni sehemu ambayo hakuna anayekumbuka kuiondoa, na muundo wa VLAN moja unapaswa kubaki VLAN moja.

Rekodi ni kikundi kipi cha bandari kilichobadilika na kwa nini, mahali pale pale ulipoandika safu ya muundo. Jozi hilo ndilo linalowezesha ukaguzi unaofuata.

Weka vitu vya mgeni wazi

Ndani ya Linux, uanachama wa daraja na umiliki wa anwani ni vitu tofauti, na kuvichanganya husababisha hali ya kuchanganya inayofanya kazi nusu. Toa anwani kwa kiolesura cha daraja au kwa handaki iliyoelekezwa, si kwa pande zote mbili za njia moja, na weka bandari wanachama bila usanidi wa IP.

Epuka kuweka subnet moja kwa kujitegemea kwenye TUN iliyoelekezwa na kwenye kiolesura cha Ethernet kisichohusiana. Usanidi huo huzalisha njia mbili kwenda kiambishi kimoja, majibu yasiyolingana na uzi wa msaada kuhusu flapping ambao hautaji njia yoyote kati ya hizo. Ikiwa mgeni pia anapangisha kontena au hypervisor ya ndani, angalia kwamba hazijadarajisha tayari kwenye uplink hiyo hiyo. Daraja mbili kwenye NIC moja ni muundo, si ajali unayotaka kuigundua wakati wa dirisha la mabadiliko.

Thibitisha kwa njia ya pakiti, si kwa ping

Thibitisha njia halisi, si ufikiaji tu. Kutoka kwa mteja, thibitisha ni anwani gani ya chanzo inayofika kwenye huduma ya mbali, kisha kwamba jibu linarudi kwa njia hiyo hiyo. Kwenye mgeni, angalia vihesabu vya upelekaji kwa mtiririko maalum, na kwenye kikundi cha bandari thibitisha kwamba hakuna mwonekano wa ziada uliowashwa zaidi ya ule unaohitajika na muundo uliochaguliwa.

Mwisho, jaribu mwelekeo wa kushindwa. Simamisha handaki au tenganisha mteja na uangalie kwamba trafiki haianguki kimya kwenye njia iliyoelekezwa uliyodhani haitumiki, kwa sababu kuanguka huko ndiko kunakofanya muundo uliodarajiwa kuwa kipanga njia kisichokusudiwa kimya.

Makala zinazohusiana