HTTPS im Heimnetzwerk, DNS?

empy

Ensign
Registriert
Dez. 2015
Beiträge
253
Hi das Forum,

ich brauche in dieser Sache etwas Schützenhilfe, da ich nicht weiß, wo wirklich anfangen. Habe im Forum nicht das passende gefunden, bzw. wenn vorhanden es nicht erkannt.

Worum gehts?
Mein Heimnetzwerk hängt hinter einer Sophos XG mit Home Lizenz als Router/Gateway. Nun möchte ich in meinem Heimnetzwerk die einzelnen Dienste (Access Point Verwaltung & Hotspot, Managed Switch, Synology, etc) auch per https nutzen können. Bisher habe ich immer das self-signed certificate der jeweiligen Dienste genutzt und akzeptiert bzw es in den trusted-bereich der browser / betriebssysteme geschoben.
Bei neuen Geräten ist dies immer wieder ein Problem und ich möchte gerne ein "offizielles" Zertifikat nutzen im LAN, gerne auch Lets Encrypt. Vor allem für meinen Guest-WLAN-Hotspot ist das einspielen mit dem self-signed Zertifikate ein großen Thema bei Besuch.

Frage:
Ich habe gelesen wie das mit Lets Encrypt funktioniert, meine Synology hätte beispielsweise auch eine Funktion dafür. Ich scheitere aber an den Basics:
Zum einen möchte ich mein LAN vom Internet aus NICHT erreichbar haben. Das ist alles per Firewall blockiert. Temporär würde ich natürlich öffnen, aber ungern dauerhaft auf Port 80 etc für alle diese Dienste die ein https bräuchten. Zum anderen weiß ich nicht, wie es im LAN wirklich mit dem DNS funktioniert und wie das zusammenhängt. Momentan surfe ich meine Dienste immer direkt mit IP an.
Ich habe eine im Internet erreichbare Domain. Hilft mir das dabei? Irgendwie mit lan1.domain.de, lan2.domain.de? Kann ich diese Nutzen? Mit einem Wildcard? Und wie kennt ein Zertifikatsaussteller meine Local-DNS einträge, welche ich bestimmt irgendwie im Sophos anlegen kann?

Könnt ihr mir bisschen Starthilfe geben? Oder ein Verweis auf eine gute Quelle?
Ich danke euch :)
 
bei lets encrypt muss der cert bot ins internet kommen und du brauchst ein gültigen domain namen wo das ganze validiert werden kann.

du kannst auch ein zert kaufen, dazu brauchst du aber auch einen gültigen domain namen.
dann richtest du intern einen split dns ein und gibts allen deinen geräten echte dns namen im internen
 
Also ich würde es so machen:

Die Sophos spielt Reverse Proxy und nimmt Verbindungen auf Port 80 und 443 entgegen (Internet und Lokal). 80 wird auf 443 umgeschrieben. Let's Encrypt dann auch auf der Sophos für die Domains. Dann je nach aufgerufener Subdomain werden die Dienste im Hintergrund angesprochen, also bspw. www.domain.tld geht zum Webserver, cloud.domain.tld geht zu deiner Nextcloud/Owncloud usw.
Das ist meiner Meinung nach das einfachste und eleganteste Vorgehen bei nur einer öffentlichen IP

Intern hättest du dann 2 Möglichkeiten:
Du sprichst die Dienste direkt an oder du gehst auch über die Sophos. Der Weg über die Sophos bedeutet unnötigen Traffic, dafür hast du aber Let's Encrypt Zertifikate. Bei den Diensten direkt würd ich nämlich auf Self-Signed setzen (oder sowas wie CACert)

Die Sophos kann dann auch sicherlich DNS spielen, da kannst du dann deine internen Aurufe hinterlegen, dann verbinden sich deine Geräte nämlich immer über den gleichen Aufruf, egal ob du von außerhalb oder innerhalb daher kommst
Die öffentlichen DNS-Einträge müssen dann natürlich auf die öffentliche IP der Sophos zeigen
 
Es gibt quasi nur die Möglichkeit Lets Encrypt zu nutzen, außer man will für (Wildcard) Zertifikate blechen im eigenen LAN... Der Hinweis auf CACert ist zwar nett gemeint, aber keiner vertraut denen. Da kann ich auch self-signed Certs deployen und bin weitaus flexibler.

