HTTPS im Heimnetzwerk, DNS?

Nilson schrieb:
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?


Nein, du hast keinen Denkfehler.

bei mir habe ich es mit mehreren virtuellen Maschinen gelöst, eine Diskstation oder Raspberry sollten es aber auch tun.

auf einer VM läuft ein DNS (Pi-Hole), der einige Geräte direkt auflöst (nas.domain.tld -> 10.0.0.2, v3.domain.tld -> 10.0.0.3, ...) und der den wildcard Eintrag an den NginX-Server weiterleitet (.domain.tld -> 10.0.0.99)

Der NginX-Server wiederum löst Dienste auf, die auf unterschiedlichen Servern laufen (dienst1.domain.tld -> https://dienst1.domain.tld -> 10.0.0.2:5001, dienst2.domain.tld -> https://dienst2.domain.tld -> 10.0.0.5:8083, ...). Auf dem NginX-Server ist auch gleichzeitig der Certbot Dienst, der das Wildcard-LE-Zertifikat anfragt und bekommt. Das wird ja auch "nur" für den reverse Proxy (NginX) für HTTPS benötigt.

die Namensauflösung der Geräte/Server, die der DNS Server macht, kennt ja keine Ports und kein SSL.

der Router gibt allen Geräten den internen DNS per DHCP als DNS mit.

Die Ports 80 und 443 müssen nur zum Zeitpunkt der Zertifikatserneuerung (aller 90Tage) auf den Server mit Certbot verweisen. Der rest verbleibt lokal.
 
Bob.Dig schrieb:
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...
Naja, UPnP kann da auch mit reinspielen. Bei UPnP erstellt der Router dynamisch Portweiterleitungen ohne Zutun des Nutzers.

Wie auch immer, ich denke meine Ausführungen haben klar gemacht, dass das Aufrufen der eigenen WAN-IP aus dem Netzwerk heraus deutlich komplizierter ist als man vermuten mag. Bei einem Consumer-Router, der unter Umständen sogar ab Werk mit aktiviertem UPnP unterwegs ist, fällt sowas nicht sofort auf - abgesehen davon, dass es hier im Forum schon den einen oder anderen Thread gab, in dem sich eben gerade über die Performance gewundert wurde (aus den genannten Gründen). Sophos ist zwar kein klassischer Consumer-Router, sondern geht in die semiprofessionelle Ecke, aber dann kommt es umso mehr auf die Konfiguration an, die wir hier nicht kennen.

Um all das muss man sich schlicht und ergreifend keinen Kopf machen, wenn man einen lokalen DNS einsetzt, der die WAN-IP gar nicht erst ins Spiel bringt ;)
 
UPnP würde ich immer, aus Sicherheitserwägungen, im Router deaktivieren.
 
  • Gefällt mir
Reaktionen: Raijin
ayngush schrieb:
UPnP würde ich immer, aus Sicherheitserwägungen, im Router deaktivieren.
Das unterschreibe ich sofort. UPnP ist eine reine Komfortfunktion, die völlig unbeobachtet im Hintergrund arbeitet und keinerlei Unterschied zwischen legitimer Software und Malware macht. Bei einer Spielkonsole (Xbox/PS) mag das Missbrauchspotential noch überschaubar sein - wenn man UPnP im Router auf bestimmte Geräte beschränken kann - aber bei einem PC ist das Sicherheitsrisiko immens hoch, weil jedes Stückchen Software munter Portweiterleitungen erstellen kann. Das zeigt sich zB darin, dass man die neue IP-Kamera wie durch Zauberhand ohne einen Finger krumm zu machen auch von unterwegs angucken kann ... hm.. wie das wohl funktioniert..... ;)

Komfort und Sicherheit sind gegenläufig. Je komfortabler etwas ist, desto unsicherer ist es in der Regel. Ich sag nur Keyless Entry bei Autos - auszuhebeln mit 08/15 WLAN-Routern und Laptop und ein bischen Software von .. .. .. bestimmten Internetseiten. Nicht ohne Grund ist es sehr "unkomfortabel" am Flughagen einzuchecken, weil man mehrere Checks über sich ergehen lassen muss (=sicher).




