SoftEther-kaskade: forbind to virtuelle hubs med vilje
En kaskade forbinder en lokal hub med en fjern under en konfigureret identitet. Den er ikke en udgangsnode, og den bærer alt, hvad disse hubs allerede bygger bro mellem.
To SoftEther-hubs forbundet med en kaskade deler ét broadcast-domæne, så en løkke eller en anden DHCP-server holder op med at være en lokal fejl og bliver en fælles. Det er hele risikomodellen. Selve kaskaden er et konfigureret klientforhold: den lokale virtuelle hub forbinder ud til en fjernservers hub under en identitet, som serveren tillader. Den er en byggeklods til et større virtuelt netværk, aldrig en internetudgang.
1. Beslut, hvad linket skal bære
Start med kravet, ikke med funktionen. En kaskade flytter lag-to-rammer mellem hubs, og det er det, du vil have, når to lokationer skal se ud som ét Ethernet-segment. Hvis behovet kun er rutet adgang til nogle få subnets, er en rutet vej enklere og fejler på måder, der er lettere at se. Når du vælger en kaskade, binder du dig til fælles broadcast, fælles opdagelse og én løkketopologi.
Skriv kravet på én linje, før du rører en server: hvilke systemer skal se ud til at være på samme ledning, og hvilke har kun brug for en rute. Alt, der svarer «en rute», hører uden for kaskaden. Denne ene sætning forhindrer de fleste designs, der ender med dobbelte adressetjenester.
2. Afgræns den identitet, der autoriserer det
De legitimationsoplysninger, der administrerer en server, og den identitet, en kaskade bruger til at forbinde, er forskellige hemmeligheder, og at blande dem er en almindelig genvej med lang hale. Fjernhubben har brug for en bruger- eller politikpost, der tillader denne kaskade at forbinde. Den post er autorisationen; et vellykket login siger intet om, hvad der ligger bag fjernhubben.
Notér, hvilken hub der tager initiativet, hvilken fjern hub den tilslutter sig, og hvad den fjern identitet kan nå. Sammenlign de to arkitekturer, før du forpligter dig:
| 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 |
Hold begge enders legitimationsoplysninger og gendannelsesinstrukser opdaterede. En adgangskodeændring eller politikredigering på fjernhubben bryder kaskaden uden at røre dine lokale brugere, og fejlen viser sig normalt som et link, der er oppe men tomt.
3. Undersøg, hvad hubben allerede bærer
En hub er sjældent isoleret. Den bygger måske allerede bro til en fysisk adapter, ruter gennem en virtuel router eller kaskaderer et andet sted, og hver af disse tilknytninger følger med ind i det nye forhold. Derfor bliver «vi forbandt bare to hubs» så ofte til «hvorfor er disse to lokationer nu ét segment?».
To hubs, der er bygget bro mellem til samme fysiske segment og derefter kaskaderet til hinanden, danner en løkke. Tilføj spanning tree, eller byg det ikke. Den samme prøve gælder for en hub, der allerede når målet gennem en anden kaskade: et andet link tilføjer ikke kapacitet, det tilføjer en vej.
Tilføj ikke et link, fordi en rute mangler; ret ruten. Tegn topologien på papir først, inklusive hver bro og kaskade, fordi diagrammet tager to minutter og fanger de fleste løkker, før de findes.
4. Ryd op i adressering før sammenkobling
Sammenføjede segmenter bringer dobbelte subnets, og dobbelte DHCP-servere er det klassiske symptom: klienter tager en lease fra den server, der svarer først, så adfærden virker tilfældig og flytter sig mellem genstarter. Beslut på forhånd, hvilken side der ejer adressetildelingen, og giv det fjerne segment et interval, der ikke overlapper noget lokalt. Deaktiver den anden DHCP-tjeneste, før kaskaden kommer online, ikke efter den første klage.
DNS er et separat spørgsmål. En kaskade bærer rammer; den konfigurerer ikke resolvere, og et navn, der opløses på den lokale side, opløses måske ikke over linket. Test opslaget separat fra IP-vejen, fordi en fungerende ping kun beviser én af de to.
5. Bevis det med en rigtig ressource
Vælg en tilladt tjeneste på det tilsigtede fjerne segment, og bekræft, at svaret kommer tilbage gennem kaskaden. Gentag derefter for navneopløsning. Hvis målet er afhængigt af broadcast-opdagelse, forvent anden adfærd over et broet link end på en enkelt ledning, og planlæg efter det i stedet for at registrere det som en fejl.
Skriv til sidst topologien ned: hvilken hub der kaskaderer hvorhen, hvilken identitet der autoriserer det, hvilke segmenter der er broet, og hvem der ejer adressetildelingen på hvert. Den note er det, der gør det muligt for den næste person at ændre en politik uden at tage et segment ned, som de ikke vidste eksisterede.