Каскад SoftEther: свідомо з’єднати два віртуальні хаби
Каскад з’єднує локальний хаб із віддаленим під налаштованою ідентичністю. Це не вихідний вузол, і він передає все, що ці хаби вже з’єднують мостом.
Два хаби SoftEther, з’єднані каскадом, ділять один домен широкомовлення, тому петля або другий сервер DHCP перестає бути локальною помилкою і стає спільною. Це вся модель ризику. Сам каскад — це налаштований клієнтський стосунок: локальний віртуальний хаб під’єднується назовні до хаба віддаленого сервера під ідентичністю, яку цей сервер дозволяє. Це будівельний блок для більшої віртуальної мережі, але ніколи не вихід в інтернет.
1. Вирішіть, що має переносити з’єднання
Починайте з вимоги, а не з функції. Каскад переносить кадри другого рівня між хабами, і це потрібно, коли два майданчики мають виглядати як один сегмент Ethernet. Якщо потреба — лише маршрутизований доступ до кількох підмереж, маршрутизований шлях простіший і відмовляє в помітніший спосіб. Вибір каскаду зобов’язує вас до спільного широкомовлення, спільного виявлення та однієї топології петлі.
Запишіть вимогу в один рядок, перш ніж торкатися сервера: які системи мають виглядати на одному дроті, а яким потрібен лише маршрут. Усе, що відповідає «маршрут», перебуває поза каскадом. Це єдине речення запобігає більшості проєктів, які закінчуються дубльованими службами адрес.
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. Доведіть це реальним ресурсом
Виберіть дозволену службу в потрібному віддаленому сегменті й підтвердьте, що відповідь повертається через каскад. Потім повторіть для розв’язування імен. Якщо мета покладається на виявлення широкомовленням, очікуйте іншої поведінки через з’єднання з мостом, ніж на одному дроті, і плануйте це, а не записуйте як дефект.
Наостанок запишіть топологію: який хаб куди каскадує, яка ідентичність це дозволяє, які сегменти з’єднані мостом і хто володіє призначенням адрес на кожному. Цей запис дозволяє наступній людині змінити політику, не зваливши сегмент, про існування якого вона не знала.