Domain kaufen und die DNS Records auf private IPs im LAN verweisen lassen. Heißt dann aber natürlich, dass Traffic nach außen geht.

Aber: Warum im eigenen LAN verschlüsseln? Ist ja kein Rechenzentrum.
 
So ganz habe ich es noch nicht verstanden. Ich habe die domain www.domain.de. Dort kann ich Subdomains anlegen und auf IPs verteilen. Soweit richtig? Diese IP ist die meines Sophos. Da sie sich ändert und nicht statisch ist, benötige ich DynDNS? Und jetzt muss ich das per Portweiterleitung weiterleiten auf meine Internen Dienste/Server?

Beispiel Synology: Wie macht das die NAS? Wenn ihr der Port 80 freigebe, welche Domain nimmt die? Wie funktioniert das?

Ich möchte eigentlich nur die lästigen Browser-Meldungen wegbekommen. Sollte ich in der Sophos mich entscheiden, die SSL Inspektion anzuschalten (für allem um Spam-Mails feiner wegzubekommen) hätte ich gern ein ordentliches Zertifikat, sonst verwirrt die weiblichen Teilnehmer in meinem Netzwerk.. ;) Und auch für die WLAN-Hotspot-Login-Seite.
Unter Android steht beispielsweise "Das Netzwerk wird möglichweise überwacht" nachdem ich das selbst signierte Zertifkat ins Handy importiert habe. Leider auch, wenn ich nicht im LAN bin, sondern auch über LTE.
 
empy schrieb:
Zum einen möchte ich mein LAN vom Internet aus NICHT erreichbar haben.

Und warum denkst du dass das nötig ist?

empy schrieb:
Zum anderen weiß ich nicht, wie es im LAN wirklich mit dem DNS funktioniert und wie das zusammenhängt. Momentan surfe ich meine Dienste immer direkt mit IP an.

Dann wird das natürlich nichts mit den Zertifikaten. Entweder irgendein DNS-Server (intern oder extern) löst die Namen auf oder du setzt auf deinen Geräte lokale Host-Einträge.

empy schrieb:
Ich habe eine im Internet erreichbare Domain. Hilft mir das dabei? Irgendwie mit lan1.domain.de, lan2.domain.de? Kann ich diese Nutzen? Mit einem Wildcard?

Sollte gehen die öffentlichen DNS-Einträge auf private IP-Adressen aufzulösen. Aber warum ein Wildcard? Dann würden ja alle Subdomains auf die gleiche IP-Adresse auflösen? Das willst du doch nicht.

empy schrieb:
Oder ein Verweis auf eine gute Quelle?

Puh... Zu welchem Thema genau? Das ist ja ein breites Feld an Basics die hier benötigt werden.

Edit:

empy schrieb:
So ganz habe ich es noch nicht verstanden. Ich habe die domain www.domain.de. Dort kann ich Subdomains anlegen und auf IPs verteilen. Soweit richtig? Diese IP ist die meines Sophos. Da sie sich ändert und nicht statisch ist, benötige ich DynDNS? Und jetzt muss ich das per Portweiterleitung weiterleiten auf meine Internen Dienste/Server?

Ich dachte du willst die Geräte/Dienst nur innerhalb des Heimnetzes nutzen!? Zusätzlich hast du geschrieben, dass du die Geräte nicht vom Internet aus erreichbar haben möchtest!? Ich komm nicht mehr mit...
 
kurz um:

ja, die externe Domain brauchst du.
Port 80 und 443 müssen für die Erstellung des Wildcardzertifikats (*.domain.de) auf deinen Zertifikatsserver verweisen.
Nach erfolgreich erstelltem Wildcardzertifikat kannst du die Ports wieder schließen. Das Zertifikat benötigt dein reverse Proxy (nginx, geht auch mit ner Diskstation). Der Proxy muss in deinem DNS Server für die interne Auflösung aller Subdomains (oder für die Wildcard) herangezogen werden.

Der Proxy löst dann deine Subdomains entsprechend auf. sub1.domaine.de -> 192.168.xx.xy:xz

Das Ganze sollte alles mit der Diskstation gehen. Solange sie auch der DNS Server ist oder du deinem DNS Server sagen kannst, dass die eigenen Domain eben dort aufgelöst werden soll.
 
