Reverse-Proxy und IP-Adresse des Clients

Allgemeine Fragen zu Problemen. Keine Fehlerberichte oder Feature-Anfragen

Moderator: Securepoint

Antworten
Benutzeravatar
isential gmbh
Beiträge: 162
Registriert: Di 05.05.2015, 22:17
Kontaktdaten:

Reverse-Proxy und IP-Adresse des Clients

Beitrag von isential gmbh »

Hallo nochmals!

Nachdem wir den Reverse-Proxy eingerichtet haben (siehe viewtopic.php?f=27&t=8196), läuft unsere Webanwendung so, wie wir uns vorgestellt hatten – fast...

Für uns ist es von Bedeutung, zu erfahren, von wo aus jemand auf die Anwendung zugreift. Wenn man sich von einem Gerät zum ersten Mal anmeldet, erhalten wir von unserer Webanwendung eine entsprechende Benachrichtigung, die unter anderem folgendes enthält:
Hallo René,
 
es sieht aus, als ob Du Dich mit einem neuen Gerät um "12.06.2020 07:37 (Europe/Berlin)" angemeldet hast:
 
Dein Gerät: Android, Firefox
Deine Lokation (relativ): unknown
Deine IP: 192.168.70.254
...
Nun ist aber die angezeigte IP-Adresse 192.168.70.254 die der UTM-Firewall, die den Reverse-Proxy bereitstellt. Dadurch ist eine relative Lokalisierung des Ortes, von dem die Anmeldung vorgenommen wurde, nicht möglich. Wie es aussieht, arbeitet der Reverse-Proxy nicht transparent, sondern er weist sich gegenüber der Webanwendung als Client aus.

Gibt es hierfür irgend eine Lösung?

Vielen Dank und gesunde Grüße

René

kennethj
Beiträge: 408
Registriert: Di 25.04.2017, 10:17
Wohnort: Lüneburg
Kontaktdaten:

Beitrag von kennethj »

Hallo,

über das Webinterface wäre mir kein Weg bekannt. Über Templates würde es vermutlich funktionieren:
http://www.squid-cache.org/Doc/config/forwarded_for/

Da das Template aber dynamisch generiert wird, wird es bei jeder Änderung in der GUI überschrieben.

Gruß
Kenneth

Benutzeravatar
isential gmbh
Beiträge: 162
Registriert: Di 05.05.2015, 22:17
Kontaktdaten:

Beitrag von isential gmbh »

Danke! Meinst du hier mit Änderung lediglich Änderungen im Bereich des Reverse-Proxys? Nun, wenn es so ist, wäre das gerade noch vertretbar, wenn auch alles andere als schön. Aber ich befürchte, wenn demnächst der Reverse-Proxy in der Lage sein wird, die Let's-Encrypt-Zertifikate selbst zu erneuern, dass Änderungen am Template über den Jordan befördert werden.

Sauberer wäre es, wenn man das im Reverse-Proxy pro Seite einstellen könnte. Dann würde ich in meinem Fall den Schalter auf "Transparent" stellen und der Fall wäre erledigt. Das dürfte zu schaffen sein, oder?

LG

René

Holger
Beiträge: 3
Registriert: Mo 15.06.2020, 09:44

Beitrag von Holger »

Danke Kenneth für den Tipp. Habe forwarded_for transparent im Template hinzugefügt und es funktioniert. Das ganze überlebt auch ein Update  von 11.8.8.1 auf 11.8.8.4 -getestet auf einer Firewall in der TerraCloud. Endlich wieder Logs mit den richtigen Quell-IPs.

Holger
Zuletzt geändert von Holger am Mo 15.06.2020, 10:46, insgesamt 1-mal geändert.

Benutzeravatar
isential gmbh
Beiträge: 162
Registriert: Di 05.05.2015, 22:17
Kontaktdaten:

Beitrag von isential gmbh »

Welches Template? Ich habe noch nie eins geändert. Wie geht das?

Holger
Beiträge: 3
Registriert: Mo 15.06.2020, 09:44

Beitrag von Holger »

Template: /etc/squid/squid.conf
als letzte Zeile einfach: forwarded_for transparent einfügen und ReverseProxy neu starten.

Die Templates findest du unter Extras in der erweiterten Ansicht.

Alles ohne Gewähr

Holger

Benutzeravatar
isential gmbh
Beiträge: 162
Registriert: Di 05.05.2015, 22:17
Kontaktdaten:

Beitrag von isential gmbh »

Danke, es funktioniert aber leider immer noch nicht – die Webanwendung meint weiterhin, der Client besäße die IP der UTM-Firewall.

Ich habe, wie von dir beschrieben, ans Ende vom /etc/squid/squid.conf

Code: Alles auswählen

 forwarded_for transparent
angefügt und den Reverse-Proxy erneut gestartet. Leider passiert gar nichts.

LG

René

kennethj
Beiträge: 408
Registriert: Di 25.04.2017, 10:17
Wohnort: Lüneburg
Kontaktdaten:

Beitrag von kennethj »

Hallo,

das Template für den Reverse Proxy ist nicht die squid.conf sondern die squid-reverse.conf ;)

Gruß

Benutzeravatar
isential gmbh
Beiträge: 162
Registriert: Di 05.05.2015, 22:17
Kontaktdaten:

Beitrag von isential gmbh »

