Pourquoi le client NFS utilise-t-il des ports de faible numéro?

J'exécute une instance CoreOS EC2. J'exécute un processus sur cette instance qui écoute sur le port local 950. En règle générale, tout fonctionne correctement, mais après un redémarrage récent du serveur CoreOS, le processus ne pouvait pas écouter sur le port 950 car il était déjà pris par un autre processus.

Cet autre processus semble être un client NFSv4 utilisé pour monter un volume AWS EFS. Voici ce que netstat me dit:

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

Voici la partie pertinente de /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

Quelques questions: 1. Pourquoi le client NFS sur le serveur CoreOS utilise-t-il un port peu numéroté pour communiquer avec le serveur NFSv4 distant? 2. Puis-je dire au client NFS d'éviter d'utiliser le port 950 (ou d'utiliser uniquement des ports non privilégiés)?

nfs aws coreos

— rlandster
source

Je ne peux pas le tester, mais si vous en avez /sys/module/sunrpc/parameters/min_resvportpeut aider, voir serverfault.com/a/372751/293440

— Jeff Schaller

voir aussi la page nfs liée expliquant pourquoi le client NFS utilise des ports à faible numéro

— Jeff Schaller

La sortie de cat /sys/module/sunrpc/parameters/min_resvportis 665.

— rlandster

Peut-être essayer de changer cela en 951

— Jeff Schaller

Je vais essayer. En supposant que le serveur NFS n’ait pas de problème, n’y a-t-il aucune raison de ne pas le régler min_resvportsur 1025?

— rlandster

(La réponse suivante découle en grande partie des commentaires de Jeff Schaller dans mon message d'origine.)

Afin d'empêcher les utilisateurs non root de monter un volume NFS, un serveur NFS peut nécessiter qu'un client NFS utilise un port privilégié (1-1023). Cependant, permettre uniquement aux utilisateurs root de monter un volume NFS n'apporte que peu de sécurité, car toute personne pouvant placer une machine sur le réseau peut être root sur cette machine.

En raison de cette ancienne pratique de sécurité, certains clients NFS utilisent par défaut des ports privilégiés lors de la connexion à un serveur NFS.

Cela peut entraîner des conflits de port si votre client doit exécuter un service sur un port privilégié. Une solution consiste à définir les ports privilégiés minimum et maximum que le client NFS utilisera de manière à ce qu'il évite les ports utilisés par d'autres services. Cette plage de ports peut être définie en tant que paramètres du noyau . Dans CoreOS, ces paramètres peuvent être stockés dans les fichiers /sys/module/sunrpc/parameters/min_resvportet /sys/module/sunrpc/parameters/max_resvport.

Vous pouvez éviter tout le problème des ports privilégiés en ajoutant une option lors du montage du volume NFS indiquant au système d'utiliser des ports non provilés. Dans le cas de Linux, c'est l' noresvportoption (voir aussi la page de manuel Linux nfs (5) ).

Voici la commande de montage que nous avons finalement utilisée sur notre serveur 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

— rlandster
source