Best Practice: AdGuard Home & unbound um Domain lokal aufzulösen

[shirocko]

Hallo zusammen,

ich habe mir jetzt auch mehrere Domains angelegt (CNAME Eintag auf die DynDNS Adresse), welche auf die DynDNS Adresse der Disk Station zeigen und dann per Reverse Proxy intern auf verschiedene Dienste zeigen. Intern werden die DNS Einträge dann umgeschrieben mittels Adguard auf interne IP Adressen.
Ich habe nun aber folgendes Problem.
Über die DynDNS Adresse läuft bei mir ein Nextcloud auf der Disk Station, welches von außen erreichbar sein soll.
Daher ist Port 443 geöffnet. Wenn ich nun die neuen Subdomains per Reverse Proxy einrichte, dann sind die Dienste, welche eigentlich nur intern laufen sollen plötzlich auch von extern erreichbar.

Beispiel:
nextcloud.abc.de zeigt direkt auf die Nextcloud Instanz auf der DS
paperless.abc.de zeigt auf die Paperless NGX Instanz
Paperless ist nun auch von außen erreichbar, was ich ja eigentlich gar nicht möchte.
Trotzdem würde ich gerne für alles Port 443 weiterhin nutzen, damit man nicht ständig den Port mit angegeben muss.
Dafür richte ich ja gerade die Domains ein, um mir das ganze Portweiterleiten und merken der Ports zu ersparen.

Hat jemand eine Idee, wie ich nextcloud erreichbar lasse von außen, aber paperless nur lokal erreichbar bleibt?

Danke shirocko

 

[alexhell]

Ich habe das folgendermaßen gelöst. *.example.de ist von außen erreichbar. Alles was nur intern erreichbar sein soll läuft unter *.intern.example.de. Mit der DNS Challenge (certbot oder acme.sh) kann man auch SSL Zertifikate bekommen für Domains die nicht öffentlich erreichbar sind. Die Domain für intern kann nämlich öffentlich nicht aufgelöst werden.

 

[plang.pl]

Man kann auch mit Zugangskontrollprofilen arbeiten. Im nginx RP heißen die "Access Lists"

 

[shirocko]

Ich habe das folgendermaßen gelöst. *.example.de ist von außen erreichbar. Alles was nur intern erreichbar sein soll läuft unter *.intern.example.de. Mit der DNS Challenge (certbot oder acme.sh) kann man auch SSL Zertifikate bekommen für Domains die nicht öffentlich erreichbar sind. Die Domain für intern kann nämlich öffentlich nicht aufgelöst werden.

Ich wollte eigentlich gerne für intern die Domains à la xyz.intern.example.de nutzen, allerdings klappt bei INWX bisher der passende DNS Eintrag nicht, obwohl es in einem Artikel so beschrieben wird.
Dort soll man einen CNAME mit * auf die DynDNS Domain setzen.
Wenn ich das mache, löst er aber nichts auf.
Nur wenn ich eine explizite Subdomain auf den CNAME der DynDNS Domain setze, dann löst er diese auf die IP des DynDNS Anschlusses auf, allerdings nicht unter
subdomain.intern.example.de, sondern unter subdomain.example.de
Es wird also eine Subdomain der Hauptdomain angelegt und nicht der DynDNS Subdomain.

Man kann auch mit Zugangskontrollprofilen arbeiten. Im nginx RP heißen die "Access Lists"

Das schau ich mir mal an. Vielen Dank erstmal.

 

[alexhell]

Die interne Domain soll ja auch gar nicht auflösen. Das macht dein interner DNS Server.
Ich kenne aber deinen Anbieter nicht und weiß daher nicht was er erlaubt oder nicht. Ich nutze die Nameserver von Cloudflare, wo die Domain liegt ist dann egal, und setze mit einem kleinen Docker Container den A Records für meine Domains direkt.

 

[shirocko]

Also ich habe jetzt beim DNS Anbieter nur die DynDNS Domain intern.example.de eingerichtet und die leitet normal auf die DS weiter, Port 443.
Dann habe ich über Adguard intern eine DNS Umschreibung von admin.intern.example.de auf die IP Adresse des internen Dienstes eingerichtet.
Im Reverse Proxy der DS habe ich dann die Domain admin.intern.example.de eingerichtet und auf den internen Dienst weiter geleitet.
Die DNS Auflösung intern klappt, von außen dann natürlich nicht erreichbar.
Aber wie schaffe ich es jetzt für die Subdomain ein gültiges LetsEncrypt Zertifikat zu bekommen?

Ich habe oben etwas von acme.sh gelesen oder ähnlich.
Hat jemand eventuell einen Link zu einem Tutorial, bevor ich nach dem falschen Inhalt google?

Danke

 

[alexhell]

https://github.com/acmesh-official/acme.sh/wiki/Synology-NAS-Guide
Oder falls du es als Docker laufen lassen willst https://hub.docker.com/r/neilpang/acme.sh
Oder einfach das Forum danach durchsuchen. Da gibt es auch viele Informationen.
Du musst aber gucken, ob dein Anbieter supported wird.

 

[*kw*]

Du musst aber gucken, ob dein Anbieter supported wird.

https://github.com/acmesh-official/acme.sh/wiki/dnsapi

Rechts das Menü erweitern, dann kommen diese Einträge

 

[shirocko]

Yay hat geklappt.
Habe nun acme.sh als Container auf der DS laufen und der hat das Wildcard Cert ausgestellt für *.abc.example.de
Nun wird auch der interne Dienst sauber mit validem Zertifikat aufgerufen und der Reverse Proxy funktioniert.
Und von außen erreicht man nichts davon.

Besten Dank an alle!

 

[Chipandchap]

