docs(espace-client): déploiement VPS (navier-espace-web host-network) + bridge /api->pont via tunnel

- conteneur nginx host-network :8085, statique + proxy /api -> pont
- point réseau: host-network requis (SNAT bridge->tunnel non appliqué, à valider)
- reste: DNS espace. + NPM/SSL ; câblage données réelles (front encore prototype)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
steve 2026-07-13 15:39:20 +02:00
parent 63716ca635
commit 196bed0bd1
1 changed files with 40 additions and 2 deletions

View File

@ -152,6 +152,44 @@ Conforme au schéma **officiel** (wiki Extrafields / Table llx_extrafields) —
### Chaîne complète prouvée
`Mac (ssh -J) → VPS → tunnel IKEv2 → NAS pont :8080 (/interventions fichinter) → Dolibarr 19 réel`.
Le pont **n'est pas exposé publiquement** : l'espace client (VPS) le relaiera en interne via le tunnel.
Le pont **n'est pas exposé publiquement** : l'espace client (VPS) le relaie en interne via le tunnel.
RESTE : espace client sur le VPS (proxy interne `/api``192.168.10.104:8080`, PAS d'`api.` public).
---
## ✅ RÉALISÉ (2026-07-13) — Espace client déployé sur le VPS + pont `/api` (host-network)
**Conteneur `navier-espace-web`** (nginx:alpine) sur le VPS, sert le front statique de l'espace
client (`/home/deploy/navier-espace-web`, rsync depuis `~/esp/navier-espace-client`) sur **:8085**
et **relaie `/api/` → le pont** `http://192.168.10.104:8080/` (conf `/home/deploy/espace.nginx.conf`).
### ⚠️ Point réseau clé : atteindre le pont (tunnel IKEv2) depuis un conteneur
La politique IPsec ne capture QUE le trafic sourcé de l'IP VPN du VPS `192.168.2.1`
(`ip xfrm policy` : `src 192.168.2.1/32 dst 192.168.10.0/24`). Un conteneur **bridge** est SNAT
vers l'IP hôte → **hors tunnel → `curl pont` = 000**. Deux solutions :
- **RETENUE (sans firewall)** : lancer le conteneur en **`--network host`** → il source depuis
l'hôte (`192.168.2.1`) → le tunnel le transporte. C'est pourquoi `navier-espace-web` tourne en
`--network host` (écoute :8085, proxy_pass direct vers le pont). Prouvé : `/api/healthz` → 200.
- **Alternative (si un conteneur *bridge* doit joindre le pont, ex. NPM en direct)** : règle SNAT
`iptables -t nat -A POSTROUTING -s 172.16.0.0/12 -d 192.168.10.0/24 -j SNAT --to-source 192.168.2.1`
(+ persistance). **Non appliquée** (changement firmware du VPS partagé = à valider hors auto-mode).
### Commandes
```bash
# déploiement statique
rsync -az --delete ~/esp/navier-espace-client/ navier-vps:/home/deploy/navier-espace-web/
# conteneur (host-network pour joindre le pont via le tunnel)
sudo docker run -d --name navier-espace-web --restart unless-stopped --network host \
-v /home/deploy/espace.nginx.conf:/etc/nginx/conf.d/default.conf:ro \
-v /home/deploy/navier-espace-web:/usr/share/nginx/html:ro nginx:alpine
# vérif
curl http://127.0.0.1:8085/ # 200 (statique)
curl http://127.0.0.1:8085/api/healthz # 200 (pont via tunnel)
```
### RESTE (2 actions distinctes)
1. **URL publique de revue** : `:8085` est fermé au public (seul NPM 80/443 est ouvert). Pour une
URL SSL → **ajouter DNS `espace.navier-instruments.com A → 78.138.45.8` (LWS)**, puis NPM proxy
host `espace.…``78.138.45.8:8085` + Let's Encrypt (même schéma que `staging.` = `set $server 78.138.45.8`).
2. **Câblage données réelles** : le front est encore un **prototype** (login factice + `var DATA` en
dur). À implémenter : login → JWT ThingsBoard (le pont le valide), puis lecture parc/SAV/factures
via le pont (`/interventions` fichinter). ⚠️ Le pont est scopé SAV-atelier (RBAC techniciens/superviseurs) :
vérifier/ajouter les routes de lecture **client** avant de câbler (ne pas deviner l'API).