Auf der Test-VM liess sich der Dienst mit einer gespeicherten Range
(192.168.81.203-212) starten, obwohl das erkannte Netz des Interfaces
192.168.80.0/24 war -- die Range gehoerte also zu einem komplett anderen
Subnetz. _dhcp_config_is_complete() prophfte bisher nur, ob Range Start/
Ende ueberhaupt ausgefuellt waren, nie ob sie zum echten Netz passen.
Neue Funktion _dhcp_matching_network(interface, start, end) validiert die
Range jetzt an drei Stellen: beim Speichern (save_dhcp_config), beim
Schreiben der Kea-Datei (write_dhcp_file) und beim Starten des Dienstes
(dhcp_service_action=enable_restart) -- jede der drei Aktionen wird mit
einer genauen Fehlermeldung abgelehnt, statt eine zum Netz nicht passende
Range durchzulassen.
Die Pruefung beruecksichtigt dabei ALLE IPv4-Adressen des Interfaces, nicht
nur die erste -- ein Interface kann mehrere IPs/Subnetze gleichzeitig
tragen (Alias-IPs). Dafuer wurde _detect_interface_network() in eine neue
_detect_interface_networks() (Mehrzahl, alle Adressen) plus einen duennen
Wrapper fuer die primaere/erste Adresse aufgeteilt -- alle bisherigen
Aufrufer (Anzeige auf der DHCP-Seite, Host-Netzwerkeinstellungen) bleiben
unveraendert auf der primaeren Adresse.
Echte Mehrfach-Ranges gleichzeitig (mehrere Subnetze parallel, z.B. auf
verschiedenen Interfaces) sind bewusst nicht Teil dieses Fixes -- laut
Ruecksprache ein separater, groesserer Umbau (DB-Tabelle statt globaler
Range, mehrere subnet4-Bloecke in der Kea-Config, Listen-UI) und als
naechster Schritt vorgesehen.
Live auf der Test-VM verifiziert: falsche Range wird beim Speichern,
Schreiben und Starten korrekt abgelehnt, eine zum erkannten Netz passende
Range weiterhin akzeptiert -- keine Fehler im journalctl-Log.
alientim
9660258940