Cloudflare RemoteIP / ClientIP an Host weiterleiten

[HayKer]

Hallo zusammen,

dieses Thema ist eigentlich super easy, ich zerbreche mir jetzt aber schon ewig den Kopf daran und finde keine Lösung.
Gefühlt bin ich schon wieder der einzige mit dem Problem.
Alle Anleitungen sagen mir genau das Gleiche. Genau dementsprechend habe ich meine Konfiguration durchgeführt.

Problem:
Ich baue gerade eine neue Infrastruktur fürs Hosting bei uns in der Firma.
Wir haben teilweise Kunden die Cloudflare nutzen und auch welche ohne.
Ziel ist es, die Original-IP des Clients über einen Reverse Proxy und einen Loadbalancer bis zum Webserver durchzuleiten.

Das funktioniert so weit auch, solange kein Cloudflare davor läuft.
Sobald Cloudflare aktiv ist, werden mir nur noch die Cloudflare IPs angezeigt.
Ironischerweise wird aber auch der CF-Connecting-IP und X-Forwarded-For Header korrekt mitgegeben.

Meiner Meinung nach ist die Konfiguration am Endpunkt korrekt, in der aktuellen Infrastruktur läuft es nämlich ohne Probleme.

Infrastruktur:

	Floating IP Address
/​		\
HAProxy​	<--->​	HAProxy
|​		|​
Router​	<--->​	Router
|​		|
Loadbalancer​	<--->​	Loadbalancer
|​		|
Webserver​	<--->​	Webserver

Nur für einen kleinen Überblick.
Das ganze funktioniert auch aktuell ganz gut.
Aber ich glaube, der Fehler liegt ausschließlich am Webserver, aufgrund dessen das mir die Header die ich brauche, bis zum Webserver durchgeleitet werden, könnte mich aber auch irren.

Ab dem HAProxy bis zum Webserver werden nur die TCP Pakete über das Proxy-Protokoll durchgejagt.

HAProxy: Debian 11 System mit HAProxy
Router: FreeBSD System mit PF Firewall
Loadbalancer: Debian 11 System mit Nginx (Da hier noch Nginx und nicht HAProxy läuft, hat einen Grund der Kompatibilität mit aktuellen Automatisierungen)

System Webserver: Debian 11 System
Software: Apache (ISPConfig Cluster Server)
Apache Mods: mod_remoteip

jedes einzelne System ist mit Corosync und Pacemaker in einem Failover Cluster demnach von jedem System jeweils zwei identische existieren.

Konfigurationen:
mod_remoteip Config:

RemoteIPHeader CF-Connecting-IP
RemoteIPTrustedProxy 103.21.244.0/22
RemoteIPTrustedProxy 103.22.200.0/22
RemoteIPTrustedProxy 103.31.4.0/22
RemoteIPTrustedProxy 104.16.0.0/13
RemoteIPTrustedProxy 104.24.0.0/14
RemoteIPTrustedProxy 108.162.192.0/18
RemoteIPTrustedProxy 131.0.72.0/22
RemoteIPTrustedProxy 141.101.64.0/18
RemoteIPTrustedProxy 162.158.0.0/15
RemoteIPTrustedProxy 172.64.0.0/13
RemoteIPTrustedProxy 173.245.48.0/20
RemoteIPTrustedProxy 188.114.96.0/20
RemoteIPTrustedProxy 190.93.240.0/20
RemoteIPTrustedProxy 197.234.240.0/22
RemoteIPTrustedProxy 198.41.128.0/17
RemoteIPTrustedProxy 2400:cb00::/32
RemoteIPTrustedProxy 2606:4700::/32
RemoteIPTrustedProxy 2803:f800::/32
RemoteIPTrustedProxy 2405:b500::/32
RemoteIPTrustedProxy 2405:8100::/32
RemoteIPTrustedProxy 2a06:98c0::/29
RemoteIPTrustedProxy 2c0f:f248::/32

Apache Log:
%h mit %a ersetzt

V-Host Apache:

<VirtualHost *:443>
...
RemoteIPProxyProtocol On
...
 </VirtualHost>

