courier 与 530 端口
530 的登记名是 courier，IANA 说明为 rpc，指向 Sun RPC 生态里程序号为 530 的耦合服务。Sun RPC（ONC RPC）用「程序号 + 版本」标识服务，端口通常由 rpcbind 动态分配，只有少数服务会固定在某个号码上；530 属于后者，是历史登记项。
基本信息
| 服务名 | courier（rpc） |
|---|---|
| 传输层 | TCP 与 UDP 各占一条登记记录 |
| 号码区间 | 0-1023 系统端口 |
| 技术体系 | Sun RPC / ONC RPC（程序号 530） |
| 端口分配 | 多数 RPC 服务由 rpcbind 动态分配 |
| 关联服务 | rpcbind（111） |
| 现状 | 历史登记 |
什么情况下会遇到
- 排查 NFS、NIS 等 RPC 相关服务时，需要逐个确认程序号与端口的对应关系
- 安全扫描报告大量高位端口开放，需要判断是否为 RPC 动态端口
- 防火墙加固要求固定端口，需要把 RPC 服务改为静态端口并对齐策略
- 跨网段访问 RPC 服务出现超时，需要同时检查 111 与动态端口是否放行
- 合规审计要求说明主机间 RPC 调用的范围与鉴权方式
排查判定对照
| 观察到的情况 | 倾向判断 | 处理动作 |
|---|---|---|
| rpcinfo 列出程序号与端口映射 | RPC 服务在用 | 按最小权限收口，评估鉴权 |
| 111 开放但对端不可达 | 链路或策略缺口 | 同时放行 rpcbind 与实际端口 |
| 大量高位端口开放且集中在某主机 | 典型 RPC 动态端口 | 用 rpcinfo 反查具体服务 |
| 程序号为 530 但无对应客户端 | 历史登记 | 确认为空后可停用 |
| 存在跨网段的 RPC 调用 | 信任面较大 | 限制调用来源，避免全网可达 |
四步定位
四步定位
rpcinfo -p <host> # 列出程序号、协议、端口映射
ss -lntup | grep -w 530 # 本机是否有固定监听
sudo lsof -i :530 -P -n # 进程归属
sudo systemctl status rpcbind # 端口映射服务状态
sudo nft list ruleset | grep -E '\b(111|530)\b' # 策略放行核对
sudo ls /etc/init.d | grep -Ei 'rpc|nfs|nis' # 相关服务脚本排查 RPC 相关问题时不能只看端口号：客户端先连 rpcbind（111）问「某程序号在哪个端口」，再连实际端口。只放行 111 或只放行实际端口都会造成连接失败，两边都要在策略里覆盖。
为了让策略可维护，生产环境通常把关键 RPC 服务固定到静态端口，再只放行这些端口。做法是在服务配置里指定端口并保持 rpcbind 最小开放，改动后需重启服务并验证 rpcinfo 输出。
NIS、NFS 一类服务历史上缺乏强鉴权，常以主机地址作为信任依据。若 530 上承载的正是这类调用，应限制来源网段并评估整体替代方案，不要仅依赖端口封堵。