Nextcloud uniquement via VPN : inventoriez d’abord chaque accès

Un projet Nextcloud uniquement via VPN échoue lorsqu’il protège le navigateur et oublie le client de synchronisation. La page web, le moteur de synchronisation de bureau, les téléversements mobiles, les outils WebDAV et les destinataires de liens partagés ont tous besoin d’un chemin vers le même service, et chacun peut exposer une entrée différente. Inventoriez-les avant de fermer quoi que ce soit. Cette liste est le vrai périmètre.

Suivez la liste de contrôle dans l’ordre. Le premier point définit ce que privé signifie pour ce déploiement ; les points suivants vérifient si le déploiement correspond réellement à cette définition.

Définissez le privé avant de changer le périmètre

Écrivez l’exigence en une phrase : chaque utilisateur doit rejoindre le VPN avant d’atteindre l’application, ou l’application peut rester publique tant que son origine reste privée. Ce sont des conceptions différentes, et un proxy inverse public qui transfère vers un tunnel privé ne satisfait que la seconde.

Une adresse de backend privée ne rend pas l’application privée. Si une correspondance publique, un second nom d’hôte ou un écouteur IPv6 atteint encore la même instance Nextcloud, l’entrée existe quel que soit l’emplacement du backend. Testez chaque nom depuis l’extérieur avant de déclarer le service privé. Un enregistrement DNS manquant n’est pas identique à un port fermé.

Mettez-vous aussi d’accord sur le public visé : salariés, un foyer, une organisation partenaire ou un sous-ensemble de comptes. La réponse décide si un lien de partage public est une fonctionnalité ou une contradiction. Inscrivez ce public dans le plan d’accès. C’est le test de chaque exception qui suit.

Inventoriez chaque entrée et chaque nom

Listez les correspondances d’adresses publiques, les proxys inverses, les noms d’hôte alternatifs, les écouteurs IPv6 et toute adresse de tunnel ou de maillage qui atteint le service. Incluez les noms qui résolvent vers ces adresses, car un enregistrement DNS oublié est une entrée avec une étiquette avenante.

Vérifiez la configuration du proxy pour les en-têtes transférés et les blocs de serveur alternatifs. Un proxy ajouté pour une autre application peut exposer le même upstream par un chemin ou par un hôte virtuel restant. Lisez la configuration réelle plutôt que le schéma prévu. Les deux divergent le plus souvent après le déplacement d’une application.

Bloquez ensuite les entrées que vous n’avez pas choisies. Un backend privé avec un frontal public n’est pas une conception uniquement VPN, et une règle de pare-feu qui ne couvre qu’IPv4 laisse l’écouteur IPv6 ouvert. Fermez les deux familles et les deux noms dans le même changement.

Donnez à chaque client un seul nom de service

Pointez le DNS privé vers le service, faites passer ce nom par le VPN et émettez le certificat pour lui. Le nom doit se résoudre par le chemin privé et se valider sans avertissement. Un client qui atteint l’IP directement a toujours besoin que le nom fonctionne.

Les clients qui se connectent par une adresse IP sans rapport ne devraient pas avoir à ignorer des erreurs de certificat pour que la conception fonctionne. Un nom stable empêche aussi les clients de synchronisation de créer des entrées de serveur en double lorsqu’une adresse change. C’est la différence entre un service privé et une IP privée.

Laissez la validation des certificats activée. Un réseau privé réduit l’exposition mais ne rend pas acceptable une connexion TLS non validée, et un client habitué à ignorer les avertissements les ignorera aussi sur d’autres réseaux.

Limitez l’accès réseau, pas tout le LAN

Autorisez les utilisateurs inscrits à atteindre le service Nextcloud et ses dépendances nécessaires, et gardez l’administration du serveur sur un chemin séparé. Un VPN qui admet un client sur tout le réseau domestique ou de bureau donne à ce client bien plus que ce que l’application exige.

L’admission au VPN ne remplace pas les comptes, les permissions ou l’authentification supplémentaire de Nextcloud. L’application décide toujours quel utilisateur peut lire quel fichier, et la couche réseau ne devrait pas être le seul contrôle.

Notez la plage source approuvée et les ports du service. Le propriétaire de la cible a besoin de la source observée, et un NAT ou un proxy peut la réécrire avant que la requête n’atteigne l’application.

Passez en revue chaque flux de travail hors navigateur

La synchronisation de bureau et les téléversements mobiles ouvrent leurs propres connexions à leurs propres moments. Ils ont besoin du chemin privé approuvé lorsqu’ils se connectent, et ils peuvent se comporter différemment quand le VPN est absent : réessayer, suspendre ou afficher une erreur. Testez chacun, pas seulement le navigateur.

Les outils WebDAV et les clients de calendrier ou de contacts sont des intégrations distinctes avec leur propre configuration. Un client qui met en cache une URL publique continue d’essayer cette URL après le changement de périmètre, et l’échec ressemble à un problème d’application.

Les liens partagés méritent une décision explicite. Un lien n’accorde pas à son destinataire l’accès au VPN, donc dans une conception réellement uniquement VPN un destinataire extérieur ne peut pas l’utiliser même si le lien est valide. Si le partage vers l’extérieur est requis, c’est une exception délibérée avec son propre chemin d’accès, pas un oubli à découvrir plus tard.

La fédération et les intégrations serveur à serveur nécessitent le même traitement. Ce sont des relations d’accessibilité entre installations, et un déploiement uniquement privé doit dire si elles sont prises en charge.

Acceptez à la fois le cas autorisé et le cas refusé

Depuis un client approuvé, vérifiez l’interface web et un téléversement ou téléchargement de fichier ordinaire. Vérifiez ensuite un client de synchronisation et un flux de travail hors navigateur. Le succès dans le navigateur seul n’est pas une acceptation.

Depuis un chemin non approuvé, confirmez que l’application est injoignable par chaque entrée de l’inventaire. Testez le nom d’hôte alternatif et l’adresse IPv6, pas seulement l’URL principale.

Enfin, examinez les réglages de l’application faciles à confondre avec la politique réseau. trusted_domains liste les noms que l’instance accepte ; ce n’est pas une liste d’IP client autorisées. Si un proxy inverse fournit des informations d’adresse, trusted_proxies doit nommer le proxy réel, et les en-têtes transférés ne devraient être acceptés que de lui.

Poursuivez le durcissement habituel en parallèle du changement réseau : gardez les données et les sauvegardes hors des chemins web non voulus, corrigez l’application, protégez l’accès administrateur et gardez la restauration utilisable. Un VPN supprime une surface d’entrée ; il ne rend pas un client inscrit digne de confiance.