# PROJET WEBUI PASSERELLE RÉSEAU – SYNTHÈSE COMPLÈTE

Ce document reprend **l’intégralité de la discussion**, structurée et consolidée, sur la conception et le développement d’une **WebUI d’administration réseau** destinée à une **VM Debian 13 (Trixie)** jouant le rôle de **passerelle LAN → Internet**.

---

## 1. OBJECTIF GÉNÉRAL

Créer une **application Web d’administration réseau**, installée dans une **machine virtuelle Debian 13**, permettant de configurer et superviser :

- le réseau local (LAN)
- l’accès Internet (WAN)
- l’attribution d’adresses IP (DHCP)
- la résolution de noms (DNS)
- le pare-feu et le partage de connexion (NAT)
- les services réseau associés

Contraintes clés :
- uniquement **outils réseau standards Debian 13** (aucun dépôt tiers)
- **WebUI simple et pédagogique**, adaptée à des utilisateurs novices
- libellés clairs, textes explicatifs, info-bulles, **pas d’acronymes non expliqués**
- accès WebUI limité au **réseau local**
- architecture modulaire (services activables/installables)

---

## 2. ARCHITECTURE GÉNÉRALE

### 2.1 Schéma fonctionnel

Navigateur → HTTPS → Nginx → API backend (non root) → scripts contrôlés → services système Debian

### 2.2 Composants

- **Frontend** : HTML/CSS/JavaScript léger (onglets + formulaires)
- **Serveur Web** : Nginx
- **Backend** : Python (API REST)
- **Services système** : configurés via fichiers standards Debian
- **Contrôle système** : systemctl, journalctl, nftables, kea, unbound

### 2.3 Sécurité

- WebUI accessible uniquement depuis le LAN
- utilisateur système dédié pour l’application
- droits permissifs en phase V1 (sudo large), durcissement ultérieur
- aucune modification appliquée sans validation explicite

---

## 3. MACHINE VIRTUELLE (PROXMOX)

### 3.1 Paramétrage recommandé

- Type : VM Linux
- Machine : q35
- BIOS : OVMF (UEFI)
- CPU : 1 socket / 2 à 4 cœurs / type host
- RAM : 4 Go (ballooning désactivé)
- Disque : 32 Go, VirtIO SCSI, iothread activé
- Réseau :
  - 2 cartes VirtIO
  - 1 WAN (Internet)
  - 1 LAN (réseau local)
- Pare-feu Proxmox : désactivé
- Watchdog : activé

### 3.2 Rôle de la VM

- passerelle LAN → Internet
- serveur DHCP principal
- serveur DNS local
- point central d’observation du trafic

---

## 4. SERVICES UTILISÉS (STANDARD DEBIAN 13)

### 4.1 Services cœur (V1)

- Gestion réseau : systemd-networkd
- Pare-feu / NAT : nftables
- DHCPv4 : kea-dhcp4-server
- DNS local : unbound
- Logs : systemd-journald
- Connexions réseau : conntrack

### 4.2 Services optionnels (V2/V3)

- Découverte réseau : avahi-daemon (LAN uniquement)
- VPN : wireguard
- QoS : tc
- IDS/IPS : suricata (non V1)

---

## 5. WEBUI – ORGANISATION DES PAGES (V1)

### 5.1 Tableau de bord

- état WAN / LAN
- état des services
- alertes simples

### 5.2 Réseau

- côté Internet : adresse automatique ou fixe
- côté réseau local : adresse de la passerelle, domaine

### 5.3 Pare-feu et partage de connexion

- interrupteurs simples
- règles prédéfinies compréhensibles

### 5.4 Attribution d’adresses (DHCP)

- plages dynamiques
- réservations fixes
- liste des appareils connectés

### 5.5 Noms (DNS)

- serveurs amont
- domaine local
- entrées fixes nom → adresse

### 5.6 Services

- installation via apt (liste blanche)
- démarrage / arrêt / activation au boot
- état en temps réel

### 5.7 Journaux

- lecture des logs par service
- filtres (date, texte, niveau)

### 5.8 Activité réseau

- connexions LAN → Internet
- requêtes DNS
- événements du pare-feu

---

## 6. MÉTHODOLOGIE DE TEST ET DÉPLOIEMENT

### 6.1 Phase 0 – Développement hors réseau

- DHCP désactivé
- pare-feu non bloquant
- génération et validation de configuration uniquement

### 6.2 Phase 1 – Intégration passive

- VM connectée au LAN
- observation uniquement (logs, trafic)

### 6.3 Phase 2 – Test DHCP contrôlé

- arrêt temporaire de l’ancien DHCP
- activation du nouveau
- tests sur un ou deux clients
- rollback immédiat possible

### 6.4 Phase 3 – Remplacement définitif

- bascule complète
- surveillance

---

## 7. MIGRATION DES ADRESSES IP EXISTANTES

### 7.1 Principe

- conserver les adresses IP actuelles
- éviter toute reconfiguration côté clients

### 7.2 Méthode retenue (recommandée)

**Import des baux DHCP existants** depuis l’ancien serveur

### 7.3 Sources supportées

- OPNsense :
  - CSV (baux DHCP)
  - XML (config complète)
- Fichier JSON générique

### 7.4 Format JSON canonique interne

{
  "source": "opnsense",
  "interface": "lan",
  "reservations": [
    {
      "nom": "nas",
      "adresse_ip": "10.0.0.10",
      "adresse_materielle": "AA:BB:CC:DD:EE:01"
    }
  ]
}

Tous les imports sont normalisés vers ce format.

### 7.5 Processus WebUI

- import fichier
- analyse et validation
- prévisualisation
- génération réservations DHCP
- aucune application automatique

---

## 8. PHILOSOPHIE DU PROJET

- sécurité avant automatisation
- aucune action irréversible sans confirmation
- priorité à la lisibilité et à la pédagogie
- architecture modulaire
- pas de dépendance externe

---

## 9. PÉRIMÈTRE V1 VALIDÉ

Modules inclus :
1. Réseau WAN/LAN
2. Pare-feu + NAT
3. DHCPv4 (Kea)
4. DNS (Unbound)
5. Services
6. Journaux
7. Activité réseau

---

## 10. ÉTAPES SUIVANTES POSSIBLES

- création du canevas de projet (arborescence + fichiers)
- écrans WebUI détaillés
- moteur d’import OPNsense (CSV/XML → JSON)
- génération automatique des configurations Kea / Unbound / nftables

---

FIN DU DOCUMENT