Was übrigens LE Zertifikate angeht, bin ich wiederum nicht so bewandert, weil das nicht so in meinen Bereich fällt. Folgende Aussagen sind daher mit Vorsicht zu genießen
Prinzipiell sollte es so sein, dass ein Zertifikat für eine Domain ausgestellt wird und diese auch im Common Name nach außen hin zeigt. Wenn man nun also computerbase.de im Browser aufruft, der Webserver zwar ein gültiges, von einer gemeinsamen offiziellen Zertifizierungsstelle signiertes, aber falsches Zertifikat zurückgibt (zB spiegel.de), spuckt der Browser einen Fehler aus, weil er eine MITM-Attacke vermutet - der Webserver ist also scheinbar nicht der, der er vorgibt zu sein (nämlich spiegel.de und eben nicht computerbase.de). Prinzipiell sollte es daher kein Problem sein, ein LE-Zertifikat auch lokal zu nutzen, wenn man einen lokalen DNS einsetzt. Der Browser stellt den DNS-Request zu blablubb.meinserver.dings.bums, bekommt eine lokale IP als Antwort, kontaktiert den Webserver unter der besagten lokalen IP und bekommt via https das passende, gültige Zertifikat zu blablubb.meinserver.dings.bums und ist zufrieden.

Allerdings kann ich nicht sagen wie genau der Prozess zur Generierung eines LE-Zertifikats abläuft, weil ich es offen gestanden noch nie ausprobiert habe. Was ich aber weiß ist, dass die LE-Zertifikate nur eine relativ kurze Gültigkeistsdauer haben (90 Tage, siehe @spcqike) und somit regelmäßig erneuert werden müssen, wobei es da wohl einen Certbot gibt, der das im Hintergrund automatisch übernehmen kann.


Wie bereits angedeutet bewege ich mich diesbezüglich jedoch auf dünnem Eis und sollte ich mich an einem Punkt (oder mehreren g) irren, bitte ich um Vergebung, aber auch um Korrektur! :daumen:
 
Raijin schrieb:
Allerdings kann ich nicht sagen wie genau der Prozess zur Generierung eines LE-Zertifikats abläuft, weil ich es offen gestanden noch nie ausprobiert habe. Was ich aber weiß ist, dass die LE-Zertifikate nur eine relativ kurze Gültigkeistsdauer haben (90 Tage, siehe @spcqike) und somit regelmäßig erneuert werden müssen, wobei es da wohl einen Certbot gibt, der das im Hintergrund automatisch übernehmen kann.

Zumindest bei Wildcard-Zertifikaten habe ich es mit meiner Strato-Domain noch nicht geschafft, dass er es automatisch macht. Dort gibt es leider keine Schnittstelle/API, sodass man die TXT Records manuell setzen muss. Zumindest habe ich noch keinen automatisierten Weg gefunden :)
 
Bei Bytecamp (mein Provider) habe ich einfach ein Skript geschrieben, welches via CURL-POST-Requests die Anmeldung am Benutzerportal vornimmt und dann den DNS-Eintrag entsprechend der Rückmeldung vom LE-ACME-Service setzt.

Hatte die bei Bytecamp auch gefragt, ob es dafür nicht auch eine API gäbe, sie meinten nein aber könnten mir auch gerne eine Zone als dynamisch definieren, sodass ich mittels eine privaten Schlüssels Einträge via Bind Utils von meiner Seite aus selbst hätte vornehmen können... Das war mir dann jedoch wieder zu kompliziert, weil ich das Skript für deren Portal schon fertig hatte :D
 
leute, ich habe einiges zu tun alle möglichkeiten zu prüfen! Danke euch für den Support.
Immerhin kann ich bei meiner domain den dns-txt ändern. mal sehen.....
 
Bob.Dig schrieb:
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?
Raijin schrieb:
Um all das muss man sich schlicht und ergreifend keinen Kopf machen, wenn man einen lokalen DNS einsetzt, der die WAN-IP gar nicht erst ins Spiel bringt ;)
Habe gerade das erste mal versucht, dem DNS-Server, der auf meinem Router(Merlin) läuft, die Auflösung beizubringen und es scheint geklappt zu haben. :)

