Zugriff aus meinem LAN auf eine Domain, die auf meine WAN IP verweist
-
Moin zusammen,
ich würde gerne aus meinen verschiedenen VLAN Netzwerken auf meine Domain (hier provisorisch meinedomain.xyz genannt) über das WAN zugreifen können.
Bisher habe ich das Problem, dass, wenn ich die Domain (und Subdomains) anpinge, eine Latenz von nur 0,3ms habe und somit die Anfrage direkt durch pfSense auf das jeweilige Gerät verweist, zu welchen meine Domain eigentlich zeigt.
Weil bei mir dies aber zu Problemen mit Letsencrypt führt, möchte ich, dass sämtliche Anfragen aus meinem Lan, die an Meinedomain.xyz gehen, über das Internet laufen und nicht von pfSense vorher abgegriffen werden.
Ich bin bereits auf "NAT Reflections" sowie "Host Overrides" in der "DNS Resolver" Kategorie gestoßen.
Bei Ersterem konnte ich jedoch auch nach lesen des Wiki-Artikels nicht wirklich damit umgehen.
Aktuell sieht meine Einstellung wie folgt aus, dabei ist 10.10.50.2 mein Server, auf dem meine Dienste, wie Plex, Rocketchat usw. sowie mein reverse proxy manager laufen.
Des Weiteren habe ich auf der "DNS Resolver" Seite von pfSense unter "advanced options" meine Domain eingetragen (2. screenshot), wovon gesagt wurde, dass es das Problem beheben könnte.
Ich bin mir aber nicht sicher, ob das überhaupt etwas bringt.Sind meine Einstellungen soweit korrekt, oder habe ich was vergessen / falsch gemacht?
Beste Grüße
-
Hallo!
@youngspace said in Zugriff aus meinem LAN auf eine Domain, die auf meine WAN IP verweist:
Aktuell sieht meine Einstellung wie folgt aus, dabei ist 10.10.50.2 mein Server, auf dem meine Dienste, wie Plex, Rocketchat usw. sowie mein reverse proxy manager laufen.
Der Hostname fehlt eben noch.
Und weitere Hostnamen, die auf denselben Server gehen sollen, kannst du unten bei "Additional Names" eintragen.@youngspace said in Zugriff aus meinem LAN auf eine Domain, die auf meine WAN IP verweist:
Des Weiteren habe ich auf der "DNS Resolver" Seite von pfSense unter "advanced options" meine Domain eingetragen (2. screenshot), wovon gesagt wurde, dass es das Problem beheben könnte.
Ich bin mir aber nicht sicher, ob das überhaupt etwas bringt.Nein, ist überflüssig, wenn es für die Domain Host Overrides gibt.
@youngspace said in Zugriff aus meinem LAN auf eine Domain, die auf meine WAN IP verweist:
ich würde gerne aus meinen verschiedenen VLAN Netzwerken auf meine Domain (hier provisorisch meinedomain.xyz genannt) über das WAN zugreifen können.
Bisher habe ich das Problem, dass, wenn ich die Domain (und Subdomains) anpinge, eine Latenz von nur 0,3ms habe und somit die Anfrage direkt durch pfSense auf das jeweilige Gerät verweist, zu welchen meine Domain eigentlich zeigt.Host Overrides und NAT Reflection sind die Mittel um unter Verwendung des public FQDN auf die internen Hosts zuzugreifen, aber Lösung für das, was du hier als Problem darstellt, sind beide nicht. Keine der beiden Varianten routet den Verkehr tatsächlich übers Internet, auch nicht irgendwie aus dem WAN Interface. Wohin auch? die Route dafür zeigt im besten Fall auf die pfSense.
Host Overrides bewirken einfach, dass der DNS Resolver (oder auch Forwarder) die interne IP auf DNS Anfragen zurückgibt. Verwendung eines dieser zur DNS-Auflösung vorausgesetzt. So kommunizieren die Geräte direkt auf den kürzestem Weg miteinander.
NAT Reflection bildet eine NAT Regel unsichtbar auch auf die anderen Interfaces ab. Heißt, wenn der Host auf den Hostnamen zugreifen möchte, bekommt er vom DNS die WAN-IP zurück, so schickt er seine Anfrage dahin, was zwangsläufig immer zur pfSense geht und diese nattet den Traffic zum internen Ziel. Diese Methode hat aber ein paar Nachteile.Um den Traffic aber tatsächlich über Internet zu schicken, müsstest du dir ein Proxy im Web suchen, der den Traffic annimmt und dann zurückschickt.
Mir fällt aber kein vernünftiger Grund für solch ein Konstrukt ein. -
@viragomann Danke für die Erklärung, jetzt verstehe ich das schon Mal deutlich besser :D
Wenn jedoch Host Overrides sich sowieso die kürzeste Route suchen, würde ich dann damit nicht etwas anderes bezwecken, als eigentlich passieren soll?
Das Problem ist ja, dass z.B. certbot, welcher ja auch in meinem LAN sitzt, beim Abfragen meiner Domain (und Subdomains) am Ende auf meiner WAN IP-Adresse laden sollte, um ein Zertifikat erstellen zu können.
Aktuell ist dies auch, wenn ich Hostnames angebe nicht möglich, weil dann der Verkehr nicht von Cloudflare gemanaged werden kann, sondern im LAN bleibt.
-
@youngspace
Ich verstehe nicht, welche Rolle bei dir Cloudflare für Certbot spielt. Dein DNS-Provider?Soweit ich die Funktion von Certbot verstanden habe, macht er Folgendes (webroot mode):
Er generiert einen private Key und einen CSR, schickt letzteren an den Server. Er platziert innerhalb deines Webroots einen Secret-Token, den er vermutlich vom ACME-Server bekommt. Der Server löst die Domain über ein Public DNS auf und versucht diesen Token runterzuladen, greift also von außen auf die WAN-IP zu. Wenn erfolgreich, wird er auf Übereinstimmung überprüft, falls auch erfolgreich, stellt der Server ein Zertifikat aus. Certbot lädt dann die Zertifikatskette vom Server und installiert sie.Ich wüsste nicht, wo hier die interne Auflösung eine Rolle spielt.
Nun habe ich auch noch nachgesehen, was ich hier konfiguriert habe. Ich habe DNS-Override im Resolver. Dahinter tut ein Certbot problemlos seinen Dienst.
Auf zwei anderen Installationen habe ich NAT Reflection, wo auch Certbots arbeiten. Alle Server haben mehrere Hostnamen und Domains.Edit:
Du hast anfangs was von einem Proxy erwähnt. Der könnte eventuell ein Problem verursachen, bspw. ein asymmetrisches Routing. Hängt davon ab, wie der in den Datenfluss integriert ist und was er macht. -
Certbot oder jeder andere Letsencrypt Client macht mit Domains im "HTTP-1" Modus gar nichts. Er sendet lediglich deinen Ausstellungs-Wunsch zu LetsEncrypt und deren Server greifen via Domainaufruf und HTTP (kein S!) auf die Domain zu, versuchen den .well-known Pfad abzurufen und damit die Domain zu validieren. Done.
Mit Cloudflare als DNS für die eigene Domain geht das nochmal um einige Ecken leichter, weil man statt HTTP die DNS-1 Methode nutzen kann, wenn man die entsprechenden Daten wie API Key, Domain etc. hinterlegt. Dann wird ein TXT Eintrag in der entsprechenden Domain erzeugt (meinedomain.xyz) für den Hostnamen der validiert werden soll, LetsEncrypt testet den DNS (wieder von außen, dein lokaler DNS auf der pfSense ist da völlig irrelevant) und stellt je nachdem ob das klappt das Zert aus oder nicht.
Ebenfalls Done.Beide Varianten haben nichts(!) mit deinem lokalen DNS und dem Überschreiben mit Host oder Domain Overrides in deiner pfSense zu tun. Der Host oder Domain Override - je nachdem was du brauchst/nutzt - sind lediglich dafür zuständig, dass deine Clients/Server nicht jedes Mal erst auf die externe IP auflösen, auf deiner pfSense rauskommen, da ggf. (wenn aktiviert) via NAT Redirection dann wieder zum Server zurückgespielt werden und insgesamt eben einmal mit dem Paket um den Block fahren, statt direkt ins Haus nebenan zu gehen, zu klingeln und reinzulaufen. Bildlich gesprochen :)
Cheers
\jens