Socket.io 实现Worker禁止直连、仅经Manager中转的安全接入

架构可行性结论 #

这套设计从技术落地层面完全可行，不存在无法实现的硬技术障碍。只要配套做好网络层隔离和应用层校验，完全可以实现“所有Worker连接必须经过Manager核验、阻断无授权直连”的核心目标。

为什么这是符合工程规范的良好实践 #

这类架构是游戏服务端生产环境经过长期验证的成熟模式，不是脱离实际的花架子：

• 信任边界清晰可控：把用户身份校验、权限判断的核心逻辑全部收敛在Manager服务上，Worker节点不需要重复开发冗余的鉴权逻辑，也不会因为鉴权漏洞直接暴露在公网攻击范围内
• 模块职责解耦彻底：Manager专注处理静态资源分发、Lobby节点状态统计、用户准入校验这类通用逻辑，Worker只承接已经完成校验的用户的大厅交互、对局实时逻辑，两类服务可以独立迭代、独立扩缩容，不会因为逻辑耦合牵一发动全身
• 运维成本更低：Worker节点不需要对客户端暴露固定的公网端口，新增、下线Worker节点时客户端完全无感知，只需要在Manager侧更新Lobby列表配置即可，不需要频繁调整客户端的连接逻辑
• 安全韧性更强：核心入口全部收敛在Manager侧，哪怕单个Worker节点遭遇恶意流量攻击，也不会影响全局的用户接入入口可用性，故障影响范围可以被严格限制在单个节点内

当前方案的常见实现缺陷与优化方向 #

如果只靠客户端代码控制连接流程、不做配套拦截，根本无法真正阻断未授权的Worker直连：因为客户端会明文携带Worker的IP、端口信息，只要抓包就能拿到Worker地址直接发起连接，完全绕开Manager的校验流程。
要实现设计目标，必须配套两层拦截机制：

1. 网络层硬隔离：在Worker节点的服务器防火墙、云安全组上配置规则，直接阻断所有来自公网的入站流量，只允许Manager服务所在IP的请求访问Worker端口，从网络根源上堵死公网直连通道
2. 应用层票据校验：Manager在返回Lobby列表时，针对每个Lobby节点给合法用户签发短期、带签名、绑定用户身份和目标Worker节点的临时访问票据；客户端向Worker发起连接时，必须携带这个票据，Worker收到连接请求后第一时间校验票据的签名、有效期、匹配关系，校验不通过直接断开连接。

现有客户端连接参考实现：

// 建立与Manager的Socket连接
var socket = io.connect('http://192.168.1.5:8080');
// 选定目标Lobby后建立与对应Worker的Socket连接
var socket = io.connect('http://192.168.1.5:2002');

优化后的连接逻辑调整点 #

• 客户端从Manager获取Lobby列表时，每个Lobby条目附带对应的临时访问票据，而非直接暴露Worker的IP和端口明文
• 客户端连接Worker时，将临时票据作为连接参数传入，Worker侧完成票据校验后才允许客户端进入对应Lobby
• 配置全局的票据失效通知机制：当用户在Manager侧登出、被封禁时，Manager要主动通知对应Worker节点作废关联的票据，避免用户脱离Manager管控后依然可以连接Worker使用服务

内容的提问来源于stack exchange，提问作者Vardan Betikyan