Domain mit linuxmuster-setup --modify ändern

Hier ist noch ein Link, der mir damals geholfen hat (zum Thema Domain für AD/Samba):

vG

Ich kann das Verhalten bestätigen und würde mir auch eine Lösung wünschen. Das, was Tobias vor hat, wollte ich auch schon mal machen… Lief damals nicht.

Halle Tobias,

Du musst folgendes eintragen:

Hostname: server
Internet-Domäne: humbi.de
FQDN: server.humbi.de

Ob der Server aus dem Internet nur unter server.humbi.de (das ist der Normalfall) oder auch unter humbi.de (das wäre eventuell zusätzlich sinnvoll) erreichbar ist, das ist eine Frage der DNS-Einstellungen. Die kannst aber nicht Du vornehmen, sondern Dein Provider muss das für Dich machen.

Viele Grüße

Jörg

Hallo Tobias,

zunächst einmal: Zertifikate gelten für Rechner, nicht für Domänen. Also für server.humbi.de und nicht für humbi.de. Genauso ist normalerweise humbi.de keine IP zugeordnet.

Nun kann man allerdings in der Tat entgegen der Logik für humbi.de eine IP hinterlegen, zum Beispiel die von server.humbi.de. Dann muss im Zertifikat von server.humbi.de zusätzlich humbi.de als alternativer Servername stehen - Let’s Encrypt kann das.

Punkt 2 und 3 funktionieren nach der Umstellung und mit einem offiziellen Zertifikat sofort.

Zu Punkt 1: Soll der Apache auf dem Server ebenfalls übers Internet erreichbar sein oder nur Dein Owncloud-Server? Wenn nur der Owncloud-Server, dann musst Du lediglich im IPFire eine Regel dafür anlegen (Port 443 aus Rot wird an Port 443 vom Owncloud-Server weitergeleitet, kopiere einfach die Regel “Ssh-Zugang von außen”).

Wenn auf beiden Rechnern der Webserrver von außen erreichbar sein soll, dann wird es trickreicher. Eine Möglichkeit ist ein Dienst auf dem Ipfire, der das sortiert, eine andere, das über unterschiedliche Ports zu regeln.

Viele Grüße

Jörg

Hallo Jörg,

danke, das sind die entscheidenden Informationen. Ich dachte “FQDN” heißt “nur die domäne eintragen”, aber FQDN ist ja ein FQHN, den man eintragen muss. Das sollte ich mal in die Doku aufnehmen.

vG, Tobias

1 „Gefällt mir“

Ein Beitrag wurde in ein neues Thema verschoben: SSL intern und extern

Eine Zwischenlösung wäre vielleicht das Root-CA Zertifikat zu importieren. Dann brauchst du die einzelnen Server Zertifikate nicht mehr einzeln importieren.

vG

Hallo mal wieder,

ich will mal die externe Domänenkonfiguration einer Schule “richtig” machen, im top-Post steht ja, wie man die linuxmuster.net v6.x umstellt.

Jetzt geht es mir hauptsächlich um die Frage: humbi.de ist kein Host, sondern nur eine Domäne (FQDN), aber ich will von außen und von innen darauf zugreifen und soll eben z.B. beim Server server.humbi.de landen. Vielleicht ratet Ihr mir auch, grundsätzlich den Zugriff auf die Domäne zu vermeiden und per rewrite/proxy umzuleiten auf einen FQHN.

Meine Frage: Wenn ich von außen darauf zugreifen will, macht mir das ein reverse proxy, der auf der öffentlichen IP lauscht richtig und leitet mich auf den entsprechenden server weiter.
Wenn ich von innen darauf zugreifen will, dann kann ich

  1. entweder in jedem client die innere IP von Hand festnageln (in /etc/hosts bspw, entsprechend in Windows)
  2. oder ich editiere den Nameserver (bind) auf dem Server
  3. oder ich lasse die DNS-Anfrage nach außen weiterleiten und dort wird meine externe IP-Adresse aufgelöst.

Was findet Ihr besser?

zu 2. Wenn ich den nameserver auf dem Server ändere, habe ich es mit einem IN A 10.16.1.1versucht und das scheint zu funktionieren - gut so? Die Datei /etc/bind/db.linuxmuster beginnt so:

$ORIGIN .
$TTL 7200       ; 2 hours
humbi.de      IN SOA  server.humbi.de. postmaster.humbi.de. (
                        2004030801
                        10800
                        3600
                        604800
                        38400
                        )
                NS      server.humbi.de.
                MX      10 server.humbi.de.

