Internen Webserver über die Domain erreichen?
-
Guten Tag zusammen!
Ich nutze pfSense in der Version 2.4.4.
In meinem LAN habe ich einige Webserver laufen, die mit SQUID Reverse Proxy behandelt werden (hier hab ich noch einige Probleme, aber das soll in diesem Thread nicht das Thema sein).
Außerdem sind 2 WANs an meiner pfSense die ich mit einem LoadBalancer "gekoppelt" habe.Will ich nun aus dem LAN heraus einen der Webserver über die Domain erreichen, klappt das nicht.
Ein GITlab Server hängt z.B auf 192.168.1.174 und öffentlich wird er über WAN1 angesprochen. Da GITlab aber nur eine external_url hat und ich den auch von außen erreichen will, muss ich natürlich den Domainnamen dort eintragen.
Also komm ich intern gar nicht drauf, selbst wenn ich die entsprechende IP im Browser angebe. Das ist aber nur ein Beispiel.Ich muss also jedesmal eine Rule aktivieren, dass ich nur über WAN2 rausgehe, damit ich von dort auf WAN1 und somit auch auf den GITlab Server komme.
Das ist aber besonderes lästig, wenn ich dann wieder den LoadBalancer nutzen will, denn dann muss ich die Rule wieder deaktivieren, oder wenn ich auf einen anderen Server zugreifen will, der von außen via WAN2 erreichbar ist, muss ich eine andere Rule aktivieren, dass ich nun via WAN1 rausgehe, damit ich auf die Domain vom zweiten Server zugreifen kann.Google hat ergeben, dass ich wohl den DNS Forwarder benutzen könnte, aber das klappt nicht, weil pfSense nicht mein DNS ist.
Außerdem habe ich rausgefunden, dass man auch NAT Reflection nutzen könnte, aber das hab ich nicht funktionierend hinbekommen.Könnt ihr mir bei meinem Problem helfen? Ich hoffe, ich hab das einigermaßen verständlich rübergebracht :)
LG
-
@hattabatatta said in Internen Webserver über die Domain erreichen?:
Google hat ergeben, dass ich wohl den DNS Forwarder benutzen könnte, aber das klappt nicht, weil pfSense nicht mein DNS ist.
Und warum ist sie das nicht? Was spricht dagegen?
Außerdem habe ich rausgefunden, dass man auch NAT Reflection nutzen könnte, aber das hab ich nicht funktionierend hinbekommen.
Das würde nur funktionieren, wenn der Gitlab Server extern via Port Forwarding oder 1:1 NAT auf WAN1 rein gemappt ist und du das dann für diese Regel einschaltest - zusätzlich muss es dann aber ggf. auch eine Regel geben, die erlaubt die dann genattete Verbindung zu verwenden.
Generell würde es wahrscheinlich(!) mit NAT reflection gehen, es wäre aber sehr viel einfacher, es schlicht mit DNS zu machen.
Gruß
-
@jegr said in Internen Webserver über die Domain erreichen?:
Und warum ist sie das nicht? Was spricht dagegen?
Weil ich Pi-Hole als meinen DNS nutze.
@jegr said in Internen Webserver über die Domain erreichen?:
Das würde nur funktionieren, wenn der Gitlab Server extern via Port Forwarding oder 1:1 NAT auf WAN1 rein gemappt ist
Der Gitlab Server ist wie einige andere via Squid Reverse Proxy gemappt.
Die externen WANs sind dort eingetragen sowie auch die entsprechenden Webserver. Das funzt auch wirklich gut -
@hattabatatta said in Internen Webserver über die Domain erreichen?:
Weil ich Pi-Hole als meinen DNS nutze.
Gut, dann ists ja doppelt unverständlich, denn dann nutzt du eh schon einen custom DNS Server -> Pi-Hole, und kannst da problemlos deine paar internen Kisten mit eintragen, damit für die eben kein Blackhole auf 127.0.0.1 o.ä. gemacht wird, sondern die auf deine internen IPs zeigen.
Ansonsten: pfSense als Default DNS per DHCP pushen und dort einfach den Pi-Hole als Forwarder eintragen, geht genauso wenn der unbedingt gebraucht wird. Denke aber, dass man die Funktion des PI-Hole auch relativ einfach mit pfBlockerNG hinbekommt, somit sich eine Kiste sparen kann :)
-
@jegr said in Internen Webserver über die Domain erreichen?:
Denke aber, dass man die Funktion des PI-Hole auch relativ einfach mit pfBlockerNG hinbekommt, somit sich eine Kiste sparen kann :)
Stimmt schon, nur will das natürlich niemand hören, der sich gerade so eine Kiste gebaut hat und darauf mächtig stolz ist...
-
Keine Sorge die "Kiste" ist nur eine VM und nicht eben mal "gebaut" und mächtig stolz bin ich auch nicht drauf.
Da bin ich auf andere Sachen mehr stolz als da drauf :)Wenn es natürlich eine Alternative gibt, die ähnlich leicht zu bedienen ist ... nur her damit.
-
Kannst du bei Pi-Hole nicht einfach ein Split DNS einrichten und fertig?
-Rico
-
Wenn es natürlich eine Alternative gibt, die ähnlich leicht zu bedienen ist ... nur her damit.
pfBlockerNG mit DNSBL tut das - und mehr, weil es nicht nur wie PiHole DNS Abfragen umleitet sondern auch Layer 3 IP blocken kann. Daher zu deiner Frage der Alternative:
- Mach es mit dem Pi Hole - ich hab mir am Samstag extra mal auf nem alten Pi1B einen installiert. (was tut man nicht alles...) Zum einen kannst du die pfSense da als Fowarder eintragen und den Split DNS dann auf der pfSense pflegen, zum anderen kannst du problemlos auch beim PiHole deine DNS Antwort auf bestimmte Fragen hinterlegen.
Wenn du also intern domain.xyz erreichen willst auf der 192.168.1.10, dann kannst du das entweder direkt in der /etc/hosts des PI eintragen, du kannst ein Domain Overwrite für eine Domain/Hostnamen machen (in der UI) oder du haust das hier für den PiHole in die Tasten:
# manuelles Einfügen eines Hostnamens mit IP pihole -a -r domain.xyz 192.168.1.10 # zum Löschen aller Hostnamen pihole -a -r
- Du kannst die Funktion auch versuchen nachzubilden, indem du pfBlockerNG(-devel) nutzt. Ich würde momentan -devel nuzten, da hier wesentlich mehr Funktion und UI schon vorhanden ist und auch mit vordefinierten Blocklisten zum einfachen abonnieren die Bedienung wesentlich leichter ist. Ist aber insgesamt auch was, mit dem man sich mal ein bisschen beschäftigen sollte. Und hat natürlich nicht so ein schönes Dashboard wie der Pi. Aber man spart sich dann die zwei-stufige Lösung.
Gruß
- Mach es mit dem Pi Hole - ich hab mir am Samstag extra mal auf nem alten Pi1B einen installiert. (was tut man nicht alles...) Zum einen kannst du die pfSense da als Fowarder eintragen und den Split DNS dann auf der pfSense pflegen, zum anderen kannst du problemlos auch beim PiHole deine DNS Antwort auf bestimmte Fragen hinterlegen.