Du willst das ganze doch nur lokal nutzen.
Spar dir Let's Encrypt und setz dir eine eigene kleine lokale CA auf, von der du Zertifikate beziehst. Das Root-Cert packste einmal an alle relevanten Stellen und kannst dann bequem komplett offline agieren.
Machen wirs mal richtig kurz um :).
 
wirelessy schrieb:
Du willst das ganze doch nur lokal nutzen.
Spar dir Let's Encrypt und setz dir eine eigene kleine lokale CA auf, von der du Zertifikate beziehst. Das Root-Cert packste einmal an alle relevanten Stellen und kannst dann bequem komplett offline agieren.
Machen wirs mal richtig kurz um :).

zumindest spart man sich damit das 90-tägige , manuelle erneuern des Wildcardzertifikats :) Zumindest muss ich dies aktuell so machen, da ich die TXT Einträge bei Strato nicht automatisch setzen lassen kann :(
 
wirelessy schrieb:
Du willst das ganze doch nur lokal nutzen.
Spar dir Let's Encrypt und setz dir eine eigene kleine lokale CA auf, von der du Zertifikate beziehst. Das Root-Cert packste einmal an alle relevanten Stellen und kannst dann bequem komplett offline agieren.
Machen wirs mal richtig kurz um :).
Hast du dafür mal ein gutes Tutorial? Wollte das schon immer mal ausprobieren bin aber immer irgendwo gescheitert...
 
Nur meinen Kopf, sorry.

Hängt auch davon ab, welche Software man dafür nutzen will. Ich mag Microsoft CAs, aber da hab ich halt auch überwiegend mit gearbeitet.
OpenSSL wäre die Alternative dazu, falls man keine Windows Server Lizenz hat.
 
wirelessy schrieb:
Du willst das ganze doch nur lokal nutzen.
Spar dir Let's Encrypt und setz dir eine eigene kleine lokale CA auf, von der du Zertifikate beziehst. Das Root-Cert packste einmal an alle relevanten Stellen und kannst dann bequem komplett offline agieren.
Machen wirs mal richtig kurz um :).

Hauptziel ist es eigentlich, die SSL-Meldung wegzukriegen, ohne jedem Besucher sagen zu müssen: Klick auf "Ausnahme akzeptieren". Das ist unseriös und erzieht meiner Meinung nach die Leute falsch. Und das alles ohne Verbindung der internen Seiten ins Internet. Nur normales surfen die Clients ist gewünscht.

Dann informiere ich mich mal über lokale CAs.
 
Mit ner lokalen CA bist du das Problem auch nicht per se los. Du musst das Stammzertifikat deiner lokalen CA dann trotzdem verteilen, der wird ja nicht automatisch vertraut.
 
Wo müsste denn eigentlich die "Intelligenz" sitzen, die zwar auf die Verbindung von außen wartet, dann nach Aufbau aber auf die interne IP umleitet (fragt sich ein Netzwerknoob). Ist das technisch ausgeschlossen oder möglich um eben doch das LE-Zertifikat auch für interne Verbindungen zu nutzen?

Wie sähe es bei IPv6 aus, wenn jeder Server/Service von außen erreichbar wäre und sein eigenes LE-Zertifikat hätte.
Ergänzung ()

Habe gerade mal was getestet, habe ein 4 GB große Datei auf meine eigene Nextcloud, die sich in meinem LAN befindet, geschoben, über den Web-Browser mit LE-Zertifikat und DDNS-Adresse (IPv4, DDNS-Client ist nicht der Router). Das Ganze hat etwas über 4 Minuten gedauert. Bei einem Upload von max. 8 Mbit/s ins WAN kann es doch unmöglich übers WAN gegangen sein, sprich hier wird intelligent umgeschaltet?
 
Zuletzt bearbeitet von einem Moderator:
Hm? Dein Router kriegt das Paket auf die öffentliche IP. Dein Router denkt sich dann: Warte, die IP ist ja meine.
Wieso sollte er das Paket dann ins WAN routen, wenn das Ziel bei ihm im LAN sitzt?

Hier wird nichts intelligent umgeschaltet. Der Traffic geht über den Router, und der routet halt entsprechend seiner Routingtabelle.
 
  • Gefällt mir
