为什么 rpcbind 在重新启动时会打开一个新的不同端口？答案

【问题标题】：Why is rpcbind opening a new and different port anytime it's restarted?为什么 rpcbind 在重新启动时会打开一个新的不同端口？
【发布时间】：2016-06-17 10:14:07
【问题描述】：

为了我自己的理智，有谁知道为什么 rpcbind (linux) 每次重新启动时都会打开一个看似随机的端口？我知道它使用端口 111，但另一个不断向它开放的端口是什么？谢谢。

    [root@testmachine ~]# nmap -sU -p 0-65535 127.0.0.1

    Starting Nmap 5.51 ( http://nmap.org ) at 2016-03-03 16:00 EST
    Nmap scan report for localhost (127.0.0.1)
    Host is up (0.0000080s latency).
    Not shown: 65533 closed ports
    PORT    STATE         SERVICE
    111/udp open|filtered rpcbind
    819/udp open|filtered unknown

    Nmap done: 1 IP address (1 host up) scanned in 3.11 seconds
    [root@testmachine ~]# service rpcbind restart
    Stopping rpcbind:                                          [  OK  ]
    Starting rpcbind:                                          [  OK  ]
    [root@testmachine ~]# nmap -sU -p 0-65535 127.0.0.1

    Starting Nmap 5.51 ( http://nmap.org ) at 2016-03-03 16:00 EST
    Nmap scan report for localhost (127.0.0.1)
    Host is up (0.0000080s latency).
    Not shown: 65533 closed ports
    PORT    STATE         SERVICE
    111/udp open|filtered rpcbind
    846/udp open|filtered unknown

    Nmap done: 1 IP address (1 host up) scanned in 2.97 seconds
    [root@testmachine ~]# service rpcbind restart
    Stopping rpcbind:                                          [  OK  ]
    Starting rpcbind:                                          [  OK  ]
    [root@testmachine ~]# nmap -sU -p 0-65535 127.0.0.1

    Starting Nmap 5.51 ( http://nmap.org ) at 2016-03-03 16:05 EST
    Nmap scan report for localhost (127.0.0.1)
    Host is up (0.0000070s latency).
    Not shown: 65533 closed ports
    PORT    STATE         SERVICE
    111/udp open|filtered rpcbind
    892/udp open|filtered unknown

    Nmap done: 1 IP address (1 host up) scanned in 2.86 seconds

【问题讨论】：

标签： linux udp port rpc

【解决方案1】：

很可能，它是一个 RPC 服务。试试rpcinfo 命令看看是什么。

与大多数其他网络服务（FTP、HTTP、SMTP 等）不同，RPC 服务绑定到动态端口。 RPC 客户端不是直接连接到服务器，而是首先向 RPC 端口映射器（默认为 UDP/111）发送请求，以找出服务器在哪个端口上（在 Windows 上使用类似的端口）。

在相关的说明中，nmap 很棒，但有更简单的方法可以了解计算机上的侦听端口。试试这个：sudo netstat -anp | grep LISTEN。它要快得多，甚至会为您提供进程名称和编号。

此外，nmap 5.51 现在大约有 5 年历史了。如果您经常使用它，那么值得升级以获得一些新功能。

【讨论】：

谢谢阿切尔。我不知道 nmap 有更高版本，因为我使用 yum install 来获取 nmap。对于我需要做的事情，5.51 版本就足够了。

【解决方案2】：

rpcbind 的 Debian 手册页告诉我：

 All RPC servers must be restarted if rpcbind is restarted.

OP 没有提到他们已经这样做了，那么任何 RPC 服务将如何重新注册？想象一下我的惊讶，然后，重复 OP 的实验并应用来自 @SArcher 的 rpcinfo -p 建议，以查看所有 RPC 服务仍在注册......并且在它们的原始端口上，这表明 @SArcher 并不完全在钱。

但是，如果我们也应用@SArcher 的另一个好建议，即sudo netstat -anp，我们会得到更有趣的东西。现在我们不能像建议的那样|grep LISTEN，因为 OP 的帖子说 udp 和 UDP 套接字永远不会处于 LISTEN 状态。我们确实发现 rpcbind 不仅在端口 111 上有套接字——它的工作——而且正如 OP 所说，当 rpcbind 启动时，似乎随机选择了另一个“保留”端口。

那么“这个另一个端口是是干什么用的？”你问。很抱歉取笑，但我只是在我的描述中回答了这个问题：

Debian bug 870579: rpcbind callit 从一个随机保留的 udp 端口回复，使防火墙变得困难

【讨论】：

【解决方案3】：

在redhat 上有一个单独的服务叫做rpcbind.socket。这从 rpcbind.service 开始。 rpcbind.service 首先检查端口 111 是否可用，如果不可用则选择一个端口并开始监听该端口。在 redhat 中，首先启动 rpcbind.socket，并开始使用端口 111。在 netstat 中，端口 111 将显示为 systemd 使用的端口。当 rpcbind 启动时，它发现端口 111 已被 systemd 使用，因此它选择了不同的端口。如果屏蔽 rpcbind.socket 服务，然后启动 rpcbind.service，rpcbind 将开始监听 111 端口。

【讨论】：