Habe jetzt für 4 GB zwei Minuten gebraucht, was noch nicht super ist, aber immerhin doppelt so schnell wie vorher.

Aber unter meiner DDNS-Adresse zu hause lauschen mehr als ein Gerät, sprich z.B. mein Mail-Server (andere IP) kann jetzt von intern nicht mehr über die DDNS-Adresse abgerufen werden.
Dnsmasq kann vermutlich nicht auch Ports berücksichtigen bei der Auflösung? Mir war so hier gelesen zu haben, dass dies z.B. im Internet gemacht wird?!
 
Zuletzt bearbeitet:
Das ist natürlich eine weitere Ebene. Ein DNS kann leider nicht anhand der Ports unterscheiden, weil die Ports bei ihm ja gar nicht vorbeikommen. Bei DNS wird ausschließlich die Domain aufgelöst, nicht jedoch Dinge wie Port oder zB Pfade im Browser. computerbase.de --> a.b.c.d, egal ob man nach der DNS-Auflösung dann a.b.c.d:x oder :y aufruft, interessiert den DNS nicht und er bekommt es auch gar nicht mit, weil DNS = Domain only.

Wenn du von außen über denselben DDNS-Eintrag via Portweiterleitungen verschiedene Server bedienst, ist es mit einem lokalen DNS also nicht getan. Da bleibt dir nur die vorherige Lösung über NAT-Loopback, die aus den genannten Gründen gewisse Nachteile mit sich bringt, oder du replizierst die Portweiterleitungen ebenfalla lokal, zB über einen Proxy. Damit schickst du dann LAN-internen Traffic unter Umständen wieder quer durch die Gegend (PC - Proxy - Server1/2/x), aber immerhin wird die NAT-Engine des Routers nicht zu stark belastet.

Alternativ kann man sonst zB auch manuell über fiktive, lokale Subdomains der DDNS-Domain verschiedene Einträge im DNS generieren, die dann jeweils zum richtigen Server zeigen. Dann kann man aber die Server sogesehen auch direkt mit ihren lokalen Namen ansprechen, ist im Prinzip nix anderes. Man muss also in diesem Fall wieder zurück zu lokalen Verbindungsnamen vs extern wie lokal = DDNS.
 
  • Gefällt mir
Reaktionen: Bob.Dig
Raijin schrieb:
Alternativ kann man sonst zB auch manuell über fiktive, lokale Subdomains der DDNS-Domain verschiedene Einträge im DNS generieren, die dann jeweils zum richtigen Server zeigen. Dann kann man aber die Server sogesehen auch direkt mit ihren lokalen Namen ansprechen, ist im Prinzip nix anderes. Man muss also in diesem Fall wieder zurück zu lokalen Verbindungsnamen vs extern wie lokal = DDNS.
Coole Idee, gleich mal ausprobieren.
Ginge das auch fürs Smartphone, was sich sowohl innerhalb als auch außerhalb des LAN befinden kann?
Ergänzung ()

@Raijin Jetzt verschluckt es sich aber wieder am LE-Zertifikat, welches wohl bei mir nicht für Subdomains zugelassen ist. 😉
Hätte ich aber die Kontrolle über einen Domain-Namen, könnte ich mir wohl ein entsprechendes Wildcard-LE-Zertifikat ausstellen lassen und die Sache würde funktionieren.
 
Zuletzt bearbeitet:
Hehe, von einem Problem zum nächsten ;)

Was das Smartphone von außerhalb angeht: Jein. Wenn dein DDNS auch Subdomains erlaubt, würde es auch von unterwegs funktionieren, wenn du für jeden lokalen DNS-Eintrag mit Subdomain einen entsprechenden Eintrag beim DDNS hättest. Damit habe ich mich offen gestanden noch nie beschäftigt. Theoretisch ginge das problemlos, aber die Frage ist ob der DDNS-Provider das so überhaupt anbietet. Zur Not mehrere DDNS? Das wäre aber eine ziemliche Krücke... Wie gesagt, DNS ist nicht auf unterschiedliche Ports ausgelegt.

