Réseau Limpida Apps

Le parcours, pas à pas

Choisissez un scénario puis avancez avec les flèches : le schéma met en lumière les éléments traversés à chaque étape.

DNS public pfSense VM Ubuntu réseaux Docker reverse proxy serveur MCP / pilotage

Vue d'ensemble

Astuce : flèches ← → du clavier. Sur mobile, le schéma défile horizontalement.

1Le DNS limpida.com

La zone limpida.com est hébergée chez GoDaddy (serveurs de noms ns25 et ns26.domaincontrol.com). C'est le premier maillon : il transforme un nom en l'unique IP publique de la Dedibox.

Ce que voit Internet

Un enregistrement générique *.apps.limpida.com → 212.129.32.80 couvre toutes les apps : paul, 11, billard… et même un nom qui n'existe pas encore. C'est pour cela que create_app n'a jamais besoin de toucher au DNS : il suffit qu'un vhost Nginx reconnaisse le nom.

mcp.limpida.com pointe lui aussi vers 212.129.32.80. Le domaine nu limpida.com pointe ailleurs (198.202.211.1) : il n'est pas servi par la Dedibox.

Ce que voit le LAN : le « split-horizon »

Une machine du LAN qui viserait l'IP publique devrait sortir par le WAN puis revenir par la NAT (« NAT reflection »), ce que les pare-feu gèrent mal. Le Host Override de pfSense court-circuite ce détour pour mcp.limpida.com.

2La Dedibox et la VM pfSense

Le serveur dédié héberge deux machines virtuelles reliées par un commutateur virtuel privé. pfSense est la seule à porter l'IP publique : c'est le portier de toute la plateforme.

Côté WAN : 212.129.32.80

Tout le trafic entrant arrive sur l'interface WAN de pfSense. Deux règles de redirection de ports le transmettent à la VM Ubuntu :

TCP 443 → 192.168.189.3:443 — le trafic HTTPS des apps et du serveur MCP ;
TCP 80 → 192.168.189.3:80 — indispensable aux défis Let's Encrypt et à la redirection vers HTTPS.

La VM Ubuntu n'a aucune IP publique : sans ces règles, elle serait invisible d'Internet.

Côté LAN : 192.168.189.0/25

pfSense est la passerelle (192.168.189.1), le serveur DHCP et le résolveur DNS du réseau privé. Le masque /25 offre 126 adresses (.1 à .126).

Dans l'autre sens, le NAT sortant de pfSense permet à la VM Ubuntu de joindre Internet : GitHub pour pousser le code des apps, les registres Docker, les mises à jour, et Let's Encrypt pour demander les certificats.

3La VM Ubuntu « limpida-apps »

Ubuntu 22.04.5 LTS, une seule interface réseau, et Docker qui fait tout le reste.

Paramètre	Valeur	Rôle
Interface	ens160 · 192.168.189.3/25	Adresse attribuée par le DHCP de pfSense
Route par défaut	via 192.168.189.1	Toute sortie passe par pfSense
Résolution DNS	127.0.0.53	systemd-resolved, qui interroge pfSense
Ports publiés	80, 443	→ conteneur `proxy` (sur toutes les interfaces)
	9000, 9443	→ `portainer`, console web Docker
	192.168.189.3:55432 / 55433	→ bases Postgres de soustraitant v3 / v4, joignables depuis le LAN uniquement

4Les conteneurs Docker et leurs réseaux

Docker crée des réseaux virtuels internes à la VM (172.16.0.0/12, jamais visibles du LAN). Chaque réseau est un pont Linux avec son propre DNS interne (127.0.0.11) qui résout les noms de conteneurs.

proxy-net le réseau commun

Réseau externe partagé par le proxy, le serveur MCP et chaque conteneur d'app. Chaque docker-compose.yml d'app s'y rattache :

networks:
  proxy-net:
    external: true
services:
  app:
    container_name: paul-app
    image: nginx:alpine
    networks: [proxy-net]   # pas de "ports:" !

Aucune app ne publie de port : le proxy les joint par leur nom (paul-app, billard-app…).

Les autres réseaux

sandbox-core_default 172.19.0.0/16 : héberge certbot, qui partage avec le proxy les volumes des certificats et du webroot ACME.
sebreno_internal 172.21.0.0/16 et aumonerie_internal 172.20.0.0/16 : l'app est sur deux réseaux (proxy-net + son réseau interne), sa base Postgres uniquement sur l'interne. Le proxy et les autres apps ne peuvent pas l'atteindre.
bridge 172.17.0.0/16 : réseau par défaut de Docker, inutilisé par la plateforme.

