Kaskada SoftEther: świadomie połącz dwa wirtualne huby
Kaskada łączy lokalny hub z odległym pod skonfigurowaną tożsamością. Nie jest węzłem wyjściowym i przenosi wszystko, co te huby już mostkują.
Dwa huby SoftEther połączone kaskadą dzielą jedną domenę rozgłoszeniową, więc pętla lub drugi serwer DHCP przestaje być lokalnym błędem i staje się błędem wspólnym. To cały model ryzyka. Sama kaskada to skonfigurowana relacja klienta: lokalny hub wirtualny łączy się na zewnątrz z hubem zdalnego serwera pod tożsamością, którą ten serwer autoryzuje. To klocek większej sieci wirtualnej, nigdy wyjście do internetu.
1. Zdecyduj, co ma przenosić łącze
Zacznij od wymagania, nie od funkcji. Kaskada przenosi ramki drugiej warstwy między hubami, i tego właśnie chcesz, gdy dwie lokalizacje mają wyglądać jak jeden segment Ethernet. Jeśli potrzeba to tylko trasowany dostęp do kilku podsieci, trasowana ścieżka jest prostsza i zawodzi w sposób łatwiejszy do zauważenia. Wybór kaskady wiąże cię ze wspólnym rozgłaszaniem, wspólnym wykrywaniem i jedną topologią pętli.
Zapisz wymaganie w jednej linii, zanim dotkniesz serwera: które systemy mają wyglądać, jakby były na tym samym kablu, a którym wystarczy trasa. Wszystko, co odpowiada «trasa», należy poza kaskadę. To jedno zdanie zapobiega większości projektów, które kończą się zduplikowanymi usługami adresów.
2. Ogranicz tożsamość, która to autoryzuje
Poświadczenia, którymi administruje się serwer, i tożsamość, której kaskada używa do połączenia, to różne sekrety, a ich mieszanie to częsty skrót z długim ogonem. Zdalny hub potrzebuje wpisu użytkownika lub zasady, który pozwala tej kaskadzie się połączyć. Ten wpis to autoryzacja; udane logowanie nie mówi nic o tym, co stoi za zdalnym hubem.
Zapisz, który hub inicjuje, do którego zdalnego hubu dołącza i co może osiągnąć zdalna tożsamość. Zanim się zobowiążesz, porównaj obie architektury:
| 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 |
Utrzymuj aktualne poświadczenia i instrukcje odzyskiwania po obu stronach. Zmiana hasła lub edycja zasady na zdalnym hubie zrywa kaskadę, nie dotykając twoich lokalnych użytkowników, a awaria zwykle objawia się jako łącze, które jest aktywne, ale puste.
3. Sprawdź, co hub już przenosi
Hub rzadko jest odizolowany. Może już mostkować fizyczny adapter, trasować przez wirtualny router lub kaskadować gdzie indziej, a każde z tych przyłączeń trafia do nowej relacji. Dlatego «połączyliśmy tylko dwa huby» tak często zamienia się w «dlaczego te dwie lokalizacje to teraz jeden segment?».
Dwa huby mostkowane do tego samego segmentu fizycznego, a potem kaskadowane jeden do drugiego, tworzą pętlę. Dodaj spanning tree albo tego nie buduj. Ten sam test dotyczy hubu, który już osiąga cel przez inną kaskadę: drugie łącze nie dodaje przepustowości, dodaje ścieżkę.
Nie dodawaj łącza, bo brakuje jednej trasy; napraw trasę. Najpierw narysuj topologię na papierze, wraz z każdym mostem i kaskadą, bo diagram zajmuje dwie minuty i łapie większość pętli, zanim powstaną.
4. Uporządkuj adresację przed dołączeniem
Połączone segmenty przynoszą zduplikowane podsieci, a zduplikowane serwery DHCP to klasyczny objaw: klienci biorą dzierżawę od serwera, który odpowie pierwszy, więc zachowanie wygląda losowo i przemieszcza się między restartami. Zdecyduj z góry, która strona odpowiada za przydział adresów, i daj dalekiemu segmentowi zakres, który nie nakłada się na nic lokalnego. Wyłącz drugą usługę DHCP, zanim kaskada będzie online, a nie po pierwszej skardze.
DNS to osobne pytanie. Kaskada przenosi ramki; nie konfiguruje resolverów, a nazwa rozwiązywana po stronie lokalnej może nie rozwiązywać się przez łącze. Testuj zapytanie osobno od ścieżki IP, bo działający ping dowodzi tylko jednego z dwóch.
5. Udowodnij to rzeczywistym zasobem
Wybierz dozwoloną usługę w docelowym dalekim segmencie i potwierdź, że odpowiedź wraca przez kaskadę. Potem powtórz to dla rozwiązywania nazw. Jeśli cel opiera się na wykrywaniu rozgłoszeniowym, spodziewaj się innego zachowania na mostkowanym łączu niż na jednym kablu, i zaplanuj to, zamiast zapisywać jako defekt.
Na koniec zapisz topologię: który hub gdzie kaskaduje, która tożsamość to autoryzuje, które segmenty są mostkowane i kto odpowiada za przydział adresów na każdym. Ta notatka pozwala następnej osobie zmienić zasadę bez wyłączania segmentu, o którego istnieniu nie wiedziała.