SoftEther 级联：有意连接两个虚拟 Hub
级联在配置好的身份下把本地 Hub 连到远端 Hub。它不是出口节点，承载的是这些 Hub 早已桥接的一切。
由级联连接的两个 SoftEther Hub 共享同一个广播域，因此一个环路或第二台 DHCP 服务器不再只是本地失误，而会变成共同失误。这就是全部的风险模型。级联本身是一种配置好的客户端关系：本地虚拟 Hub 以远端服务器授权的身份向外连接该服务器的 Hub。它是更大虚拟网络的构件，从来不是互联网出口。
1. 决定链路必须承载什么
从需求出发，而不是从功能出发。级联在 Hub 之间搬运二层帧，这正是两个站点需要看起来像同一个以太网段时所要的东西。如果需求只是路由访问少数几个子网，路由路径更简单，失败的方式也更容易看清。选择级联意味着接受共享广播、共享发现和单一环路拓扑。
在动服务器之前，把需求写成一行：哪些系统必须看起来在同一根线上，哪些只需要一条路由。凡是回答「一条路由」的，都留在级联之外。这一句话就能挡掉大多数最终出现重复地址服务的设计。
2. 划定授权身份的边界
管理服务器的凭据和级联用来连接的身份是不同的秘密，把它们混用是常见的长尾捷径。远端 Hub 需要一条允许该级联连接的用户或策略条目。那条条目就是授权；登录成功并不能说明远端 Hub 后面是什么。
记下哪个 Hub 发起、连到哪个远端 Hub、远端身份能到达哪里。在做出承诺之前比较两种架构：
| 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 |
两端都要保持凭据和恢复说明是最新的。远端 Hub 上改密码或改策略会断开级联，却不影响你的本地用户，故障通常表现为链路已通但空无一物。
3. 检查 Hub 已经在承载什么
Hub 很少是孤立的。它可能已经桥接到物理网卡、经由虚拟路由器路由，或级联到别处，而这些连接都会被带进新的关系里。这就是为什么「我们只是连了两个 Hub」常常变成「为什么这两个站点现在成了一个网段？」。
两个 Hub 桥接到同一物理网段之后再互相级联，就形成环路。要么加上生成树，要么不要这样建。同样的检验也适用于已经通过另一条级联到达目标的 Hub：第二条链路不增加容量，只增加一条路径。
不要因为缺一条路由就加一条链路；先把路由修好。先在纸上画出拓扑，包括每一处桥接和级联，因为画图只要两分钟，却能在环路出现之前抓住大部分。
4. 接入之前先理清地址
合并的网段会带来重复子网，而重复的 DHCP 服务器就是典型症状：客户端从最先应答的那台服务器取租约，所以行为看起来随机，并在重启之间漂移。事先定好哪一侧负责地址分配，并给远端网段一个不与任何本地地址重叠的网段。在级联上线之前就停掉另一套 DHCP 服务，而不是等第一次投诉之后。
DNS 是另一个问题。级联搬运的是帧，它不配置解析器，本地能解析的名字不一定能跨链路解析。把解析查询和 IP 路径分开测，因为能 ping 通只能证明两者之一。
5. 用真实资源验证
在目标远端网段上选一个被允许的服务，确认应答是经级联回来的。然后再对名字解析重复一遍。如果目标依赖广播发现，就要预期桥接链路上的行为与单根线不同，并据此规划，而不是把它当成缺陷报上去。
最后把拓扑写下来：哪个 Hub 级联到哪里、由哪个身份授权、哪些网段被桥接、每个网段的地址分配归谁。正是这份记录让下一个人能在不弄断一个他根本不知道存在的网段的前提下改策略。