Verwendet man einen Loadbalancer wie z.B. HAProxy um Webzugriffe von Clients auf mehrere Squid Proxy Server zu verteilen, sieht es im access.log des Squid Proxy so aus, als kämen die Zugriffe alle vom HAProxy nicht vom eigentlichen Client. Da das HTTP Forwarding des HAProxy auf Applikationsebene basiert, ist dieses Verhalten korrekt. Wenn man TCP Offloading machen würde, wäre dies wahrscheinlich nicht der Fall.
Um beim HTTP Forwarding dennoch die originale Client-IP im Squid access.log zu sehen, kann man diese über den HTTP Header X-Forwarded-For (Beschreibung) weiterleiten.
In Squid kommen die Requests alle von der IP-Adresse des HAProxy:
1514450659.711 40186 10.0.0.5 TCP_MISS/200 31540 CONNECT images.outbrain.com:443 - HIER_DIRECT/2.19.240.34 - 1514450660.977 40078 10.0.0.5 TCP_MISS/200 3753 CONNECT www.summerhamster.com:443 - HIER_DIRECT/52.27.8.169 -
In HAProxy müssen die folgenden beiden Optionen gesetzt werden. Diese setzen den Header „X-Forwarded-For“ auf die Client IP-Adresse. Dadurch wird die eigentliche Client IP im Header mitgegeben:
option http-server-close option forwardfor
Der Squid Proxy registriert den veränderten Header, verwirft ihn aber aus Sicherheitsgründen standardmäßig – sofern nicht anderweitig konfiguriert. Also muss in der Konfiguration des Squid der QuellIP des HAProxy vertraut werden. Dies wird dementsprechend über eine acl in der squid.conf angepasst:
acl haproxy src 10.0.0.5 follow_x_forwarded_for allow haproxy
Abschließend den Squid neustarten und den Webzugriff über ein Client testen. Wie man nun im access.log sieht, ist die Client-IP jetzt korrekt weitergeleitet.
1514451557.721 5 10.0.0.10 TCP_MISS/200 910 POST http://ocsp.digicert.com/ - HIER_DIRECT/93.184.220.29 application/ocsp-response 1514451557.749 5 10.0.0.10 TCP_MISS/200 2194 POST http://ocsp2.globalsign.com/gsalphasha2g2 - HIER_DIRECT/104.31.74.124 application/ocsp-response