Bei Portweiterleitung/DNAT schreibt der Kernel den Zielport in PREROUTING um,
BEVOR der Filter laeuft -- eine Regel auf den oeffentlichen Port (z.B. 1194)
matcht dann nie, weil im Filter der interne Port (z.B. 6666/6667) ankommt.
Genau der Fall auf Endian-Appliances (public 1194 -> intern 6666-6667,
443 -> 30443).
Neue Option 'match_original_dport = true': matcht per 'conntrack --ctorigdstport'
den urspruenglichen Zielport (vor DNAT). Dann in 'ports' die OEFFENTLICHEN Ports
eintragen -- immun gegen den internen Remap.
- build_rule_variants: bei orig-dport eine Regel pro (proto, port), da conntrack
--ctorigdstport einwertig ist (kein multiport). _variant_port_args nutzt dann
conntrack statt multiport.
- load_config: match_original_dport (bool, default false).
- show_status zeigt den Match-Modus an.
- Doku: geoblock.ini.example + README-Abschnitt "Dienst hinter Portweiterleitung/DNAT".
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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>
- --with-watchdog analog zu --with-testserver im Installations-Abschnitt
dokumentiert (inkl. kombinierter Aufruf).
- Explizit klargestellt: Installer OHNE Optionen installiert weder Testserver
noch Watchdog, nur das eigentliche Geoblocking (geoblock.py + geoblock.timer).
- Endian in die Liste der gemanagten Firewalls aufgenommen.
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>