Problema de firewall usando o autofs com montagens exportadas pelo NFS

0

Eu configurei com sucesso um sistema servidor / cliente NFS funcionando em minhas máquinas de rede local. Eu amo isso!

Mas, tendo ficado cansado do longo atraso quando uma montagem não estava disponível durante a inicialização, decidi aceitar @ridgy em sua sugestão de usar o autofs para montar os compartilhamentos - usando as informações de esta postagem .

Eu tive problemas de firewall antes, Então, eu imediatamente suspeitei que o ufw poderia ser a razão para as montagens expirarem. Então, eu desabilitei o ufw no servidor e no cliente. E com certeza; Isso fez com que o autofs funcionasse bem. Então, tenho certeza de que a configuração básica está correta.

As únicas outras regras no ufw neste ponto são as regras ALLOW para as portas 2078 e 6589. Não há regras BLOCK configuradas. E, como o NFS funciona bem com o ufw on durante a montagem controlada pelo fstab, estou um pouco confuso sobre onde o bloqueio está ocorrendo.

Até agora, não encontrei documentação sobre quais portas / protocolos são exclusivos para o autofs, além do usual NFS 111.2049 TCP / UDP.

Sempre que eu reativar o ufw. As ações ficam inacessíveis novamente.

Alguma idéia?

@ridgy

Depois de seguir os seus conselhos abaixo para editar o nfs-common e o nfs-kernel-server .. Eu fiz a triplicação e as edições foram feitas exatamente como mostradas. Eu reiniciei e corri ...

$sudo netstat -nalp | grep rpc ... A saída foi

tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      1220/rpcbind    
tcp        0      0 0.0.0.0:32767           0.0.0.0:*               LISTEN      4158/rpc.mountd 
tcp6       0      0 :::111                  :::*                    LISTEN      1220/rpcbind    
tcp6       0      0 :::32767                :::*                    LISTEN      4158/rpc.mountd 
udp        0      0 0.0.0.0:972             0.0.0.0:*                           1220/rpcbind    
udp        0      0 0.0.0.0:32767           0.0.0.0:*                           4158/rpc.mountd 
udp        0      0 0.0.0.0:111             0.0.0.0:*                           1220/rpcbind    
udp6       0      0 :::972                  :::*                                1220/rpcbind    
udp6       0      0 :::32767                :::*                                4158/rpc.mountd 
udp6       0      0 :::111                  :::*                                1220/rpcbind    
unix  2      [ ACC ]     STREAM     LISTENING     15939    1/init              /run/rpcbind.sock
unix  2      [ ]         DGRAM                    49175    4158/rpc.mountd     
unix  3      [ ]         STREAM     CONNECTED     48294    1220/rpcbind        /run/rpcbind.sock
unix  3      [ ]         STREAM     CONNECTED     16984    1220/rpcbind        
unix  3      [ ]         STREAM     CONNECTED     48275    4157/rpc.idmapd     
unix  3      [ ]         STREAM     CONNECTED     48276    4157/rpc.idmapd 

OK ... Então, eu me pergunto ... Onde está o rpc.statd ??? Além disso, meus compartilhamentos NFS (o autofs ainda estava desabilitado) ainda estavam visíveis no cliente. mesmo que o firewall não tenha sido atualizado com a nova porta rpc.mountd 32767.

    
por Orian 09.02.2017 / 10:31

1 resposta

1

No final, não foi tão complicado, seguindo as dicas em Protegendo o NFS . Eu modifiquei os arquivos /etc/default/nfs-common e /etc/default/nfs-kernel-server de acordo:

nfs-common:

.
.
# Options for rpc.statd.
#   Should rpc.statd listen on a specific port? This is especially useful
#   when you have a port-based firewall. To use a fixed port, set this
#   this variable to a statd argument like: "--port 4000 --outgoing-port 4001".
#   For more information, see rpc.statd(8) or http://wiki.debian.org/SecuringNFS
STATDOPTS="--port 32765 --outgoing-port 32766"
.
.

nfs-kernel-server:

.
.
# Options for rpc.mountd.
# If you have a port-based firewall, you might want to set up
# a fixed port here using the --port option. For more information,
# see rpc.mountd(8) or http://wiki.debian.org/SecuringNFS
# To disable NFSv4 on the server, specify '--no-nfs-version 4' here
RPCMOUNTDOPTS="--manage-gids --port 32767"
.
. 