Reaktionen: Bob.Dig
Warum sollte es auch ins WAN gehen? Der Router erkennt, dass die Datei ins eigene Netzt soll und routet die entsprechend.

Ich finde die Idee über einen lokal DNS ganz gut. Du holst dir ein Wildcard Certificate und ein lokaler DNS gibt dir dann die passende lokale IP.
Browser ist zufrieden, weil du hast ja ein gültiges Zertifikat von einer offiziellen Stelle mit *.domain.tld und dein lokaler DNS gibt dir dann für sub1.domain.tld die 10.10.10.1 und für sub2.domain.tld die 10.10.10.2 etc.
Oder hab ich jetzt ein Denkfehler?
@Raijin was sagst du dazu, du kennst dich doch mit solchen Fragen aus?
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: wirelessy
Allerdings muss man eines bedenken:

Wenn man vom eigenen Netzwerk aus die eigene WAN-IP anspricht - ob nu über eine DDNS-Domain oder auch direkt - dann merkt der Router das üblicherweise im allerletzten Moment und dreht dann den Traffic um 180° um. Das heißt, dass die Daten trotzdem am WAN-Port "reinkommen", wenngleich sie ja nie "draußen" waren. Im worst case bedeutet das also, dass ein potentiell langsamer Router mit eingeschränkter WAN-LAN Routing-/Firewall-Performance so eine Verbindung negativ beeinflussen kann, weil er nicht mit vollen 1 Gbit/s durchreichen kann. Genau genommen nimmt der Traffic dabei auch die komplette NAT-Pipeline mit, es werden also ggfs Portweiterleitungen benötigt, auch wenn man sie nur lokal ansteuert.
Stichwort: NAT-Loopback

Wenn jedoch ein lokaler DNS die DDNS-Domain (oder welche Domain auch immer) eben nicht mit der WAN-IP , sondern mit der lokalen IP beantwortet, dann bleibt der Traffic 100% lokal, weil er direkt von der LAN-Quelle zum LAN-Ziel geht und der Router davon abgesehen vom initialen DNS-Request nichts mehr mitbekommt - höchstens, wenn die Daten über seinen internen Switch gehen, aber wenn Quelle und Ziel am selben anderen Switch hängen, sieht der Router sogar kein einziges Bit von der Verbindung.

Ich rate daher immer zur letzteren Lösung, weil sie gewissermaßen die organischste Variante darstellt. Das einzige was sich von einer direkten Verbindung via lokaler IP unterscheidet ist der anfängliche DNS-Request, der die DDNS-Domain lokal auflöst und eben nicht auf die WAN-IP zeigt und die NAT-Performance des Routers potentiell ausreizt.
Ergänzung ()

Um das mal in beispielhaften Zahlen auszudrücken:

Router = 08/15 30€-Kiste mit max 100 Mbit/s WAN<>LAN Performance (man hat ja zB nur VDSL25, reicht ja)

Lokaler Download vom NAS via DDNS mit oben beschriebenem NAT-Loopback, also WAN-IP.
>Maximaler Download PC<>NAS = 100 Mbit/s = 12,5 MByte/s , weil dem Router beim WAN2LAN-NAT einfach die Puste ausgeht.

Selbes Szenario, aber mit lokalem DNS (=DDNS ---> aufgelöst auf lokale IP).
>Maximaler Download PC<>NAS = 1 Gbit/s = 125 MByte/s, weil der Router den Traffic höchstens an seinem internen Gigabit-Switch vorbeiziehen sieht.

Bei einem schnellen Router, der auch am WAN 1 Gbit/s schafft, merkt man zwar keinen Performance-Unterschied, aber wenn parallel die Internetleitung belastet wird, kann das die vermeintlich lokale Übertragungsrate PC<<NAS eben doch einschränken (zB ein großer Download mit 250 Mbit/s). Auch muss man sich vor Augen führen, dass zB bei einem 3-stöckigen Haus (Router = Keller, PC+NAS nebeneinander am selben Switch im 2. OG) die Daten erstmal vom PC bis in den Keller gehen, um dann vom Keller wieder ins 2. OG zu laufen, um dann am NAS anzukommen - die Antwort nimmt den umgekehrten Weg - das gilt für alle Pakete der Verbindung, jedes Bit, jedes Byte. Man pumpt also Gigabyte an Daten quer durch das Haus obwohl PC und NAS nebeneinander stehen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: snaxilian, Bob.Dig, Nilson und eine weitere Person
@Raijin
Aber wieso geht das wie bei mir nicht auch automatisch beim TE, weil bei ihm die Ports nicht geöffnet sind? Wenn er nun mehrere verschiedene Web-Dienste so aufrufen wollte dürfte das ja eh nicht per IPv4 gehen...
Und zu zweitem, ist das in einem IPv4 NAT-Szenario mit LE-Zertifikat so einfach möglich ?
 
