Montar NFS “pendurado” ao acessar de um servidor em uma sub-rede diferente

Question

Aqui está um problema que não consigo diagnosticar:

Nossos diretórios pessoais de usuário são servidos via NFS de um Apple XServe executando o Mac OS X 10.5.7. Normalmente eles são exportados para nossa sub-rede de escritório padrão, "lan". Recentemente eu tenho construído uma nova sub-rede, "farm". Os computadores no "farm" executam o mesmo sistema operacional (openSUSE 11.1 e Gentoo) que os do "lan", e as versões do software são as mesmas.

O problema é que, quando meus usuários usam uma máquina em farm por algum tempo (5 minutos, às vezes 30, às vezes uma hora inteira), a montagem NFS parece travar. A tentativa de fazer um ls no diretório ou qualquer outra coisa (como login, etc) que tente acessar o diretório inicial do usuário fica paralisada. Montagens para outros servidores NFS da máquina "desligada" parecem funcionar como esperado.

Não há nada nos registros do cliente ou do servidor que indique qualquer problema. Os mesmos tipos de clientes funcionam bem com a sub-rede "lan" padrão.

Eu tentei todos os tipos de configurações diferentes do servidor e cliente NFS (desativando / habilitando kerberos, diferentes opções de montagem), mas nada parece fazer qualquer diferença.

Eu estou strongmente suspeitando de alguns problemas de nível de rede entre essas duas sub-redes, talvez algumas falhas por firewall / roteador (OpenBSD com pf como o filtro de pacotes). A conexão entre os dois conjuntos de máquinas é bastante simples:   x serve --> switch --> router --> switch --> clients

Eu quase não tenho métodos de depuração para tentar em seguida, ou qual a possível solução. Alguma idéia de como abordar esse problema a partir deste ponto?

Atualização:

Ainda não conseguiu resolver isso. Eu pensei que eu tinha cortado por aí quando eu desabilitei scrub nas interfaces internas, mas o problema se manifestou novamente. O que é estranho é que o pf parece ainda estar modificando alguns pacotes.

Um exemplo de conversa, no lado farm vlan:

09:17:39.165860 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472382:2887472382(0) win 5840 <mss 1460,sackOK,timestamp 236992843 0,nop,wscale 6> (DF)
09:17:39.166124 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: . ack 43 win 65535 <nop,nop,timestamp 316702204 236992843> (DF)
09:17:54.164490 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472385:2887472385(0) win 5840 <mss 1460,sackOK,timestamp 236996593 0,nop,wscale 6> (DF)
09:17:54.164760 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: R 1441270809:1441270809(0) ack 43 win 65535 (DF)
09:17:54.164776 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: R 4243886205:4243886205(0) ack 46 win 0 (DF)
09:17:54.164989 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472388:2887472388(0) win 5840 <mss 1460,sackOK,timestamp 236996593 0,nop,wscale 6> (DF)
09:17:57.164066 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472388:2887472388(0) win 5840 <mss 1460,sackOK,timestamp 236997343 0,nop,wscale 6> (DF)
09:17:57.164330 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: . ack 49 win 65535 <nop,nop,timestamp 316702384 236997343> (DF)
09:18:03.163468 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472388:2887472388(0) win 5840 <mss 1460,sackOK,timestamp 236998843 0,nop,wscale 6> (DF)
09:18:03.163732 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: . ack 49 win 65535 <nop,nop,timestamp 316702444 236998843> (DF)

e o mesmo na lan vlan:

