In dem Artikel zeige ich dir, wie du es hinbekommst, deine internen Dienste, sowohl von extern als auch intern, mit (Sub-)Domains und HTTPS zu erreichen 🎉
Seit dem ich mein HomeLab zuhause habe, stellt sich natürlich die Frage, wie ich es schaffe, die internen Dienste auch über sprechende Domain-Namen anzusprechen. Zudem wäre internes HTTPS natürlich auch sehr super. Ich möchte mir einfach nicht mehr IPs oder Hostnamen merken, sondern einfach nur (Sub-)Domains.
💡 Dieser Artikel richtet sich an fortgeschrittene Nutzer. Solltest du dich hier nicht so gut auskennen, wäre es ratsam, dass du das mit einem Freund umsetzt, der sich auskennt.
Überlegungen 🤔
Grundsätzlich musst du dir Gedanken darüber machen, ob du überhaupt deine Dienste von extern erreichen willst. Falls nicht, ist das auch nicht schlimm, das machen wir alles später.
Bevor wir überhaupt etwas machen können, musst du prüfen, ob du eine statische oder dynamische IP-Adresse hast. Über diese IP wird dein Anschluss gekennzeichnet und wäre über diese IP auch dann später von extern nutzbar. Hast du keine externe IP oder läuft über einen Dual-Stack, wird das unterfangen natürlich etwas schwieriger.
Zudem brauchst du auch eine externe Domain, bei einem Hoster deiner Wahl. Ich selbst bin seit 2008 bei All-Inkl. und mit denen sehr zufrieden 👇
Führender Webhost & Provider für Domains, Homepage-Webspace (Domain-Webhosting) & Server (Server-Hosting, Managed Server). ALL-INKL - für Retail & Reseller!DynDNS (DDNS)
Damit dein Anschluss dann später auch über eine sprechende Domain erreichbar ist, musst du einen ein "DynDNS" anlegen. Prinzipiell ist "DynDNS" nicht anderes als ein Dienst, der deine aktuelle IP-Adresse an einen Dienst meldet und mit deiner Wahl-Domain verknüpft. Hierzu werde ich aber demnächst mal einen eigenen Artikel schreiben. Ich gehe erst einmal davon aus, dass das bei dir schon klappt und wir den Anschluss fiktiv über mydomain.dev erreichen können. Ein DynDNS arbeitet relativ simpel:
DNS-Änderungen
Bei deinem Domain-Hoster musst du nun deinen DNS konfigurieren, so dass alle Subdomains von *.mydomain.dev an deine DynDNS weitergeleitet werden. Hierfür muss dein Hoster es aber zulassen, dass du an deinem DNS-Server Änderungen vornehmen kannst/darfst.
⚠️
Ab hier ist absolute Vorsichtig geboten! Wenn du hier etwas Falsches machst, sind ggf. andere Domains nicht mehr erreichbar. Prüfe deine Daten mehrfach und versichere dich, dass alles korrekt ist.
Diese Umleitung können wir recht einfach über einen CNAME-Eintrag konfigurieren. Wichtig ist hier, dass du den CNAME als Wildcard angibst. Das hat den Vorteil, dass du bei neuen Subdomains nicht immer wieder den DNS-Server anpassen musst. Ein beispielhafter CNAME könnte so aussehen:
Name: *.mydomain.dev
Typ/Prio: CNAME / 0
Data: mydomain.dev
Damit würden nun alle Subdomains (also z.B. blog.mydomain.dev) auf mydomain.dev umgeleitet werden. Das die alle zusammengeführt werden, ist an der Stelle unproblematisch. Das brechen wir nachher im Reverse Proxy wieder auf.
Die Änderungen dauert bei öffentlichen DNS-Servern immer etwas, bis sie auf allen DNS-Server repliziert sind. Daher kann diese Änderung zwischen 1 Minute bis zu mehrere Stunden dauern. In der Regel geht das aber sehr schnell.
Mit dem CNAME-Lookup-Tool kannst du das dann entsprechend prüfen.
Reverse Proxy
Damit wir nun überhaupt irgendetwas tun können, müssen wir einen "Reverse Proxy" einrichten. Die Funktionsweise ist recht einfach erklärt. Alle Anfragen werden zentral an den Reverse Proxy weitergeleitet. Dieser entscheidet nach gewissen Kriterien, wohin er die Anfrage dann nun weiterleiten soll. Das kann z.B. über den Port passieren, das Protokoll oder über (Sub-)Domains. In unserem Falle konzentrieren wir uns auf den Domain-Teil. Als Reverse Proxy kann ich mit gutem Gewissen "Nginx Proxy Manager" empfehlen:
Docker container and built in Web Application for managing Nginx proxy hosts with a simple, powerful interface, providing free SSL support via Let’s EncryptDer Nginx Proxy Manager hat den ganz großen Vorteil, dass er für deine Subdomains auch direkt passende SSL-Zertifikate bereitstellen kann und, dass die die Zugriffe auf bestimmte Netzsegmente eingrenzen kannst. So kannst du z.B. den Service A so beschränken, dass er nur aus deinem lokalen Netz erreichbar ist, aber ein anderer Service Baus dem Internet.
Diesen Blog hier, hoste ich z.B. bei mir zuhause. Und so sieht meine Konfiguration im Nginx Proxy Manager dafür aus:
Heißt konkret, dass ich alle Anfragen der Domain blog.disane.devüber HTTP an die IP 192.168.8.5(mein DMZ-Netz) über den Port 2368erreichbar mache. Gleichzeitig habe ich auch noch ein SSL-Zertifikat erstellen lassen unter dem Reiter SSL:
Das kannst du natürlich auf einen Service deiner Wahl legen oder einfach erstmal was zum testen. Hier kannst du auch einfach einen kleinen Nginx Server nutzen.
Konfiguration des Routers
Damit dein Router nun auch mit externen Anfragen was anfangen kann, muss du die natürlich erst einmal weiterleiten. Das passiert mit dem Portforwarding. Hier empfehle ich, dass du Port 80 und 443. Port 80 brauchen wir für die Anfragen von Lets Encrypt, der damit die Valdierung für die SSL-Zertifikate ausführt.
Das Portforwarding sollte mit beiden Ports auf deinen Nginx Proxy Manager zeigen. Hier ist z.B. meine Konfiguration in meiner UDM-Pro:
Nicht wundern, das mit Port 8080und 4443ist schon richtig so. Ich habe nämlich den Nginx Proxy Manager auf meinem Server in einem Docker-Container laufen und dort beide Ports exposed. Nun würden alle Anfragen auf deine IP/DDNS gegen deinen Reverse Proxy laufen. Damit wärst du auch prinzipiell schon fertig wenn du nur Dienste von extern bereitstellen willst.
Externe Domains intern verfügbar machen
Jetzt wird es leider etwas wild. Was würde passieren wenn nun von intern deine Domain blog.mydomain.devaufrufen würdest? Wenn du Glück hast, geht deine Anfrage an deinen Router, der kann die Frage nicht beantworten und leitet sie an einen externen DNS-Server weiter. Irgendwann antwortet dein DNS-Server und sagt:
Ich kenne
blog.mydomain.dev, der zeigt doch über den CNAME auf mydomain.blog, der wiederum auf die IP1.1.1.1(nur als Beispiel) zeigt.
Siehst du das Problem? Genau, du gehst mit deiner Anfrage einmal aus dem Netz raus und dann wieder rein. Ebenso alle deine weiteren Anfragen. Ziemlich dämlich, wenn man dich alles schon intern direkt haben kann. Hat auch den Vorteil, dass wenn das Netz einmal ausfällt und du kein Internet mehr hast, du deine internen Dienste dennoch (gesichert über SSL) über die Domain aufrufen kannst. Und genau dafür brauchst du einen internen DNS-Server.
Interner DNS-Server
Damit das alles auch rein intern klappt, brauchst du einen internen DNS-Server. Ich habe mich hier für AdGuard-Home entschieden. Arbeitet ähnliche wie PiHole aber kann einiges mehr (dazu folgt auch bald ein Artikel). Er kann aber nicht nur Werbung filtern auf DNS-Level, sondern ist auch gleichzeitig ein DNS-Server. Sehr cool!
Network-wide ads & trackers blocking DNS server. Contribute to AdguardTeam/AdGuardHome development by creating an account on GitHub.Das klappt aber auch mit jedem anderen DNS-Server, der DNS Rewritesbeherrscht.
Im DNS-Server konfigurieren wir uns nun praktisch das selbe wie im externen Server. Nämlich, dass alle Anfragen der Wildcard-Domain *.mydomain.devauf deinen Reverse Proxy zeigen sollen). Bei mir sieht es z.B. so aus:
Hier kannst du aber auch z.B. für einfache Geräte spezielle Umleitungen einrichten.
Der Test
Unser Konstrukt kannst du nun einfach testen. Schau dir mal mit dem DNS-Lookup deine Domain an. Wir nehmen hier als Beispiel mal meine Blog-Subdomain. Der zeigt nun brav auf meine IP-Adresse:
Ich habe die ganz bewusst nicht geschwärzt, weil man sie ohnehin rausbekommt. Wenn du das nun mit deinem DynDNS gegenprüfst, sollte das zusammenpassen.
Das kannst du daran sehen, dass der A-Record von blog.disane.devauf meine IP zeigt. Das liegt daran, weil der CNAME nur ein Alias auf einen anderen Hostnamen ist, nämlich der deines DynDNS. Der DynDNS ist nämlich nichts anderes als ein variabler A-Record, der durch den Router immer wieder mit deiner IP gefüttert wird.
Prüfst du nun deine Subdomain von intern, solltest du nun auf deinem Reverse Proxy auflösen können:
Solltest du sehen, dass die Anfragen fälschlicherweise dein Netz verlassen, dann musst du die Konfiguration noch einmal nacharbeiten und prüfen, warum sie rausgehen. Sie sollten mit der Hilfe eigentlich in deinem Netz bleiben.
Die korrekte Umschreibung solltest du auch z.B. im AdGuard-Home sehen können.
Das Endergebnis
Das Endergebnis sollte nun wie folgt (schematisch) aussehen:
Wenn das alles klappt, hast du es nun geschafft, sowohl Dienste extern freizugeben über eine (Sub-)Domain, diese nach intern weiterzuleiten, einen Reverse Proxy aufgesetzt der die Anfragen verteilt und zusätzlich einen internen DNS-Server aufgesetzt, der interne Anfrage an die (Sub-)Domains auch intern beibehält. Zudem sind alle deine internen Dienste auch über den Nginx Proxy Manager nun auch via SSL gesichert. Cool oder?🎉
If you like my posts, it would be nice if you follow my Blog for more tech stuff.
Top comments (0)