- VM Linux dédiée issue d'un template Ubuntu Server
- Nginx comme reverse proxy
- Certificats Let's Encrypt gérés par Certbot
- Pare-feu local actif
- Fail2ban actif et validé pour l'administration SSH
- Redirection HTTP → HTTPS et renouvellement de certificat testés
- Réponses progressives et connexions WebSocket validées
- Redémarrage de VM200 validé sans perte de configuration
| Service | État public |
|---|---|
| OpenWebUI · VM210 | 🟢 publié & validé HTTPS |
| n8n · VM300 | 🟢 publié & validé HTTPS |
| Nextcloud · VM205 | 🟢 publié & validé HTTPS |
| autres services internes | ⚪ non publiés / différés |
1. Navigateur Internet
↓ demande gpt.stephanemuraro.fr
2. DNS public
↓ renvoie l'adresse Internet de la connexion
3. Routeur
↓ transfère uniquement le trafic Web vers VM200
4. VM200 / Nginx
↓ choisit le virtual host correspondant au nom
5. VM210 / OpenWebUI
↓ produit la réponse applicative
6. VM200 / Nginx
↓ renvoie la réponse dans la session HTTPS
7. NavigateurLe DNS associe seulement le nom public à l'adresse Internet — il ne connaît pas la VM qui héberge l'application. Le routeur ne choisit pas non plus le service : il remet les connexions Web à VM200. C'est Nginx qui effectue le routage applicatif : le nom demandé pendant la négociation TLS et dans la requête HTTP sélectionne un bloc de configuration (virtual host) qui désigne la machine et le service internes cibles.
gpt.stephanemuraro.fr ─┐
n8n.stephanemuraro.fr ─┼─> même adresse publique ─> VM200
nextcloud.stephanemuraro.fr ─┘ ├─> VM IA
├─> VM automatisation
└─> VM fichiers| Composant | Responsabilité | Limite |
|---|---|---|
| DNS public | associer un nom à l'adresse Internet | ne choisit pas la VM interne |
| Routeur | transmettre le trafic Web vers VM200 | ne comprend pas les applications |
| Pare-feu VM200 | refuser les entrées non prévues | ne remplace pas l'authentification |
| Nginx | terminer HTTPS, sélectionner le virtual host, relayer | ne stocke pas les données métier |
| Certbot | obtenir/renouveler les certificats Let's Encrypt | ne publie pas seul une application |
| Fail2ban | bloquer certaines attaques répétitives des journaux | ne remplace ni pare-feu ni mots de passe robustes |
| Backend | fournir l'application, contrôler ses utilisateurs | ne doit pas être exposé directement |
Le chiffrement public se termine sur VM200. Le certificat et sa clé privée restent centralisés sur le reverse proxy, ce qui évite de gérer un certificat public différent sur chaque backend.
Client Internet ═════ HTTPS chiffré ═════> VM200 VM200 ───── flux LAN contrôlé ──> backend
Nginx transmet au backend le nom demandé, le protocole externe et les informations nécessaires à la traçabilité. Pour les applications interactives, il prend en charge les WebSockets, les réponses progressives et des délais adaptés aux traitements longs.
- le routeur n'envoie à VM200 que le trafic Web nécessaire
- le pare-feu local refuse les autres connexions entrantes
- l'administration reste limitée au réseau interne
- Nginx ne relaie que les noms et services configurés
- TLS chiffre et authentifie la connexion publique
- Fail2ban réduit certaines tentatives répétitives observables
- chaque backend conserve son authentification et son filtrage
- bases de données et API techniques restent absentes du WAN
Fail2ban est validé pour SSH ; cela ne protège pas automatiquement les formulaires de connexion applicatifs — chaque protection exige un journal exploitable et un filtre testé.
- valider le service sur le réseau local
- identifier ses besoins HTTPS, WebSocket, taille de requête et délais
- définir son nom public et son modèle d'authentification
- configurer l'application pour son origine publique
- créer un virtual host distinct sur VM200
- valider la syntaxe Nginx avant rechargement
- obtenir et tester le certificat
- tester depuis un réseau réellement extérieur
- vérifier les journaux et l'absence d'exposition directe
- documenter le retour arrière
- désactiver uniquement le virtual host d'un service ;
- retirer temporairement le transfert Web vers VM200 ;
- arrêter VM200 pour neutraliser toutes les publications sans modifier les applications internes.
Le test formel du retour arrière global par retrait du transfert WAN reste le dernier contrôle ouvert de la première tranche.
- Conception d'un reverse proxy mutualisé
- DNS, NAT, SNI, virtual hosts et en-têtes de proxy
- Automatisation du cycle de vie des certificats
- Prise en charge des WebSockets et du streaming
- Segmentation entre frontière Internet et backends
- Défense en profondeur et stratégie de retour arrière
- Publication d'un service hébergé sur une autre machine
Infrastructure
n8n
Nextcloud