Kurz notiert: Mit Forensik dem Apachen auf die Finger geschaut

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

Am Anfang war das Problem

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 Konfigurationsoptionen 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 standardkonforme 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.

Das muss doch auch einfacher gehen!

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:

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

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.

Über Christian Spoo

"Mr. Fix-It" zwingt Soft- und Hardware gerne seinen Willen auf. Spricht fließend Meme und Picdump. Bei der Marketing Factory für die Bereiche Entwicklung und technische Konzeption zuständig.