Beim Zugriff auf Nginx über Cloudflare funktionieren IP-Beschränkungen mit allow/deny-Direktiven möglicherweise nicht wie erwartet. Dieser Artikel erklärt die Ursache und Lösung für Fälle, in denen Sie den Zugriff nur von bestimmten IPs erlauben möchten, aber alle Anfragen 403-Fehler erhalten.
Warum Allow nicht funktioniert
Wenn der Traffic über Cloudflare läuft, ist die von Nginx gesehene Quell-IP nicht die tatsächliche Client-IP, sondern die IP des Cloudflare-Reverse-Proxy-Servers.
# Diese Konfiguration funktioniert nicht richtig
allow 192.0.2.1; # Ihre IP
deny all;Die obige Konfiguration beabsichtigt “Zugriff nur von 192.0.2.1 erlauben”, aber die Quell-IP, die Nginx erreicht, ist tatsächlich Cloudflares IP (z.B. 104.16.x.x). Daher entsprechen alle Anfragen deny all und geben 403 Forbidden zurück.
Lösung: real_ip_header verwenden
Nginx hat eine Funktion, um die tatsächliche Client-IP anstelle der Reverse-Proxy-IP zu verwenden. Bei Cloudflare wird die tatsächliche Client-IP im CF-Connecting-IP-Header gespeichert.
# Cloudflare IP-Bereiche vertrauen
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 104.24.0.0/14;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 131.0.72.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
# IPv6 falls benötigt
set_real_ip_from 2400:cb00::/32;
set_real_ip_from 2606:4700::/32;
set_real_ip_from 2803:f800::/32;
set_real_ip_from 2405:b500::/32;
set_real_ip_from 2405:8100::/32;
set_real_ip_from 2a06:98c0::/29;
set_real_ip_from 2c0f:f248::/32;
# Tatsächliche IP aus Cloudflare-Header holen
real_ip_header CF-Connecting-IP;Damit enthält $remote_addr die tatsächliche Client-IP, und allow/deny funktioniert korrekt.
X-Forwarded-For (XFF) Fallstricke
Die Verwendung des X-Forwarded-For-Headers ist auch möglich, erfordert aber Vorsicht.
real_ip_header X-Forwarded-For;
real_ip_recursive on;XFF-Header sammeln mehrere IPs kommagetrennt an, wenn sie durch mehrere Proxys gehen. Außerdem können Clients diesen Header fälschen.
Das Setzen von real_ip_recursive on schließt vertrauenswürdige Proxy-IPs aus und verwendet die letzte nicht vertrauenswürdige IP, aber Fehlkonfiguration kann Sicherheitslücken schaffen.
Für Cloudflare ist die Verwendung von CF-Connecting-IP zuverlässiger.
Konfiguration überprüfen
Um zu überprüfen, ob die Konfiguration korrekt funktioniert, prüfen Sie, ob die tatsächliche IP in den Zugriffsprotokollen aufgezeichnet wird.
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent"';Wenn Ihre IP in $remote_addr erscheint, funktioniert die Konfiguration korrekt. Wenn Cloudflares IP erscheint, überprüfen Sie die set_real_ip_from-Konfiguration.
Cloudflare IP-Bereiche aktualisieren
Cloudflare IP-Bereiche ändern sich gelegentlich. Die neuesten IP-Bereiche finden Sie auf der offiziellen Seite (https://www.cloudflare.com/ips/).
Regelmäßiges Aktualisieren oder das Erstellen eines Automatisierungsskripts zur Aktualisierung der Nginx-Konfiguration gibt Sicherheit.
Zusammenfassung
Der Grund, warum Nginx allow/deny über Cloudflare nicht funktioniert, ist dass die Quell-IP zu Cloudflares IP wird. Durch die Konfiguration von set_real_ip_from und real_ip_header CF-Connecting-IP wird Zugriffskontrolle basierend auf der tatsächlichen Client-IP möglich.