Beginnen wir mit dem "DNS-Server". Wie schon angedeutet - ist der "Name-Server" - eigentlich ist es ja eine Server-Funktion - die "online"- Namensauflösung - für das Finden und Aufrufen von Webseiten - essentiell wichtig.

Unsere Domains müssen draußen im Internet vorab weltweit publiziert (referenziert) sein, sonst findet niemand unseren Server. ("Niemand" steht für "kein Browser"). - Der "Apache2"- Web-Server selbst muß dann die eintrudelnden Anfragen auf die sogenannten "virtuellen Hosts" verteilen. Also auch der muß das mit den "Nameservices" können.
.

Bei einem mit XEN/KMS virtualisierten Linux-Server betreut der "Host" (die DOM-0 oder auch "das Grundsystem") die installierten virtuellen Gäste (in der Regel werden die auch VM's = "virtuelle Maschine(n)" genannt).

Bei einem in solch einer "VM" installierten Websever kann man mit einer einzigen Domain glücklich werden oder aber den Webserver für mehrere sogenannte "virtuelle Web-Hosts" (das sind dann sogenannte "v-hosts") konfigurieren, also für mehrere unterschiedliche Domain-Namen (z.B. hifimuseum, fernsehmuseum, tonbandmuseum, ipw.net usw.) einrichten.

Dafür gibt es jeweils eigene Konfigurations-Dateien, die den Domain-Namen enthalten und die natürlich auch das Zielverzeichnis mit den Inhalten (bzw. Konfigurationen für die jeweilige Domain) auf dem Linux-Server kennen.
.

Aber der Apache-Server-Dienst ist kritisch. Er will automatisch und ungefragt (beim Start) die Namen der konfigurierten "vhost"- Domains draußen in den DNS Servern abfragen und mit seiner Server-IP Nummer verbunden sehen, sonst meldet er Fehler über Fehler und startet einfach nicht.

Diesen Automatismus wußte / kannte ich bis dahin nicht, weil soetwas bislang nie gefordert war, es hatte bislang immer funktioniert - in Düsseldorf zwar extrem langsam, aber ok. Der Linux-Server bzw. dessen Netzwerkkarte hatte nämlich immer die korrekte IP-Nummer aus dem DNS-Nameserver-Eintrag des Domain-Records verfügbar.
.

Jedenfalls funktionierte es so lange, wie unser Web-Server die draußen im Internet publizierten und abrufbaren DNS-Einträge gefunden sowie die abgefragte IP-Nummer ebenfalls gefunden hatte.

Jetzt hatte unser neuer Server hinter der Firewall eine gänzlich andere IP-Nummer, nämlich eine aus unserem internen "privaten" 192.168.xxx.yyy Bereich. Das sind Nummern, die (per Definition) ganz bewußt nicht routbar sind und es auch nie sein sollen - aus Scherheitsgründen.
.
Und schon wieder ging es nicht mehr. Der Apache startete nicht mehr. Aber zum Glück den Fehler gefunden, auch wieder durch einen Zufall ......
.

Das Geniale dabei ist, nur die in der Fritzbox eingetragenen, geöffneten und angenommenen Ports werden überhaupt weiter geleitet (geroutet), alle anderen Ports werden geblockt bzw. völlig ignoriert. Die sind einfach nicht da.

Und die internen IP-Nummern der gerouteten internen Server kennt draußen keiner. Hinter der Fritzbox kann ich damit jedem virtuellen Server eine eigene IP-Nummer vergeben, damit ich ihn aus unserem Inhaus- Netzwerk gezielt und sicher (und schnell) administrieren kann.

Im Prinzip kann ich jetzt auf allen virtuellen Servern (Gästen) die Firewalls abschalten. Es wird pro virtuellem Server nur ein Port angesprochen (maximal 3 oder 4)
.

Der Apache2 Web-Server monierte anfänglich beim Start, daß das mit den mehreren konfigurierten "vhost"-Einträgen nicht stimme und nur der erste Eintrag sei der Richtige ... und dann war es das. Der Webserver startete nicht (=Abbruch). Beim zweiten Startversuch (ich war einfach hartnäckig) startete er komischer Weise dann doch, aber immer nur mit unserer allerersten Dummi-Hilfs-Seite. Die Museenseiten (in der Prioritäts-Abfolge der 3. Eintrag von oben) blieben verschollen.

Und wieder stand die "Weisheit" oder das Wissen in einem Forum in einem völlig anderen Thema. Ein Linux-Newcomer wollte in seinem internen Netzwerk seinen Webserver über zwei oder drei unterschiedliche hausinterne Domain-Namen ansprechen und es klappte nicht, obwohl er in seinem lokalen Inhaus-Netzwerk einen eigenen kleinen Name-Server betrieb.

Ein feundlicher Helfer verriet ihm dann, er müsse (zusätzlich) auf dem Web-Server in der Datei "/etc/hosts" diese beiden oder drei Domain-Namen mitsamt der echten internen lokalen Server-IP eintragen und siehe da, es funktionierte.
.
Und so war es bei mir auch. In der Datei "/etc/hosts" des Museen-Webservers sind nun (zusätzlich) alle benutzen Domainnamen mit der Inhaus-IP des virtuellen Hosts - also nicht mit der externen IP der Fritzbox - eingetragen und es funktioniert.
.

Wie schon angeführt, ist diese neue Fritzbox erheblich beschleunigt worden, damit sie einen 1GBit/s Kabel-Anschluß betreuen und diese Datenrate zu den vier Gbit/s Ethernet-Ports durchschleusen kann.

In der Grundkonfiguration blockt die Fritzbox alle ankommenden eingehenden TCP und UDP Requests auf ihrer IP-Nmmer komplett ab. Man könnte die https-Konfiguration von außen aus dem Internet (über Port 443) zwar zulassen, doch das ist aus meiner Sicht "unglücklich" und normalerweise nicht notwendig.

Bei der Einrichtung eines VPN Eintrags benennt man einen (den) zu öffnenden Port, zum Beispiel Port 80 für http, und bestimmt dann die interne lokale IP-Nummer und auch dort den Port, zu dem die Anfrage weiter geleitet (geroutet) werden soll.

Um zum Beispiel eine hausinterne Testinstallation zu betreiben und auch von draußen zu prüfen, könnte man den (eigentlich abweichenden) Port 88 oder 188 oder sogar 60.000 öffnen und per VPN-Route gezielt auf einen virtuellen Gast-Server auf dessen interne IP- Nummer und dort wiederum auf den richtigen hhtp-Port 80 weiterleiten.

Das grafische Server-Admin-Programm "webmin" macht das zum Beispiel mit dem Port 10.000. Damit kollidiert es nicht mit dem Port 80 eines gleichzeitig aktiven Webservers. Dieser Port 10,000 und andere sensible Ports sind von außen nicht sichtbar.
.

Es gab und gibt noch eine Menge weiterer kleiner Hürden, die ich so nach und nach aus dem Gedächtnis zusammensuche.

Im Moment wird die halbautomatische Datensicherung perfektioniert, denn dort lag auch ein Teil des (hausgemachten !!) Problems.
.

Wie weiter vorne bereits erwähnt, brauche ich auf dem Host den Virtualisierungs-Manager für die Gäste. Der ist nur (noch) mit einer (Schmalspur-) grafischen Oberfläche vernünftig komfortabel und schnell zu bedienen.

Hier von meinem Redaktions-Arbeitsplatz aus kann ich mir sowohl die Server-Tastatur eines einfachen Text-Terminals holen oder (und) über den Windows "VNC-Client" den grafischen Bildschirm des Servers holen. Dazu mußte ich 20 Jahre lang auf dem Host den "VNC-Server" (X11-vnc) von Hand oder automatisch starten.

Nach dem Upgrade auf die opensuse Version 15.4 (oder 15.5) gab es den Aufruf "vncserver" auf einmal nicht mehr. Wie gesagt, dieses Programm hatte 20 Jahre auf allen Revisionen funktioniert. Im suse Forum bekam ich die Antwort, der "vncserver" würde jetzt nicht mehr unterstützt - fertig - das war alles.

Nach langem Suchen bekam ich einen Tip, "versuche doch mal, in dem Verwaltungsprogramm YAST bei den Netzwerkeinstellungen die Remote Administration zu aktivieren und dazu den "vnc-manager" nachzuinstallieren", dann ginge es wieder. Also war der gar nicht weg, irgend ein Genie bei suse hatte nur die Prozeduren geändert und uns wieder einen Tag geklaut. Es gab da keinen Hinweis bei dem Upgrade, daß "dieses und jenes" und "so und so" wieder funktioniert - oder wie es wieder funktioniert.
.

.

.

.