用 Kerberos 协商 IPsec 密钥
910 对应 kink，规范是 RFC 4430，TCP 与 UDP 同号注册，全称是用 Kerberos 完成密钥协商。它把 IPsec 的密钥协商过程放到现有的 Kerberos 体系里：双方先借助域内票据完成身份认证，再由此推导出用于保护通信的密钥材料。设计意图是复用企业已有的身份基础设施，减少额外部署一套独立密钥协商服务的成本。
基本信息
| 服务 | kink（用 Kerberos 协商密钥） |
|---|---|
| 协议 | TCP 与 UDP 均有注册 |
| 规范 | RFC 4430 |
| 用途 | IPsec 密钥协商，依赖域内身份体系 |
| 暴露要求 | 仅域内受信主机之间 |
典型使用场景
- 身份体系统一：希望加密通信复用企业域账号的场景
- 方案评估：对比不同密钥协商方式对基础设施的依赖
- 排障：协商失败时先确认域内票据是否正常获取
- 安全核对：确认该端口只在内网受信主机之间可达
- 协议对照：理解为何主流方案仍以独立协商协议为主
协商方式对照
| 方式 | 依赖基础设施 | 特点 |
|---|---|---|
| 基于 Kerberos 的协商 | 域内身份服务 | 复用现有身份，部署门槛取决于域环境 |
| 通用密钥协商 | 证书体系 | 跨组织部署成熟，配置项较多 |
| 手工配置密钥 | 无 | 维护成本高，不适合规模化 |
核对方式
核对方式
# Linux 主机侧：确认端口是否被监听
ss -lntup 'sport = :910'
# 域内身份是否正常：确认票据可获取
klist
# 向域内服务请求票据，验证身份链路
kinit -V
# 确认到对端主机的可达性
nc -zv peer.example.com 910协商失败的表现往往不在加密层，而在身份层：票据过期、时钟偏离或者域内服务地址不可达，都会让协商在第一步就中断。排查顺序应先是身份与时间，再是网络与加密策略。
域内身份体系是这类方案的信任根：一旦票据签发服务被攻破，整个加密通信的身份基础随之失效。相关主机应严格限制访问来源，并把时间同步与票据异常纳入监控。
核实要点
- 确认域内票据获取正常且未过期
- 确认主机时间与域内时间源一致
- 确认该端口只在受信主机之间可达
- 确认异常时同时检查身份服务与加密策略