NFS sobre TCP dentro dun túnel UDP de OpenVPN: dous transportes

Levar unha conversa NFS que usa TCP dentro dun túnel que transporta UDP é totalmente coherente, e confunde a xente porque nomea dous transportes á vez. TCP é a conversa do servizo de ficheiros entre o cliente e o servidor NFS. UDP é o portador cifrado entre os extremos da VPN. Ningún dos dous implica nada sobre o outro.

Anote ambos por separado antes de depurar nada; a maioría destes incidentes comezan cando alguén cambia a capa equivocada.

Dúas capas, dous axustes

A opción de montaxe proto=tcp describe como fala o cliente NFS co servidor NFS. O axuste proto udp do perfil da VPN describe como intercambian paquetes encapsulados os extremos do túnel. Cambiar unha opción de montaxe non cambia o túnel, e cambiar o transporte do túnel non cambia o que negociou o cliente NFS. Confirme as opcións de montaxe efectivas con nfsstat -m en lugar da liña de fstab, e confirme o transporte da VPN desde o perfil que se usa realmente.

Despois anóteos nas notas do incidente como dous campos separados. Unha mellora aparente só se pode rastrexar se a nota di que capa cambiou.

Navegar non é unha lectura masiva

Unha listaxe de directorio demostra que algunhas operacións se completaron. Non demostra que unha lectura sostida, unha escritura, un bloqueo ou o backend de almacenamento vaian completarse nas mesmas condicións. Un bloqueo a metade dun ficheiro grande é unha observación distinta dunha montaxe que nunca funciona, e apuntan a capas diferentes.

Describa a operación que falla con precisión: ruta, dirección, punto aproximado do bloqueo e o último evento relevante nos rexistros do cliente, do servidor e da VPN. Logo compare onde continúa o tráfico e onde se detén.

A MTU é unha hipótese, non un diagnóstico

A perda dependente do tamaño do paquete é unha posibilidade real cando un túnel transporta segmentos grandes, e produce exactamente o patrón de que navegar funciona e ler atasca. Con todo, ese patrón non demostra un problema de MTU, porque a mesma forma aparece cando un servidor vai lento, cando unha devasa pecha por tempo de espera unha conexión de longa duración ou cando un disco está ocupado. Probe a hipótese cunha sonda controlada en lugar de baixar a MTU en todas partes e declarar a vitoria.

Un tempo de espera por si só non di nada sobre se se debería cambiar UDP. É un síntoma con varios posibles responsables.

Cambie unha variable á vez

Ao comparar transportes, manteña estables a carga de traballo NFS e todos os demais axustes. Cambiar o transporte de montaxe, o protocolo do túnel e a MTU na mesma ventá de mantemento produce un resultado que ninguén pode atribuír. Execute a mesma operación de ficheiro antes e despois, e anote o resultado en cada paso.

Garde tamén os valores anteriores no ticket. Se un cambio empeora as cousas, a volta atrás debería ser un número documentado e non o recordo de alguén de como era antes.

Lea a capa que fallou

Se o túnel está activo e a solicitude NFS espera, a VPN non fallou; fallou o servizo de ficheiros. Se o túnel caeu, o fallo da solicitude NFS é unha consecuencia e non unha causa. Cotejar liñas de rexistro das dúas capas é a forma máis rápida de distinguir eses dous casos, e supera adiviñar desde o xestor de ficheiros.

Escriba a conclusión como dúas frases, unha por capa. Iso abonda para que a seguinte persoa reproduza a proba sen volver deducir que transporte é cal.