Hi Tobias,
ich sehe schon, das wäre mal ein Thema für eine Fortbildung. Ich habe da auch keinen Plan und plage mich öfters herum.
Ich kann allerdings von intern meine Cloud in der DMZ mit ihrer externen Adresse erreichen (owncloud.eichendorff-gymnasium.de/owncloud). Sie hat aber auch eine eigene IP im Internet.
Hat Deine Nextcloud die gleiche externe IP wie der Server (nur einen anderen Port?)
LG
Max
Hallo Tobias,
ja, ich habe das Thema auch noch nicht ganz durchschaut und ich habe auch kaum Antworten auf deine Fragen, da bei uns z.B. Mails extern laufen, d.h. wir nutzen nicht die LMN dafür.
Wir haben auch noch keine Server in einer DMZ. Bisher sind alle nur intern zu erreichen. Ich habe dazu in unserer Firewall DNS-Overrides angelegt, sodass eine eigentlich externen Domain, intern an eine IP aufgelöst wird (z.B. library.example.com löst nur intern auf, da es diesen DNS Eintrag extern noch nicht gibt). Ob das noch mit Zertifikaten etc. klappt, wenn der Server einmal von außen zu erreichen ist, muss ich noch sehen.
Ich habe eben schön gefrühstückt 
vG
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
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
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
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 … 
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
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