☰

为什么 NFS 客户端使用低编号端口？

tag-icon • tag-icon nfs aws coreos
为什么 NFS 客户端使用低编号端口？

我正在运行 CoreOS EC2 实例。我在此实例上运行一个侦听本地端口 950 的进程。通常，一切正常，但在最近重新启动 CoreOS 服务器后，该进程无法侦听端口 950，因为它已被另一个进程占用。

这个其他进程似乎是一个 NFSv4 客户端，用于挂载 AWS EFS 卷。这是 netstat 告诉我的内容：

Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 10.30.102.250:950       10.30.102.170:2049      ESTABLISHED

这是相关部分/etc/mtab：

fs-faa33256.efs.us-west-2.amazonaws.com:/ /efs nfs4 rw,relatime,vers=4.1,\
rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,\
clientaddr=10.30.102.250,local_lock=none,addr=10.30.102.170 0 0

有几个问题： 1. 为什么 CoreOS 服务器上的 NFS 客户端使用低数的与远程 NFSv4 服务器通信的端口？ 2. 我可以告诉 NFS 客户端避免使用端口 950（或仅使用非特权端口）吗？

答案1

（以下答案很大程度上源自 Jeff Schaller 对我原始帖子的评论。）

为了防止非 root 用户挂载 NFS 卷，NFS 服务器可以要求 NFS 客户端使用特权端口 (1-1023)。然而，现在只允许 root 用户挂载 NFS 卷几乎没有安全性，因为任何可以将计算机放到网络上的人都可以成为该计算机的 root 用户。

由于这种旧的安全实践，某些 NFS 客户端在连接到 NFS 服务器时将默认使用特权端口。

如果您的客户端需要在特权端口上运行服务，这可能会导致端口冲突。解决此问题的一种方法是设置 NFS 客户端将使用的最小和最大特权端口，以便 NFS 客户端避免其他服务使用的端口。该端口范围可以设置为内核参数;在 CoreOS 中，这些参数可以存储在文件/sys/module/sunrpc/parameters/min_resvport和 /sys/module/sunrpc/parameters/max_resvport.

您可以通过在安装 NFS 卷时添加一个选项来告诉系统使用非特权端口，从而完全避免整个特权端口问题。对于 Linux，这是一个noresvport选项（另请参见Linux nfs(5) 手册页）。

这是我们最终在 CoreOS 服务器上使用的挂载命令：

fs-faa33256.efs.us-west-2.amazonaws.com:/ /efs nfs4 rw,relatime,vers=4.1,\
rsize=1048576,wsize=1048576,namlen=255,hard,noresvport,proto=tcp,timeo=600,retrans=2,sec=sys,\
clientaddr=10.30.102.250,local_lock=none,addr=10.30.102.170 0 0

相关内容