Nextcloud solo por VPN: inventaríe primero cada acceso

Un plan de Nextcloud solo por VPN falla cuando protege el navegador y olvida el cliente de sincronización. La página web, el motor de sincronización de escritorio, las subidas móviles, las herramientas WebDAV y los destinatarios de enlaces compartidos necesitan todos una ruta hacia el mismo servicio, y cada uno puede exponer una entrada distinta. Inventaríelos antes de cerrar nada. Esa lista es el perímetro real.

Siga la lista de comprobación en orden. El primer punto define qué significa privado para esta implantación; los siguientes comprueban si la implantación coincide realmente con esa definición.

Defina qué es privado antes de cambiar el perímetro

Escriba el requisito en una sola frase: cada usuario debe unirse a la VPN antes de llegar a la aplicación, o la aplicación puede seguir siendo pública mientras su origen permanece privado. Son diseños distintos, y un proxy inverso público que reenvía a un túnel privado solo cumple el segundo.

Una dirección de backend privada no hace privada la aplicación. Si una asignación pública, un segundo nombre de host o un escucha IPv6 siguen llegando a la misma instancia de Nextcloud, la entrada existe independientemente de dónde esté el backend. Pruebe cada nombre desde fuera antes de declarar privado el servicio. Un registro DNS ausente no es lo mismo que un puerto cerrado.

Acuerde también el público destinatario: empleados, un hogar, una organización asociada o un subconjunto de cuentas. La respuesta decide si un enlace compartido público es una función o una contradicción. Escriba ese público en el plan de acceso. Es la prueba para cada excepción que siga.

Inventaríe cada entrada y cada nombre

Enumere las asignaciones de direcciones públicas, los proxys inversos, los nombres de host alternativos, los escuchas IPv6 y cualquier dirección de túnel o malla que llegue al servicio. Incluya los nombres que resuelven a esas direcciones, porque un registro DNS olvidado es una entrada con una etiqueta amable.

Revise la configuración del proxy por si tiene cabeceras reenviadas y bloques de servidor alternativos. Un proxy añadido para otra aplicación puede exponer el mismo upstream por una ruta o por un host virtual sobrante. Lea la configuración real en lugar del diagrama previsto. Los dos divergen más a menudo después de mover una aplicación.

Después bloquee las entradas que no eligió. Un backend privado con un frontend público no es un diseño solo por VPN, y una regla de cortafuegos que solo cubre IPv4 deja abierto el escucha IPv6. Cierre ambas familias y ambos nombres en el mismo cambio.

Dé a cada cliente un único nombre de servicio

Apunte el DNS privado al servicio, encamine ese nombre por la VPN y emita el certificado para él. El nombre debe resolverse por la ruta privada y validarse sin advertencia. Un cliente que llega directamente a la IP sigue necesitando que el nombre funcione.

Los clientes que se conectan por una dirección IP no relacionada no deberían tener que descartar errores de certificado para que el diseño funcione. Un nombre estable también evita que los clientes de sincronización creen entradas de servidor duplicadas cuando cambia una dirección. Esa es la diferencia entre un servicio privado y una IP privada.

Mantenga activada la validación de certificados. Una red privada reduce la exposición, pero no hace aceptable una conexión TLS sin validar, y un cliente acostumbrado a ignorar advertencias también las ignorará en otras redes.

Limite el acceso a la red, no toda la LAN

Permita que los usuarios inscritos lleguen al servicio de Nextcloud y a sus dependencias necesarias, y mantenga la administración del servidor en una ruta separada. Una VPN que admite a un cliente en toda la red doméstica o de oficina da a ese cliente mucho más de lo que la aplicación requiere.

La admisión a la VPN no sustituye las cuentas, los permisos ni la autenticación adicional de Nextcloud. La aplicación sigue decidiendo qué usuario puede leer qué archivo, y la capa de red no debería ser el único control.

Anote el rango de origen aprobado y los puertos del servicio. El propietario del destino necesita el origen observado, y un NAT o un proxy pueden reescribirlo antes de que la petición llegue a la aplicación.

Revise cada flujo de trabajo fuera del navegador

La sincronización de escritorio y las subidas móviles abren sus propias conexiones en sus propios momentos. Necesitan la ruta privada aprobada cuando se conectan, y pueden comportarse de forma distinta cuando falta la VPN: reintentar, pausar o mostrar un error. Pruebe cada uno, no solo el navegador.

Las herramientas WebDAV y los clientes de calendario o contactos son integraciones separadas con su propia configuración. Un cliente que almacena en caché una URL pública sigue intentando esa URL tras el cambio de perímetro, y el fallo parece un problema de la aplicación.

Los enlaces compartidos merecen una decisión explícita. Un enlace no concede acceso a la VPN a su destinatario, así que en un diseño genuinamente solo por VPN un destinatario externo no puede usarlo aunque el enlace sea válido. Si se necesita compartir fuera, es una excepción deliberada con su propia ruta de acceso, no un descuido que se descubra después.

La federación y las integraciones de servidor a servidor necesitan el mismo tratamiento. Son relaciones de alcanzabilidad entre instalaciones, y una implantación solo privada tiene que decir si se admiten.

Acepte tanto el caso permitido como el denegado

Desde un cliente aprobado, compruebe la interfaz web y una subida o descarga de archivo corriente. Después compruebe un cliente de sincronización y un flujo de trabajo fuera del navegador. El éxito solo en el navegador no es aceptación.

Desde una ruta no aprobada, confirme que la aplicación no es alcanzable por ninguna entrada del inventario. Pruebe el nombre de host alternativo y la dirección IPv6, no solo la URL principal.

Por último, revise los ajustes de la aplicación que se confunden fácilmente con la política de red. trusted_domains enumera los nombres que la instancia acepta; no es una lista de permitidos de IP de cliente. Si un proxy inverso proporciona información de dirección, trusted_proxies debe nombrar el proxy real, y las cabeceras reenviadas solo deberían aceptarse de él.

Continúe el trabajo habitual de refuerzo junto con el cambio de red: mantenga los datos y las copias de seguridad fuera de rutas web no previstas, actualice la aplicación, proteja el acceso de administrador y mantenga la recuperación utilizable. Una VPN elimina una superficie de entrada; no hace fiable a un cliente inscrito.