09:17:39.165876 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472382:2887472382(0) win 5840 <mss 1460,sackOK,timestamp 236992843 0,nop,wscale 6> (DF)
09:17:39.166110 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: . ack 1 win 65535 <nop,nop,timestamp 316702204 236992843> (DF)
09:17:54.164505 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472385:2887472385(0) win 5840 <mss 1460,sackOK,timestamp 236996593 0,nop,wscale 6> (DF)
09:17:54.164740 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: R 1:1(0) ack 1 win 65535 (DF)
09:17:54.164745 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: R 2802615397:2802615397(0) ack 4 win 0 (DF)
09:17:54.165003 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472388:2887472388(0) win 5840 <mss 1460,sackOK,timestamp 236996593 0,nop,wscale 6> (DF)
09:17:54.165239 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: S 449458819:449458819(0) ack 2887472389 win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 316702354 236996593,sackOK,eol> (DF)
09:17:55.123665 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: S 449458819:449458819(0) ack 2887472389 win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 316702363 236996593,sackOK,eol> (DF)
09:17:57.124839 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: S 449458819:449458819(0) ack 2887472389 win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 316702383 236996593,sackOK,eol> (DF)
09:17:57.164082 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472388:2887472388(0) win 5840 <mss 1460,sackOK,timestamp 236997343 0,nop,wscale 6> (DF)
09:17:57.164316 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: . ack 1 win 65535 <nop,nop,timestamp 316702384 236997343> (DF)
09:18:01.126690 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: S 449458819:449458819(0) ack 2887472389 win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 316702423 236997343,sackOK,eol> (DF)
09:18:03.163483 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472388:2887472388(0) win 5840 <mss 1460,sackOK,timestamp 236998843 0,nop,wscale 6> (DF)
09:18:03.163717 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: . ack 1 win 65535 <nop,nop,timestamp 316702444 236998843> (DF)

Devo mencionar também que temos outro tráfego NFS passando por essa mesma máquina, mas de um servidor NFS diferente. Nós temos usado isso há anos e não tivemos nenhum problema lá. Da mesma forma, esses XServes têm servido o NFS para clientes Linux em sua própria sub-rede por um longo tempo também e continuam a fazê-lo.

    

Answer 1

Só queria atualizar isso caso alguém encontre o mesmo problema.

Essencialmente, isso se resume às regras do estado em Pf. Por padrão, Pf mantém o estado e usa S / SA como uma máscara. No entanto, parece que a implementação do servidor NFS no OS X tenta iniciar uma conversa de volta ao cliente usando um conjunto de sinalizadores não padrão. Isso estava causando falhas porque Pf simplesmente descartava os pacotes. Eu juntei isso tcpdumping as interfaces lan e farm. Depois de ajustar os sinalizadores de estado para as regras entre as sub-redes, a conexão foi estabelecida corretamente.

No entanto, parece que o Pf continuou a filtrar alguns pacotes devido a alguma outra forma de normalização interna, e nenhuma quantidade de ajustes nas opções que tentei conseguiram fazer com que funcionasse.

No final, acabei criando outra interface no servidor de arquivos e colocando-a diretamente na farm vlan, ignorando completamente o roteador.

    

Answer 2

Eu não usei pf ; mas acho que foi um dos primeiros filtros de estado. Talvez seja manter em conta as 'conexões' e soltá-las?

Eu procuraria por qualquer regra de filtro dependente do estado. No iptables do Linux geralmente o filtro começa com um

ACCEPT all state RELATED,ESTABLISHED

porque assim não será necessário verificar novamente todas as regras relevantes para cada pacote após o primeiro. Mas como o NFS é baseado em UDP e não se preocupa com longos períodos de silêncio (mesmo horas), talvez o roteador esteja perdendo o estado ESTABLISHED e os novos pacotes não sejam válidos para começar.

verifique se existe algum parâmetro 'keepalive' para fazer o cliente enviar pacotes de heartbeat após um minuto ou mais de silêncio. se não, tente o NFS sobre TCP. (que tem pacotes de pulsação).

    

Answer 3

A primeira coisa a fazer é garantir que o firewall seja realmente o culpado.

Para fazer isso, defina suas regras de bloqueio padrão para registrar. Nos meus firewalls, são duas linhas no topo das regras de filtragem:

block in log
block out log

Espere a montagem NFS travar novamente e verifique sua interface de log:

tcpdump -eeni pflog0 'host <client ip> and host <nfs server ip>'

Se você estiver vendo esses pacotes bloqueados no firewall, poste seu pf.conf. Se não, precisamos começar a olhar além do firewall.