Danke! Hatte es auch mit diesem erfolglos getestet. Ich habe es gerade eben nochmals gemacht, die Webanwendung erhält aber die IP-Adresse der UTM-Firewall und nicht die des Clients.

Holger
Beiträge: 3
Registriert: Mo 15.06.2020, 09:44

Beitrag von Holger »

... also bei mir steht es in der squid.conf und danach zeigen die Logs vom IIS im x-forwarded-for Feld die richtigen IPs ....

Holger

Benutzeravatar
isential gmbh
Beiträge: 162
Registriert: Di 05.05.2015, 22:17
Kontaktdaten:

Beitrag von isential gmbh »

Jo, ich glaub's euch allen. Nur bei mir tut es nicht. Ich habe zwar kein IIS, das dürfte aber egal sein. Ich habe NGINX unter Ubuntu Server 18.04. Alle Einträge im dazugehörigen "/var/log/nginx/*.access.log" kommen meisten entweder von der UTM-Firewall oder ein paar wenige vom internen Netzwerk (ein paar Arbeitsstationen greifen intern auf die Webanwendung zu). Ich stehe auf dem Schlauch...

Andre.S
Beiträge: 65
Registriert: Fr 19.06.2015, 14:24

Beitrag von Andre.S »

Das liegt doch bestimmt daran das in der Mail/ den Logs die IP der TCP/IP Verbindung stehen und nicht der Inhalt des Header-Feldes

Michael Schürle
Beiträge: 9
Registriert: Mi 21.11.2018, 11:43

Beitrag von Michael Schürle »

@isential gmbh:
Man muss keine speziellen Flags im Template setzen - zumindest funktioniert das bei uns (anonymizing off) out of the box.
Ist das ngx_http_realip_module geladen und sind die entsprechenden Einträge in der nginx config gesetzt?

Code: Alles auswählen

sudo vi /etc/nginx/conf.d/default.conf

dort dann

Code: Alles auswählen

set_real_ip_from <interne IP der Securepoint>;
real_ip_header X-Forwarded-For;
oder allgemeiner:

Code: Alles auswählen

set_real_ip_from 192.168.0.0/16;
set_real_ip_from 172.16.0.0/12;
set_real_ip_from 10.0.0.0/8;
real_ip_header X-Forwarded-For;
so funktioniert das bei uns einwandfrei.

Benutzeravatar
isential gmbh
Beiträge: 162
Registriert: Di 05.05.2015, 22:17
Kontaktdaten:

Beitrag von isential gmbh »

Vielen Dank!

Leider fehlen mir an dieser Stelle Linux-Kenntnisse, so dass es für mich alles ziemlich steinig ist. Ich habe mir die nginx-Installation anzeigen lassen und folgendes dabei erhalten:

Code: Alles auswählen

nginx version: nginx/1.14.0 (Ubuntu)
built with OpenSSL 1.1.1  11 Sep 2018
TLS SNI support enabled
configure arguments:
--with-cc-opt='-g -O2 -fdebug-prefix-map=/build/nginx-GkiujU/nginx-1.14.0=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2'
--with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -fPIC'
--prefix=/usr/share/nginx
--conf-path=/etc/nginx/nginx.conf
--http-log-path=/var/log/nginx/access.log
--error-log-path=/var/log/nginx/error.log
--lock-path=/var/lock/nginx.lock
--pid-path=/run/nginx.pid
--modules-path=/usr/lib/nginx/modules
--http-client-body-temp-path=/var/lib/nginx/body
--http-fastcgi-temp-path=/var/lib/nginx/fastcgi
--http-proxy-temp-path=/var/lib/nginx/proxy
--http-scgi-temp-path=/var/lib/nginx/scgi
--http-uwsgi-temp-path=/var/lib/nginx/uwsgi
--with-debug
--with-pcre-jit
--with-http_ssl_module
--with-http_stub_status_module
--with-http_realip_module
--with-http_auth_request_module
--with-http_v2_module
--with-http_dav_module
--with-http_slice_module
--with-threads
--with-http_addition_module
--with-http_geoip_module=dynamic
--with-http_gunzip_module
--with-http_gzip_static_module
--with-http_image_filter_module=dynamic
--with-http_sub_module
--with-http_xslt_module=dynamic
--with-stream=dynamic
--with-stream_ssl_module
--with-mail=dynamic
--with-mail_ssl_module
Darin finde ich unter anderem folgende Angabe:
--with-http_realip_module
Gehe ich dann richtig in der Annahme, dass das von dir aufgeführte und notwendige Modul geladen ist bzw. mitkompiliert wurde?
Nun habe ich die default.conf, wie von dir beschrieben, in /etc/nginx/conf.d/ erstellt. Durch die Anweisung "include /etc/nginx/conf.d/*.conf;"in der "/etc/nginx/nginx.conf" gehe ich davon aus, dass diese beim Neustart von nginx geladen wird. Es passiert aber trotzdem nichts – Zugriffe von draußen werden mit der IP der UTM-Firewall protokolliert. Habe was übersehen.

Benutzeravatar
isential gmbh
Beiträge: 162
Registriert: Di 05.05.2015, 22:17
Kontaktdaten:

Beitrag von isential gmbh »

Ich hatte noch forwarded_for transparent in der UTM-Firewall angegeben. Ohne und mit den nginx-Einstellungen auf dem Ubuntu-Server funktioniert es nun.

Vielen Dank!

Antworten