From 1ed113a866f51d09ad12dd3cb8bb406c55ec260e Mon Sep 17 00:00:00 2001 From: ARIA Date: Tue, 21 Jul 2026 12:34:19 +0000 Subject: [PATCH] README: Abschnitt zu ALB vs. NLB (AWS Load Balancer) ergaenzen --- README.md | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) diff --git a/README.md b/README.md index 0863436..14da6cb 100644 --- a/README.md +++ b/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.**