Test-Webserver fuer Verbindungstests hinzufuegen (systemd-Service, .ini-Sektion, README)

README.md

@@ -17,8 +17,10 @@ und droppt Pakete bereits auf Netzwerk-Ebene.
 | `aria_geoblock.ini` | Konfiguration (Laenderliste, Chain, Logging, ...) |
 | `aria-geoblock.service` | systemd-Unit, fuehrt `--apply` aus |
 | `aria-geoblock.timer` | systemd-Timer: beim Booten + einmal taeglich |
-| `install_aria_geoblock.sh` | Installer: kopiert alles nach `/opt/aria-geoblock`, richtet Timer ein |
+| `install_aria_geoblock.sh` | Installer: kopiert alles nach `/opt/aria-geoblock`, richtet Timer + Testserver ein |
 | `aria_geoblock_checkmk` | checkmk local-check Plugin (manuell kopieren) |
+| `aria_geoblock_testserver.py` | Kleiner Test-Webserver, um die Regeln von aussen zu pruefen |
+| `aria-geoblock-testserver.service` | systemd-Unit, startet den Test-Webserver dauerhaft |
 
 ## Installation
 
@@ -35,6 +37,8 @@ Das:
   (bestehende `.ini` wird NICHT ueberschrieben, neue landet als `.example`)
 - legt `/var/log/aria_geoblock/` an
 - installiert + aktiviert `aria-geoblock.timer` (`systemctl enable --now`)
+- installiert + startet `aria-geoblock-testserver.service` (Test-Webserver,
+  siehe Abschnitt "Verbindungstest" unten)
 
 Danach `/opt/aria-geoblock/aria_geoblock.ini` anpassen (Laenderliste!) und
 einmal manuell testen:
@@ -67,6 +71,53 @@ zusaetzlich braucht: `iptables-persistent` / `netfilter-persistent save`
 nutzen — der systemd-Timer sorgt aber ohnehin bei jedem Boot fuer einen
 frischen `--apply`-Lauf, das reicht in der Praxis meist aus.
 
+## Verbindungstest (Test-Webserver)
+
+`aria_geoblock_testserver.py` ist ein winziger HTTP-Server ohne
+Abhaengigkeiten (nur Python-Stdlib). Er beantwortet jeden Request mit einer
+kleinen Info-Seite (Client-IP, Zeitstempel, User-Agent) und loggt jeden
+Request. Er weiss selbst NICHTS von Laendern/Blocklisten — der eigentliche
+Test ist der Netzwerkeffekt: **geblockte** IPs erreichen ihn gar nicht erst
+(iptables droppt vor dem TCP-Handshake), **erlaubte** IPs bekommen die Seite.
+
+Laeuft nach `install_aria_geoblock.sh` automatisch als
+`aria-geoblock-testserver.service` auf Port `8899` (einstellbar unter
+`[testserver]` in `aria_geoblock.ini`, siehe unten).
+
+**Testablauf:**
+
+```bash
+# 1) Von einem ERLAUBTEN Netz/Land aus aufrufen -> sollte laden
+curl http://<host>:8899/
+
+# 2) Testweise den eigenen Laendercode (z.B. DE) in aria_geoblock.ini
+#    eintragen und aktivieren:
+sudo python3 aria_geoblock.py --config aria_geoblock.ini --apply
+
+# 3) Jetzt von einem Client MIT einer IP aus diesem Land connecten
+#    (z.B. Handy im Mobilfunknetz) -> sollte jetzt TIMEOUT geben
+curl --max-time 5 http://<host>:8899/
+
+# 4) Land wieder aus der .ini entfernen + --apply -> Zugriff geht wieder
+```
+
+Manuell ohne systemd starten:
+
+```bash
+python3 aria_geoblock_testserver.py --config aria_geoblock.ini
+# oder komplett ohne .ini:
+python3 aria_geoblock_testserver.py --port 8899 --bind 0.0.0.0 \
+    --log-file /var/log/aria_geoblock/testserver.log
+```
+
+Requests landen (Zeit, Client-IP, Methode/Pfad, User-Agent) in der unter
+`log_file` im `[testserver]`-Abschnitt konfigurierten Datei.
+
+**Achtung Firewall/Portfreigabe:** der Testserver selbst oeffnet nur den
+Port lokal — ob er von aussen erreichbar ist, haengt von eurer sonstigen
+Firewall/Portweiterleitung ab (das ist bewusst getrennt von den
+Geoblock-DROP-Regeln, die ja genau diesen Port betreffen sollen).
+
 ## Logging
 
 In `aria_geoblock.ini` unter `log_file` einen Pfad eintragen (Default:
@@ -105,3 +156,9 @@ Siehe Kommentare in der Datei selbst — kurz:
 - `log`: iptables-LOG-Eintrag vor dem DROP (dmesg/kern.log) an/aus
 - `ipset_name`: Name des ipset-Sets
 - `log_file`: Pfad zur script-eigenen Log-Datei (fuer checkmk)
+
+Abschnitt `[testserver]` (fuer `aria_geoblock_testserver.py`):
+
+- `port`: TCP-Port des Test-Webservers (Default `8899`)
+- `bind`: Bind-Adresse (`0.0.0.0` = alle IPv4-Interfaces)
+- `log_file`: Pfad zur Request-Log-Datei des Testservers