Zuletzt bearbeitet von einem Moderator:
Also ich erzeuge mein Lets Encrypt Wildcard-TLS-Zertifikat für interne Dienste (Router-Webinterface, Unifi-Controller, diverse interne Web-Services, Heimautomatisierung-Services wie Homekit HomeMatic Homebridge, usw.) für *.home.<meinetolledomain>.de ohne, dass irgendwas vom LAN im Internet erreichbar sein muss. Man braucht dafür jedoch eine eigene Domain und die Möglichkeit beim Provider TXT-Einträge im, für die Domain öffentlich registrierten, DNS einzurichten und zu ändern. Dann läuft der LE-Validierungsprozess nämlich darüber ab und ich muss keine Services von innen nach außen freigeben.

Der Interne DNS für die internen Namen ist bei mir einfach ein dnsmasq ein einer Debian VM mit der Suchadresse home.<meinetolledomain>.de und in der /etc/hosts sind die Einträge in der Form

10.2.3.100 router.home.<...>.de router
10.2.3.110 service1.home.<...>.de service1
10.2.3.120 servicexyz.home.<...>.de servicexyz

usw. eingetragen.

Meine gesamte DNS-Konfiguration sieht so aus:

DHCP macht bei mir Pi-Hole und liefert sich dabei selber als DNS für die Clients aus. Der macht einen DNS-Forward auf internen dnsmaq-DNS und kennt die Suchdomain home.<...>.de und weiß, dass der dnsmasq-Server dafür zuständig ist (kann man so in der Konfiguration angeben).

Der interne dnsmasq-DNS macht ein Forward auf einen öffentlichen DNS (Cloudflare, Google, Quad9, CCC, ...).

Meine Fritzbox hat als DNS-Weiterleitungsziel meinen Pi-Hole-Server eingetragen und macht (eigentlich) kein DNS, bis auf eine Ausnahme.
Diese Config brauche ich, damit mein Smartphone über VPN vom Pi-Hole profitiert, da das sonst nicht funktioniert, da die Fritzbox der internen VPN-IP zwingend sich selber als DNS zuweist.
In der Fritzbox muss dann noch der DNS-Rebind Schutz für router.home.<...>.de eingetragen werden, sonst kann man die Oberfläche so nicht aufrufen oder müsste "fritz.box" als auch DNS-Record im dnsmasq anlegen, was ich jedoch nicht empfehlen würde... ich warte nämlich nur auf dem Tag, wo sich jemand fritz.box krallt: https://www.heise.de/newsticker/mel...ringt-manche-Netze-durcheinander-3491185.html

Auf Rechnern, wo ich keinen Pi-Hole Werbeblocker haben möchte, trage ich den internen dnsmasq-DNS nebst statischer IP manuell ein.

Für die Lets Encrypt Geschichte nutze ich einen LE-Client, der die DNS-Validierung für Wildcard-Zertifikate beherrscht und lasse den im Cron-Job zusammen mit einem Skript laufen, das bei meinen Provider die DNS-Einstellungen automatisch setzt.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Bob.Dig
wirelessy schrieb:
Hm? Dein Router kriegt das Paket auf die öffentliche IP. Dein Router denkt sich dann: Warte, die IP ist ja meine.
Wieso sollte er das Paket dann ins WAN routen, wenn das Ziel bei ihm im LAN sitzt?
Sag ja, bin Netzwerknoob. Mein Router kennt die WAN-IP übrigens nicht wirklich, zumindest kann er sie nicht anzeigen, es wird eine andere IP angezeigt, weil eine Art von CG-NAT bei meinem ISP gefahren wird, Ports etc. kann ich trotzdem öffnen.
 
Zuletzt bearbeitet von einem Moderator:
Zurück
Oben