Es ist Juli 2019 und ich stellte meinen Root Server von Windows Server 2012 RS auf Debian Linux um. Von da an begann meine gesamte Linux-Karriere, die sich von hier an auch mehr in die Open Source Welt zog. Kurzerhand stellte ich auch alle meine PCs auf Linux um, denn Spielen unter Linux war zu dem Zeitpunkt auch keine riesen Hürde mehr – aber noch Problembehaftet. Jetzt haben wir 2026 und ich verspüre den Drang, mich zusätzlich mehr in Richtung Enterprise-Netzwerke und dessen Diensten einzuarbeiten. Wie man einen Root-Server managed, weiß ich ja mittlerweile.

Doch da mir leider das Geld für die teilweise recht teure Hardware fehlt und ich sonst nichts z. B. in Richtung Managed Switches da habe, musste ich ein bisschen improvisieren.

Ein holpriger Anfang

Ich habe auf meinem PC schon länger VirtualBox installiert, damit ich, z. B. für iTunes, eine Windows-VM installieren kann. Hier versuchte ich dann mittels verschiedener VMs, einem Gespann aus OPNsense und zweimal Debian Linux, ein relativ reelles Szenraio aufzubauen, um im Anschluss mit VLANs zu experimentieren bzw. dessen Prinzip zu erlernen. Das gestaltete sich bei VirtualBox leider schwierig, da VirtualBox keine vSwitches abbilden kann. Ich versuchte es erst mit verschiedenen Netzwerkadaptern an der OPNsense-VM und versuchte dann entsprechend die VLAN-VMs dort einzuklinken. Doch leider scheiterte mein Vorhaben eben wegen der fehlenden vSwitch-Funktionalität. Ich hätte es schon auch mit 2 Adaptern geschafft, doch VirtualBox kann auch kein VLAN. Dazu müsste man spezielle Netzwerktreiber in der VM installieren.

Dann kam mir plötzlich Proxmox VE in den Sinn – ein riesen Linux-Virtualisierungsmonster. Ich informierte mich, was Proxmox so alles kann und was nicht. Aber worauf sollte ich es installieren? Denn Proxmox ist, anders als VirtualBox, nicht einfach ein Programm, sondern ein komplettes System auf Debian-Basis, das man auf einen nackten Rechner installieren muss.

Deshalb überlegte ich mir, worauf ich es installieren könnte. Auf meinem Raspberry Pi 4 Model B? Ne, der hat leider nur 2 GB RAM. Kaufe ich mir ein Netzteil und Gehäuse für mein altes HTPC-Gespann aus ASRock Z77 Pro 3 Mainboard, Intel Core i3-3220 CPU und 10 GB Kingston HyperX Blu DDR3-RAM? Eher nicht. Ich wollte es schon mit Mitteln versuchen, die ich bereits da habe. Denn ich weiß auch nicht, ob ich das Hardwaregespann dann später noch brauche. Aber früher oder später werde ich mir da trotzdem Netzteil und Gehäuse für andere Projekte kaufen. Dann fiel mir mein Werkstatt-Laptop ein – ein Dell Latitude E6430 mit Intel Core i5-3320M CPU und 8 GB DDR3-RAM. Völlig ausreichend für das, was ich gerne lernen möchte! Also tauschte ich die SSD aus und installierte Proxmox auf dem Laptop.

Die Firewall

Über einen LinkedIn-Beitrag von jemandem, hatte ich von OPNsense gehört bzw. gelesen. Einer Open Source Firewall-Lösung aus den Niederlanden. Wichtig bei meinem Lernziel ist, vollkommen auf Open Source zu gehen, da ich persönlich hierin die Zukunft und den richtigen Schritt in die digitale Souveränität sehe. Monopolisten wie z. B. Cisco, Juniper und Co. sollen dabei ganz hinten anstehen – auch wenn sie gut und Platzhirsche sind.

