La reexportación de NFS a través de una VPN no es reenvío de paquetes
La máquina intermedia es cliente y servidor, no un enrutador. Los identificadores de sistema de archivos, los handles de archivo envueltos y la falta de soporte de bloqueo cambian el diseño.
Una máquina Linux se une a una VPN, monta una exportación NFS remota y luego sirve ese montaje a otro conjunto de clientes. Este arreglo parece enrutamiento con pasos extra, y esa es la primera suposición equivocada. La máquina intermedia es cliente del servidor de aguas arriba y servidor de los clientes de aguas abajo, y participa en ambas relaciones de servicio de archivos. El reenvío de paquetes no tiene opinión sobre los handles de archivo, el bloqueo ni la identidad del sistema de archivos; una reexportación sí.
Empiece preguntando si los clientes de aguas abajo podrían llegar al servidor original directamente. Si pueden, la máquina intermedia es opcional.
Tres modelos, tres historias de consistencia
El montaje directo es el más simple: cada cliente monta el servidor original a través del túnel, y la política de exportación de ese servidor gobierna el acceso. La reexportación es la máquina intermedia presentando una frontera de servicio distinta, lo que resulta útil cuando la red orientada a los clientes no debe llegar directamente al servidor. La replicación es un tercer modelo, y cambia la pregunta de consistencia a sincronización y resolución de conflictos.
No describa una copia replicada como si fuera una reexportación viva. Los modos de fallo difieren, y un usuario que espera que cada operación llegue al sistema de archivos original se llevará una sorpresa durante una interrupción del enlace.
La identidad sobrevive al comando de montaje
Las reexportaciones necesitan un identificador de sistema de archivos explícito, y esa identidad debe sobrevivir a reinicios y reconstrucciones de configuración. La documentación del núcleo es clara sobre el requisito, y también advierte que crossmnt no elimina la necesidad de exportar sistemas de archivos hijos con sus propios identificadores. Un árbol de directorios que parece continuo para un usuario puede cruzar varias fronteras de sistema de archivos. Los nfs-utils actuales pueden asignar identificadores automáticamente para configuraciones compatibles, y cuando lo hacen, su base de datos pasa a formar parte del estado de la puerta de enlace. Trate esos identificadores como identidad de servicio en lugar de archivos desechables.
Los handles de archivo son la otra frontera de identidad: una reexportación envuelve el handle original, lo que lo hace más grande y puede superar el límite de un cliente. Un montaje exitoso no demuestra que todo diseño de exportación sea compatible.
No toda función de NFS sobrevive a la máquina intermedia
La guía de reexportación del núcleo afirma que el servidor que reexporta no admite bloqueo ni solicitudes de delegación. Las aplicaciones que dependen de esas operaciones necesitan otra ruta o un diseño verificado contra ellas. Un montaje exitoso y un listado de directorios funcional no demuestran que las operaciones reales de la aplicación funcionen.
La identidad de usuario y la política de exportación también importan en cada salto. Un inicio de sesión VPN demuestra que un participante de la red se autenticó; no autoriza a un usuario de NFS ni reenvía las credenciales de un cliente a través de la puerta de enlace.
La puerta de enlace tiene dos dependencias de aguas arriba
La puerta de enlace depende de la VPN para el montaje de aguas arriba y del servidor de aguas arriba para el sistema de archivos mismo. Un proceso de exportación local que sigue ejecutándose no puede hacer saludable un almacenamiento no disponible. Planifique el orden de inicio, el comportamiento de reconexión y los reinicios del servidor, incluido qué ocurre con los handles de archivo que los clientes ya tienen. Un cliente que montó a través de la puerta de enlace y perdió su handle necesita volver a montar, y eso es un evento operativo y no una recuperación transparente.
Si todo lo que el requisito necesitaba era accesibilidad de IP privadas, el enrutamiento directo al servidor original es la arquitectura más simple. La reexportación debería existir por una razón que sobreviva a ser escrita.
Pruebe la carga de trabajo, no el montaje
Ejercite la carga de archivos real en un entorno controlado: las operaciones que realiza la aplicación, los tamaños de archivo que usa y la concurrencia que espera. Vigile las carencias de funciones y no solo los errores de transporte. Luego anote qué modelo eligió y por qué, porque de lo contrario la siguiente persona asumirá que la puerta de enlace es un enrutador.
Una reexportación es legítima cuando existe por una razón deliberada, como una red de clientes aislada o una frontera de versión controlada. Es un mal accidente, y la diferencia es si alguien lo decidió.