$ORIGIN humbi.de.
humbi.de. IN A 10.16.1.1 ; # diese Zeile manuell eingefügt
server IN A 10.16.1.1
ipfire IN A 10.16.1.254

;### linuxmuster - begin ### DON'T REMOVE THIS LINE ###
rl-pc10 A 10.16.12.10
rl-pc11 A 10.16.12.11
...

zu 1. Nachteil: wenn ich /etc/hosts editiere, klappt das nicht für BYOD-Geräte

zu 3. Nachteil: wenn ich die externe IP auflösen lasse, dann weiß ich nie genau, wie der IP-Verkehr funktioniert.

Grundsätzlich frage ich mich auch zusätzlich, ob die Server-IP das Ziel sein muss, oder ob ich nicht meinen Reverse-Proxy (auch von innen) als Ziel der reinen Domäne wähle.

für jegliches Mitdenken, vielen Dank!
Tobias

Hallo Tobias,

Bei uns ist es so, und können damit alle Clients Innen mit der Domäne auf alle Server zugreifen :

# head -16 /etc/bind/db.linuxmuster 
$ORIGIN .
$TTL 7200       ; 2 hours
schule.org	IN SOA	server.schule.org. postmaster.schule.org. (
			2004030801
			10800
			3600
			604800
			38400
			)
		NS	server.schule.org.
		MX	10 mail.schule.org.

$ORIGIN schule.org.
server 	          IN A 10.16.1.1
horde 		  IN A 10.16.1.1
schule 		  IN A 10.16.1.1

Natürlich müssen auch die externe DNS angepasst werden so, dass du von zu Hause darauf kommst.
Wir verwenden Pound auf Ipfire als Reverse-Proxy.

Gruß

Arnaud

'Hallo Arnaud,

danke. Aber kannst du mit der konfiguration auch auf “schule.org” zugreifen?
z.b: “ping schule.org” oder “firefox http://schule.org” usw.?

VG, Tobias

Nein, aber das brauche ich nicht : ich habe eine Subdomäne pro “Oberfläche/Software” eingestellt, und damit sind alle Sachen klar.

Ok, danke,
ich denke an die Schulen, die das nicht können, also unter Umständen nur schule.org auf eine IP zeigen lassen können und alles andere via schule.org/software regeln müssen.
Die sollten auch von innen an ihre URLs kommen.

Vg, Tobias

Ich glaube ich habe noch nicht ganz verstanden, was du vorhast. Du willst das die Anfragen an schule.org beim entsprechenden Webserver rauskommen, aber schule.org zeigt nur auf eine IP?

Falls da so ist, kannst du alle DNS-Einträge auf die öffentliche IP zeigen lassen (DNS von deinem Anbieter) und dann kann man den Reverse Proxy konfigurieren, dass er sich um die richtige Verteilung kümmert.

Von intern kannst du die DNS Einträge auf dem Server oder besser der Firewall machen und ebenfalls auf die IP des Reverse Proxy zeigen lassen. Musst du aber auch nicht. Dann geht der Verkehr einmal raus und wieder rein :slight_smile:

vG

Ja, genau letzteres war mein post oben mit 3 Alternativen, wie man bewerkstelligt, dass intern man auch richtig rankommt.

Beispiel: Man hat eine nextcloud unter “cloud.schule.org/cloud”. Ich will von innen wie außen darauf zugreifen. Habe ich aber keine Möglichkeit, meinen DNS-Anbieter anzuweisen, sowohl “cloud.schule.org” als auch “schule.org” auf meine IP zeigen zu lassen, dann muss intern auch “schule.org” eben am ende bei cloud.schule.org landen. Dass der reverse proxy das kann, ist mir klar. Oben habe ich mich gefragt, ob ich das über /etc/hosts, oder über den bind des lmn-servers oder über die externe IP-Adresse der externen DNS-Auflösung lösen sollte oder sage: “das gibt es nicht, jeder DNS-Anbieter muss subdomänen zulassen, was anderes wird nicht supported.”

Ich gehe davon aus das kleine Schulen wenn überhaupt genau eine DNS -> IP Zuordnung von extern haben und zwar dann “schule.org” und nicht “server.schule.org

vG, Tobias

