opalis-rdv 与 536 端口
536 的登记名是 opalis-rdv，IANA 说明为 Opalis Rendezvous，登记人 Laurent Domenech，对应 Opalis 自动化软件中的 Rendezvous 组件；同厂商的另一个号码是 314 opalis-robot。Opalis 后被微软收购并整合进其自动化产品线，原有品牌逐步淡出，这一组端口也随之成为历史登记。
基本信息
| 服务名 | opalis-rdv（Opalis Rendezvous） |
|---|---|
| 传输层 | TCP 与 UDP 各占一条登记记录 |
| 号码区间 | 0-1023 系统端口 |
| 登记联系人 | Laurent Domenech |
| 关联号码 | 314 opalis-robot |
| 产品归属 | 被微软收购后产品线整合 |
| 公开实现 | 无当前部署资料 |
什么情况下会遇到
- IT 自动化平台梳理时，老编排组件仍在内网运行，端口出现在清单里
- 运维平台迁移评估需要列出代理与调度端之间的通信端口
- 安全审计要求说明自动化平台的权限边界，因为调度组件通常权限很高
- 老代理停止工作后，调度端仍在重试连接，产生持续告警
- 并购整合过程中两套自动化平台并存，端口归属需要区分
排查判定对照
| 观察到的情况 | 倾向判断 | 处理动作 |
|---|---|---|
| 调度端与代理端通信正常且业务在用 | 自动化链路在用 | 限源、审计、纳入变更管理 |
| 调度组件使用高权限账号 | 高风险配置 | 拆分账号职责，最小化运行权限 |
| 存在大量失败重连 | 代理失效或配置错误 | 清理失效代理，避免告警噪音 |
| 端口对全网开放 | 暴露过大 | 收口到管理网段并记录例外 |
| 有监听但无任何客户端 | 历史残留 | 确认后停用并核对自启项 |
四步定位
四步定位
ss -lntup 'sport = :536' # 监听面
sudo lsof -i :536 -P -n # 进程与路径
sudo ss -tnp 'sport = :536 or dport = :536' # 双向会话
ps -o pid,user,etime,cmd -p <PID> # 运行账号与时长
sudo grep -rnw 536 /etc /opt 2>/dev/null # 配置引用
sudo journalctl --since -24h | grep -w 536 # 日志佐证自动化编排组件的权限通常是运维体系里最高的一类：它需要登录大量主机执行脚本。因此其通信端口的风险等级应按「等价于运维凭据」来评估，而不只是普通服务端口。
产品线被收购整合后，组件名称与端口往往在新版本里发生变化。继续使用旧平台时，应以原厂商或承接方的版本文档确认端口，不要依据注册表登记推断。
自动化平台常见的故障模式是「调度端还在、代理端已下线」：调度任务按周期重试，产生大量连接尝试。排查时先清理失效代理的注册信息，再判断是否有真实异常。