Mehr Konfigurationsaufwand sollte das ganze ja nicht haben, wie gesagt in der anderen Infrastruktur funktioniert es genau so auch.

Beispiele des Fehlers anhand der PHP-Info:
Korrekte Client IP = 62.*.*.*

Ohne Cloudflare:
https://test.mxp.dev/phpinfo.php

Hier existiert dann logischerweise kein CF-Connecting-IP und kein X-Forwarded-For Header

Mit Cloudflare:
https://test2.mxp.dev/phpinfo.php

So kann ich / Kunde aber weder mittels .htaccess eine IP Restriktion konfigurieren, noch in den Logs die IPs nachvollziehen.

Für jeden Denkanstoß wäre ich aktuell wirklich dankbar

 

[Zeroflow]

Ja, das ist leider so richtig.

Sollte aber configs bzw. module geben, welche das wiederherstellen können.
Die weitere Frage wäre aber eher an den Kunden, warum er unbedingt bei euch am Server per .htaccess eine Restriktion haben will und nicht an einer anderen Stelle. Cloudflare selbst sollte das ja auch können und ihr limitiert dann eben direkt nur auf cloudflare.

https://support.cloudflare.com/hc/en-us/articles/200170786-Restoring-original-visitor-IPs

 

[HayKer]

Hm schade, wäre mir gerade lieber gewesen ich hätte einen Fehler in der Konfiguration

Ich hatte auch schon einen Post in einem anderen Forum gelesen, der sogar zwei Reverse Proxies davor stehen hatte, aber kein Cloudflare. Bei ihm ging es auch. In meinen Augen wäre in meinem Fall Cloudflare auch nur noch ein weiterer Reverse Proxy vor der Infrastruktur.
Ich habe auch schon mal versucht die REMOTE_ADDR Variable auf dem Server zu bearbeiten, mit dem Eintrag aus den Headern. Leider auch ohne Erfolg.

Du hast natürlich recht, würde das aber liebend gerne als „Last Resort“ so umsetzen.

Warum ich das gerne so hätte, hat verschiedene Gründe.
Zum einen möchte ich dem Kunden möglichst viel Freiheit in der Konfiguration seines Webspace geben. Natürlich alles innerhalb seiner gebuchten Optionen.
Zum anderen haben wir auch einige Kunden, die einen eigenen Webentwickler / Dienstleister haben, der gerne selber die Konfiguration übernehmen möchte.
Der Hauptgrund ist aber, dass ich nicht möchte, dass unseren Entwickler in Cloudflare herumspielen oder generell was anderes machen müssen als sich voll und ganz auf die Entwicklung zu fixieren. Ich möchte aber auch nicht wegen jeder Kleinigkeit unter die Arme greifen müssen. Sie sollen nicht anders arbeiten, nur weil Cloudflare vor der Webseite liegt.
Beispielsweise würden die Entwickler die Möglichkeit verlieren, bei Wartungsarbeiten an den Webseiten eine Wartungsseite vorzuschalten, mit unserer IP als Ausnahme, um daran uneingeschränkt arbeiten zu können.
Was bei z. B. Magento Projekten sehr wichtig wäre.

Mir wäre wichtig alle Konfigurationsstechnischen dinge möglichst nur in der ISPConfig Verwaltung durchführen zu können, ganz egal wie die Infrastruktur aufgebaut ist.

 

[HayKer]

Als Workaround habe ich mir nun überlegt die .htaccess Datei dazu zu bewegen einen der beiden Header zu benutzen, um die IP Restriktionen durchzuführen.

<Directory "{DOCROOT_CLIENT}">
    Order deny,allow
    Deny from all

    ## If Not Cloudflare
    #Allow from 62.*.*.*

    ## If Cloudflare
    # SetEnvIf X-Forwarded-For ^62.*.*.* youshallnotpass # OR
    SetEnvIf CF-Connecting-IP ^62.*.*.* youshallnotpass
    Allow from env=youshallnotpass
</Directory>

Das ist für mich auch noch in Ordnung.
Das lässt sich sicherlich auch noch dynamischer machen in dem ich Abfrage ob einer der Header X-Forwarded-For oder CF-Connecting-IP existieren oder nicht.