[SOLVED] Brauche Hilfe für einen Outside Proxy

[jmalter]

Hi Folks,

bis jetzt bin ich noch zu keiner Lösung gekommen, aber vielleicht kann mir von euch jemand helfen.

Szenario:
Von bestimmten Outside IPs wird eine Verbindung zum Router mittels HTTPS aufgebaut. Diese sollen über einen Proxy an eine andere Domain geproxied werden, abhängig von der URI.

Beispiel:
Router = xyz.domainA.com
Anfrage an https://xyz.domainA.com/bla1 soll an https://server.domainB.com/bla1/irgendwas.pl
Anfrage an https://xyz.domainA.com/bla2 soll an https://server.domainC.com/bla2/irgendwasanderes.pl
und vier weitere.

Na klar könnte ich einen Server ins Büro stellen, aber wir wollen ja den letzten Server abschalten, da wir nur noch Cloud Services benutzen. Allerdings brauche ich irgendwas wo ich die o.a. Anfragen über einen Proxy wieder weiterleiten kann.
Ich bin mir noch nicht ganz sicher, wäre der Relayd Proxy das Tool der Wahl?

Viele Grüße

Jörg

[JeGr]

Warum ein Proxy?

> Diese sollen über einen Proxy an eine andere Domain geproxied werden, abhängig von der URI.

Das was du im weiteren beschreibst sind simple HTTP Redirects (301) die lediglich auf eine (andere) Domain und Pfadelement verweisen. Das ist vom Prinzip her weder ein Job für einen Proxy (Overkill / unötig) noch für einen Loadbalancer (RelayD) - beide würden die Verbindung ja weiter halten und nicht übergeben.

Es sei denn natürlich die Verbindung müsste immer zwischen Client und DomainA/bla ablaufen. Wenn aber die Clients (Browser?) lediglich auf DomainB/C/D umgeleitet werden müssen genügt wie gesagt ein Redirect von einem Webserver. Und der müsste notfalls nicht mal auf der Firewall laufen. Warum nicht einfach xyz.domainA.com auf eine andere IP verweisen lassen (wenn ihr eh alles auf Cloud Services laufen habt, gibts ja sicher irgendwo nen Webserver, der den Job dankend mit abwickeln kann).

Grüße

[jmalter]

Hi,

ein Redirect wird nicht funktionieren. Also ich muss ein bisschen ausholen.
Unsere produktiven Server greifen bei verschiedenen Dienstleistern (whitelisted IPs) auf APIs zu.
Für den Testbetrieb können wir leider nur eine IP anmeden, deswegen der proxy über unsere Outside IP. Diverse Testserver und auch unsere Entwickler Mac's ob von zuhause, unterwegs oder im Office müssen dann durch uns geproxied werden, da nur die Office IP whitelisted ist.

Viele Grüße

Jörg

[franco]

Hi Jörg,

Das HAproxy-Plugin sollte das alles regeln.


Grüsse
Franco

[jmalter]

Hallo Franco,

danke für Deinen Tip. Werde es damit umsetzen.

Viele Grüße

Jörg

[jmalter]

Hi zusammen,

vielleicht kann mir hier jemand damit weiterhelfen. Ich brüte jetzt schon seit zwei Tagen an der Konfiguration und weiß noch nicht weiter. Wie vorgeschlagen wollte ich das mit HAProxy umsetzen.

https://dev.firma.de (name geändert) ist eine der Domains wie wir erreichbar sind. Die Server die darauf zugreifen können, sind per PF eingeschränkt. Ein LetsEncrypt Zertifikat (auch für den Router und weiteres) holt OPNSense bereits.

Die folgenden Regeln sollen beschreiben, wie der Proxy (wichtig redirect darf nicht nicht, da wir nur eine IP whitelisten können)
https://dev.firma.de/anbieter1                -> https://soatest.anbieter1.com/psc/services/PscService
https://dev.firma.de/anbieter2                -> https://test.api.anbieter2.com
https://dev.firma.de/anbieter3/deposit     -> https://pay.anbieter3.com
https://dev.firma.de/anbieter3/status       -> https://www.anbieter3.com/app/query.pl
https://dev.firma.de/anbieter3/withdrawal -> https://www.anbieter3.com/app/pay.pl

