Cascadă SoftEther: leagă două huburi virtuale intenționat
O cascadă leagă un hub local de unul la distanță sub o identitate configurată. Nu este un nod de ieșire și transportă tot ce acele huburi pun deja în punte.
Două huburi SoftEther legate printr-o cascadă împart un singur domeniu de difuzare, așa că o buclă sau un al doilea server DHCP încetează să fie o greșeală locală și devine una comună. Acesta este întregul model de risc. Cascada în sine este o relație de client configurată: hubul virtual local se conectează spre exterior la hubul unui server la distanță sub o identitate pe care acel server o autorizează. Este o piesă pentru o rețea virtuală mai mare, niciodată o ieșire în internet.
1. Decideți ce trebuie să transporte legătura
Începeți de la cerință, nu de la funcție. O cascadă mută cadre de nivel doi între huburi, și asta doriți când două locații trebuie să pară un singur segment Ethernet. Dacă nevoia este doar acces rutat la câteva subrețele, o cale rutată este mai simplă și eșuează în moduri mai ușor de văzut. Alegerea unei cascade vă obligă la difuzare comună, descoperire comună și o singură topologie de buclă.
Scrieți cerința într-o singură linie înainte de a atinge un server: ce sisteme trebuie să pară că sunt pe același cablu și care au nevoie doar de o rută. Tot ce răspunde „o rută” rămâne în afara cascadei. Această singură frază evită majoritatea proiectelor care se termină cu servicii de adrese duplicate.
2. Delimitați identitatea care o autorizează
Acreditările care administrează un server și identitatea pe care o cascadă o folosește pentru conectare sunt secrete diferite, iar amestecarea lor este o scurtătură obișnuită cu coadă lungă. Hubul la distanță are nevoie de o intrare de utilizator sau de politică ce permite acestei cascade să se conecteze. Acea intrare este autorizarea; o autentificare reușită nu spune nimic despre ce se află în spatele hubului la distanță.
Înregistrați care hub inițiază, cărui hub la distanță se alătură și ce poate atinge identitatea la distanță. Comparați cele două arhitecturi înainte de a vă angaja:
| 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 |
Mențineți actualizate acreditările și instrucțiunile de recuperare ale ambelor capete. O schimbare de parolă sau o editare de politică pe hubul la distanță rupe cascada fără a atinge utilizatorii locali, iar defectul apare de obicei ca o legătură activă dar goală.
3. Inspectați ce transportă deja hubul
Un hub este rareori izolat. Poate deja pune în punte un adaptor fizic, rutează printr-un router virtual sau cascadează altundeva, iar fiecare dintre aceste conexiuni este dusă în noua relație. De aceea „am legat doar două huburi” se transformă atât de des în „de ce aceste două locații sunt acum un singur segment?”.
Două huburi puse în punte în același segment fizic și apoi cascadate unul spre celălalt formează o buclă. Adăugați spanning tree sau nu îl construiți. Același test se aplică unui hub care atinge deja ținta printr-o altă cascadă: o a doua legătură nu adaugă capacitate, adaugă o cale.
Nu adăugați o legătură pentru că lipsește o rută; reparați ruta. Desenați mai întâi topologia pe hârtie, inclusiv fiecare punte și cascadă, pentru că diagrama durează două minute și prinde majoritatea buclelor înainte de a exista.
4. Rezolvați adresarea înainte de unire
Segmentele unite aduc subrețele duplicate, iar serverele DHCP duplicate sunt simptomul clasic: clienții iau un lease de la serverul care răspunde primul, așa că comportamentul pare aleatoriu și se mută între reporniri. Decideți dinainte ce parte deține atribuirea adreselor și dați segmentului îndepărtat un interval care nu se suprapune cu nimic local. Dezactivați celălalt serviciu DHCP înainte ca cascada să fie online, nu după prima reclamație.
DNS este o întrebare separată. O cascadă transportă cadre; nu configurează resolveri, iar un nume care se rezolvă pe partea locală poate să nu se rezolve prin legătură. Testați interogarea separat de calea IP, pentru că un ping funcțional dovedește doar una din două.
5. Dovediți-o cu o resursă reală
Alegeți un serviciu permis pe segmentul îndepărtat dorit și confirmați că răspunsul se întoarce prin cascadă. Apoi repetați pentru rezolvarea numelor. Dacă ținta se bazează pe descoperire prin difuzare, așteptați-vă la un comportament diferit pe o legătură pusă în punte decât pe un singur cablu, și planificați asta în loc să o înregistrați ca defect.
În final, scrieți topologia: care hub cascadează unde, ce identitate o autorizează, ce segmente sunt puse în punte și cine deține atribuirea adreselor pe fiecare. Acea notă este ce îi permite persoanei următoare să schimbe o politică fără a doborî un segment despre care nu știa că există.