sandbox-mcp pilote tout ce petit monde via le socket /var/run/docker.sock monté dans son conteneur, ainsi que le dossier /opt/sandbox (apps, vhosts, certificats, registre apps.json).

5Le reverse proxy en tête

Un seul conteneur Nginx (proxy, nginx:1.27-alpine) reçoit 100 % du trafic web et le répartit selon le nom demandé. Voici le vhost réel de cette app, /opt/sandbox/proxy/conf.d/paul.conf :

server {
    listen 80;
    server_name paul.apps.limpida.com 11.apps.limpida.com;   ①
    location /.well-known/acme-challenge/ {
        root /var/www/certbot;                           ②
    }
    location / { return 301 https://$host$request_uri; }
}

server {
    listen 443 ssl;  http2 on;
    server_name paul.apps.limpida.com 11.apps.limpida.com;
    ssl_certificate /etc/letsencrypt/live/paul/fullchain.pem; ③
    ssl_certificate_key /etc/letsencrypt/live/paul/privkey.pem;
    add_header Strict-Transport-Security "max-age=31536000…";

    location / {
        proxy_pass http://paul-app:80;                     ④
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Upgrade $http_upgrade;     # WebSocket
    }
}

1Routage par nom. Toutes les apps partagent la même IP et le même port 443 ; Nginx choisit le bon bloc grâce au nom envoyé par le navigateur (SNI en TLS, en-tête Host ensuite). Le nom canonique et l'alias numérique figurent ensemble.
2Défi Let's Encrypt. Sur le port 80, seul le chemin ACME est servi, depuis le dossier partagé avec certbot ; tout le reste est redirigé en HTTPS.
3Terminaison TLS. Le chiffrement s'arrête au proxy. Un certificat par app (ici valable jusqu'au 25 janvier 2027), renouvelé par certbot.
4Relais interne. La requête continue en HTTP clair sur proxy-net vers le conteneur, avec les en-têtes X-Forwarded-* pour que l'app connaisse l'IP et le protocole d'origine.

Le cas particulier du serveur MCP

Le vhost mcp.limpida.com relaie vers http://sandbox-mcp:8080 avec proxy_buffering off et des délais de 3600 s : le protocole MCP renvoie ses réponses en flux et une opération (build, certificat) peut durer.

Plan d'adressage

Relevé effectué le 27 octobre 2026.

Élément	Adresse	Rôle
Dedibox · WAN pfSense	212.129.32.80	IP publique, cible de `*.apps` et `mcp`
pfSense · LAN	192.168.189.1/25	Passerelle, DNS (Unbound), DHCP
VM Ubuntu limpida-apps	192.168.189.3/25	Hôte Docker
Réseau proxy-net	172.18.0.0/16	Proxy ↔ apps ↔ serveur MCP
Réseau sandbox-core_default	172.19.0.0/16	certbot
Réseau aumonerie_internal	172.20.0.0/16	App ↔ base, isolé
Réseau sebreno_internal	172.21.0.0/16	App ↔ base, isolé
proxy	172.18.0.3	Nginx, ports hôte 80 / 443
sandbox-mcp	172.18.0.4:8080	Serveur MCP sandbox-ops
portainer	172.18.0.2	Console Docker, ports hôte 9000 / 9443
certbot	172.19.0.2	Certificats Let's Encrypt
paul-app (cette page)	172.18.0.38:80	paul.apps.limpida.com · 11.apps.limpida.com

Points d'attention relevés

Constats faits en explorant la plateforme pour construire cette page.

*.apps.limpida.com ne résout pas depuis le LAN

Interrogé via pfSense, paul.apps.limpida.com renvoie NXDOMAIN alors qu'il résout publiquement : le résolveur ne relaie visiblement pas les noms de limpida.com qu'il ne connaît pas. Piste : dans Unbound (options avancées), une zone local-zone: "apps.limpida.com." redirect + local-data: "apps.limpida.com. A 192.168.189.3" couvrirait toutes les apps d'un coup.

Portainer publié sur toutes les interfaces

Les ports 9000 / 9443 sont ouverts sur la VM pour tout le LAN. À vérifier côté pfSense qu'aucune redirection ne les expose sur Internet, ou les restreindre à 127.0.0.1.

Bases Postgres partagées sur proxy-net

Les apps plus anciennes (gaspard, finance, compterendu, ficheespace…) ont leur base sur proxy-net, donc joignable par le proxy et les autres apps. Le modèle « réseau interne par app » de sebreno et aumonerie est plus sûr ; les bases soustraitant v3/v4 sont en outre publiées sur le LAN (55432 / 55433).

Un peu de ménage possible

Deux conteneurs arrêtés sans nom explicite (cool_pare, inspiring_northcutt) et l'ancien vhost sbcmi1.limpida.com subsistent.