SoftEther каскада: свесно повезивање два виртуелна хаба

Два SoftEther хаба повезана каскадом деле једну broadcast домену, па петља или други DHCP сервер престаје да буде локална грешка и постаје заједничка. То је цео модел ризика. Сама каскада је конфигурисан однос клијента: локални виртуелни хаб повезује се према споља на хаб удаљеног сервера под идентитетом који тај сервер одобрава. Она је градивни блок за већу виртуелну мрежу, никада излаз на интернет.

1. Одлучите шта веза мора да преноси

Пођите од захтева, а не од функције. Каскада преноси оквире другог слоја између хабова, што је оно што желите када две локације морају да изгледају као један Ethernet сегмент. Ако је потребан само рутирани приступ до неколико подмрежа, рутирана стаза је једноставнија и пада на начине који се лакше виде. Избор каскаде вас обавезује на заједнички broadcast, заједничко откривање и једну топологију петље.

Напишите захтев у једном реду пре него што дотакнете сервер: који системи морају да изгледају на истој жици и којима треба само рута. Све што одговара «рута» припада изван каскаде. Та једна реченица спречава већину пројеката који се завршавају дуплираним адресним сервисима.

2. Ограничите идентитет који то одобрава

Акредитиви којима се администрира сервер и идентитет који каскада користи за повезивање различите су тајне, а њихово мешање је чест пречица са дугим репом. Удаљени хаб треба унос корисника или правила који дозвољава овој каскади да се повеже. Тај унос је одобрење; успешна пријава не говори ништа о томе шта стоји иза удаљеног хаба.

Забележите који хаб иницира, коме се удаљеном хабу придружује и шта удаљени идентитет може да достигне. Упоредите две архитектуре пре него што се обавежете:

Одржавајте акредитиве и упутства за опоравак оба краја ажурнима. Промена лозинке или уређивање правила на удаљеном хабу прекида каскаду без дирања ваших локалних корисника, а квар се обично појављује као веза која је подигнута али празна.

3. Проверите шта хаб већ преноси

Хаб је ретко изолован. Он можда већ премошћује физички адаптер, рутира кроз виртуелни рутер или каскадира негде другде, и свако од тих прикључења преноси се у нови однос. Зато се «повезали смо само два хаба» тако често претвара у «зашто су ове две локације сада један сегмент?».

Два хаба премошћена у исти физички сегмент и затим каскадирана један на други творе петљу. Додајте spanning tree или то не градите. Исти тест важи за хаб који већ достиже циљ кроз другу каскаду: друга веза не додаје капацитет, додаје стазу.

Не додајте везу зато што недостаје једна рута; поправите руту. Прво нацртајте топологију на папиру, укључујући сваки мост и каскаду, јер дијаграм траје два минута и хвата већину петљи пре него што настану.

4. Решите адресирање пре спајања

Спојени сегменти доносе дуплиране подмреже, а дуплирани DHCP сервери класичан су симптом: клијенти узимају закуп од сервера који први одговори, па понашање изгледа случајно и сели се између поновних покретања. Унапред одлучите која страна поседује доделу адреса и дајте далеком сегменту опсег који се не преклапа ни са чим локалним. Искључите другу DHCP услугу пре него што каскада постане онлајн, а не после прве жалбе.

DNS је засебно питање. Каскада преноси оквире; не конфигурише резолвере, а име које се разрешава на локалној страни можда се неће разрешавати преко везе. Тестирајте упит одвојено од IP стазе, јер успешан ping доказује само једно од два.

5. Докажите то стварним ресурсом

Изаберите дозвољену услугу на жељеном удаљеном сегменту и потврдите да се одговор враћа кроз каскаду. Затим поновите за разрешавање имена. Ако се циљ ослања на откривање broadcast-ом, очекујте другачије понашање преко премошћене везе него на једној жици, и планирајте то уместо да то пријавите као дефект.

На крају запишите топологију: који хаб камо каскадира, који идентитет то одобрава, који су сегменти премошћени и ко поседује доделу адреса на сваком. Та белешка омогућује следећој особи да промени правило без рушења сегмента за који није знала да постоји.