README: Reverse-Proxy/nginx-Betrieb und Client-IP-Sichtbarkeit erklaert

This commit is contained in:
ARIA
2026-07-21 13:23:44 +02:00
parent 9c635c49e3
commit a608af9a27
+44
View File
@@ -162,3 +162,47 @@ 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
## Betrieb hinter einem Reverse-Proxy (z.B. nginx)
Wichtig zu verstehen, weil es leicht zu falschen Testergebnissen fuehrt:
**Geoblocking mit iptables/ipset arbeitet auf Netzwerk-Ebene (TCP), nicht auf
HTTP-Ebene.** Es sieht immer nur die IP, die die TCP-Verbindung tatsaechlich
zum jeweiligen Host aufbaut — unabhaengig davon, was in HTTP-Headern steht.
**Wo die echte Client-IP ankommt, haengt vom Aufbau ab:**
- **nginx ist der einzige "Proxy" (direkt am Internet, kein CDN/WAF davor):**
Die TCP-Verbindung vom Client landet direkt am nginx-Host. Dort sieht sowohl
iptables als auch nginx selbst die echte oeffentliche Client-IP. In diesem
Setup **muessen die Geoblock-Regeln auf dem nginx-Host greifen**, und zwar
auf dem Port, auf dem nginx nach aussen lauscht (z.B. 80/443) — NICHT auf
dem internen Port des dahinterliegenden Testservers/Backends.
- **Davor haengt zusaetzlich ein CDN/WAF (Cloudflare, Fastly, ...):** Dann
kommt am nginx-Host nur noch die IP des CDN-Rechenzentrums an, nicht die
echte Client-IP. iptables auf dem nginx-Host wuerde dann effektiv das CDN
blocken, nicht den Endnutzer — Geoblocking muesste in diesem Fall beim CDN
selbst konfiguriert werden (die meisten bieten das nativ an).
- **Der Testserver haengt NUR intern hinter nginx** (z.B. `proxy_pass` auf
`127.0.0.1:8899`): Der Testserver selbst sieht dann nur die IP von nginx
(`127.0.0.1`), nicht die des echten Clients — die Verbindung des Clients
wurde ja schon vorher bei nginx "verbraucht" und neu aufgebaut. Ein
iptables-DROP auf Port 8899 wuerde in diesem Aufbau **gar nichts bewirken**,
weil der Traffic zum Testserver nie ueber das oeffentliche Netz laeuft,
sondern nur lokal von nginx zum Backend.
**Praktische Konsequenz fuer den Verbindungstest:**
Um den Testserver (`aria_geoblock_testserver.py`, siehe oben) sinnvoll von
aussen zu testen, muss er entweder:
1. selbst direkt mit einer oeffentlichen IP/Port erreichbar sein (kein Proxy
dazwischen) — z.B. indem die Testmaschine testweise eine eigene
oeffentliche IP bekommt, oder
2. hinter nginx haengen, wobei dann **nginx** (nicht der Testserver) der
Punkt ist, an dem die Geoblock-Regeln greifen muessen.
Fuer einen sauberen End-to-End-Test der iptables-Regeln selbst (ohne Fragen
zu Proxy-Ketten/CDN reinzumischen) ist Variante 1 — Testmaschine direkt mit
eigener oeffentlicher IP, Geoblocking direkt auf dieser Maschine — der
einfachste und eindeutigste Weg.