Por que esses portos? Como 32767 é o maior número de 15 bits, é muito improvável que essas portas já estejam sendo usadas por outra coisa.

Não estou usando cotas, por isso não modifiquei /etc/default/quota como sugerido. E eu tive que reiniciar depois que fiz essas alterações. Então eu vi o resultado com

$ sudo netstat -nalp | grep rpc

tcp        0      0 0.0.0.0:32767           0.0.0.0:*               LISTEN      1018/rpc.mountd 
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      735/rpcbind     
tcp        0      0 0.0.0.0:32765           0.0.0.0:*               LISTEN      806/rpc.statd   
tcp6       0      0 :::32767                :::*                    LISTEN      1018/rpc.mountd 
tcp6       0      0 :::111                  :::*                    LISTEN      735/rpcbind     
tcp6       0      0 :::32765                :::*                    LISTEN      806/rpc.statd   
udp        0      0 0.0.0.0:875             0.0.0.0:*                           735/rpcbind     
udp        0      0 127.0.0.1:982           0.0.0.0:*                           806/rpc.statd   
udp        0      0 0.0.0.0:32765           0.0.0.0:*                           806/rpc.statd   
udp        0      0 0.0.0.0:32767           0.0.0.0:*                           1018/rpc.mountd 
udp        0      0 0.0.0.0:111             0.0.0.0:*                           735/rpcbind     
udp6       0      0 :::875                  :::*                                735/rpcbind     
udp6       0      0 :::32765                :::*                                806/rpc.statd   
udp6       0      0 :::32767                :::*                                1018/rpc.mountd 
udp6       0      0 :::111                  :::*                                735/rpcbind     
unix  2      [ ACC ]     STREAM     LISTENING     11412    735/rpcbind         /run/rpcbind.sock
unix  2      [ ]         DGRAM                    9521     806/rpc.statd       
unix  2      [ ]         DGRAM                    9614     1018/rpc.mountd     
unix  3      [ ]         STREAM     CONNECTED     11721    862/rpc.idmapd      
unix  3      [ ]         STREAM     CONNECTED     11722    862/rpc.idmapd      

Como você pode ver, as portas rpc.mountd e rpc.statd estão ouvindo agora são estáticas.

Ao inserir showmount no cliente (aqui 192.168.192.20), o Wireshark mostra a comunicação (o servidor é 192.168.192.111). Importante aqui: O GETPORT Call e o GETPORT reply , que retorna Port:32767 . A comunicação então usa essa porta.

Agoravocêdevepodermodificarasregrasdofirewalldeacordoeusarshowmounteautofsatravésdofirewall.

Apenaspararegistro

Seguindoasdicasnoscomentárioseminhaprópriaexperiência,encontreiumcomportamentodiferenteemdiferentesdistribuições:

  • Noatualraspbianjessie(combaseemdebian),háumserviçonfs-common(arquivo/etc/init.d/nfs-common),quequandoativadoinicia,p.rpc.statdnainicialização,respeitandoasconfiguraçõesdaportaem/etc/default/nfs-common.
  • NoatualUbuntu16.04nãoexisteesseserviço.rpc.statdnãoéiniciadonainicialização,poisnãoénecessáriocomoNFSV4.Porém,assimquemount....-onfsvers=3forconcluído,rpc.statdseráiniciado,respeitandoasconfiguraçõesdeportaem/etc/default/nfs-common.

Eunãoencontreiumadocumentaçãoconsistentesobreisso;em Como configurar NFS o arquivo /etc/init.d/nfs-common é explicitamente mencionado, embora seja não no pacote. Se alguém tiver dicas / links sobre isso, seria merecidamente merecido.

Mais uma observação: man rpc.mountd e man rpc.statd say (para a opção --port ):

"Se esta opção não for especificada, o rpc.statd tentará consultar o / etc / services, se obtiver êxito na porta, definir a mesma porta para todos os soquetes do listener, caso contrário, escolhe uma porta efêmera aleatória para cada soquete do listener." / p>

Mesmo ao definir as portas em /etc/services (como sugerido no wiki mencionado acima), isso não funcionou. Portanto, modificar os arquivos em /etc/default parece obrigatório - as páginas man não estão corretas nesse ponto.

    
por ridgy 10.02.2017 / 14:42