NFS sobre TCP dentro de un túnel UDP de OpenVPN: dos transportes

Llevar una conversación NFS que usa TCP dentro de un túnel que transporta UDP es del todo coherente, y confunde a la gente porque nombra dos transportes a la vez. TCP es la conversación del servicio de archivos entre el cliente y el servidor NFS. UDP es el portador cifrado entre los extremos del VPN. Ninguno de los dos implica nada sobre el otro.

Anote ambos por separado antes de depurar nada; la mayoría de estos incidentes empiezan cuando alguien cambia la capa equivocada.

Dos capas, dos ajustes

La opción de montaje proto=tcp describe cómo habla el cliente NFS con el servidor NFS. El ajuste proto udp del perfil de VPN describe cómo intercambian paquetes encapsulados los extremos del túnel. Cambiar una opción de montaje no cambia el túnel, y cambiar el transporte del túnel no cambia lo que ha negociado el cliente NFS. Confirme las opciones de montaje efectivas con nfsstat -m en lugar de la línea de fstab, y confirme el transporte del VPN desde el perfil que se usa realmente.

Después anótelos en las notas del incidente como dos campos separados. Una mejora aparente solo se puede rastrear si la nota dice qué capa cambió.

Navegar no es una lectura masiva

Un listado de directorio demuestra que algunas operaciones se completaron. No demuestra que una lectura sostenida, una escritura, un bloqueo o el backend de almacenamiento vayan a completarse en las mismas condiciones. Un bloqueo a mitad de un archivo grande es una observación distinta de un montaje que nunca funciona, y apuntan a capas diferentes.

Describa la operación que falla con precisión: ruta, dirección, punto aproximado del bloqueo y el último evento relevante en los registros del cliente, del servidor y del VPN. Luego compare dónde continúa el tráfico y dónde se detiene.

La MTU es una hipótesis, no un diagnóstico

La pérdida dependiente del tamaño del paquete es una posibilidad real cuando un túnel transporta segmentos grandes, y produce exactamente el patrón de que navegar funciona y leer se atasca. Sin embargo, ese patrón no demuestra un problema de MTU, porque la misma forma aparece cuando un servidor va lento, cuando un cortafuegos cierra por tiempo de espera una conexión de larga duración o cuando un disco está ocupado. Pruebe la hipótesis con una sonda controlada en lugar de bajar la MTU en todas partes y declarar la victoria.

Un tiempo de espera por sí solo no dice nada sobre si debería cambiarse UDP. Es un síntoma con varios posibles responsables.

Cambie una variable a la vez

Al comparar transportes, mantenga estables la carga de trabajo NFS y todos los demás ajustes. Cambiar el transporte de montaje, el protocolo del túnel y la MTU en la misma ventana de mantenimiento produce un resultado que nadie puede atribuir. Ejecute la misma operación de archivo antes y después, y anote el resultado en cada paso.

Guarde también los valores anteriores en el ticket. Si un cambio empeora las cosas, la vuelta atrás debería ser un número documentado y no el recuerdo de alguien de cómo era antes.

Lea la capa que falló

Si el túnel está activo y la solicitud NFS espera, el VPN no falló; falló el servicio de archivos. Si el túnel se cayó, el fallo de la solicitud NFS es una consecuencia y no una causa. Cotejar líneas de registro de ambas capas es la forma más rápida de distinguir esos dos casos, y supera a adivinar desde el gestor de archivos.

Escriba la conclusión como dos frases, una por capa. Eso basta para que la siguiente persona reproduzca la prueba sin volver a deducir qué transporte es cuál.