Domain mit linuxmuster-setup --modify ändern

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

Hi Michael,

wir haben es so uns:

Wir haben es damals so gemacht, weil ich so die Empfehlungen von Microsoft (für AD) und aus anderen Artikeln verstanden habe.

VG Stephan

… und wenn ich das so mache, wird beim internen Aufruf von
www.example.com (bzw anderen foo.example.com -Aufrufen) wieder „draußen/extern“ nachgeschaut, ob es die Seite gibt? Das würde das Problem dann tatsächlich lösen und man käme um die bind9-Konfiguration völlig herum, oder?

Wo läuft denn bei dir das LetsEncrypt? Intern oder extern? Wenn es intern ist, muss ja Port 80 während der Erneuerung erreichbar sein. Da bei uns auf Port 80 des linuxmuster-Servers allerdings bereits der Apache2 seinen Dienst tut, frage ich mich auch da, wie man das am besten macht. Oder kommt man um einen Reverse Proxy tatsächlich nicht herum? Dann könnte man eine andere VM für diesen Zweck nehmen, oder?

Michael

Hi Michael,

Ja: dns - Unable to access website from internal network - Stack Overflow Die Domain für den Domaincontroller (AD/Samba) sollte niemals eine existierende Domain (z.B. Schulwebseite) sein.

Deshalb nimmt man am besten eine Domain, die man besitzt und nutzt für Samba eine Subdomain (siehe auch diese Meinung Welche TLD sollte man für interne Adressen n… | Forum - heise online)

Alles andere ist „Domain-Hijacking“ :slight_smile: und erfordert nur zusätzliche Pflege des DNS-Servers und macht die ganze Geschichte unnötig komplizierter.

LetsEncrypt läuft (noch) auf den Webservern direkt. Da ist Port 80 und 443 offen → für den Webserver, wobei alle Anfragen auf Port 80 nach 443 weitergeleitet werden.

vG Stephan

Ok, ich habe das --modify gerade nochmal laufen lassen. Jetzt heißt er also “server.intern.schule.org”. Warum gilt das dann nicht als “Domain-Hijacking”??

Der Durchlauf von /var/lib/linuxmuster/config-dynamic/99_start-services dauert hier übrigens extrem lange. Hohe Systemlast erzeugt das Script aber nicht. Die Umstellung ist gerade erfolgreich durchgelaufen. Jetzt kann’s mit LE weitergehen…

Ich nehme mal an, dass du „schule.org“ mit euer Schul-Domain ersetzt hast, richtig? Dann sollte alles ok sein.

vG Stephan

Klar … das ist nur ein Platzhalter. Ich habe es gerade ausprobiert: ping auf www.schule.org (mit unserer domain :slight_smile: ) usw läuft.

Eine Sache noch: Warum erzeugt das --modify-Script die ssh_dsa/rsa/ecdsa-Keys neu? Zusätzlich wird .ssh/config gelöscht – unschön, finde ich.

Und noch eine Ergänzung hinterher: Ich habe gerade die Anleitung zu LE gelesen:
(https://github.com/linuxmuster-docs/howto_letsencrypt_dehydrated/blob/master/source/index.rst) Ich sehe das doch, richtig, dass der Eintrag in der domains.txt jetzt logischerweise server.intern.example.org lauten muss, richtig?
Michael

Hi Michael,
schalte mich jetzt erst dazu, sorry.

Ja, leider bzw. was solls. Irgendwo hab ich das schon geschrieben, dass man das vorher sichern sollte. Bei mir musste ich noch „ssh ipfire“ testen und wieder ohne passwort zum Laufen kriegen (schau mal ob bei dir das geht!, sonst funktioniert import_workstations (und anderes) nicht mehr.

Ja, würde ich sagen.

VG, Tobias

Hi.
Also diese Baustelle ist abgearbeitet, würde ich sagen. Der Server reagiert unter dem neuen FQDN. Der passwortlose Zugang zum IPFire (und zum OSPI) laufen auch wieder.

Jetzt geht’s mit LE im Parallel-Thread weiter…