Ich habe ein ähnliches "Problem" wie shirocko, ich verstehe die Lösung aber noch nicht ganz.
Ich benutze eine *.synology.me-Adresse um einige wenige Dienste wie Vaultwarden per reverse proxy von extern zu erreichen. Dazu nutze ich den Reverse-Proxy-Server der DS.
Adguard habe ich auch installiert und benutze es schon für Umschreibungen, damit z.B. *.example.synology.me direkt intern direkt lokal aufgelöst wird.

Ist es denn mit diesem Setup auf einfache Weise möglich, eine Subdomain von *.example.synology.me nur lokal verfügbar zu machen, inklusive Zertifikat, während andere Subdomains noch von extern erreichbar sind?

Ich jetzt mal ausprobiert, was passiert, wenn ich wie hier vorgeschlagen in der DS einen Reverse Proxy für z.B. paperless.intern.example.synology.me anlege. Dann passieren zwei Dinge: A) Die Seite hat kein Zertifikat und B) die Seite ist von extern erreichbar - dies erscheint mir auch irgendwie logisch, weil die DS versucht alles von extern über Port 443 aufzulösen.

In der Anleitung hier steht unter Schritt 1.2.1 "man kann (bei Bedarf) für internen und externen Zugriff die gleiche DDNS-Adresse nutzen" ist das nun möglich oder verstehe ich das falsch und diie gleiche DDNS-Adresse ist immer entweder komplett erreichbar oder eben nicht (wenn ich Port 443 nicht öffne)?

 

[alexhell]

Mit einer synology.me DDNS Adresse ist das nicht möglich. Du brauchst einen Anbieter, wo du die Records selber bearbeiten kannst. bei synology.me hast du nur die Wahl, dass es intern oder extern auflöst. Aber du kannst es nicht pro Subdomain setzen.
Du bräuchtest also entweder einen anderen Anbieter, der das unterstützt oder eine eigene Domain.

 

[Chipandchap]

Danke für die schnelle Antwort. Bei einem anderen Anbieter muss ich mich um das Zertifikat vermutlich wieder selbst kümmern, oder? Ist es auch möglich, mir für eine "lokale domain" (z.B. "paperless.lan" die per Umschreibung in AdGuard auf die DS zeigt) ein Zertifikat zu erstellen?

Was ist dafür die einfachste Lösung bzw. gibt es dafür auch eine Schritt-für-Schritt Anleitung wie hier?

 

[alexhell]

Ja bei einem anderen Anbieter wirst du dich um das Zertifikat selber kümmern müssen. Wobei mit https://www.duckdns.org müsstest du das Zertifikat auch von denen nutzen können. Da kann man auch Records anlegen, aber ich habe das nie probiert.
Du kannst kein offizielles Zertifikat für eine Domain bekommen, wo du nicht nachweisen kannst, dass es deine ist. Also entweder weil die Domain auf deinen Server auflöst oder aber falls nicht von außen erreichbar, dann über DNS Challenge. Da werden DNS Einträge angelegt und danach ausgelesen. Wie du siehst, geht beides nicht für interne Domains. Wie soll die CA auch sonst prüfen, dass es sich wirklich um den Server handelt und um einen der gerne ein Zertifikat für google.de hätte.....

 

[*kw*]

@Chipandchap: als kleine Randnotiz, am günstigsten kannst du das bei netcup.de umsetzen. Du kaufst im Angebot einfach nur eine Domain für 13 Cent (kein Webhosting-Paket!) und kannst es per acme.sh verlängern lassen, ohne einen Port öffnen zu müssen.

Adguard als internen DNS zum "Umbiegen" hast du bereits.

Edit: PS: wenn dir die regulären 0,42€ im Monat nicht zu viel sind, dann auch gleich.

 

[plang.pl]

Man kann aber im Reverse Proxy der DS auch Zugangskontrollprofile setzen, wo man festlegen kann, welche Quell Adressen den RP aufrufen dürfen. Wenn man da nur den internen Netzbereich reinnimmt, sind die von extern nicht erreichbar

 

[Chipandchap]

Vielen Dank plang.pl, dass klappt wunderbar.

Danke auch an *kw*, hätte nicht gedacht, dass eine eigene Domain so günstig ist, vielleicht beschäftige ich mich mal damit. Rein aus Interesse: Von dem Zugangsprofil mal abgesehen, auch die Domain von einem anderen Anbieter ist doch dann von Extern erreichbar, wenn ich ein Reverse Proxy dafür anlege und Port 443 dafür offen ist. Oder kann man das direkt beim Anbieter einstellen, dass die z.B. immer auf eine lokale IP zeigt?

 

[*kw*]

Du stellst ja im reverse proxy ein, welches Zertifikat für welchen Dienst (intern) genutzt wird.

 

[alexhell]

Mit acme.sh kannst du ein Zertifikat auch durch DNS Challenge bekommen. Es wird geprüft, ob die DNS Records gesetzt und ausgelesen werden können mit deinem Token/Zugangsdaten. Wenn dies er Fall ist, dann ist es ja deine Domain. Da ist es egal wo die Domain hinzeigt. Du musst nur intern einen DNS-Server haben, der deine Domain auf deine interne IP auflöst. Dann kannst du intern deine Domain nutzen und von außen kommt z.B. die standard "Hier entsteht eine Webseite" Meldung vom Hoster.

 

[Riyan17]

AdGuard Home paired with unbound is a best practice for local domain resolution. This powerful combination ensures efficient ad blocking and enhanced privacy by resolving domain names locally. By utilizing AdGuard Home's filtering capabilities alongside unbound's recursive DNS functionality, users can experience a faster and more secure browsing experience while maintaining control over their network traffic and protecting against unwanted content.