Kurz notiert: Mit Forensik dem Apachen auf die Finger geschaut

Heute habe ich eine elegante Lösung für ein in der Praxis immer wieder­kehrendes Problem gefunden, die ich euch nicht vorenthalten möchte:

Bei der Einrichtung von Geolokalisierung in einer TYPO3-Instanz hatte ich das Problem, dass ich die Vermutung hatte, dass TYPO3 in den einlaufenden Requests nicht die korrekte Client-IP zu sehen bekommt. Dazu muss man wissen, dass die fragliche Instanz unter Kubernetes läuft. Hierbei werden ankommende Requests – stark vereinfacht gesagt – über einen Proxy (sog. Ingress) zur Applikation geleitet. Damit das klappt, muss die Applikation darauf vorbereitet sein, Standard-Proxy-Header wie X-Forwarded-For und X-Forwarded-Host auszuwerten.

Normalerweise ist das in TYPO3 kein größeres Problem. Unterhalb von $GLOBALS['TYPO3_CONF_VARS']['SYS'] existieren die Konfigurations­optionen reverseProxyHeaderMultiValue, reverseProxyIP, reverseProxySSL und trustedHostsPattern. Richtig gesetzt, wertet TYPO3 die Header korrekt aus und erkennt, dass nicht die IP des anfragenden Proxys, sondern die des Clients dahinter die interessante ist.

In diesem Fall wurde als Ingress-Provider ein Google-Load-Balancer unter GKE (Google Kubernetes Engine) benutzt. Dieser hat die Eigenheit, in X-Forwarded-For ausschließlich die IP des Clients zu übergeben. Leider hat sich die standard­konforme Variante aus RFC 7239 (Forwarded-Header) bislang nicht durchgesetzt. Daher kann man Google hier noch nicht mal einen Vorwurf machen. Wo kein Standard ist, kann ich auch keinen verletzen.

Wie habe ich jetzt gemerkt, dass das so ist? Grundsätzlich kann ich natürlich ins TYPO3-Backend gehen und dort unter „Admin Tools -> Environment -> PHP Info“ schauen, was PHP an HTTP-Headern sieht. Der Ansatz birgt aber zwei Probleme:

1. Das funktioniert logischerweise nur im Backend. Frontend-Probleme kann ich so nicht nachvollziehen. Erst recht nicht, wenn Front- und Backend nicht den selben Weg im Webserver nehmen (z.B. verschiedene vHosts).
2. Ins Backend muss ich dazu erst einmal kommen. Wenn ich beispielsweise ein Problem mit der Referrer-Konfiguration debuggen möchte, komme ich ohne [SYS][features][security.backend.enforceReferrer] = false gar nicht ins Backend, um die Header zu sehen. Unschön.

Schön wäre doch, wenn man direkt sehen könnte, welche Header der Webserver (hier Apache) vom Client bzw. Proxy bekommen hat. Im Prinzip genauso, als würde ich einer Varnish-Instanz per varnishlog zuschauen. Und genau hier kommt das Apache-Modul mod_log_forensic ins Spiel!

In der einfachsten Konfiguration setzt man etwa Folgendes im vHost, nachdem man das Modul per a2enmod log_forensic aktiviert hat:

<IfModule log_forensic_module>
  ForensicLog /var/log/apache2/forensic_log
</IfModule>

Apache schreibt dann z.B. Folgendes in die Datei /var/log/apache2/forensic_log:

+28:5fb2fb02:1d|GET / HTTP/1.1|Host:www.pfmmedical.de.feature-french-layer.pfm-corporate.review.web-factory.de|X-Request-ID:f038a5c9ef22f01276e4aafd790b346d|X-Real-IP:83.135.142.198|X-Forwarded-For:83.135.142.198|X-Forwarded-Proto:https|X-Forwarded-Host:www.pfmmedical.de.feature-french-layer.pfm-corporate.review.web-factory.de|X-Forwarded-Port:443|X-Scheme:https|accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8|accept-encoding:gzip, deflate, br|user-agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.1 Safari/605.1.15|accept-language:de-de
-28:5fb2fb02:1d
+25:5fb2fb0a:1f|GET /robots.txt HTTP/1.1|Host:feature-french-layer.pfm-corporate.review.web-factory.de|User-Agent:kube-probe/1.17+|Accept-Encoding:gzip|Connection:close
-25:5fb2fb0a:1f

Man sieht sehr schön, dass hier zwei Requests eingelaufen sind, einer von einem Mac und eine von kube-probe (hier die readiness probe der Applikation). Das Praktische ist, dass auch die vollständigen Request-Header auftauchen, sodass man (vermeintliche) Proxy-Probleme nun wesentlich einfacher einkreisen kann.

Denn letzten Endes stellte sich heraus, dass das ursprüngliche Problem überhaupt nicht an der TYPO3-Konfiguration lag, sondern an einem schnöden Bug in der Geolokalisierungs-Logik. Naja, so kanns manchmal eben auch gehen.