5.5 KiB
5.5 KiB
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 :
- Réseau WAN/LAN
- Pare-feu + NAT
- DHCPv4 (Kea)
- DNS (Unbound)
- Services
- Journaux
- 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