5963755347
12.07.2023
1792
4
0
Reverse Proxy mit Authelia - Transparent oder per DNS Einträgen
Hallo zusammen,
wir haben hier aktuell ein Netzwerksetup, bei dem die Clients im LAN direkt auf die jeweiligen Dienste zugreifen können, also z.B. Nextcloud, Bitbucket, Mattermost etc.
Beim Zugriff von aussen werden die Anfragen zuerst zu einem Apache Reverse Proxy umgeleitet, der ein SSL Zertifikat verlangt bevor er die Anfrage weiterleitet.
Ich möchte das nun so umstellen, dass bei Anfragen aus dem LAN immer ein Reverse Proxy mit Authelia dazwischengeschaltet ist, der die Anfrage erst bei erfolgreicher Authentifizierung durchlässt.
Server und Clients sind in seperaten VLANs und Subnetzen, werden aber aktuell noch einfach komplett gerouted. Das werde ich abstellen, die Clients kommen dann nur noch auf den Reverse Proxy,.
Die Frage ist nun, wie ich diesen Reverse Proxy dort dazwischenschalte. Ich habe meiner Meinung nach zwei Optionen:
1. Es wird ein transparenter Reverse Proxy. Die pfSense ist dann dafür zuständig die Anfragen abzufangen undauf den Reverse Proxy umzuleiten
2. Ich arbeite mit DNS Einträgen. Die DNS Einträge die die Clients für die Dienste verwenden, (z.B. nextcloud.example.com) verweisen auf den Reverse Proxy. Zusätzlich gibts dann noch nen DNS Eintrag für die IP im Servernetz, z.B. nextcloud.internal.example.com, auf den der Reverse Proxy dann zugreift. Die zusätzlichen DNS Einträge sind zwar Zusatzaufwand, den werden wir aber in absehbarer Zeit durch automatisierungen und Skripte auffangen können.
Was würdet ihr machen und warum?
Danke und viele Grüße
Michael
wir haben hier aktuell ein Netzwerksetup, bei dem die Clients im LAN direkt auf die jeweiligen Dienste zugreifen können, also z.B. Nextcloud, Bitbucket, Mattermost etc.
Beim Zugriff von aussen werden die Anfragen zuerst zu einem Apache Reverse Proxy umgeleitet, der ein SSL Zertifikat verlangt bevor er die Anfrage weiterleitet.
Ich möchte das nun so umstellen, dass bei Anfragen aus dem LAN immer ein Reverse Proxy mit Authelia dazwischengeschaltet ist, der die Anfrage erst bei erfolgreicher Authentifizierung durchlässt.
Server und Clients sind in seperaten VLANs und Subnetzen, werden aber aktuell noch einfach komplett gerouted. Das werde ich abstellen, die Clients kommen dann nur noch auf den Reverse Proxy,.
Die Frage ist nun, wie ich diesen Reverse Proxy dort dazwischenschalte. Ich habe meiner Meinung nach zwei Optionen:
1. Es wird ein transparenter Reverse Proxy. Die pfSense ist dann dafür zuständig die Anfragen abzufangen undauf den Reverse Proxy umzuleiten
2. Ich arbeite mit DNS Einträgen. Die DNS Einträge die die Clients für die Dienste verwenden, (z.B. nextcloud.example.com) verweisen auf den Reverse Proxy. Zusätzlich gibts dann noch nen DNS Eintrag für die IP im Servernetz, z.B. nextcloud.internal.example.com, auf den der Reverse Proxy dann zugreift. Die zusätzlichen DNS Einträge sind zwar Zusatzaufwand, den werden wir aber in absehbarer Zeit durch automatisierungen und Skripte auffangen können.
Was würdet ihr machen und warum?
Danke und viele Grüße
Michael
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 7825052858
Url: https://administrator.de/forum/reverse-proxy-mit-authelia-transparent-oder-per-dns-eintraegen-7825052858.html
Ausgedruckt am: 10.05.2025 um 21:05 Uhr
4 Kommentare
Neuester Kommentar
Moin,
Gruß,
Dani
Beim Zugriff von aussen werden die Anfragen zuerst zu einem Apache Reverse Proxy umgeleitet,
Wo ist hier der Sicherheitsgewinn? Weil ohne Zusatzmodule, Firewall Configuration Parameter werden einfach alle Verbindungen 1:1 weitergeleitet.1. Es wird ein transparenter Reverse Proxy. Die pfSense ist dann dafür zuständig die Anfragen abzufangen undauf den Reverse Proxy umzuleiten
eigentlich nutzt man nie eine Firewall zugleich als Reverse Proxy. Denn in der Sicherheitsarchitektur sind das immer zwei physikalisch getrennte Geräte von verschiedenen Hersteller. Dazu kommt das es sich bei dem Reverse Proxy um eine WAF handelt. Anderenfalls kannst du ja nicht in den verschlüsselten Datenverkehr so einfach reinschauen, sondern bist wieder blind. Somit kommuniziert der Client mit der Firewall oder WAF. Je nachdem wie rum man es drehen will/muss.Gruß,
Dani
Zitat von @Dani:
Moin,
Moin,
Beim Zugriff von aussen werden die Anfragen zuerst zu einem Apache Reverse Proxy umgeleitet,
Wo ist hier der Sicherheitsgewinn? Weil ohne Zusatzmodule, Firewall Configuration Parameter werden einfach alle Verbindungen 1:1 weitergeleitet.Das steht im zweiten Halbsatz. Es wird ein SSL Zertifikat verlangt, ohne ist Ende.
1. Es wird ein transparenter Reverse Proxy. Die pfSense ist dann dafür zuständig die Anfragen abzufangen undauf den Reverse Proxy umzuleiten
eigentlich nutzt man nie eine Firewall zugleich als Reverse Proxy.Deshalb leitet die pfSense den Verkehr ja auch auf den Reverse Proxy um.
Moin,
Gruß,
Dani
Das steht im zweiten Halbsatz. Es wird ein SSL Zertifikat verlangt, ohne ist Ende.
da dachte in an ein einfaches SSL-Zertifikat wie es jeder Webseite hat. Du redest in dem Fall von einer Authentifizierung mit Hilfe eines Client/Benutzer Zertifikats.Deshalb leitet die pfSense den Verkehr ja auch auf den Reverse Proxy um.
Unter einem transparenten Proxy verstehe ich etwas anderes. In diesem Fall werden nämlich keine Requests and Responses ergänzt/manipuliert. Was aber mit deiner Erklärung der Fall ist.Gruß,
Dani
Zitat von @Dani:
Moin,
Moin,
Das steht im zweiten Halbsatz. Es wird ein SSL Zertifikat verlangt, ohne ist Ende.
da dachte in an ein einfaches SSL-Zertifikat wie es jeder Webseite hat. Du redest in dem Fall von einer Authentifizierung mit Hilfe eines Client/Benutzer Zertifikats.Und das Client/Benutzer Zertifikat ist kein SSL Zertifikat?
Deshalb leitet die pfSense den Verkehr ja auch auf den Reverse Proxy um.
Unter einem transparenten Proxy verstehe ich etwas anderes. In diesem Fall werden nämlich keine Requests and Responses ergänzt/manipuliert. Was aber mit deiner Erklärung der Fall ist.Darum stand da auch "Reverse" Proxy. Entschuldige vielmals, dass ich evtl. bei der Beschreibungen der zwei Lösungsansätze evtl. den Begriff "Transparenter Proxy" nicht zu 100% korrekt sauber eingesetzt habe.
Im Übrigen hat das trotzdem genau überhaupt nichts mit deinem ersten Einwand, dass pfSense nicht Firewall und Proxy sein sollte zu tun ...
Aber schön, dass nun zumindest die Begriffe schon mal ganz genau definiert wurden, ich denke das führt zu nix ...