Nach ein bisschen Recherche, stellte sich für mich OPNsense als gute, allumfassende und einfach zu handhabende Lösung heraus. Denn OPNsense kann nicht nur Firewall, sondern kann auch DHCP und DNS übernehmen. Gerade in kleinen Firmennetzwerken wäre so eine Lösung total ausreichend. In größeren Firmen teilt man das auf, um den Arbeitsalltag nicht all zu sehr zu behindern. Denn ist gleich Firewall, DHCP- und DNS-Server weg, dann gibt’s Probleme.

Somit habe ich in Proxmox extra einen weiteren Netzwerkadapter angelegt, der dann als „vSwitch“ agieren soll (VLAN-Aware in dem Fall). Dieser Netzwerkadapter wird dann auch für alle anderen VMs und Container verwendet. Die Ersteinrichtung gestaltete sich in der Konsole der VM sehr einfach. Doch für die weitere umfassendere Konfiguration, musste ich eine extra Debian-VM mit Xfce-Desktopumgebung aufsetzen – die ist schlank und kann alles was man braucht. Ich klickte mich so bissl durch die Menüs der Firewall, um mir einen Überblick zu verschaffen. Anschließend fing ich mit Hilfe von Gemini an zu lernen, wie man diese Firewall so einrichtet, wie ich sie dann brauche und wie sie im richtigen Leben auch zum Einsatz kommt. Ich legte also zwei VLANs (10 für Hauptnetz und 20 für Gästenetz) plus zweier Debian-LXC-Containern an und sorgte durch Firewall-Regeln dafür, dass die VLANs zwar ins Internet können, jedoch untereinander nicht kommunizieren dürfen. Dies jedoch mit Ausnahme eines VLANs, in dem Netzwerkdienste laufen. Dazu komme ich gleich.

Verzeichnisdienst-Server 1

Als ich dann das Verhalten der VLANs und VMs so hatte, wie es im Firmenalltag vorkommt, legte ich ein zusätzliches VLAN an (hier 2 für Netzwerkdienste). Erst wollte ich 1 nehmen, doch dann lernte ich, dass VLAN-1 für die ungetaggten Verbindungen ist. Nun legte ich zum VLAN-2 einen zusätzlichen Debian-LXC-Container an, auf dem ich im Anschluss OpenLDAP installierte. Auch hier versuchte ich mittels Gemini und Probieren zu lernen, wie man OpenLDAP so handhabt. Die Ersteinrichtung erfolgte erst mal Old School per Shell und LDIF-Konfigurationsdatei. Weitere Konfigurationen nahm ich erst mal mit dem LDAP Account Manager (LAM) vor. Später dann mit phpLDAPadmin, was es nur marginal besser und weniger komfortabel machte. Ich erstellte eine Gruppe und einen Benutzer. Doch OpenLDAP ist scheinbar nackt nicht für den Einsatzzweck geeignet, für den ich es brauche.

OpenLDAP ist nackt erst mal im guten alten Old School Unix-Posix-Modus eingestellt. Das heißt, dass hier vor allem in den Strukturen mit uidNumber und gidNumber gearbeitet wird. Das Problem ist nur, dass moderne Linux-Dienste nicht mit dem Unix-Posix-System zurecht kommen und man sich so z. B. bei OPNsense damit nicht anmelden kann. OPNsense setzt die groupOfNames-Objektklasse voraus und kein posixGroup. Sprich, Benutzer müssen das memberOf-Attribut haben, welches jedoch nur durch die groupOfNames-Objektklasse zustande kommt. Man kann das memberOf-Overlay zwar nachträglich aktivieren, doch da beide Systemstrukturen sind, kann man nur entweder oder machen. Ich hätte daher OpenLDAP nun so umkonfigurieren müssen, dass das posixGroup als „Erweiterung“ (AUXILIARY) zusätzlich zu groupOfNames fungiert.

Aber ehrlich: Den Aufwand wollte ich jetzt nicht machen. Zum einen gibt es einfach komfortablere und modernere LDAP-Dienste und zum Anderen lohnt es sich einfach nicht, da OpenLDAP meist eher nur noch für ältere System als Backend eingesetzt wird. Ich wollte auch eher in Zukunft als Vergangenheit investieren. Zumindest habe ich durch OpenLDAP den Aufbau einer Verzeichnisstruktur gelernt bzw. vertiefen können.

