Каскад 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. Докажите это реальным ресурсом
Выберите разрешённую службу в нужном удалённом сегменте и подтвердите, что ответ возвращается через каскад. Затем повторите для разрешения имён. Если цель опирается на обнаружение широковещанием, ожидайте иного поведения через соединение с мостом, чем на одном проводе, и планируйте это, а не записывайте как дефект.
Наконец, запишите топологию: какой хаб куда каскадирует, какая идентичность это разрешает, какие сегменты соединены мостом и кто владеет назначением адресов на каждом. Эта запись позволяет следующему человеку изменить политику, не свалив сегмент, о существовании которого он не знал.