Nextcloud només per VPN: inventarieu primer tots els accessos

Un pla de Nextcloud només per VPN fracassa quan protegeix el navegador i s’oblida del client de sincronització. La pàgina web, el motor de sincronització d’escriptori, les pujades mòbils, les eines WebDAV i els destinataris d’enllaços compartits necessiten tots un camí cap al mateix servei, i cadascun pot exposar una entrada diferent. Inventarieu-los abans de tancar res. Aquesta llista és el perímetre real.

Seguiu la llista de verificació en ordre. El primer punt defineix què vol dir privat per a aquesta implantació; els punts següents comproven si la implantació s’ajusta realment a aquesta definició.

Definiu què és privat abans de canviar el perímetre

Escriviu el requisit en una sola frase: cada usuari ha de connectar-se a la VPN abans d’arribar a l’aplicació, o bé l’aplicació pot romandre pública mentre el seu origen es manté privat. Són dissenys diferents, i un proxy invers públic que reenvia cap a un túnel privat només compleix el segon.

Una adreça de backend privada no fa que l’aplicació sigui privada. Si un mapatge públic, un segon nom d’amfitrió o un oient IPv6 encara arriben a la mateixa instància de Nextcloud, l’entrada existeix independentment d’on se situï el backend. Proveu cada nom des de fora abans de declarar el servei privat. Un registre DNS absent no és el mateix que un port tancat.

Acordeu també el públic destinatari: empleats, una llar, una organització associada o un subconjunt de comptes. La resposta decideix si un enllaç compartit públic és una funcionalitat o una contradicció. Escriviu aquest públic al pla d’accés. És la prova per a cada excepció que segueixi.

Inventarieu cada accés i cada nom

Llisteu els mapatges d’adreces públics, els proxys inversos, els noms d’amfitrió alternatius, els oients IPv6 i qualsevol adreça de túnel o de malla que arribi al servei. Incloeu-hi els noms que resolen cap a aquestes adreces, perquè un registre DNS oblidat és un accés amb una etiqueta amable.

Reviseu la configuració del proxy per si té capçaleres reenviades i blocs de servidor alternatius. Un proxy afegit per a una altra aplicació pot exposar el mateix upstream per una ruta o per un amfitrió virtual sobrant. Llegiu la configuració real en lloc del diagrama previst. Els dos divergeixen més sovint després de moure una aplicació.

Aleshores bloqueu els accessos que no heu triat. Un backend privat amb un frontal públic no és un disseny només per VPN, i una regla de tallafoc que només cobreix IPv4 deixa l’oient IPv6 obert. Tanqueu totes dues famílies i tots dos noms en el mateix canvi.

Doneu a cada client un sol nom de servei

Apunteu el DNS privat al servei, encamineu aquest nom a través de la VPN i emeteu-ne el certificat. El nom s’ha de resoldre pel camí privat i validar-se sense cap avís. Un client que arriba directament a la IP encara necessita que el nom funcioni.

Els clients que es connecten per una adreça IP no relacionada no haurien de descartar errors de certificat perquè el disseny funcioni. Un nom estable també evita que els clients de sincronització creïn entrades de servidor duplicades quan canvia una adreça. Aquesta és la diferència entre un servei privat i una IP privada.

Mantingueu activada la validació de certificats. Una xarxa privada redueix l’exposició, però no fa acceptable una connexió TLS no validada, i un client acostumat a ignorar avisos també els ignorarà en altres xarxes.

Limiteu l’accés a la xarxa, no tota la LAN

Permeteu que els usuaris inscrits arribin al servei de Nextcloud i a les seves dependències necessàries, i manteniu l’administració del servidor en un camí separat. Una VPN que admet un client a tota la xarxa domèstica o d’oficina dóna a aquest client molt més del que l’aplicació requereix.

L’admissió a la VPN no substitueix els comptes, els permisos ni l’autenticació addicional de Nextcloud. L’aplicació continua decidint quin usuari pot llegir quin fitxer, i la capa de xarxa no hauria de ser l’únic control.

Enregistreu el rang d’origen aprovat i els ports del servei. El propietari de la destinació necessita l’origen observat, i un NAT o un proxy poden reescriure’l abans que la petició arribi a l’aplicació.

Reviseu cada flux de treball fora del navegador

La sincronització d’escriptori i les pujades mòbils obren les seves pròpies connexions en els seus propis moments. Necessiten el camí privat aprovat quan es connecten, i poden comportar-se de manera diferent quan falta la VPN: reintentar, posar-se en pausa o mostrar un error. Proveu-ne cada un, no només el navegador.

Les eines WebDAV i els clients de calendari o de contactes són integracions separades amb configuració pròpia. Un client que fa memòria cau d’un URL públic continua provant aquest URL després del canvi de perímetre, i la fallada sembla un problema de l’aplicació.

Els enllaços compartits mereixen una decisió explícita. Un enllaç no atorga accés a la VPN al seu destinatari, així que en un disseny genuïnament només per VPN un destinatari extern no el pot fer servir encara que l’enllaç sigui vàlid. Si cal compartir fora, és una excepció deliberada amb el seu propi camí d’accés, no un descuit a descobrir més endavant.

La federació i les integracions de servidor a servidor necessiten el mateix tractament. Són relacions d’abastabilitat entre instal·lacions, i una implantació només privada ha de dir si s’hi dóna suport.

Accepteu tant el cas permès com el denegat

Des d’un client aprovat, comproveu la interfície web i una càrrega o descàrrega de fitxer corrent. Després comproveu un client de sincronització i un flux de treball fora del navegador. L’èxit només al navegador no és acceptació.

Des d’un camí no aprovat, confirmeu que l’aplicació no és abastable per cap dels accessos de l’inventari. Proveu el nom d’amfitrió alternatiu i l’adreça IPv6, no només l’URL principal.

Finalment, reviseu la configuració de l’aplicació que és fàcil confondre amb la política de xarxa. trusted_domains llista els noms que la instància accepta; no és una llista d’IP de client permeses. Si un proxy invers proporciona informació d’adreça, trusted_proxies ha de nomenar el proxy real, i les capçaleres reenviades només s’han d’acceptar d’ell.

Continueu la feina habitual de reforç al costat del canvi de xarxa: manteniu les dades i les còpies de seguretat fora de rutes web no previstes, actualitzeu l’aplicació, protegiu l’accés d’administrador i manteniu la recuperació utilitzable. Una VPN elimina una superfície d’entrada; no fa fiable un client inscrit.