feat(deploy): URL sans port et certificats Let's Encrypt sur la VM ENI

Les trois environnements passent sur enervision-g3.duckdns.org, rec. et
dev. : noms publics qui visent l'IP privée de la VM, donc résolus sans
/etc/hosts sur le réseau de l'école et injoignables ailleurs (ADR 0018).

- infra/front : nginx sur le réseau de l'hôte, seul exposé en 80 et 443.
  Aiguille par SNI vers la stack visée sans déchiffrer le TLS, et lui
  transmet l'IP du client en PROXY protocol.
- Proxy de stack : écouteur 4443 en PROXY protocol, real_ip_header ;
  sans lui, limit_req et get_client_ip() compteraient tous les postes
  comme un seul. PROXY_FRONT_PORT le publie sur 127.0.0.1.
- make tls-duckdns : Let's Encrypt par défi DNS-01 via l'API DuckDNS
  (acme.sh 3.1.6), rejouable, rejoué à chaque déploiement et chaque nuit.
- provision-host.sh fait foi pour l'adressage et les secrets : un .env
  existant garde ses secrets, reçoit ceux qui manquent (supervision) et
  voit hôte et ports réalignés. Planifie le renouvellement des certificats.
- deploy.yml : nouvelles URL, sonde prod sur 10443, front-up en prod.
- Terraform : variable domaine. CI : validation du frontal.

infra/proxy/README.md

@@ -76,8 +76,27 @@ Renouvellement, à passer en tâche planifiée sur la machine :
 17 3 * * * cd /srv/enervision && make tls-renew >> /var/log/enervision-tls.log 2>&1
 ```
 
-Pour un domaine sans port 80 entrant, le défi DNS-01 est l'alternative : elle demande un
-greffon certbot propre au fournisseur DNS et un jeton d'API, hors périmètre à ce jour.
+### Let's Encrypt par DNS-01, le mode de la VM
+
+La VM n'a qu'une IP privée : le défi HTTP-01 y est impossible. Ses trois noms sont chez DuckDNS,
+dont l'API pose l'enregistrement TXT du défi DNS-01, et acme.sh le fait sans rien ouvrir
+([ADR 0018](../../docs/adr/0018-noms-duckdns-certificats-dns01-et-frontal-sni.md)).
+
+```bash
+make tls-duckdns        # PUBLIC_HOST lu dans .env, jeton dans ../duckdns.token (600)
+```
+
+La cible est rejouable : acme.sh ne renouvelle qu'à trente jours de l'échéance, installe le
+résultat dans `tls/` et recharge le proxy s'il tourne. Son état vit dans `acme/`, ignoré par git.
+`deploy.yml` la rejoue avant chaque `make stack-up`, et `/etc/cron.d/enervision-tls` chaque nuit.
+
+## Écouteur PROXY protocol
+
+Sur la VM, le frontal `infra/front` relaie les connexions TLS sans les déchiffrer. Reçues sur
+443, elles porteraient son adresse, et `limit_req` comme `get_client_ip()` compteraient tous les
+postes comme un seul. Le port 4443 ne les accepte qu'avec l'en-tête PROXY protocol, d'où
+`real_ip_header proxy_protocol` tire l'IP du client ; seules les adresses des réseaux Docker ont
+le droit de l'annoncer, et le port n'est publié que sur `127.0.0.1` (`PROXY_FRONT_PORT`).
 
 ## Vérifier la configuration sans démarrer la stack
 

infra/proxy/conf.d/enervision.conf

@@ -7,6 +7,8 @@
 # variable et le résolveur interne de Docker : la résolution redevient dynamique.
 # Pourquoi : la redirection 80 vers 443 conserve `$host` plutôt qu'un nom canonique, faute de
 # quoi l'accès par IP cesserait de fonctionner sur la cible. Risque acté dans l'ADR 0007.
+# Piège : 4443 n'accepte que le PROXY protocol du frontal (infra/front, ADR 0018), qui y porte
+# l'IP du client. Seules les adresses des réseaux Docker ont le droit de l'annoncer.
 
 server {
     listen 80 default_server;
@@ -23,9 +25,14 @@ server {
 
 server {
     listen 443 ssl default_server;
+    listen 4443 ssl proxy_protocol default_server;
     http2 on;
     server_name _;
 
+    set_real_ip_from 172.16.0.0/12;
+    set_real_ip_from 192.168.0.0/16;
+    real_ip_header proxy_protocol;
+
     resolver 127.0.0.11 valid=10s ipv6=off;
 
     ssl_certificate     /etc/nginx/tls/fullchain.pem;