mir fällt noch das andere Szenario ein, weswegen man “schule.org” brauchen könnte: Das SSL-Zertifikat.
Wenn ich von außen auf schule.org/nextcloud zugreife und der ReverseProxy das SSL bereitstellt aber intern auf “http://cloud.schule.org” umleitet (ohne SSL), dann kann ich muss ich intern auch auf “https://schule.org/nextcloud” zugreifen können, alleine schon wg. der BYOD-Geräte.

Würde ich das mit dem FQHN “cloud.schule.org” von vorne herein machen, brauche ich unbedingt auch SSL auf dem cloud-server. Das wiederum zieht nach sich, dass das SSL-Zertifikat auch auf cloud.schule.org ausgestellt wird.
Ja, das ganze ist mit letsencrypt schon gelöst (anderer Thread), aber ziemlich sicher gibt es szenarien, wo man intern ohne SSL und extern mit SSL arbeiten will.
VG, Tobias

und noch eins: wenn man die cloud umzieht auf einen anderen host, dann muss man den hostnamen behalten, wenn man “cloud.schule.org” als URL hat, aber nicht, wenn man schule.org nimmt. Dann ist man hintendran flexibler.
VG; Tobias

Hi Tobias.
Ich mache dieses Fass jetzt nochmal auf … :slight_smile:

Auf unserem Testserver mit V6.2 habe ich gerade nochmal den --modify-Befehl laufen lassen. Das lief letztlich erfolgreich durch und nun habe also intern auch einen FQDN gesetzt. Der Server reagiert jetzt bei
ping server mit dem kompletten Namen “server.schule.org”. Auch der IPFire usw verhalten sich jetzt so.

Wenn ich im Client-Browser den Server aufrufe, reagiert er auch bereits richtig. Alle Varianten funktionieren:

(bei https muss das Zertifikat auf dem Client jetzt neu akzeptiert werden – macht Sinn!)
Wenn ich nun aber eine externe Seite aufrufen will, wie z.B. ganz schlicht
http://www.schule.org, gibt es ein Problem:
Server nicht gefunden.
Das sieht ja sehr nach den oben diskutierten DNS-Problemen aus. Vermutlich wird erst gar nicht extern nachgeschaut, da die Seite intern “vermutet wird”, richtig?
Wie löst man das Problem denn jetzt am besten?
Wir haben extern natürlich diverse weitere Subdomains zu schule.org, wie z.B. schuelerrat.schule.org oder webmail.schule.org oder was weiß ich … die sind im Moment natürlich alle nicht auflösbar.
(Es ist nur Testserver und NDS hat bereits Osterferein … daher ist es kein Problem im produktiven Betrieb)

Schöne Grüße,
Michael

P.S. Erst jetzt sehe ich, dass es die domain schule.org tatsächlich gibt … sorry :slight_smile:

Hallo Michael,

meine eigene Dokumentation und mein Server zeigen keine vollständige Übereinstimmung, aber in jedem Fall habe ich auf dem Server in der Datei /etc/bind/db.linuxmuster unterhalb der ersten 4 Zeilen (in meiner Doku, aber in echt Zeile 10) sinngemäß folgendes stehen:

  $ORIGIN schule.org. 
  server IN A 10.64.1.1 
  ipfire IN A 10.64.1.254 
  www IN NS schule.org

Aktuell ist die letzte Zeile auf meinem Server aber

www IN NS 10.64.1.254

Und für die Nextcloud z.B.

nextcloud IN A 172.16.65.2

Du siehst, ich habe einen anderen Adressbereich (10.64.x.x statt 10.16.x.x). Offensichtlich reicht es, wenn der Hinweis da steht, dass für www auf dem IPFire nachgeschaut werden soll.
Nach der Änderung habe ich ein

service bind9 restart

ausgeführt.

VG Christian

Am einfachsten ist, du nimmst eine Subdomain wie in den Artikeln oben verlinkt. Dann entfallen deine beschriebenen Probleme.

Da wir aber z.B. keine Mail mit der LMN machen, weiß ich nicht, wie sich das darauf auswirkt.
VG Stephan

Hi.

Ok, dann muss man für diesen Fall also alle externen Subdomains in der bind9-Config selbst pflegen … und auch daran denken, wenn mal eine dazu kommt, richtig?

Ich blicke nicht mehr ganz durch. Wo genau meinst du jetzt? Da wir extern auf unserem vServer auch mehrere Domains haben, ist für uns der beste Weg evtl eine andere als die offizielle zu nehmen, unter der alle Services laufen? Dann müsste ich aber später die LetsEncrypt Zertifikate für beide domains ausstellen lassen…

Michael