Interne Services mit externer DNS-Wildcard erreichen

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 ­čÄë

Interne Services mit externer DNS-Wildcard erreichen
Photo by Jan Huber / Unsplash

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 ­čĹç

Domains, Webspace, Domain Webhosting, Server-Hosting Provider ALL-INKL
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:

Nginx Proxy Manager
Docker container and built in Web Application for managing Nginx proxy hosts with a simple, powerful interface, providing free SSL support via LetÔÇÖs Encrypt

Der 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 IP 1.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!

Docker
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?­čÄë