NFS sobre TCP dentro de um túnel UDP do OpenVPN: dois transportes

Levar uma conversa NFS que usa TCP dentro de um túnel que transporta UDP é totalmente coerente, e confunde as pessoas porque nomeia dois transportes ao mesmo tempo. TCP é a conversa do serviço de arquivos entre o cliente e o servidor NFS. UDP é o transporte cifrado entre as extremidades da VPN. Nenhum dos dois implica nada sobre o outro.

Registre ambos separadamente antes de depurar qualquer coisa; a maioria desses incidentes começa quando alguém altera a camada errada.

Duas camadas, duas definições

A opção de montagem proto=tcp descreve como o cliente NFS fala com o servidor NFS. A definição proto udp do perfil de VPN descreve como as extremidades do túnel trocam pacotes encapsulados. Alterar uma opção de montagem não altera o túnel, e alterar o transporte do túnel não altera o que o cliente NFS negociou. Confirme as opções de montagem efetivas com nfsstat -m em vez da linha do fstab, e confirme o transporte da VPN a partir do perfil que é realmente usado.

Depois registre ambos nas notas do incidente como dois campos separados. Uma melhoria aparente só pode ser rastreada se a nota disser qual camada mudou.

Navegar não é uma leitura em massa

Uma listagem de diretório prova que algumas operações foram concluídas. Não prova que uma leitura prolongada, uma escrita, um bloqueio ou o backend de armazenamento vão ser concluídos nas mesmas condições. Uma paralisação no meio de um arquivo grande é uma observação diferente de uma montagem que nunca funciona, e apontam para camadas diferentes.

Descreva a operação que falha com precisão: caminho, direção, ponto aproximado da paralisação e o último evento relevante nos registros do cliente, do servidor e da VPN. Depois compare onde o tráfego continua e onde para.

A MTU é uma hipótese, não um diagnóstico

A perda dependente do tamanho do pacote é uma possibilidade real quando um túnel transporta segmentos grandes, e produz exatamente o padrão em que a navegação funciona e a leitura trava. Esse padrão, porém, não prova um problema de MTU, porque a mesma forma aparece quando um servidor está lento, quando um firewall encerra por tempo de espera uma conexão longa ou quando um disco está ocupado. Teste a hipótese com uma sonda controlada em vez de baixar a MTU em todo lugar e declarar vitória.

Um tempo de espera por si só não diz nada sobre ser preciso trocar o UDP. É um sintoma com vários donos possíveis.

Altere uma variável por vez

Ao comparar transportes, mantenha a carga de trabalho NFS e todas as outras definições estáveis. Alterar o transporte de montagem, o protocolo do túnel e a MTU na mesma janela de manutenção produz um resultado que ninguém consegue atribuir. Execute a mesma operação de arquivo antes e depois, e registre o resultado em cada etapa.

Guarde também os valores anteriores no ticket. Se uma alteração piorar as coisas, a reversão deve ser um número documentado e não a lembrança de alguém de como era antes.

Leia a camada que falhou

Se o túnel está ativo e o pedido NFS espera, a VPN não falhou; o serviço de arquivos falhou. Se o túnel caiu, a falha do pedido NFS é uma consequência e não uma causa. Comparar linhas de registro das duas camadas é a forma mais rápida de distinguir esses dois casos, e é melhor do que adivinhar pelo gerenciador de arquivos.

Escreva a conclusão em duas frases, uma por camada. Isso basta para a próxima pessoa reproduzir o teste sem deduzir de novo qual transporte é qual.