Nextcloud apenas por VPN: inventarie primeiro cada entrada

Um plano de Nextcloud apenas por VPN falha quando protege o navegador e esquece o cliente de sincronização. A página web, o motor de sincronização de ambiente de trabalho, os envios móveis, as ferramentas WebDAV e os destinatários de links partilhados precisam todos de um caminho para o mesmo serviço, e cada um pode expor uma entrada diferente. Inventarie-os antes de fechar seja o que for. Essa lista é o perímetro real.

Percorra a lista de verificação por ordem. O primeiro ponto define o que significa privado para esta implementação; os pontos seguintes testam se a implementação corresponde realmente a essa definição.

Defina o privado antes de alterar o perímetro

Escreva o requisito numa frase: cada utilizador tem de entrar na VPN antes de chegar à aplicação, ou a aplicação pode continuar pública enquanto a origem permanece privada. São desenhos diferentes, e um proxy inverso público que encaminha para um túnel privado satisfaz apenas o segundo.

Um endereço de backend privado não torna a aplicação privada. Se um mapeamento público, um segundo nome de anfitrião ou um ouvinte IPv6 ainda chegam à mesma instância de Nextcloud, a entrada existe independentemente de onde está o backend. Teste cada nome a partir de fora antes de declarar o serviço privado. Um registo DNS em falta não é o mesmo que uma porta fechada.

Acorde também o público pretendido: empregados, um agregado familiar, uma organização parceira ou um subconjunto de contas. A resposta decide se um link de partilha público é uma funcionalidade ou uma contradição. Escreva esse público no plano de acesso. É o teste para cada exceção que se segue.

Inventarie cada entrada e cada nome

Enumere mapeamentos de endereços públicos, proxies inversos, nomes de anfitrião alternativos, ouvintes IPv6 e qualquer endereço de túnel ou malha que chegue ao serviço. Inclua os nomes que resolvem para esses endereços, porque um registo DNS esquecido é uma entrada com uma etiqueta amigável.

Verifique a configuração do proxy quanto a cabeçalhos reencaminhados e blocos de servidor alternativos. Um proxy acrescentado para outra aplicação pode expor o mesmo upstream por um caminho ou por um anfitrião virtual remanescente. Leia a configuração real em vez do diagrama previsto. Os dois divergem mais frequentemente depois de uma aplicação ser movida.

Depois bloqueie as entradas que não escolheu. Um backend privado com uma frente pública não é um desenho apenas por VPN, e uma regra de firewall que só cobre IPv4 deixa o ouvinte IPv6 aberto. Feche ambas as famílias e ambos os nomes na mesma alteração.

Dê a cada cliente um único nome de serviço

Aponte o DNS privado para o serviço, encaminhe esse nome através da VPN e emita o certificado para ele. O nome tem de resolver pelo caminho privado e validar sem aviso. Um cliente que chega diretamente ao IP continua a precisar que o nome funcione.

Os clientes que ligam por um endereço IP não relacionado não deviam ter de dispensar erros de certificado para o desenho funcionar. Um nome estável também impede os clientes de sincronização de criar entradas de servidor duplicadas quando um endereço muda. É a diferença entre um serviço privado e um IP privado.

Mantenha a validação de certificados ativa. Uma rede privada reduz a exposição mas não torna aceitável uma ligação TLS não validada, e um cliente habituado a ignorar avisos também os ignorará noutras redes.

Limite o acesso à rede, não toda a LAN

Permita que os utilizadores inscritos cheguem ao serviço Nextcloud e às suas dependências necessárias, e mantenha a administração do servidor num caminho separado. Uma VPN que admite um cliente em toda a rede doméstica ou de escritório dá a esse cliente muito mais do que a aplicação exige.

A admissão à VPN não substitui as contas, as permissões ou a autenticação adicional do Nextcloud. A aplicação continua a decidir que utilizador pode ler que ficheiro, e a camada de rede não devia ser o único controlo.

Registe o intervalo de origem aprovado e as portas do serviço. O proprietário do destino precisa da origem observada, e um NAT ou proxy podem reescrevê-la antes de o pedido chegar à aplicação.

Reveja cada fluxo de trabalho fora do navegador

A sincronização de ambiente de trabalho e os envios móveis abrem as suas próprias ligações nos seus próprios momentos. Precisam do caminho privado aprovado quando ligam, e podem comportar-se de forma diferente quando a VPN falta: tentar de novo, pausar ou mostrar um erro. Teste cada um, não apenas o navegador.

As ferramentas WebDAV e os clientes de calendário ou contactos são integrações separadas com a sua própria configuração. Um cliente que coloca um URL público em cache continua a tentar esse URL após a alteração do perímetro, e a falha parece um problema da aplicação.

Os links partilhados merecem uma decisão explícita. Um link não concede acesso à VPN ao seu destinatário, por isso num desenho genuinamente apenas por VPN um destinatário externo não o pode usar mesmo que o link seja válido. Se a partilha para fora for necessária, é uma exceção deliberada com o seu próprio caminho de acesso, não um descuido a descobrir mais tarde.

A federação e as integrações servidor-a-servidor precisam do mesmo tratamento. São relações de alcançabilidade entre instalações, e uma implementação apenas privada tem de dizer se são suportadas.

Aceite tanto o caso permitido como o negado

A partir de um cliente aprovado, verifique a interface web e um envio ou transferência de ficheiro comum. Depois verifique um cliente de sincronização e um fluxo de trabalho fora do navegador. O sucesso apenas no navegador não é aceitação.

A partir de um caminho não aprovado, confirme que a aplicação é inalcançável através de cada entrada do inventário. Teste o nome de anfitrião alternativo e o endereço IPv6, não apenas o URL principal.

Por fim, reveja as definições da aplicação que são fáceis de confundir com a política de rede. trusted_domains lista os nomes que a instância aceita; não é uma lista de IP de cliente permitidos. Se um proxy inverso fornece informações de endereço, trusted_proxies tem de nomear o proxy real, e os cabeçalhos reencaminhados só devem ser aceites dele.

Continue o trabalho habitual de reforço a par da alteração de rede: mantenha os dados e as cópias de segurança fora de caminhos web não previstos, atualize a aplicação, proteja o acesso de administrador e mantenha a recuperação utilizável. Uma VPN remove uma superfície de entrada; não torna um cliente inscrito fidedigno.