gilles/netui
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
netui/projet_web_ui_passerelle_reseau_synthese_complete.md

5.5 KiB
Raw Permalink Blame History

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

Reference in New Issue View Git Blame Copy Permalink