Verzeichnisdienst-Server 2

Irgendwie hatte ich die Schnauze voll von OpenLDAP und sah mich nach einer besseren Lösung um. Microsofts Active Directory (AD) scheidet ja kategorisch aus. Deshalb fiel hier mein Augenmerk auf FreeIPA. FreeIPA ist nicht nur reiner LDAP-Verzeichnisdienst, sondern bietet auch Benutzerauthentifizierung per Kerberos an, ist ein vollwertiger Identity Manager und kann im Falle-X sogar als DNS-Server fungieren. Zwar wird FreeIPA auf vorzugsweise auf Fedora oder Red Hat Enterprise Linux (RHEL) eingesetzt, doch die Syntax in manchen belangen unterscheidet sich nur marginal z. B. von Debian, weswegen mir die Einarbeitung leicht von der Hand ging. Das beste an FreeIPA ist, dass es schon groupOfNames und posixGroup miteinander von Haus aus vereint.

Also die alte OpenLDAP-VM eingestampft (deaktiviert), einen Fedora-LXC-Container für FreeIPA samt fester IP im VLAN-2 angelegt und mit der Einrichtung begonnen. Die Installation und Ersteinrichtung ging viel einfacher und intuitiver von der Hand, als mit dem angestaubten OpenLDAP. Es gab jedoch ein kleines Problemchen mit Chrony. Da meckerte die Installationsroutine immer, weil das Script die Uhrzeit selber einstellen wollte. Doch LXC-Container teilen sich die Zeitangaben mit dem Host. Aus diesem Grund musste ich FreeIPA mit --no-ntp installieren. Das ist aber nur bei Containern der Fall und nicht bei normalen VMs.

Nach der Installation legte ich auch gleich wieder eine Gruppe und einen Benutzer an und pflegte FreeIPA in OPNsense zur Anmeldung ein. Hatte wunderbar im Anschluss geklappt und war vor allem auch einfach einzurichten. Doch bei den Clients wurde es dann nicht so einfach – zumindest bei den LXC-Containern.

LDAP-Anmeldung per Client

Ich hatte ja neben der „Debian-GUI-VM“ auch noch einen Debian-LXC-Container angelegt. Hier startete ich dann die Installation des FreeIPA-Clients und SSSD, das unter Linux die Authentifizierung vornimmt. Doch anfänglich stieß ich hier wiedermal auf Hürden, die in erster Linie wie immer dem LXC-Container geschuldet sind und auf dedizierten Maschinen so nicht vorkommen. Zum einen wieder die Chrony-Thematik und zum Anderen ein Problem mit der Erstellung der GID/UID auf dem Linux-Client.

Nach der Installation versuchte ich dann mich per LDAP anzumelden, doch Linux meldete immer su: cannot set groups: Invalid argument. Das deutete darauf hin, dass Linux die Gruppe auf dem Client nicht anlegen kann. Das ging glaube ich bei OpenLDAP auch nicht. Also wieder Gemini um Rat gefragt und auf Spurensuche gegangen. Bis mir gesagt wurde, dass es schlicht wieder mal am LXC-Container liegt! Grund dafür ist, dass die Container standardmäßig als unprivileged=1 arbeiten und scheinbar nicht wahllos User-Namespaces vergeben können. Es ist normal nur ein Bereich von 100000 bis 165535 vorgesehen. FreeIPA arbeitet aber viel höher ab 1774600000. Das Problem bestand aber bei der Debian-GUI-VM nicht, da es sich hier um eine normale VM und keinen LXC-Container handelte.

Um die Anmeldung nun zum Laufen zu bringen, machte ich einen Haken bei keyctl in den Optionen > Features des LXC-Containers und führte folgende Kommandos in der Shell aus:

echo "root:1774600000:100000" >> /etc/subuid
echo "root:1774600000:100000" >> /etc/subgid
Code-Sprache: Bash (bash)

Im Anschluss bearbeitete ich die Konfigurationsdatei des LXC-Containers über die Proxmox-Shell (nano /etc/pve/lxc/105.conf) und fügte folgendes ans Ende der Datei:

