6
Strategie bei Subdomain, FQDN, Hostnamen im Netzwerk
Hallo zusammen.
Ich hadere gerade an der Benennung meiner Rechner im Heimnetz und hätte gerne eure Meinung dazu.
Folgende Ausgangssituation habe ich hier:
Zu Beginn habe ich meine Geräte zuhause alle in einer frei erfundenen Domain betrieben: zurhorst.baerl
Die Server hießen dann entsprechend: adguardhome.zurhorst.baerl, bitwarden.zurhorst.baerl, usw.
Nun war ich unsicher, ob das schlau ist, und ich habe alles umbenannt, damit sie einen einheitlichen Muster folgen:
Mein Dilemma:
Eine "Strategie" setzt ja erst mal Wissen voraus. Ich habe aber absolut keine Ahnung, ob ich da überhaupt etwas beachten muss.
Im Netzwerk zuhause sind meine Rechner in beiden Fällen über nur den Hostnamen erreichbar, da macht es also keinen Unterschied.
Ein Bündel Fragen wäre:
Was mein ihr dazu?
Vielen Dank und Grüße,
Marcus
Ich hadere gerade an der Benennung meiner Rechner im Heimnetz und hätte gerne eure Meinung dazu.
Folgende Ausgangssituation habe ich hier:
- Domain und Webhosting vorhanden bei Netcup. (meindomain.de)
- Dort wird nur Nextcloud gehostet unter einer Subdomain (cloud.meinedomain.de)
- Zuhause verteilt eine OPNsense meinen Internetzugang auf verschiedene VLANs (Privat, Arbeit, Kinder, Gäste, ...)
- ich habe ein paar Debian VMs in Proxmox laufen für verschiedene Dienste
- Zwei dieser Dienste sollen aus dem Internet erreichbar sein (Bitwarden, Homeassistant)
- und ich hätte gerne Letsencrpyt SSL-Zertifikate
Zu Beginn habe ich meine Geräte zuhause alle in einer frei erfundenen Domain betrieben: zurhorst.baerl
Die Server hießen dann entsprechend: adguardhome.zurhorst.baerl, bitwarden.zurhorst.baerl, usw.
Nun war ich unsicher, ob das schlau ist, und ich habe alles umbenannt, damit sie einen einheitlichen Muster folgen:
- Subdomain angelegt: baerl.meinedomain.de
- Für diese Domain eine CNAME-Weiterleitung auf DuckDNS eingerichtet
- Server umbenannt zu z.B. homeassistant.baerl.meinedomain.de
Mein Dilemma:
Eine "Strategie" setzt ja erst mal Wissen voraus. Ich habe aber absolut keine Ahnung, ob ich da überhaupt etwas beachten muss.
Im Netzwerk zuhause sind meine Rechner in beiden Fällen über nur den Hostnamen erreichbar, da macht es also keinen Unterschied.
Ein Bündel Fragen wäre:
- Ist es sinnvoll, ein einheitliches Benennungsmuster für ausschließlich interne sowie von außen erreichbare Server zu nutzen?
- Ist die Benennung relevant, wenn ich Letsencrypt einrichten möchte?
- Ist den Zertifikat egal, ob es für ein Endgerät, oder für eine "Subsubdomain" ausgestellt wird?
Was mein ihr dazu?
Vielen Dank und Grüße,
Marcus
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 3634910971
Url: https://administrator.de/contentid/3634910971
Ausgedruckt am: 22.11.2024 um 05:11 Uhr
6 Kommentare
Neuester Kommentar
Wenn's anfängt, unübersichtlich zu werden, was von Außen und was nur intern erreichbar ist, würde ich die Hostnamen entsprechend anpassen, also für die internen Hosts sowas wie ".loc" anhängen.
"Sicherheitstechnisch" ist es ratsam, ALLE Rechner quasi wie in einer DMZ zu betreiben, aber nur mit interner IP-Adresse und internem Zugriff. Die Hostnamen würden dann nach o.g. Beispiel alle auf *.loc enden.
Die Schnittstelle nach Außen geht dann über einen Reverse Proxy. Also Apache, nginx, HAproxy oder sowas.
Damit könntest Du steuern, welcher Host welche Applikation nach Außen bringen darf, ohne dass Du an den Hostnamen etwas ändern musst (manche Apps möchten aber gerne sowas wie eine konstante "Basis URL" haben).
Die Benennung IST relevant, wenn sie als offizieller Hostname gelten soll. Lets Encrypt zertifiziert nur Hostnamen, die als solche mit ihrem Namen im Internet erreichbar sind. Alternativ kannst Du auch ein Wildcard-Zertifikat ausstellen lassen und das dann für alle Deine Hosts benutzen. Oder im o.g. Ansatz auf dem Reverse Proxy betreiben. Soweit ich weiss, gehen auch Subdomain-Wildcards, also "*.blubb.bla.welt".
Dem Zertfikat is ejal, wofür. Hauptsache, am anderen Ende ist ein Gerät, was als SSL-Endpunkt dient und von Lets Encrypt aus erreichbar ist. Du kannst getrennte (Wildcard-)Zertifikate für die Subsubdomains erstellen oder einzelne für jedes Gerät.
Du musst allerdings bei der Einrichtung darauf achten, dass Lets Encrypt dich nicht temporär sperrt, wenn Du zu viele Zertfikate hintereinandner erstellen willst.
Probier das mal mit den Wildcards für Subdomains aus. Gute Anleitungen finden sich u.a. bei DigitalOcean: https://www.digitalocean.com/community/tutorials/how-to-create-let-s-enc ...
"Sicherheitstechnisch" ist es ratsam, ALLE Rechner quasi wie in einer DMZ zu betreiben, aber nur mit interner IP-Adresse und internem Zugriff. Die Hostnamen würden dann nach o.g. Beispiel alle auf *.loc enden.
Die Schnittstelle nach Außen geht dann über einen Reverse Proxy. Also Apache, nginx, HAproxy oder sowas.
Damit könntest Du steuern, welcher Host welche Applikation nach Außen bringen darf, ohne dass Du an den Hostnamen etwas ändern musst (manche Apps möchten aber gerne sowas wie eine konstante "Basis URL" haben).
Die Benennung IST relevant, wenn sie als offizieller Hostname gelten soll. Lets Encrypt zertifiziert nur Hostnamen, die als solche mit ihrem Namen im Internet erreichbar sind. Alternativ kannst Du auch ein Wildcard-Zertifikat ausstellen lassen und das dann für alle Deine Hosts benutzen. Oder im o.g. Ansatz auf dem Reverse Proxy betreiben. Soweit ich weiss, gehen auch Subdomain-Wildcards, also "*.blubb.bla.welt".
Dem Zertfikat is ejal, wofür. Hauptsache, am anderen Ende ist ein Gerät, was als SSL-Endpunkt dient und von Lets Encrypt aus erreichbar ist. Du kannst getrennte (Wildcard-)Zertifikate für die Subsubdomains erstellen oder einzelne für jedes Gerät.
Du musst allerdings bei der Einrichtung darauf achten, dass Lets Encrypt dich nicht temporär sperrt, wenn Du zu viele Zertfikate hintereinandner erstellen willst.
Probier das mal mit den Wildcards für Subdomains aus. Gute Anleitungen finden sich u.a. bei DigitalOcean: https://www.digitalocean.com/community/tutorials/how-to-create-let-s-enc ...
wir in der firma (und zuhause mache ich es auch so)
- alles was intern ist (cliens, server) bekommen die domain .in.meinedomain.de
- was ich extern erreichen will bekommt entsprechend: xxx.meinedomain.de
- idrag, ipmi usw. .kvm.meinedomain.de
- systeme in der dmz: .dmz.meinedomain.de
und einige system haben natürlich mehre dns einträge (wenn z.b. mehre dienste auf einer hardware laufen)
ganz einfach
- alles was intern ist (cliens, server) bekommen die domain .in.meinedomain.de
- was ich extern erreichen will bekommt entsprechend: xxx.meinedomain.de
- idrag, ipmi usw. .kvm.meinedomain.de
- systeme in der dmz: .dmz.meinedomain.de
und einige system haben natürlich mehre dns einträge (wenn z.b. mehre dienste auf einer hardware laufen)
ganz einfach
Moin,
Gruß,
Dani
Ist es sinnvoll, ein einheitliches Benennungsmuster für ausschließlich interne sowie von außen erreichbare Server zu nutzen?
Beides hat Nach- und Vorteile. Was besser für dich ist, können wir meiner Meinung nach ad-hoc in einer Frage nicht beantworten.Ist die Benennung relevant, wenn ich Letsencrypt einrichten möchte?
Hängt davon ab ob du bei LE die Verifizierung via http-01 oder dns-01 durchführst? Bei erstem kannst du nur Zertifikate erhalten, wenn der FQDN im Internet auflösbar ist.Ist den Zertifikat egal, ob es für ein Endgerät, oder für eine "Subsubdomain" ausgestellt wird?
Erst mal schon. Wenn es immer um Serverauthentifizierung geht.Gruß,
Dani
Hallo
Praxis Ansatz, ist absolut firmentaglich
1) Domain (extern/intern) wegen der Sicherheit trennen
- externe Services foo.meinedomain.de
- interne Services foo.meinedomain.priv
2) Splitt-DNS
- externer Primary-DNS (meinedomain.de) ist für alle aus dem Internet verfügbaren Services (z.B. www.meinedomain.de), inkl. derer die Inhouse laufen und vom Internet her zugänglich sind zuständig.
- interner DNS ist für beide Domains (Zonen meinedomain.de / meinedomain.priv) für alle internen Servernamen und Services (z.B. foo.meinedomain.priv) im LAN zuständig.
- Services die Inhouse gehostet sind, sowohl intern wie auch aus dem Internet her verfügbar sein sollen, werden per CNAME Record konfiguriert (z.b. fooextern.meinedomain,de CNAME foointern.meinedomain.priv).
- nicht bekannte Domains (z.B. www.google.de) werden per Forward-Lookup beim Provider DNS angefragt.
Fazit:
- Im Internet sind nur die Services bekannt die auch tatsächlich bekannt sein müssen (Sicherheit)
- alle internen Geräte erhalten den internen DNS (Manuell oder via DHCP) zugewiesen
- Wandernde Geräte (z.B. Handy) die sich sowohl im Internet wie auch mit WIFI verbinden, können immer über die gleiche Sevice URL zugreifen
- kleiner vernachlässigbarer Mehraufwand für die Splitt-DNS Konfiguration
Gruss
Adi
PS: läuft so auf meiner Infrastruktur mit 6 Domains seit Jahren problemlos
Praxis Ansatz, ist absolut firmentaglich
1) Domain (extern/intern) wegen der Sicherheit trennen
- externe Services foo.meinedomain.de
- interne Services foo.meinedomain.priv
2) Splitt-DNS
- externer Primary-DNS (meinedomain.de) ist für alle aus dem Internet verfügbaren Services (z.B. www.meinedomain.de), inkl. derer die Inhouse laufen und vom Internet her zugänglich sind zuständig.
- interner DNS ist für beide Domains (Zonen meinedomain.de / meinedomain.priv) für alle internen Servernamen und Services (z.B. foo.meinedomain.priv) im LAN zuständig.
- Services die Inhouse gehostet sind, sowohl intern wie auch aus dem Internet her verfügbar sein sollen, werden per CNAME Record konfiguriert (z.b. fooextern.meinedomain,de CNAME foointern.meinedomain.priv).
- nicht bekannte Domains (z.B. www.google.de) werden per Forward-Lookup beim Provider DNS angefragt.
Fazit:
- Im Internet sind nur die Services bekannt die auch tatsächlich bekannt sein müssen (Sicherheit)
- alle internen Geräte erhalten den internen DNS (Manuell oder via DHCP) zugewiesen
- Wandernde Geräte (z.B. Handy) die sich sowohl im Internet wie auch mit WIFI verbinden, können immer über die gleiche Sevice URL zugreifen
- kleiner vernachlässigbarer Mehraufwand für die Splitt-DNS Konfiguration
Gruss
Adi
PS: läuft so auf meiner Infrastruktur mit 6 Domains seit Jahren problemlos
Vielen Dank für euren Input.
Mein Fazit ist, dass ich hier gleich eine Rolle Rückwärts antrete, und erst mal wieder zurück auf meine ursprüngliche, lokale Domain wechseln werde.
Mir war auch nicht bewusst, dass ich problemlos mehrere Hostnamen verwenden kann für den gleichen Host. Dann bekommen die zwei Service, die nach außen gehen, einen zweiten Namen verpasst.
Tja, wer von euch hat nun die Lösung gebracht? -- Kann ich allesamt gleichermaßen als Lösung markieren?
Besten Dank, Grüße,
Marcus
Mein Fazit ist, dass ich hier gleich eine Rolle Rückwärts antrete, und erst mal wieder zurück auf meine ursprüngliche, lokale Domain wechseln werde.
Mir war auch nicht bewusst, dass ich problemlos mehrere Hostnamen verwenden kann für den gleichen Host. Dann bekommen die zwei Service, die nach außen gehen, einen zweiten Namen verpasst.
Tja, wer von euch hat nun die Lösung gebracht? -- Kann ich allesamt gleichermaßen als Lösung markieren?
Besten Dank, Grüße,
Marcus
Du kannst soviele verschiedene DNS-Servernamen verwenden wie du willst.
Z.B. bei Webservern, für Namebased vhosts. Du must einzig bei den Zertifikaten aufpassen, die URL sollte dem CN entsprechen oder als SAN enthalten sein
Z.B. bei Webservern, für Namebased vhosts. Du must einzig bei den Zertifikaten aufpassen, die URL sollte dem CN entsprechen oder als SAN enthalten sein
