Und so sollte man die Fragen beantworten, danke an @jrichter, der das weiter unten erklärt:
der Hostname (standard: server) -> server
“Internet-Domäne des Schulnetzes” (standard: linuxmuster-net.lokal) -> humbi.de
später wird der externe Name des Servers abgefragt (FQDN, sollte eigentlich FQHN heißen) (standard: leer) -> server.humbi.de
nicht beides Mal humbi.de eingeben, bekomme ich Ärger mit dem bind.
Zugriff von außen und innen
Zugriff über “humbi.de” sollte man meinen, aber ich habe z.B. einen server und einen cloud server. Die SSL-Zertifikate sind auf hosts ausgestellt (und auf die domäne), deswegen mach ich das (meiner Meinung nach sauber) jetzt so:
ich habe meinen Provider (belwue) gebeten, DNS-Aliaseinträge für server.humbi.de und cloud.humbi.de auszustellen, die auf humbi.de zeigen.
das Zertifikat wird für apache, slapd und cyrus auf dem server sowie auf dem cloud-server für den apache dort eingerichtet.
von außen komme ich nun mit humbi.de oder mit server.humbi.de auf meinen server, z.B. für horde, mit humbi.de/cloud (wenn ich es in ipfire+pound einrichte) oder mit cloud.humbi.de auf den cloud-server
von innen komme ich auch mit server.humbi.de auf den server, z.B. für horde, schulkonsole, etc und mit cloud.humbi.de auf die cloud.
Client einrichten
Am Client muss ich jetzt statt server:242 jetzt server.humbi.de schreiben. jVorsichtshalber habe ich in /etc/hosts noch dem server.humbi.de die 10.16.1.1 verpasst.
Die Zertifikate sind jetzt einfach gültig, man muss sie nicht mehr als Ausnahmen eintragen.
Troubleshooting
Bei der Umstellung wird der LDAP-Eintrag geändert, d.h. aus dc=linuxmuster-net,dc=lokal wird dc=humbi,dc=de. Das hat zur Folge, dass in den per LDAP angebundenen Diensten, wie moodle, dokuwiki, cloud die Base-DN angepasst werden muss. Dokuwiki klappte wunderbar, moodle hab ich nicht, nextcloud machte Ärger. Entweder wg. der DN-Umstellung oder weil ich gleich nochmal versuchte den Server per LDAPs statt LDAP anzubinden, fand nextcloud beim Einloggen, es müsse neue User anlegen (“kuechel_12354” statt bisher “kuechel” im log). Es gab den Knopf “UUID-Zuordnungen löschen”, die half mir, warum auch immer.
Es werden beim Befehl linuxmuster-setup --modify auch neue SSH-Zertifikate in /etc/ssh/ssh_host* und /root/.ssh/id* erzeugt. Ich brauche die nicht und hab mir die alten wiedergeholt, damit meine passwortlosen SSH-Verbindungen bleiben wie sie sind. Außerdem wurde die passwortlose IPFire-connection gekappt (lsg: @server# cat .ssh/id_ecdsa.pub | ssh -p 222 -l root ipfire "cat >> /root/.ssh/authorized_keys" )
Wenn jemand noch mehr Probleme findet oder Lösungen, bitte her damit.
bei der “Internet-Domäne des Schulnetzes” geht es um die SAMBA DNS-Domain. Die darf nicht gleich der externen Domain sein, ansonsten bekommst du Probleme mit deinem DNS. Split-DNS wäre da eine Lösung, aber das war mir damals zu umständlich. Ich habe bei uns deshalb einfach “internal.example.com” als Samba DNS Domain. Siehe auch hier Empfehlungen von M$:
sorry, bist du dir sicher? Samba-Domäne wird doch vorher schon abgefragt, die heißt standardmäßig SCHULE. Hast du an der Stelle dann internal.example.com genommen?
Ich kann jetzt leider nicht genau auf das Bild in der Doku verlinken, weil es kein Sprungziel dahin gibt.
Aber von der Reihenfolge bei der Installation: SAMBA-Domäne, Hostname server, dann internet-domäne des schulnetzes.
Und dann zwei später der FQDN aka “externer Name des servers”.
Sry, hast natürlich recht. Ich meine die interne DNS-Domain. Ich finde den Begriff “Internet-Domain des Schulnetzes” etwas irreführend.
Edit: Bei der Samba-Domain habe ich das nicht eingetragen, da steht z.B. “SCHULE”. Wie gesagt, was ich so gelesen habe, gab es bei fast allen die Empfehlung die DNS-Domain als Subdomain der Hauptdomain einzurichten, anstatt auf eine Fake-Adresse zu setzen. Wie schlimm das für ein Schulnetzwerk ist, kann ich aber nicht abschätzen.
Ok. Das heißt, ich setze die “internet-domäne” auf linuxmuster-net.lokal oder auf internal.humbi.de und den FQDN auf meine externe Domäne humbi.de.
Ich glaube aber nicht, dass das das ist was die anderen gemacht haben.
Was ich eigentlich will:
https://humbi.de/cloud soll intern wie extern auf meine cloud zeigen und das ssl-zertifikat richtig liefern.
Schulkonsole, LDAPS, Cyrus+postfix soll mir keine SSL-Fehler bringen.
ich will emails an kuechel@humbi.de von intern wie extern schicken und sie sollen ankommen.
Womit ich dann eigentlich ein Problem habe ist, wenn ein Zertifikat für “humbi.de” nicht mehr nur auf einem server liegt.
zu 2.: ich kann Schulkonsole, LDAPS, Cyrus+postfix alle mit demselben SSL-Zertifkat bestücken, liegen ja alle auf demselben server. WEnn ich es intern benenne, steht im Zertifikat z.B: server.linuxmuster-net.lokal (so klappt es bisher).
Wenn ich es extern über letsencrypt mache, muss ja humbi.de im Zertifikat stehen. Dann muss ich aber auch von intern an humbi.de gelangen… hm das klappt doch nicht, oder? Selbst wenn ich im Zertifikat server.humbi.de reinschreibe und dann an den Server von intern wie extern gelange, klappt das dann nicht mehr, wenn ich auch noch dasselbe Zertifikat für den cloud-server verwenden will. Intern muss ich den ja anders auflösen.
Ich steh auf dem Schlauch und geh am besten ins Bett… Danke fürs mitdenken.
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?)
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 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.
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.
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.
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.
Eine Zwischenlösung wäre vielleicht das Root-CA Zertifikat zu importieren. Dann brauchst du die einzelnen Server Zertifikate nicht mehr einzeln importieren.
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
entweder in jedem client die innere IP von Hand festnageln (in /etc/hosts bspw, entsprechend in Windows)
oder ich editiere den Nameserver (bind) auf dem Server
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.
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.
Ok, danke,
ich denke an die Schulen, die das nicht können, also unter Umständen nurschule.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.
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