Es gibt zwar im DNS-Protokoll auch SRV-Einträge, die tatsächlich verschiedene Ports erlauben würden, aber das muss der Client so auch unterstützen, weil explizit die SRV-Einträge via DNS abgefragt und ausgewertet werden müssen. Wenn du also beispielsweise zwei Webserver auf zwei getrennten Maschinen laufen hast und von außen Port 80 bzw. 8080 dorthin weiterleitest, kannst du das von innen mit einem Standard-DNS-Eintrag so natürlich nicht nachbilden, weil eine 08/15 DNS-Abfrage lediglich den A-Record abfragt, also nur die IP zu einer Domain. Du müsstest nun aber SRV-Records haben, die dann gezielt abgefragt werden können, um dann je nach srv-tag eben IP A oder IP B zurückzugeben.


Zertifikate sind natürlich auch ein Problem, klar. Vermutlich wäre es am Ende am "einfachsten", wenn du zB einen Raspberry PI als Proxy einsetzt und dann den lokalen DNS-Eintrag auf den PI zeigen lässt, der dann wiederum den eingehenden Traffic je nach Port an den betreffenden Server weiterleitet. Wie gesagt, im worst case schickst du den Traffic dann auch wieder quer durch die Bude (zB vom Dachgeschoss in den Keller zum PI, der dann alles wieder ins Dachgeschoss zum NAS leitet), aber einen Tod muss man dann sterben, wenn man uuuuunbedingt die DDNS-Domain von außen wie von innen nutzen will - ich persönlich mache das übrigens ganz einfach extern über DDNS und lokal eben .. .. lokal über den Servernamen. Ich habe kein Problem damit außen/innen verschiedene Ziele ansteuern zu müssen.
 
  • Gefällt mir
Reaktionen: Bob.Dig
Verschiedene DDNS, für jeden Server einen, auch genial. Ich wäre allerdings mit der jeweiligen LE-Zertifikat-Erstellung überfordert. Wird Zeit, dass ich mir mal ne eigene Domain zulege.

Einen Proxy könnte ich auch woanders aufsetzen, dessen Konfig dürfte mich aber ebenfalls überfordern. ;)
 
Bob.Dig schrieb:
Verschiedene DDNS, für jeden Server einen, auch genial.
Absolut nicht. Von außen (also in public DNS) würden die ja alle auf dieselbe IP zeigen (wenn man nicht wie angesprochen SRV-Records nutzt bzw. nutzen kann). nas.deineddnsdomain, mail.deineddnsdomain, kamera.deineddnsdomain und auch deineddnsdomain würden alle auf deine öffentliche IP zeigen. Von innen würdest du im lokalen DNS dann aber nas.deineddnsdomain auf die NAS-IP zeigen lassen, während mail.deineddnsdomain lokal auf die IP vom Mailserver zeigt, etc.. Ob das aber so der wahre Sack der Zwerge ist, sei mal dahingestellt...

Das Problem ist einfach, dass von außen und von innen zwei verschiedene Situationen gegeben sind, die nicht so einfach unter einen Hut zu bringen sind. Von außen siehst du ja nur eine Ziel-IP, quasi nur einen "Server", während du von innen jeden Server einzeln siehst. Zwei Paar Schuhe, die nicht so ohne weiteres vereinbar sind.

Nu wird's aber zu OffTopic, weil das so ja gar nicht vom TE gefordert war.
 
  • Gefällt mir
Reaktionen: Bob.Dig
Raijin schrieb:
Absolut nicht. Von außen (also in public DNS) würden die ja alle auf dieselbe IP zeigen (wenn man nicht wie angesprochen SRV-Records nutzt bzw. nutzen kann). nas.deineddnsdomain, mail.deineddnsdomain, kamera.deineddnsdomain und auch deineddnsdomain würden alle auf deine öffentliche IP zeigen.
Das würde aber nur für v4 gelten, v6 würde erst recht von der Namensauflösung profitieren. Ich bleib dabei, das ist eine super Idee. ;)
 
Habe das jetzt mal so umgesetzt für IPv4, ein paar Subdomains extern kreiert und diese ebenfalls in den internen DNS eingetragen, läuft gut. Keine Zertifikatsfragen mehr dank Wildcard-Cert und immer direkt verbunden. 😁
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Raijin
Zurück
Oben