HAProxy -> Synology autom. Blockierung (IP) // SSH-Forwarding

[Bytechanger]

Hallo,

ich nutze den HAProxy als ReverseProxy.
Eingehende Verbindungen werden zu meine Synology Diskstation weitergeleitet.
1) Die Synology hat eine automatische Blockierung, wenn zu viele fehlerhafte Anmeldeversuche stattfinden, wird die IP gesperrt. Aktuell erkennt sie aber offensichtlich nur die IP des Proxy und blockiert diese.
D.h. wenn sich jemand zu oft falsch anmeldet, sind damit automatisch ALLE Anmeldungen und IPs gesperrt, da ja alle über den Proxy kommen. Gibt es eine Möglichkeit, dass die Synology erkennt, dass die Quell-IP eine andere ist und nur der Proxy als Mittelsmann funktioniert ?
Ich habe i Frontend  X-Forwarded-For header aktiviert.

1b) Mir kommt die Anmeldung sehr verlangsamt vor. Klar, es gibt eine Zwischenstation, die kann aber die Verbindung nicht so lähmen. Gibt es da Optimierungsmöglichkeiten in den Einstellunge?

2) Ich möchte mein SSH vom Raspi auch über den ReverseProxy laufen lassen. Wie stelle ich das an und was muss ich beachten?
Frontend habe ich auf TCP gestellt.
Im Backend TCP Layer 4

Greets

Byte

[superwinni2]

1) Du musst deiner Syno irgendwie beibringen den "X Forwarded For" Header auszulesen...
Da ich jedoch selbst keine habe.. vielleicht bringt dich google da auf den richtigen Weg?
https://www.google.com/search?q=synology+x+forwarded+for&oq=synology+x+forwarded+for


1b) Was heißt verlangsamt? Über welches "Zeitgefühl" reden wir hier? Wie performant ist deine FW?


2) Sorry habe ich selbst noch nicht gemacht bzw. gebraucht...

[JeGr]

> 2) Ich möchte mein SSH vom Raspi auch über den ReverseProxy laufen lassen. Wie stelle ich das an und was muss ich beachten?

Mal platt gefragt: Warum? Mit welchem Sinn dahinter?

[Tattoofreak]

Hast du je herausgefunden wie das geht mit der Synology? Ich stehe vor dem selben Problem!

[Bytechanger]

@JeGr: Die Antwort ist recht einfach. Wer sich mit IPv6 beschäftigt (und die Deutsche Glasfaser hat nur native IPv6) wird feststellen, dass es dort kein Portforwarding gibt. Das kann ich aber indirekt über einen reverseproxy machen. D.h. ich habe EIN Ziel in meinem Netzwerk (Reverse Proxy) und der leitet je nach dem Weiter auf die verschiedenen Endgeräte in meinem Netz. Weiterer Vorteil, die https-Verbindung (nicht bei ssh) wird mit dem reverse proxy aufgebaut und ich brauche nur ein SSL-Zertifikat.

@Tattofreak:   -- ich schaue nach, bin nicht mehr sicher, glaube, man konnte einen vertrauenswürdigen Proxy angeben....

[JeGr]

> Wer sich mit IPv6 beschäftigt (und die Deutsche Glasfaser hat nur native IPv6) wird feststellen, dass es dort kein Portforwarding gibt. Das kann ich aber indirekt über einen reverseproxy machen.

Eigentlich lese ich da 2 falsche Aussagen.
Es gibt bei IPv6 nach wie vor Port Forwarding (da PFW eigentlich in PF lediglich Redirects sind und die funktionieren mit IPv6 genauso immer noch). Und warum sollte ich bei IPv6 - wenn ich ein ganzes Subnetz zugewiesen bekomme, was eigentlich überall sein muss - überhaupt Redirecten wenn ich so viele Adressen zur Verfügung habe? Darum frage ich mich wozu man SSH proxy'en möchte. Bei so viel Adressen gibts genug für alle.

Dass HTTPS via Reverse Proxy Sinn macht ist unbestritten, aber da gehts ja auch um ganz andere Baustellen wie SSL Termination etc.

[Bytechanger]

Weil ich dann nur eine IPv6 auf eine Domain (DynDNS) lege und dann, wie bisher auch, über die verschiedenen Ports verschiedene Maschinen ansteuere.
Andernfalls müsste ich jede Maschine eine DynDNS zuweisen und sie darüber ansprechen....
Nach außen hat jede Maschine ihre eigene ipv6 Adresse, daher ist Portforwarding ja eher "ungewünscht" als nicht möglich in ipv6.

[JeGr]

Ah also dynamisches Prefix und ständige Zwangstrennung. OK davon stand da nichts
Ja die Freuden von Providern...

Aber gerade SSH ist da ja recht schmerzfrei. Warum nicht einfach unterschiedliche Ports. Dann muss man sich nicht mit Multiplexen rumschlagen? SSH ist da halt das einfachste Protokoll für weil sehr handzahm, packt mans einfach auf verschiedene Ports und gut ist. Positiver Nebeneffekt - weg von 22/tcp extern heißt weg von den ganzen stupiden SSH Bots die einem ständig die Verbindung zusabbeln

Cheers

[Bytechanger]

Ich habe nach "draußen" keine Standardports -never ever-.
Der 80 wird nur kurzfristig für die Erneuerung des Lets Encrypt Zertifikates geöffnet. Ansonsten immer custom ports. So dann auch für ssh. Läuft übrigens prima und ist hat ein Nebenprodukt, da ich https sowieso über den reverse proxy leite. Schön daran ist, dass dieser dann auch eine Authentifizierung über Zertifikat zulässt.

Greets

Byte

[fabian]

Theoretisch geht es aber du brauchst nen HTTP CONNECT oder SOCKS proxy dafür, weil SSH keine Host-Information wie HTTP mitschickt. Dazu brauchst du die Client IP Adresse (Stichwort PROXY protocol).

Wenn du auf dem Server blocken willst, musst du das nicht lokal machen, sondern musst die Information irgendwie an die OPNsense weiterleiten, weil der Server in so einer Konfiguration nur den Proxy sieht. Man kann irgendwie auch die Quell-IP-Adresse spoofen, aber das kann imho kein Proxy auf OPNsense.

[Bytechanger]

Hi,

@Tattoofreak

Ich habe folgendes konfiguriert, das -wie ich glaube- ganz gut funktioniert.

Im reverse proxy habe ich  "X-Forwarded-For header" aktiviert, was dafür sorgen sollte, das die eigentliche Client IP im Header an die Synology übermittelt wird.

In der Synology dann unter Sicherheit->Sicherheit->vertrauenswürdige Proxys die IP des reverse proxys eingetragen. Damit vertraut die Synology dann dem reverse proxy und mithin auch deem X-Forwarded header!

Greets

Byte