purge_geoblock_rules() scannt jetzt die konfigurierten Chains PLUS die Standard-
Filter-Chains INPUT/FORWARD/OUTPUT. Damit werden verwaiste geoblock-Regeln auch
dann entfernt, wenn 'chain' zwischen zwei Laeufen geaendert wurde (z.B. INPUT ->
FORWARD) -- vorher blieben die alten Regeln der nicht mehr konfigurierten Chain
stehen. Es werden nur Regeln geloescht, die auf das eigene ipset verweisen.
README: Abschnitt "Manuelle Nutzung" um die Aufraeum-Semantik ergaenzt (jeder
--apply/Service-Restart entfernt alle geoblock-Regeln und setzt sie frisch,
inkl. Reste aus geaenderter ports/protocol/chain-Config).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
'chain' akzeptiert jetzt eine komma-getrennte Liste. Noetig, wenn der geschuetzte
Dienst hinter einer Firewall/einem Router liegt (Portweiterleitung/DNAT): solcher
Traffic laeuft durch die FORWARD-Chain und wird von einer reinen INPUT-Regel nie
gesehen. "chain = INPUT, FORWARD" deckt beide Wege ab.
- load_config: cfg["chain"] -> cfg["chains"] (Liste), Default ["INPUT"].
- apply/purge/set_iptables_rules/reassert/status/Watchdog arbeiten ueber alle
konfigurierten Chains. geoblock_rules_on_top aggregiert (on_top nur, wenn in
JEDER Chain oben; present, wenn in mindestens einer vorhanden) -- neuer Helper
_chain_rules_position() prueft je Chain. --status zeigt Position pro Chain.
- Doku: geoblock.ini.example + README-Abschnitt "INPUT vs FORWARD" (inkl.
DNAT-Diagnose und Endian-Hinweis).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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