KayandClaude Sonnet 5
772549c991
Standardmäßig aus (Toggle wie VLAN) -- höchstes Risiko aller bisherigen Schritte, falsche Regeln können Fernzugriff kappen. Preset ist Mikrotiks eigener Standard-Ansatz (unverändert seit Jahren in RouterOS-Werkskonfigurationen): NAT/Masquerade auf WAN, established/ related erlauben, invalid verwerfen, unaufgeforderte WAN-Verbindungen zu LAN-Geräten blocken (außer explizitem Port-Forward via connection-nat-state=!dstnat). Jede neue Regel bekommt ein place-before mit aufsteigendem Index, damit sie vor eventuell schon vorhandenen Regeln des Routers landet -- sonst könnte eine bereits vorhandene "alles blocken"-Regel unsere neuen Regeln wirkungslos machen. NAT und Filter sind getrennte, unabhängig nummerierte RouterOS-Listen. Vor dem Anwenden zeigt der Schritt die Anzahl bereits vorhandener Filter-/NAT-Regeln (neuer fetchFirewallRuleCounts()-Aufruf in RouterOSTransport/RestTransport/SSHTransport/ConnectionService) -- Transparenz, bevor auf einem möglicherweise schon konfigurierten Router weitere Regeln landen. Nutzer-Entscheidung, extra Lese-Aufruf in Kauf zu nehmen statt nur Warntext. Build + Test-Compile (build-for-testing) sind grün. Der eigentliche Testlauf (xcodebuild test) hängt aktuell an einem macOS-Gatekeeper- Netzwerk-Check für ad-hoc-signierte Binaries (amfid: "adhoc signed or signed by an unknown certificate chain", GK performScan über syspolicyd) -- kein Code-Bug, tritt nur bei CLI-Testläufen auf, nicht beim normalen Xcode-Cmd+R-Weg. Nutzer verifiziert M6 deshalb direkt in Xcode. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HReLXMbmPvtQ23p1iWiJNW