lxc.idmap = u 0 100000 65536
lxc.idmap = g 0 100000 65536
lxc.idmap = u 1774600000 1774600000 100000
lxc.idmap = g 1774600000 1774600000 100000

Dies sagt LXC, dass die Standard-IDs gemappt werden sollen, aber eben in einem viel höheren Bereich. Danach hat die Anmeldung wunderbar geklappt! Auf der Debian-GUI-VM lief alles problemlos – sowohl per Shell als auch GUI.

Kleiner Zwischenfall

Als ich dann das Ergebnis des Tages, nach mehreren Stunden erreicht hatte (hatte den ganzen Samstag gelernt), schaltete ich am Abend das Proxmox-System aus. So ca. 1-2 Stunden später, als ich dann meine Notizen anfertigte und das Gelernte in meinem Joplin-Notizbuch niederschrieb, wollte ich nochmal etwas überprüfen und fuhr das System nochmal hoch. Dabei fiel mir auf, dass ich mich plötzlich nicht mehr per LDAP bei OPNsense anmelden konnte – selbst das Web-UI von FreeIPA war tot.

Deshalb schaute ich mir die FreeIPA-Dienst an. Hm, ipa.service konnte nicht gestartet werden. Der systemd-Log war hier genauso wenig aussagekräftig wie journalctl. Deshalb schaute ich in den http-Log von FreeIPA. Dabei stellte sich heraus, dass der Webserver Probleme mit der Schlüsseldatei hatte und meldete, dass eine falsche Passphrase oder ein leeres Kennwort vorliegt.

Da ich solch ein Problem noch nie in meinem Leben hatte, fragte ich wieder Gemini was da los war und versuchte das Problem zu lösen. Hier wurde mir zu verstehen gegeben, dass in den neusten Enterprise-Linux-Distributionen/Fedora-Releases OpenSSL 3 mit strengeren Kryptographieregeln zum Einsatz kommt. Certmonger hatte den Key in einem älteren PKCS#12/PBE-Containerformat verschlüsselt hinterlegt. Das Hilfsscript ipa-httpd-pwdreader hatte die PIN aus der PIN-Datei zwar auslesen und an den Webserver übergeben können, doch die neue OpenSSL-3-Bibliothek in mod_ssl hat die übergebene Passphrase mit den Fehlern pkcs12 cipherfinal error und wrong tag quittiert. Das Passwort passte strukturell nicht mehr zum geänderten Krypto-Standard des Schlüssels. Letztendlich musste ich dann die Schlüsseldatei unverschlüsselt auf dem Laufwerk ablegen. Im Anschluss lief wieder alles. Das scheint aber ein generelles Problem und nicht ungewöhnlich zu sein.

Was habe ich nun alles gelernt?

Ich habe innerhalb von 2 Tagen jede Menge gelernt. U. a. wie man VLANs einrichtet, wie man OPNsense so konfiguriert, wie man es braucht oder genutzt wird. Ich habe gelernt, wie haaresträubend OpenLDAP sein kann, aber wie LDAP im Grunde funktioniert und wie einfach FreeIPA ist. Aber eben auch, welche Hürden oder Probleme gewisse Systeme mit sich bringen können. Und nebenbei habe ich auch ein wenig Proxmox gelernt. 😉

Draußen in der Realität gestaltet sich manches nochmal ein wenig anders. Doch es ist wahrlich keine Raketenwissenschaft (nun ja, im Gegensatz zu OpenLDAP ;D). Wenn man mal soweit alles verstanden hat, wie was zusammen funktioniert, ist das hardwarenahe Arbeiten sicher nicht schwerer. Wie Netzwerke im Grunde aufgebaut sind, wusste ich schon lange, doch mit diesen Schritten bin ich noch weiter in die Netzwerktechnik eingetaucht.

Es gibt immer noch unzählige Dinge, die ich noch nicht weiß. Aber genau diese Wissenslücken machen es so spannend! Auch wenn ich sicher noch nicht mit jahrelang eingespielten Netzwerk-Spezis auf einer Stufe stehe: Das Fundament steht, die Zusammenhänge sind verstanden und das nächste Bastelprojekt im Home-Lab kann definitiv kommen!