README: Abschnitt zu ALB vs. NLB (AWS Load Balancer) ergaenzen

README.md

@@ -314,6 +314,46 @@ zu Proxy-Ketten/CDN reinzumischen) ist Variante 1 — Testmaschine direkt mit
 eigener oeffentlicher IP, Geoblocking direkt auf dieser Maschine — der
 einfachste und eindeutigste Weg.
 
+## Betrieb hinter einem AWS Load Balancer (ALB vs. NLB)
+
+Gleiches Grundproblem wie beim Reverse-Proxy-Abschnitt oben, nur mit
+AWS-spezifischer Antwort — **ob die echte Client-IP am Server ankommt, haengt
+vom Load-Balancer-Typ ab:**
+
+- **Application Load Balancer (ALB):** Arbeitet auf **Layer 7 (HTTP)**. Der
+  ALB terminiert die TCP-Verbindung vom Client komplett und baut eine
+  **neue** TCP-Verbindung zum Backend auf — mit der **IP des ALB-Nodes**
+  (private VPC-IP) als Absender, nicht der des Clients. Die echte Client-IP
+  steckt nur noch im HTTP-Header `X-Forwarded-For`. iptables/ipset sehen aber
+  ausschliesslich die TCP-Ebene, also die ALB-Node-IP — **Geoblocking auf dem
+  Backend bringt hinter einem ALB nichts**, es wuerde effektiv die eigene
+  AWS-Infrastruktur "blocken" bzw. gar nichts filtern. Optionen in diesem
+  Fall: AWS WAF mit Geo-Match-Regel direkt am ALB (die vorgesehene
+  AWS-Loesung dafuer), oder auf NLB wechseln, falls auf L7-Features wie
+  Pfad-Routing verzichtet werden kann.
+- **Network Load Balancer (NLB):** Arbeitet auf **Layer 4**, terminiert die
+  TCP-Verbindung NICHT, sondern leitet sie durch. Die Quell-IP im TCP/IP-Paket,
+  das am Server ankommt, ist die **echte Client-IP** — genau das, was
+  iptables/ipset zur Filterung brauchen. `geoblock.py` funktioniert hinter
+  einem NLB in der Standard-Konfiguration also **wie auf einem Server ohne
+  Load Balancer davor**.
+  - **Standardfall (funktioniert direkt):** Targets liegen im selben VPC und
+    sind als **Instance-Target** registriert — die echte Client-IP kommt
+    transparent im TCP-Paket an, nichts weiter zu konfigurieren.
+  - **Vorbehalt:** Bei **IP-Targets** oder wenn der NLB ueber
+    **PrivateLink**/Cross-VPC/Cross-Account angesprochen wird, bewahrt AWS
+    die Client-IP nur, wenn am NLB **Proxy Protocol v2** aktiviert ist. Ist
+    das der Fall, kommt die IP nicht mehr "nackt" im TCP-Paket an, sondern
+    als PROXY-Header vor dem eigentlichen Payload — iptables sieht dann
+    weiterhin nur die NLB-Node-IP, die echte IP muesste applikationsseitig
+    aus dem PROXY-Header ausgewertet werden, nicht von iptables. In diesem
+    Fall vorher pruefen, ob Proxy Protocol aktiv ist.
+
+**Kurz zusammengefasst:** ALB → Geoblocking auf dem Backend funktioniert
+nicht (WAF am ALB nutzen). NLB mit Instance-Targets im selben VPC (Standard)
+→ `geoblock.py` funktioniert unveraendert. NLB mit IP-Targets/PrivateLink →
+vorher pruefen, ob Proxy Protocol v2 aktiv ist.
+
 ## Proxy fuer den Zonefile-Abruf (`proxy` in `geoblock.ini`)
 
 **Wichtig — das ist ein ANDERES Thema als der Reverse-Proxy-Abschnitt oben.**