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>
15 lines
759 B
Desktop File
15 lines
759 B
Desktop File
[Unit]
|
|
Description=Geoblocking Watchdog - Block-Regeln am Anfang der Chain halten (prueft/korrigiert Position, ohne ipdeny-Download)
|
|
Documentation=https://git.hacker-net.de/Aria-Software/geoblocking-python-script
|
|
ConditionPathExists=__INSTALL_DIR__/geoblock.ini
|
|
|
|
[Service]
|
|
Type=oneshot
|
|
User=root
|
|
# --reassert laedt KEINE Zonefiles (kein Netz noetig), nutzt das bestehende ipset
|
|
# und setzt die Regeln nur dann neu an den Anfang der Chain, wenn sie nach unten
|
|
# gerutscht sind oder fehlen -- z.B. weil eine gemanagte Firewall die Chain neu
|
|
# gebaut hat. Ist noch kein ipset vorhanden, tut es nichts (der geoblock.timer
|
|
# fuellt es beim naechsten --apply).
|
|
ExecStart=/usr/bin/python3 __INSTALL_DIR__/geoblock.py --config __INSTALL_DIR__/geoblock.ini --reassert
|