SoftEther kaskada: svjesno povezati dva virtualna huba
Kaskada povezuje lokalni hub s udaljenim pod konfiguriranim identitetom. Nije izlazni čvor i prenosi sve što ti hubovi već premošćuju.
Dva SoftEther huba povezana kaskadom dijele jednu broadcast domenu, pa petlja ili drugi DHCP poslužitelj prestaje biti lokalna greška i postaje zajednička. To je cijeli model rizika. Sama kaskada je konfiguriran odnos klijenta: lokalni virtualni hub spaja se prema van 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 je jednostavnija i pada na načine koji se lakše vide. Odabir kaskade obavezuje 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 dupliciranim 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 je čest 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:
| 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 |
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 rijetko je 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 duplicirane podmreže, a duplicirani 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.