Problem: auf Hosts mit gemanagter Firewall (z.B. Endian-UTM) stand die DROP-Regel
am Ende der INPUT-Chain (-A) und wurde von einer ACCEPT-Regel davor abgefangen ->
Geoblocking griff nicht, obwohl Set/Config korrekt waren.
geoblock.py:
- DROP-Regel jetzt wie die LOG-Regel per 'iptables -I' an den ANFANG der Chain
(Reihenfolge LOG -> DROP). Rule-Setzen in set_iptables_rules() refaktoriert.
- Neue Aktion --reassert: leichtgewichtiger Watchdog, der die Regel-Position
prueft und die Regeln nur bei Bedarf wieder nach oben setzt -- OHNE Zonefiles
von ipdeny nachzuladen (nutzt bestehendes ipset). Kein Eingriff, wenn kein
ipset existiert (dann erst voller --apply noetig).
- geoblock_rules_on_top(): erkennt, ob die Regeln luueckenlos die ersten der
Chain sind. --status zeigt die Position jetzt mit an.
systemd:
- geoblock-reassert.service + .timer (alle 2 Min, opt-in via install_geoblock.sh
--with-watchdog). uninstall raeumt sie mit ab und stoppt sie vor --remove.
README: Abschnitt "Regeln bleiben nicht oben (gemanagte Firewall)" + tcpdump-
Diagnose (anonymisiert) + Fehlersuche-Abschnitt.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Neue Funktion purge_geoblock_rules() entfernt per 'iptables -S <chain>' ALLE
Regeln mit '--match-set <name> src' (LOG wie DROP), unabhaengig von
Proto/Port/Variante. Das Loeschkommando wird per shlex direkt aus der
-S-Ausgabe rekonstruiert, damit --log-prefix inkl. Leerzeichen exakt passt.
- --apply purged jetzt vor dem Neu-Setzen der Regeln, aber erst NACH dem
atomaren Befuellen des ipsets -> kein Traffic-Loch waehrend des
ipdeny-Downloads.
- --remove nutzt denselben Purge statt der bisherigen varianten-basierten
Loeschung -> keine verwaisten Regeln mehr, wenn sich ports/protocol
zwischen zwei Laeufen geaendert haben.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
duffyduckandClaude Opus 4.8
ARIA