Kaskada SoftEther: zavestno povežite dva virtualna huba
Kaskada poveže lokalni hub z oddaljenim pod konfigurirano identiteto. Ni izhodno vozlišče in prenaša vse, kar ti hubi že premostijo.
Dva huba SoftEther, povezana s kaskado, si delita eno broadcast domeno, zato zanka ali drugi strežnik DHCP preneha biti lokalna napaka in postane skupna. To je celoten model tveganja. Sama kaskada je konfigurirano odjemalsko razmerje: lokalni virtualni hub se poveže navzven s hubom oddaljenega strežnika pod identiteto, ki jo ta strežnik dovoli. Je gradnik za večje virtualno omrežje, nikoli izhod v internet.
1. Odločite, kaj mora povezava prenašati
Začnite pri zahtevi, ne pri funkciji. Kaskada prenaša okvire druge plasti med hubi, in to je tisto, kar želite, ko morata dve lokaciji izgledati kot en sam segment Ethernet. Če je potreba le usmerjen dostop do nekaj podomrežij, je usmerjena pot preprostejša in odpove na bolj vidne načine. Izbira kaskade vas zaveže k skupnemu broadcastu, skupnemu odkrivanju in eni topologiji zanke.
Zapišite zahtevo v eno vrstico, preden se dotaknete strežnika: kateri sistemi morajo izgledati na isti žici in kateri potrebujejo le pot. Vse, kar odgovori »pot«, sodi izven kaskade. Ta edini stavek prepreči večino zasnov, ki se končajo s podvojenimi naslovnimi storitvami.
2. Omejite identiteto, ki to dovoli
Poverilnice, s katerimi se upravlja strežnik, in identiteta, ki jo kaskada uporablja za povezavo, so različne skrivnosti, njihovo mešanje pa je pogosta bližnjica z dolgim repom. Oddaljeni hub potrebuje vnos uporabnika ali pravilnika, ki tej kaskadi dovoli povezavo. Ta vnos je dovoljenje; uspešna prijava ne pove nič o tem, kaj stoji za oddaljenim hubom.
Zabeležite, kateri hub začne, kateremu oddaljenemu hubu se pridruži in kaj lahko doseže oddaljena identiteta. Preden se zavežete, primerjajte obe arhitekturi:
| Requirement | Routed path | Cascaded segment |
|---|---|---|
| Broadcast domain | Separate on each side | Shared across the link |
| Address service | One DHCP server per side | Must not run two on one domain |
| Loop risk | Route loops only | Layer-two loops if segments overlap |
Vzdržujte poverilnice in navodila za obnovitev obeh strani ažurne. Sprememba gesla ali urejanje pravilnika na oddaljenem hubu prekine kaskado, ne da bi se dotaknila vaših lokalnih uporabnikov, in napaka se običajno pokaže kot povezava, ki je aktivna, a prazna.
3. Preglejte, kaj hub že prenaša
Hub je redko izoliran. Morda že premosti fizični vmesnik, usmerja skozi virtualni usmerjevalnik ali kaskadira drugam, in vsaka od teh povezav se prenese v novo razmerje. Zato se »povezali smo le dva huba« tako pogosto spremeni v »zakaj sta ti dve lokaciji zdaj en segment?«.
Dva huba, premostena v isti fizični segment in nato kaskadirana eden na drugega, tvorita zanko. Dodajte spanning tree ali tega ne gradite. Isti test velja za hub, ki cilj že doseže po drugi kaskadi: druga povezava ne doda zmogljivosti, doda pot.
Ne dodajte povezave zato, ker manjka ena pot; popravite pot. Najprej narišite topologijo na papir, vključno z vsakim mostom in kaskado, ker diagram traja dve minuti in ujame večino zank, preden nastanejo.
4. Uredite naslavljanje pred povezovanjem
Povezani segmenti prinesejo podvojena podomrežja, podvojeni strežniki DHCP pa so klasičen simptom: odjemalci vzamejo najem pri strežniku, ki prvi odgovori, zato je vedenje videti naključno in se med ponovnimi zagoni seli. Vnaprej odločite, katera stran ima dodeljevanje naslovov, in oddaljenemu segmentu dajte obseg, ki se ne prekriva z ničimer lokalnim. Izklopite drugo storitev DHCP, preden gre kaskada v splet, ne po prvi pritožbi.
DNS je ločeno vprašanje. Kaskada prenaša okvire; ne konfigurira razreševalnikov, in ime, ki se razreši na lokalni strani, se morda ne bo razrešilo prek povezave. Preizkusite poizvedbo ločeno od poti IP, ker delujoč ping dokaže le eno od dveh.
5. Dokažite to z resničnim virom
Izberite dovoljeno storitev v predvidenem oddaljenem segmentu in potrdite, da se odgovor vrne skozi kaskado. Nato ponovite za razreševanje imen. Če je cilj odvisen od odkrivanja z broadcastom, pričakujte drugačno vedenje prek premostene povezave kot na eni žici, in to načrtujte, namesto da bi to zabeležili kot napako.
Na koncu zapišite topologijo: kateri hub kam kaskadira, katera identiteta to dovoli, kateri segmenti so premoščeni in kdo ima dodeljevanje naslovov na vsakem. Ta zapis omogoči naslednji osebi, da spremeni pravilnik, ne da bi zrušila segment, za katerega ni vedela, da obstaja.