SoftEther каскада: свесно поврзување на два виртуелни хабови
Каскадата поврзува локален хаб со далечен под конфигуриран идентитет. Таа не е излезен јазол и пренесува сѐ што овие хабови веќе премостуваат.
Два SoftEther хаба поврзани со каскада делат една broadcast-домена, па јамка или втор DHCP сервер престанува да биде локална грешка и станува заедничка. Тоа е целиот модел на ризик. Самата каскада е конфигурирана клиентска врска: локалниот виртуелен хаб се поврзува кон надвор со хабот на далечен сервер под идентитет што тој сервер го дозволува. Таа е градежен блок за поголема виртуелна мрежа, никогаш излез во интернет.
1. Одлучете што треба да пренесува врската
Започнете од барањето, не од функцијата. Каскадата пренесува рамки од вториот слој меѓу хабовите, и тоа е она што го сакате кога две локации треба да изгледаат како еден Ethernet сегмент. Ако потребата е само рутиран пристап до неколку подмрежи, рутираниот пат е поедноставен и откажува на начин што е полесно видлив. Изборот на каскада ве обврзува на заедничко broadcast, заедничко откривање и една топологија на јамка.
Напишете го барањето во еден ред пред да допрете сервер: кои системи треба да изгледаат на истиот кабел и на кои им треба само рута. Сѐ што одговара „рута“ припаѓа надвор од каскадата. Оваа единствена реченица спречува повеќето дизајни што завршуваат со дупли адресни услуги.
2. Ограничете го идентитетот што го дозволува
Акредитивите со кои се администрира сервер и идентитетот што каскадата го користи за поврзување се различни тајни, а нивното мешање е чест кратенка со долга опашка. Далечниот хаб бара запис за корисник или политика што ѝ дозволува на оваа каскада да се поврзе. Тој запис е авторизацијата; успешната најава не кажува ништо за тоа што стои зад далечниот хаб.
Забележете кој хаб иницира, на кој далечен хаб се приклучува и до што може да стигне далечниот идентитет. Пред да се обврзете, споредете ги двете архитектури:
| 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 |
Одржувајте ги акредитивите и упатствата за враќање на двата краја ажурни. Промена на лозинка или уредување на политика на далечниот хаб ја крши каскадата без да ги допре вашите локални корисници, а дефектот обично се појавува како врска што е подигната но празна.
3. Прегледајте што хабот веќе пренесува
Хаб ретко е изолиран. Тој може веќе да премостува физички адаптер, рутира низ виртуелен рутер или каскадира некаде на друго место, и секое од тие приклучувања се пренесува во новата врска. Затоа „само поврзавме два хаба“ толку често се претвора во „зошто овие две локации се сега еден сегмент?“.
Два хаба премостени во истиот физички сегмент и потоа каскадирани еден кон друг образуваат јамка. Додадете spanning tree или не го градете. Истиот тест важи за хаб што веќе стигнува до целта преку друга каскада: втората врска не додава капацитет, таа додава пат.
Не додавајте врска затоа што недостасува една рута; поправете ја рутата. Прво нацртајте ја топологијата на хартија, вклучително секој мост и каскада, бидејќи дијаграмот трае две минути и фаќа повеќето јамки пред да постојат.
4. Средете го адресирањето пред поврзување
Споените сегменти носат дупли подмрежи, а дуплите DHCP сервери се класичен симптом: клиентите земаат закуп од серверот што прв одговара, па однесувањето изгледа случајно и се движи меѓу престартувања. Одлучете однапред која страна поседува доделување адреси и дајте му на далечниот сегмент опсег што не се преклопува со ништо локално. Исклучете ја другата DHCP услуга пред каскадата да излезе онлајн, а не по првата жалба.
DNS е посебно прашање. Каскадата пренесува рамки; таа не конфигурира резолвери, а име што се разрешува од локалната страна може да не се разреши преку врската. Тестирајте го барањето одделно од IP патот, бидејќи работен ping докажува само едно од двете.
5. Докажете го со вистински ресурс
Изберете дозволена услуга на предвидениот далечен сегмент и потврдете дека одговорот се враќа преку каскадата. Потоа повторете за разрешување на имиња. Ако целта се потпира на откривање преку broadcast, очекувајте различно однесување преку премостена врска отколку на еден кабел, и планирајте го тоа наместо да го евидентирате како дефект.
На крајот запишете ја топологијата: кој хаб каде каскадира, кој идентитет тоа го дозволува, кои сегменти се премостени и кој поседува доделување адреси на секој. Таа белешка му овозможува на следниот човек да смени политика без да урне сегмент за кој не знаел дека постои.