NFS detrás de una VPN: ¿montaje en el arranque o automontaje bajo demanda?

Dos configuraciones resuelven el mismo problema y fallan en direcciones opuestas. Montar el recurso compartido en el arranque da a cada servicio un sistema de archivos que o bien está ahí o bien explica por qué se detuvo el arranque. Un automontaje bajo demanda da a la máquina un arranque rápido y pasa la espera a quien toque la ruta primero. Detrás de una VPN el segundo suele ser el mejor intercambio, y la razón es que el túnel impone un orden que la secuencia de arranque no puede ver.

Montaje en el arranque frente a automontaje

Un montaje en el arranque es fácil de razonar. El destino del sistema de archivos espera al montaje, los servicios que declaran una dependencia de él arrancan después, y si el servidor no es accesible la máquina o espera o falla según las opciones. Todo lo que va detrás hereda esa única decisión.

Un automontaje lo invierte. La ruta existe de inmediato, el montaje real ocurre cuando algo la abre, y los servicios que arrancan pronto no se bloquean en un túnel que aún no ha subido.

La comparación se reduce a quién debe absorber el retraso. Una estación de trabajo que necesita el recurso antes de que el usuario pueda trabajar probablemente debería esperar. Un portátil que arranca dentro de una bolsa, o un servidor cuyo recurso es opcional, no.

Ninguna de las dos opciones arregla una ruta que falta. Ambas solo deciden cuándo se observa el fallo.

La línea de fstab, opción por opción

Suponga que una instancia de cliente OpenVPN existente es [email protected], el servidor es files.corp.example y el punto de montaje es /mnt/work. Sustituya los tres por los valores autorizados de su propio sitio. Una línea que funciona se ve así:

files.corp.example:/export/work /mnt/work nfs _netdev,nofail,x-systemd.automount,[email protected],x-systemd.mount-timeout=30s 0 0

_netdev marca el montaje como necesitado de red, y no nombra ningún túnel. nofail mantiene el recurso opcional para el destino normal del sistema de archivos. x-systemd.automount crea el disparador bajo demanda en lugar de montar de inmediato.

x-systemd.requires= es la parte que ata el intento de montaje a la unidad de VPN, y pertenece a la operación de montaje, no al disparador. Poner un orden amplio en la propia unidad de automontaje es como la gente crea ciclos de los que luego systemd se queja en un idioma que nadie lee dos veces.

x-systemd.mount-timeout=30s limita el comando de montaje inicial. No limita nada de lo que ocurre después, y ese es el malentendido más común sobre esta opción.

Qué no significa «iniciado»

Compruebe qué significa estar activo para la unidad de VPN que ha nombrado. Un servicio de túnel puede informar de que se ha iniciado antes de que exista la ruta al servidor de archivos o antes de que se resuelva el nombre privado, y ordenar después de él entonces no le compra nada. En ese hueco vive casi todo intento fallido. También es invisible a menos que mire la ruta y el resolutor en lugar del estado de la unidad.

Use la propia señal de preparación del dueño de la conexión como requisito previo adicional donde exista. Una espera fija es una suposición que funciona en su escritorio y falla en una red más lenta o tras una reconexión.

Inspeccione las unidades generadas para la ruta del ejemplo: mnt-work.automount y mnt-work.mount. Tras un cambio de fstab revisado, recargue systemd y gestione esas unidades directamente en lugar de ejecutar un comando de montaje general que ejercita entradas no relacionadas.

Aquí cabe una advertencia más. Un servicio que toca /mnt/work al arrancar sigue disparando el montaje y sigue esperándolo, así que marcar el recurso como opcional no hace paciente a todas las aplicaciones.

Después del montaje el fallo es otro

Una vez montado NFS, el comportamiento de reintento y recuperación del sistema de archivos gobierna qué le hace una caída posterior a una lectura o una escritura. El tiempo de espera de montaje que haya puesto no influye en eso.

Un montaje suave acorta algunas esperas y cambia la semántica de los errores, con consecuencias para la integridad de los datos fáciles de pasar por alto cuando el objetivo es un arranque más rápido. Elegirlo para ganar dos segundos de arranque rara vez es un buen intercambio. Si el requisito es de verdad una operación acotada durante una caída, eso es una decisión a nivel de aplicación, no un indicador de fstab.

Decida qué debe pasar con un proceso que está a mitad de escritura cuando el túnel cae, y anótelo. Esa respuesta es más útil que cualquier cadena de opciones.

Pruebe cuatro estados, no uno

Un arranque normal con el túnel disponible es el caso fácil y no demuestra casi nada. Confirma que la cadena está bien escrita y nada más. Pruebe el primer acceso sin la VPN, luego la recuperación cuando sube, luego una caída controlada tras un montaje correcto.

Cuatro estados, cuatro observaciones, y las notas van junto a la entrada de fstab. La siguiente persona hereda comportamiento en lugar de una configuración que tiene que reconstruir.