Bis jetzt hatte ich es immer so gemacht, dass Outside 443 per NAT an einen Apache intern geht und dieser dann die Proxy Rules ausgeführt hat. Aber dieser verbliebene Server soll ja auch raus.

ProxyPass /anbieter1 https://soatest.anbieter1.com/psc/services/PscService
ProxyPassReverse /anbieter1 https://soatest.anbieter1.com/psc/services/PscService

ProxyPass /anbieter2 https://test.api.anbieter2.com
ProxyPassReverse /neteller https://test.api.anbieter2.com

ProxyPass /anbieter3/deposit https://pay.anbieter3.com
ProxyPassReverse /anbieter3/deposit https://pay.anbieter3.com

ProxyPass /anbieter3/status https://www.anbieter3.com/app/query.pl
ProxyPassReverse /anbieter3/status https://www.anbieter3.com/app/query.pl

ProxyPass /anbieter3/withdrawal https://www.anbieter3.com/app/pay.pl
ProxyPassReverse /anbieter3/withdrawal https://www.anbieter3.com/app/pay.pl

Wie gesagt, ich stehe da irgendwie auf dem Schlauch oder denke einfach zu kompliziert.

Viele Grüße

Jörg

[lewald]

Hallo,

ich bin kein Experte für Haproxy.

Aber die anforderung ist zuerst mal ein Reserve Proxy. Das geht mit Haproxy ja problemlos.
Die zweite Anforderung ist ja eine neue Source ip zu erzeugen.

Normalerweise macht ein Reserve Proxy das nicht. Hierzu mal folgender Link.
https://security.stackexchange.com/questions/2927/does-using-an-http-proxy-completely-hide-my-real-ip-address

Technisch müsste das meiner Meinung nach so laufen.

haproxy auf pf sense an eine virtuelle ip binden (weiß nicht ob das geht). So wie bisher alles 443 auf diese ip mappen.
Dann sollte der Datenverkehr von innen via nat nach draußen gehen.
Ich denke selbst dann wird noch full cone nat benötigt.

PS: Evtl. wär VPN für die Clients die bessere und sichere Variante

[fabian]

Die zweite Anforderung ist ja eine neue Source ip zu erzeugen.

Das macht ein Reverse Proxy sowieso - der Proxy baut ja selbe eine TCP-Verbindung zum Backend server auf.

Normalerweise macht ein Reserve Proxy das nicht. Hierzu mal folgender Link.
https://security.stackexchange.com/questions/2927/does-using-an-http-proxy-completely-hide-my-real-ip-address

Falsch!!! Die IP wird immer ersetzt. Mal abgesehen davon geht es hier um einen Forward Proxy und ob der die IP nicht irgendwie preis gibt. Als ausgehende IP wird hier aber die des Proxy genommen. X-Forwarded-For ist ein HTTP-Header, den ein Proxy üblicherweise setzt, um dem Zielserver die Information, mitzuteilen, wo der Request her kam (original IP).

haproxy auf pf sense an eine virtuelle ip binden (weiß nicht ob das geht). So wie bisher alles 443 auf diese ip mappen.
Dann sollte der Datenverkehr von innen via nat nach draußen gehen.
Ich denke selbst dann wird noch full cone nat benötigt.

wozu auf einmal ne virtuelle IP, was ist ein "full cone nat" und wozu soll man das alles brauchen? Wenn ich das richtig verstehe soll es ja kein transparenter forward proxy werden.

PS: Evtl. wär VPN für die Clients die bessere und sichere Variante

Vermutlich ja, da sonst auch URLs und links umgeschrieben werden müssen - man denke an absolute pfade in Webseiten, die von verschiedenen CMS generiert werden.

[jmalter]

Hi,

nach ein paar Tagen probieren, alles verwerfen, dann Workflow aufmalen und es dann neu versuchen, hat es soweit geklappt, dass ich anhand des Pfades auf die verschiedenen Backend/Server verteile. In soweit funktioniert es schon mal.

Die Doku von HAPROXY ist etwas gewöhnungsbedürftig aber mit viel trial and error klappt es

Viele Grüße

Jörg