SoftEther kaskada: svjesno povezati dva virtualna huba

Dva SoftEther huba povezana kaskadom dijele jednu broadcast domenu, pa petlja ili drugi DHCP poslužitelj prestaje biti lokalna pogreška i postaje zajednička. To je cijeli model rizika. Sama kaskada konfigurirani je odnos klijenta: lokalni virtualni hub spaja se na hub udaljenog poslužitelja pod identitetom koji taj poslužitelj odobrava. Ona je gradivni blok za veću virtualnu mrežu, nikada izlaz na internet.

1. Odlučite što veza mora prenositi

Pođite od zahtjeva, a ne od funkcije. Kaskada prenosi okvire drugog sloja između hubova, što je ono što želite kada dvije lokacije moraju izgledati kao jedan Ethernet segment. Ako je potreban samo rutirani pristup do nekoliko podmreža, rutirana staza jednostavnija je i pada na načine koji se lakše vide. Odabir kaskade obvezuje vas na zajednički broadcast, zajedničko otkrivanje i jednu topologiju petlje.

Napišite zahtjev u jednom redu prije nego dotaknete poslužitelj: koji sustavi moraju izgledati na istoj žici i kojima treba samo ruta. Sve što odgovara «ruta» pripada izvan kaskade. Ta jedna rečenica sprječava većinu dizajna koji završe s dvostrukim adresnim servisima.

2. Ograničite identitet koji to odobrava

Vjerodajnice kojima se administrira poslužitelj i identitet koji kaskada koristi za spajanje različite su tajne, a njihovo miješanje čest je prečac s dugim repom. Udaljeni hub treba unos korisnika ili pravila koji dopušta ovoj kaskadi da se spoji. Taj unos je odobrenje; uspješna prijava ne govori ništa o tome što stoji iza udaljenog huba.

Zabilježite koji hub inicira, kojem se udaljenom hubu pridružuje i što udaljeni identitet može dosegnuti. Usporedite dvije arhitekture prije nego se obvežete:

Održavajte vjerodajnice i upute za oporavak obaju strana aktualnima. Promjena lozinke ili uređivanje pravila na udaljenom hubu prekida kaskadu bez diranja vaših lokalnih korisnika, a kvar se obično pojavljuje kao veza koja je podignuta ali prazna.

3. Provjerite što hub već prenosi

Hub je rijetko izoliran. Možda već premošćuje fizički adapter, rutira kroz virtualni router ili kaskadira negdje drugdje, i svaki od tih priključaka prenosi se u novi odnos. Zato se «spojili smo samo dva huba» tako često pretvori u «zašto su ove dvije lokacije sada jedan segment?».

Dva huba premošćena u isti fizički segment i zatim kaskadirana jedan na drugi tvore petlju. Dodajte spanning tree ili to ne gradite. Isti test vrijedi za hub koji već doseže cilj kroz drugu kaskadu: druga veza ne dodaje kapacitet, dodaje stazu.

Ne dodajte vezu zato što nedostaje jedna ruta; popravite rutu. Prvo nacrtajte topologiju na papiru, uključujući svaki most i kaskadu, jer dijagram traje dvije minute i hvata većinu petlji prije nego nastanu.

4. Riješite adresiranje prije spajanja

Spojeni segmenti donose dvostruke podmreže, a dvostruki DHCP poslužitelji klasičan su simptom: klijenti uzimaju najam od poslužitelja koji prvi odgovori, pa ponašanje izgleda slučajno i seli se između ponovnih pokretanja. Unaprijed odlučite koja strana posjeduje dodjelu adresa i dajte dalekom segmentu raspon koji se ne preklapa ni s čim lokalnim. Isključite drugu DHCP uslugu prije nego kaskada postane online, a ne nakon prve pritužbe.

DNS je zasebno pitanje. Kaskada prenosi okvire; ne konfigurira rezolvere, a ime koje se razrješava na lokalnoj strani možda se neće razrješavati preko veze. Testirajte upit odvojeno od IP staze, jer uspješan ping dokazuje samo jedno od dvoga.

5. Dokažite to stvarnim resursom

Odaberite dopuštenu uslugu na željenom udaljenom segmentu i potvrdite da se odgovor vraća kroz kaskadu. Zatim ponovite za razrješavanje imena. Ako se cilj oslanja na otkrivanje broadcastom, očekujte drugačije ponašanje preko premošćene veze nego na jednoj žici, i planirajte to umjesto da to prijavite kao defekt.

Na kraju zapišite topologiju: koji hub kamo kaskadira, koji identitet to odobrava, koji su segmenti premošćeni i ko posjeduje dodjelu adresa na svakom. Ta bilješka omogućuje sljedećoj osobi da promijeni pravilo bez rušenja segmenta za koji nije znala da postoji.