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“
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 …
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
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
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…
zusätzliche Dienste sind bei uns in einer DMZ, der DNS für unsere Schuldomain extern. Die Einträge für foo.example.com oder bar.example.com zeigen auf die öffentliche IP der Firewall. Per reverse Proxy wird das an den richtigen Webserver weitergeleitet.
Wir haben es damals so gemacht, weil ich so die Empfehlungen von Microsoft (für AD) und aus anderen Artikeln verstanden habe.
… 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?
Alles andere ist „Domain-Hijacking“ 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.
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…
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.
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.