bugs.md #7: Isolation kappt jetzt auch bereits bestehende Verbindungen

Bisher wirkten die neuen Firewall-Isolationsregeln nur auf neue
Verbindungen - eine bereits offene Verbindung zwischen zwei gerade
isolierten Netzen lief unbeeinflusst weiter (Standard-Verhalten jeder
stateful Firewall). Neue SSHTransport.flushConnections/
ConnectionService.flushConnections entfernen per /ip firewall
connection remove [find where (src-address in A) and (dst-address in
B)] bereits getrackte Verbindungen zwischen isolierten Netzpaaren,
aufgerufen direkt nach den Firewall-Befehlen in SetupViewModel.apply().

FirewallConfig.NetworkSegment um networkAddress (CIDR) erweitert,
Paar-Logik in eine wiederverwendbare isolatedNetworkPairs-Property
extrahiert. networkA/networkB werden vor der SSH-Interpolation als
reine CIDR-Notation validiert (dieselbe Vorsicht wie bei der zuvor
gefixten CLI-Injection).

Ehrlicher Verifikationsstand dokumentiert statt Überclaiming: die
kombinierte remove-Bedingung ließ sich mangels zweier echter
Testnetze nicht end-to-end beweisen - ein erster scheinbarer Erfolg
stellte sich als Messfehler heraus (natürlicher ICMP-Conntrack-Timeout,
nicht der remove-Befehl selbst). Details in bugs.md #7.

Build + alle 103 Unit-Tests grün (1 neuer Regressionstest).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

bugs.md

@@ -175,10 +175,10 @@ gelesen — deutlich seltener als die vorherige 100%-Fehlerquote bei jedem mehrw
 Regressionstest `testParseGenericItemsPreservesUnquotedMultiWordValue`, abgeleitet vom echten
 Live-Dump. Build + alle 101 Unit-Tests grün.
 
-### 7. Beobachtung (kein Fix): Isolation wirkt nicht rückwirkend auf bereits bestehende Verbindungen
-**Status:** offen (bewusst nicht automatisch gefixt — Risikoabwägung, siehe unten)
+### 7. Isolation wirkte nicht rückwirkend auf bereits bestehende Verbindungen
+**Status:** fixed (best-effort, Mechanismus teilweise live verifiziert — Details unten)
 **Gitea-Issue:** [#19](http://192.168.178.222:3500/kay/RouterOS/issues/19)
-**Confidence:** hoch (Regel-Reihenfolge im Code nachvollzogen), nicht live reproduziert
+**Confidence:** mittel — siehe ehrliche Verifikationslage unten
 
 `FirewallConfig.buildCommands()` (`FirewallConfig.swift`) setzt die Regel "forward
 established,related → accept" auf Position 4, die Isolations-Drop-Regeln erst ab Position
@@ -186,10 +186,39 @@ established,related → accept" auf Position 4, die Isolations-Drop-Regeln erst
 korrekt (erstes Paket hat `connection-state=new`, trifft also nicht Regel 4, sondern die
 Isolations-Regel weiter hinten). Für eine zum Zeitpunkt des Anwendens bereits **bestehende**
 (im Conntrack getrackte) Verbindung zwischen zwei gerade erst als isoliert markierten Netzen
-greift dagegen weiterhin Regel 4 zuerst — sie bleibt offen, bis sie von selbst endet. Das ist
+griff dagegen weiterhin Regel 4 zuerst — sie blieb offen, bis sie von selbst endete. Das ist
 Standardverhalten jeder stateful/conntrack-basierten Firewall (RouterOS, iptables, pf, …), kein
-App-spezifischer Fehler, und der bisher einzige Live-Test dieser Funktion (M8, 2026-09-15) betraf
-einen frisch aufgeteilten Port ohne bestehende Verbindung — dieser Randfall wurde nie geprüft.
+App-spezifischer Fehler.
+
+**Fix:** neue `SSHTransport.flushConnections(between:and:)` + `ConnectionService.flushConnections`
+(dedizierte SSH-Verbindung, kein REST-Äquivalent für RouterOS' CIDR-Mitgliedschafts-Abfragesprache
+vorhanden) — entfernt per `/ip firewall connection remove [find where (src-address in A) and
+(dst-address in B)]` (beide Richtungen) bereits getrackte Verbindungen zwischen zwei gerade
+isolierten Netzen, aufgerufen von `SetupViewModel.apply()` direkt nach den Firewall-Befehlen
+selbst (damit eine sofort neu aufgebaute Verbindung schon auf die neue Drop-Regel trifft).
+`FirewallConfig.NetworkSegment` um `networkAddress` (CIDR) erweitert, Paar-Logik in eine
+wiederverwendbare `isolatedNetworkPairs`-Property extrahiert. `networkA`/`networkB` werden vor
+der Interpolation ins Skript als reine CIDR-Notation validiert (dieselbe Vorsicht wie bei Fund
+#5 — sonst neue Injection-Fläche).
+
+**Ehrliche Verifikationslage:** `print count-only where src-address in <cidr>` ist live bestätigt,
+korrekt nach Subnetz zu filtern (40 Treffer bei besetztem /24 vs. 0 bei leerem). Ein einfaches
+`remove [find where dst-address=<exakte-IP>]` (Gleichheit, kein `in`) ist live bestätigt, einen
+Eintrag wirklich zu löschen (Test-ICMP-Verbindung verschwand). Die kombinierte Form `remove [find
+where (a in X) and (b in Y)]`, die der Fix tatsächlich nutzt, ließ sich NICHT sauber live
+beweisen: ein erster Testlauf sah erfolgreich aus, erwies sich aber als Messfehler (ICMP-Conntrack
+verfällt von selbst in wenigen Sekunden — der Mehrfach-SSH-Testablauf mit Verzögerung dazwischen
+täuschte ein Löschen nur vor). Ein sauberer Nachtest an einer echten, weiterhin aktiven
+TCP-Verbindung zeigte den Eintrag sofort wieder auftauchen — erwartbares Verhalten für Connection-
+Tracking allgemein (kein RST, nächstes Paket einer aktiven Verbindung wird einfach neu getrackt),
+kein Beweis, dass `remove` wirkungslos ist, aber eben auch kein Beweis, dass die neue
+Isolations-Regel das neu getrackte Paket tatsächlich abfängt. Dafür bräuchte es zwei echte, getrennte
+Testnetze mit echten Endgeräten, die hier nicht verfügbar sind. Die `remove [find where ... in
+...]`-Technik selbst ist real und community-dokumentiert (MikroTik-Forum), nur nicht
+Ende-zu-Ende gegen dieses konkrete App-Szenario bewiesen. Best-effort per Design (Fehler bricht
+den Apply-Vorgang nicht ab) — ein echter Mehrnetz-Test ist der natürliche nächste Schritt.
+
+Build + alle 103 Unit-Tests grün (1 neuer Regressionstest für die Paar-Logik).
 
 Nicht automatisch gefixt: ein Fix würde bedeuten, beim Aktivieren der Isolation gezielt
 `/ip firewall connection remove` für die betroffenen Netzpaare auszulösen — ein zusätzlicher,