ESXi-gasta VPN: enkursigi aŭ ponti — decidu antaŭ la pordogrupo
Enkursigita TUN bezonas revenajn vojojn; pontita TAP bezonas atingon de tavolo 2 kaj pli larĝan pordogrupan politikon. Fiksu la rolon antaŭ ol vastigi la promiscuous-reĝimon.
Enkursigu la pakojn aŭ etendu la Ethernet-domajnon: la ŝanĝo de la pordogrupo sekvas tiun elekton. El aplikaĵo kun privata adreso la rezultoj povas aspekti identaj, dum la postuloj de la hipervizoro tute malsamas. Tial la pordogrupo unue vastiĝas kaj la dezajna demando respondiĝas due, kutime post dissenda ŝtormo. Trapasu ĉi tiujn kontrolojn laŭ ordo kaj haltu dum la postulo ankoraŭ estas malklara, ĉar neniu pordogrupa agordo riparas dezajnon, kiun oni neniam elektis.
La decido apartenas al la posedanto de la servo; la hipervizora agordo devas ĝin efektivigi, ne hazarde difini.
Kontrolu, kion la fora fino vere bezonas
Listigu la servojn, kiujn la remotaj klientoj devas atingi, kaj la protokolojn, kiujn ili uzas. Se la listo estas kelkaj TCP-servoj sur konataj prefiksoj, enkursigado sufiĉas. Se io vere bezonas najbarecon de tavolo 2 — dissende dependan malkovron, ne-IP protokolojn, aparaton, kiu ne akceptas enirejon — enkursigado ne povas tion imiti kaj tion oni diru frue. Estu honesta pri la ne-IP eroj en tiu listo, ĉar tie enkursigita dezajno silente fiaskas semajnon poste.
Poste kontrolu la klientan naĝejon. Enkursigita dezajno bezonas adresan aron kaj eksplicitan revenan vojon ĉe la fora flanko; pontita dezajno bezonas, ke la etendita Ethernet-domajno posedu adresan asignadon kaj izoladon. Kion ajn vi elektos, iu ekster ĉi tiu VM devas konsenti pri ĝi.
Kion ĉiu dezajno postulas de la virtuala reto
La du dezajnoj malsamas en tio, kion la virtuala reto devas toleri, kaj la tabelo estas la plej mallonga maniero vidi tion:
| Dezajno | Rolo ĉe la gasta flanko | Kion la virtuala reto devas akcepti | Fiaskmaniero se vi elektas malĝuste |
|---|---|---|---|
| Enkursigita TUN | Enkursigilo inter apartaj prefiksoj | Enkursigita klienta naĝejo plus revenaj vojoj ĉe la fora flanko | Klientoj atingas la enirejon kaj neniam atingas la servon malantaŭ ĝi |
| Pontita TAP | Ponto de tavolo 2 por la klientoj, kiuj aliĝas | Pliaj Ethernet-identecoj, dissenda trafiko kaj VLAN-reguloj | La vSwitch faligas kadrojn, aŭ la dezajno bezonas promiscuous-reĝimon, kiun neniu aprobis |
Enkursigado lasas la dissendan domajnon tie, kie ĝi estas, kaj donas naturan lokon por limigi, kiuj servoj transiras la enirejon. Pontado movas la limon: la klientoj fariĝas partoprenantoj en la etendita Ethernet-domajno, kaj adresa asignado, izolado kaj ajna tavolo-2 politiko nun aplikiĝas al ili. Skribu la elektitan vicon en la ŝanĝprotokolon. Frazo kiel „enkursigita TUN, klienta naĝejo 10.90.0.0/24, revena vojo sur la kerno“ malhelpas la sekvan inĝenieron reargumenti la dezajnon el la pordogrupaj agordoj.
Kiu rajtas vidi kies kadrojn
Demandu la posedanton de la platformo unu aferon antaŭ ol tuŝi la pordogrupon: ĉu la dezajno postulas, ke ĉi tiu VM ricevu kadrojn adresitajn al aliaj partoprenantoj? Se la respondo estas ne, nenio en ĉi tiu sekcio aplikiĝas, ĉar enkursigita TUN neniam bezonas tiun videblecon. Se la respondo estas jes, la gvidilo de Broadcom pri promiscuous-reĝimo estas la legaĵo, kiu gravas: ĝi klarigas, kiom pli de la vSwitch la VM povas vidi, kaj rekomendas limigi tiun politikon al unu pordogrupo.
Traktu tion kiel postulkontrolon, ne kiel permesilon. Ŝaltu la agordon por unu dediĉita konekto, kiam la pontbezono estas skribita, kaj lasu ĝin malŝalta ĉie alie. Larĝa VLAN-trunk kopiita el alia ponta ekzemplo estas la parto, kiun neniu memoras forigi, kaj unu-VLANa dezajno devus resti unu-VLANa.
Registru, kiu pordogrupo ŝanĝiĝis kaj kial, en la sama loko, kie vi skribis la dezajnan vicon. Tiu paro ebligas la sekvan revizion.
Tenu la objektojn de la gasto eksplicitaj
Ene de Linux, ponta membreco kaj adresa posedo estas apartaj objektoj, kaj ilia kunfandiĝo kaŭzas la konfuzan duonfunkciantan staton. Asignu adresojn al la ponta interfaco aŭ al la enkursigita tunelo, ne al ambaŭ flankoj de la sama vojo, kaj tenu la membrajn pordojn sen IP-agordo.
Evitu meti unu subreton sendepende sur enkursigitan TUN kaj sur nerilatan Ethernet-interfacon. Tiu agordo produktas du vojojn al la sama prefikso, nesimetriajn respondojn kaj subtenan fadenon pri flapping, kiu mencias neniun el la vojoj. Se la gasto ankaŭ gastigas ujojn aŭ lokan hipervizoron, kontrolu, ke ili jam ne pontas en la saman uplink. Du pontoj sur unu NIC estas dezajno, ne akcidento, kiun vi volas malkovri dum ŝanĝa fenestro.
Konfirmu per paka vojo, ne per ping
Kontrolu la faktan vojon, ne nur atingeblon. De kliento konfirmu, kiu fontadreso alvenas al la fora servo, poste ke la respondo revenas la saman vojon. Sur la gasto kontrolu la plusendajn nombrilojn por la konkreta fluo, kaj sur la pordogrupo konfirmu, ke neniu plia videbleco estis ŝaltita super tio, kion bezonas la elektita dezajno.
Fine testu la fiaskdirekton. Haltigu la tunelon aŭ malkonektu la klienton kaj kontrolu, ke la trafiko ne silente refalas al enkursigita vojo, kiun vi pensis neuzata, ĉar tiu refalo estas kiel pontita dezajno silente fariĝas neintenca enkursigilo.