HA-Proxy & ACME, wie läuft die Verbindung
-
Hallo zusammen,
ich nutze die aktuelle Version von pfSense. Da für mehrere Systeme im LAN HTTPS / 443 benötige wird habe ich auf dem externen Server auf welchem die externe Domain gehostet ist entsprechende Subdomain angelegt und die passenden DNS-Records erstellt.
Auf der pfSense ist HA-Proxy eingerichtet welcher die aufgerufenen Subdomain auf die Hosts verteilt und ACME kümmert sich um gültige Zertifikate.
Wenn ich es richtig verstanden habe ist NAT-Reflection dafür verantwortlich dass ich die internen Systeme aus dem LAN heraus auch mit der externen URL erreiche.
Das läuft schon länger ohne Probleme.
Ein Frage die mich um-treibt ist wie die Verbindung abläuft.
Beispiel: Mein Groupware-Server hat intern die 192.168.xx.6 (selbst signiertes Zertifikat). In der externen Domain gibt es dafür die Subdomain gw.meinedomain.de welcher auf die WAN-IP der pfSense zeigt.
Aus dem LAN heraus spreche ich diesen Server mit https://gw.meinedomain.de an. Dadurch wird mir ein vertrauenswürdiges Zertifikat gezeigt.
Läuft nun der ganze Datenverkehr dieser Verbindung über die pfSense. Also:
LAN-Client <-> pfSense <-> Groupwareserver ?
Oder wir die pfSense in diesem Beispiel lediglich für die Initialisierung der HTTPS-Verbindung kontaktiert und danach greift der Client direkt auf den internen Server zu. Also:
LAN-Client <-> Groupwareserver ?
Beste Grüße
Sven -
@pixel24 Wenn du den HAProxy nutzt, dann brauchst du kein NAT und damit auch keine NAT-Reflection. Die Verbindungen gehen intern sowie extern direkt auf den HAProxy. Für externe Verbindungen muss am WAN Interface das jeweilige Port (z.B. 443) als Ziel WAN address geöffnet werden. Interne Verbindungen benötigen eine Standardfreischaltung, Ziel any Port 443.
-
@nonick Die pfSense ist auch der Einwahlrouter ins Internet. Habe ich dann nicht immer NAT?
-
@pixel24 said in HA-Proxy & ACME, wie läuft die Verbindung:
Die pfSense ist auch der Einwahlrouter ins Internet. Habe ich dann nicht immer NAT?
Über IPv4 ja, über IPv6 normalerweise nicht. Das hat aber nichts mit dem HAProxy zu tun. Dieser sitzt direkt auf deinem WAN Interface und wird über die öffentliche IPv4 / IPv6 Adresse angesprochen.
Man sollte zwischen eingehenden und ausgehenden NAT bei IPv4 unterscheiden. Bei ausgehenden Verbindungen hat man ja immer NAT.
Eine normale Portweiterleitung wäre eingehendes NAT, vom Internet (öffentliche IP-Adresse) zu deinem Server (private IP-Adresse). Dort wäre NAT-Reflection -> Pure NAT notwendig, wenn auch von intern auf den Server zugegriffen werden soll (DNS Überschreibung wäre in dem Fall aber die bessere Lösung). Mit einem HAProxy umgeht man das ganze, da dieser immer nur über seine öffentlichen IP-Adresse angesprochen wird.
Portweiterleitung -> Zugriff vom öffentlichen Netz direkt auf eine private IPV4 Adresse.
HAProxy -> Zugriff vom öffentlichen Netz direkt auf die öffentliche IPv4 Adresse am WAN Interface, um die anschließende Verteilung zum jeweiligen Server kümmert sich der HAProxy selbst (dazu sind auch keine Firewall Regeln notwendig). -
@pixel24
Ich versuche das noch einmal etwas zu differenzieren.Grundsätzlich lauscht die pfSense auf allen ihren zugewiesenen IPs und der Zugriff darauf kann von allen Interfaces erfolgen.
D.h. du kannst bspw. auch vom internen Gastnetz die WAN-IP ansprechen, wenn es, wie üblich, da eine Regel gibt die Zugriff auf alle öffentlichen IPs erlaubt.
Daher könnte so auch das Web-Interface der pfSense vom Gastnetz erreicht werden, wenn es auf einem erlaubten Port lauscht.Mit NAT ist hier die Portweiterleitung von der WAN IP auf eine interne gemeint. Die NAT-Regel ist allerdings auf dem WAN Interface definiert. Du kannst zwar von intern auf die WAN-IP zugreifen, allerdings fehlt dir da die NAT-Regel, die dich auf den internen Zielhost weiterleitet.
Da kommt NAT Reflection ins Spiel. Es macht nichts anderes als die NAT-Regel auf allen internen Interfaces abzubilden, ohne die Regel in der Admin-Oberfläche darzustellen.Der HAproxy ist aber einfach auf die WAN-IP gebunden. Wenn du diese IP von intern ansprichst, kommst du auf den Proxy und damit auf deine interne Webseite.
-
Ja, ich denke so hatte ich es auch immer verstanden. Mein interner Groupwareserver auf welchen ich per HTTPS / 443 zugreifen möchte hat intern die 192.168.xx.6 und den FQH com01.intern.lan. Für dieses Dienst habe ich auf dem externen Webserver welcher die Domain (meinedomain.de) verwaltet eine Subdomain gw.meinedomain.de eingerichtet und den A-Record auf die WAN-IP (feste) der pfSense gesetzt. Der HA-Proxy löst die ankommende Anfrage auf https://gw.meinedomain.de auf und leitet sie auf 192.168.xx.6.
Da ich mehrere Hosts im LAN habe die über HTTPS/444 von extern erreichbar sein sollen habe ich dieses Szenario mit mehren Subdomains wiederholt. Das würde mit einer Portweiterleitung ja so nicht funktionieren.
Ich dachte immer das NAT-Reflection nun dafür verantwortlich ist dass ich vom internen LAN aus den Dienst ebenfalls unter https://gw.meinedomain.de ansprechen kann anstatt über https://com01.intern.lan
-
@pixel24 said in HA-Proxy & ACME, wie läuft die Verbindung:
Da ich mehrere Hosts im LAN habe die über HTTPS/444 von extern erreichbar sein sollen habe ich dieses Szenario mit mehren Subdomains wiederholt. Das würde mit einer Portweiterleitung ja so nicht funktionieren.
Vermute du meinst 443 :)
Das würde mit einer Portweiterleitung ja so nicht funktionieren.
Richtig, ein PortForward kann nur IP weiterleiten, aber nicht differenzieren.
@pixel24 said in HA-Proxy & ACME, wie läuft die Verbindung:
Ich dachte immer das NAT-Reflection nun dafür verantwortlich ist dass ich vom internen LAN aus den Dienst ebenfalls unter https://gw.meinedomain.de ansprechen kann anstatt über https://com01.intern.lan
Das ist auch umgangssprachlich so. Da gehts aber nicht direkt um NAT oder nicht, sondern um Regellogik. Dein Portforward von extern gilt normalerweise NUR GENAU auf dem WAN wenn etwas von extern auf die externe IP ankommt und wird - ebenfalls NUR dann - nach innen geschickt. Kommt dein Client von innen jetzt mit der externen IP, landet er auf der Sense, auf dem äußeren Interface und ... ja versauert da. Denn der Forward ist ja auf dem WAN definiert und nicht auf dem LAN. Du kommst dann aber vom LAN.
NAT Reflection fügt nun quasi jedem Port Forwarding automatisch noch weitere Regeln zu, die von allen anderen Interfaces aus weitere Redirects machen auf die entsprechende interne IP. Damit bekommt der Request dann die richtige Richtig. Prinzipiell könntest du die Regel selbst bauen und 1:1 die gleiche Regel wie mit dem WAN Interface nochmal bauen fürs LAN - dann hättest du dir manuell den Forward quasi gebaut.
Ob du intern den Dienst über deine externe Domain oder nicht ansprechen kannst liegt übrigens überhaupt nicht bei NAT, sondern beim DNS ;) Wenn du intern deinen DNS Resolver von der sense nutzt und dir dann dort einen Host Override für dein gw.meinedomain.de auf die interne IP setzt (man spricht von Split DNS weil du dann intern eine andere Antwort als extern erhältst) brauchst du auch kein NAT Reflection, sondern kommst ohne durch und baust die Verbindung direkt mit dem richtigen System ohne 3-Ecken dazwischen auf :)
Cheers
-
@jegr said in HA-Proxy & ACME, wie läuft die Verbindung:
Vermute du meinst 443 :)
Jeb
@jegr said in HA-Proxy & ACME, wie läuft die Verbindung:
NAT Reflection fügt nun quasi jedem Port Forwarding automatisch noch weitere Regeln zu, die von allen anderen Interfaces aus weitere Redirects machen auf die entsprechende interne IP. Damit bekommt der Request dann die richtige Richtig. Prinzipiell könntest du die Regel selbst bauen und 1:1 die gleiche Regel wie mit dem WAN Interface nochmal bauen fürs LAN - dann hättest du dir manuell den Forward quasi gebaut.
Ja ok, verstanden ... zumindest hoffe ich das.
@jegr said in HA-Proxy & ACME, wie läuft die Verbindung:
Ob du intern den Dienst über deine externe Domain oder nicht ansprechen kannst liegt übrigens überhaupt nicht bei NAT, sondern beim DNS ;) Wenn du intern deinen DNS Resolver von der sense nutzt und dir dann dort einen Host Override für dein gw.meinedomain.de auf die interne IP setzt (man spricht von Split DNS weil du dann intern eine andere Antwort als extern erhältst) brauchst du auch kein NAT Reflection, sondern kommst ohne durch und baust die Verbindung direkt mit dem richtigen System ohne 3-Ecken dazwischen auf :)
Ja, hier tun sich dann ernsthafte Wissenslücken auf die es zu schließen gilt. Wie ich intern den DNS Resolver von der pfSense nutze kann ich nur vermuten :-( Ich konfiguriere am lokalen DNS-Server (Univention) die pfSense als "externer DNS" ?
with best
-
This post is deleted! -
Ich denke ich muss mich zuerst mit dem Thema DNS beschäftige und nachfolgend mit HA-Proxy.
Ich habe hier eine Testumgebung und eine frisch installierte pfSense.
Ebenfalls habe ich das Handbuch zum Thema konsultiert.
Während der Installation bzw. dem nach-gelagerten Setup habe ich als Domain mein lokale Domain 'intern.lan' sowie den dafür zuständigen lokalen DNS-Server (UCS-Server) mit seiner IP '192.168.xx.5' konfiguriert. Zusätzlich habe ich noch einen DNS vom Provider (Vodafone) als Secondary DNS Server: 80.69.100.230 gesetzt.
Per Default ist der DNS-Resolver der pfSense ja im 'Resolver mode' um Problemen mit nicht vorhanden oder falsch konfigurierten loaklen DNS-Servern vorzubeugen. Wenn ich das Handbuch hier richtig interpretiere ist es sinnvoll unter: Dienste -> DNS-Weiterleitung den 'Forward Mode' zu aktivieren. Vorher den REsolver-Mode deaktivieren
Hier habe ich ebenfalls eine Host-Überschreibung hinzugefügt:
Host: gw Domäne: meinedomain.de IP: 192.168.xx.6Wenn ich nun von einem Client im Testlan:
dig gw.meinedomain.deerhalte ich vom lokal DNS die LAN-IP mit externem Domain-Suffix, also:
gw.meinedomain.de 192.168.xx.6Das schein nun also korrekt zu sein wenn ich es soweit richtig verstanden. habe
Beste Grüße
pixel24 -
@pixel24 said in HA-Proxy & ACME, wie läuft die Verbindung:
Ja, hier tun sich dann ernsthafte Wissenslücken auf die es zu schließen gilt. Wie ich intern den DNS Resolver von der pfSense nutze kann ich nur vermuten :-( Ich konfiguriere am lokalen DNS-Server (Univention) die pfSense als "externer DNS" ?
Warum "externer DNS"? Jeder Rechner braucht nen DNS. Welchen du einträgst liegt an dir. Wenn du ne interne DNS Zone aufbauen willst weil mehrere Geräte macht es Sinn einen internen DNS zu führen/füttern. Das kann man mit dem DNS der Sense problemlos machen.
Und da der caching etc. macht, macht es ja Sinn wenn alle internen Clients ihr DNS nicht einfach in die Welt rauströten, sondern das an die pfSense schicken, die das dann für sie auflöst (resolver mode, nicht forwarding mode) und ihnen antwortet. Als Edge Device direkt am Rand des lokalen Netzes zum Internet macht das am meisten Sinn.
Und wenn alle internen Kisten dann eh die Sense als DNS haben, kann man dort dann auch problemlos DNS Einträge überschreiben oder via DNS Blocklisting mit pfBlockerNG bspw. eben rausblocken (Werbeblocking, Porn-Filter, etc. blah) :)
-
@pixel24 said in HA-Proxy & ACME, wie läuft die Verbindung:
Dienste -> DNS-Weiterleitung den 'Forward Mode' zu aktivieren. Vorher den REsolver-Mode deaktivieren
Nein. Warum solltest du das?
@pixel24 said in HA-Proxy & ACME, wie läuft die Verbindung:
Per Default ist der DNS-Resolver der pfSense ja im 'Resolver mode' um Problemen mit nicht vorhanden oder falsch konfigurierten loaklen DNS-Servern vorzubeugen.
Und weil es einfach Sinn macht DNS ordentlich zu "resolven" statt stumpf zu forwarden? :)
@pixel24 said in HA-Proxy & ACME, wie läuft die Verbindung:
Während der Installation bzw. dem nach-gelagerten Setup habe ich als Domain mein lokale Domain 'intern.lan' sowie den dafür zuständigen lokalen DNS-Server (UCS-Server) mit seiner IP '192.168.xx.5' konfiguriert. Zusätzlich habe ich noch einen DNS vom Provider (Vodafone) als Secondary DNS Server: 80.69.100.230 gesetzt.
Das macht für mich keinen Sinn. Warum sollte die pfSense einen Server "hinter" ihr im LAN für DNS fragen, der dann wieder im Netz nach DNS fragt? Das ist doch Ping-Pong?
Und als 2. DNS einen Provider Server (die notorisch anfällig sind mal nicht zu laufen) der deine interne Domain nicht kennt zu nutzen bringt auch eher wenig :) -
Zum Thema DNS Hiearchie siehe auch
-
Ok, den Forward-Mode deaktiviert und dort die Host-Überschreibung gelöscht. Den Resolver-Mode wieder aktiviert und dort die Host-Überschreibung hinzugefügt.
In den Allgemeinen Einstellungen die beiden DNS-Server entfernt.
Mit dig vom Client aus die gw.meinedomain.de abegfragt. Als Ergebnis erhalte ich die LAN-IP.
So sollte es nun passen
-
This post is deleted!
