Nextcloud só por VPN: inventarie primeiro cada acceso

Un plan de Nextcloud só por VPN falla cando protexe o navegador e esquece o cliente de sincronización. A páxina web, o motor de sincronización de escritorio, as subidas móbiles, as ferramentas WebDAV e os destinatarios de ligazóns compartidas necesitan todos unha ruta cara ao mesmo servizo, e cada un pode expor unha entrada distinta. Inventaríeos antes de pechar nada. Esa lista é o perímetro real.

Siga a lista de comprobación en orde. O primeiro punto define que significa privado para esta implantación; os seguintes comproban se a implantación coincide realmente con esa definición.

Defina que é privado antes de cambiar o perímetro

Escriba o requisito nunha soa frase: cada usuario debe unirse á VPN antes de chegar á aplicación, ou a aplicación pode seguir sendo pública mentres a súa orixe permanece privada. Son deseños distintos, e un proxy inverso público que reenvía a un túnel privado só cumpre o segundo.

Un enderezo de backend privado non fai privada a aplicación. Se unha asignación pública, un segundo nome de host ou un oínte IPv6 seguen chegando á mesma instancia de Nextcloud, a entrada existe independentemente de onde estea o backend. Probe cada nome desde fóra antes de declarar privado o servizo. Un rexistro DNS ausente non é o mesmo que un porto pechado.

Acorde tamén o público destinatario: empregados, un fogar, unha organización asociada ou un subconxunto de contas. A resposta decide se unha ligazón compartida pública é unha función ou unha contradición. Escriba ese público no plan de acceso. É a proba para cada excepción que siga.

Inventaríe cada entrada e cada nome

Enumere as asignacións de enderezos públicas, os proxies inversos, os nomes de host alternativos, os oíntes IPv6 e calquera enderezo de túnel ou malla que chegue ao servizo. Inclúa os nomes que resolven a eses enderezos, porque un rexistro DNS esquecido é unha entrada cunha etiqueta amable.

Revise a configuración do proxy por se ten cabeceiras reenviadas e bloques de servidor alternativos. Un proxy engadido para outra aplicación pode expor o mesmo upstream por unha ruta ou por un host virtual sobrante. Lea a configuración real en lugar do diagrama previsto. Os dous diverxen máis a miúdo despois de mover unha aplicación.

Despois bloquee as entradas que non escolleu. Un backend privado cun frontend público non é un deseño só por VPN, e unha regra de cortalumes que só cobre IPv4 deixa aberto o oínte IPv6. Peche ambas as familias e ambos os nomes no mesmo cambio.

Dea a cada cliente un único nome de servizo

Apunte o DNS privado ao servizo, encamiñe ese nome pola VPN e emita o certificado para el. O nome debe resolverse pola ruta privada e validarse sen advertencia. Un cliente que chega directamente ao IP segue necesitando que o nome funcione.

Os clientes que se conectan por un enderezo IP non relacionado non deberían ter que descartar erros de certificado para que o deseño funcione. Un nome estable tamén evita que os clientes de sincronización creen entradas de servidor duplicadas cando cambia un enderezo. Esa é a diferenza entre un servizo privado e un IP privado.

Manteña activada a validación de certificados. Unha rede privada reduce a exposición, pero non fai aceptable unha conexión TLS sen validar, e un cliente afeito ignorar advertencias tamén as ignorará noutras redes.

Limite o acceso á rede, non toda a LAN

Permita que os usuarios inscritos cheguen ao servizo de Nextcloud e ás súas dependencias necesarias, e manteña a administración do servidor nunha ruta separada. Unha VPN que admite un cliente en toda a rede doméstica ou de oficina dá a ese cliente moito máis do que a aplicación require.

A admisión á VPN non substitúe as contas, os permisos nin a autenticación adicional de Nextcloud. A aplicación segue decidindo que usuario pode ler que ficheiro, e a capa de rede non debería ser o único control.

Anote o rango de orixe aprobado e os portos do servizo. O propietario do destino necesita a orixe observada, e un NAT ou un proxy poden reescribila antes de que a petición chegue á aplicación.

Revise cada fluxo de traballo fóra do navegador

A sincronización de escritorio e as subidas móbiles abren as súas propias conexións nos seus propios momentos. Necesitan a ruta privada aprobada cando se conectan, e poden comportarse de forma distinta cando falta a VPN: reintentar, pausar ou mostrar un erro. Probe cada un, non só o navegador.

As ferramentas WebDAV e os clientes de calendario ou contactos son integracións separadas coa súa propia configuración. Un cliente que almacena en caché un URL público segue intentando ese URL tras o cambio de perímetro, e o fallo parece un problema da aplicación.

As ligazóns compartidas merecen unha decisión explícita. Unha ligazón non concede acceso á VPN ao seu destinatario, así que nun deseño xenuinamente só por VPN un destinatario externo non pode usala aínda que a ligazón sexa válida. Se se necesita compartir fóra, é unha excepción deliberada coa súa propia ruta de acceso, non un descoido que se descubra despois.

A federación e as integracións de servidor a servidor necesitan o mesmo tratamento. Son relacións de alcanzabilidade entre instalacións, e unha implantación só privada ten que dicir se se admiten.

Acepte tanto o caso permitido como o denegado

Desde un cliente aprobado, comprobe a interface web e unha subida ou descarga de ficheiro corrente. Despois comprobe un cliente de sincronización e un fluxo de traballo fóra do navegador. O éxito só no navegador non é aceptación.

Desde unha ruta non aprobada, confirme que a aplicación non é alcanzable por ningunha entrada do inventario. Probe o nome de host alternativo e o enderezo IPv6, non só o URL principal.

Por último, revise os axustes da aplicación que se confunden facilmente coa política de rede. trusted_domains enumera os nomes que a instancia acepta; non é unha lista de permitidos de IP de cliente. Se un proxy inverso fornece información de enderezo, trusted_proxies debe nomear o proxy real, e as cabeceiras reenviadas só deberían aceptarse del.

Continúe o traballo habitual de reforzo xunto co cambio de rede: manteña os datos e as copias de seguridade fóra de rutas web non previstas, actualice a aplicación, protexa o acceso de administrador e manteña a recuperación utilizábel. Unha VPN elimina unha superficie de entrada; non fai fiábel un cliente inscrito.