Infosite von Joe Brandes
Eine Website von Trainer Joe Brandes. Infos zu IT-Seminaren von A bis Z.
Das klassische PCS Zertifikat
Von der Hardware und Netzwerktechnik bis zu den den Betriebssystemen Windows, Windows Server und Linux
Ich biete diese Module an!
Zertifikat CMSOD
Module Basiszertifikat
Module Specialist
Ready for Tech Deep Dives...
Dieser Workshop richtet sich an interessierte Teilnehmer, die tiefer in das Betriebssystem Linux eintauchen möchten. Das Seminar soll die Informationen zum Thema Linux (siehe auch Seminar des FITSN) vertiefen und fortführen: Linux als Serversystem und Diensteanbieter in Netzwerken und Infrastrukturen.
Wir werden uns alle notwendigen Themen für die dargestellten und mit Trainees abgesprochenen Einsatzzwecke vornehmen und dann die Serverdienste implementieren und nutzen. Und natürlich nutzen wir auch die Gelegenheit die tägliche Nutzung unserer Linux Systeme zu optimieren.
Die dargestellte Topologie soll den Roten Faden für unser Seminar darstellen und wird aktiv mit den Trainees im Rahmen des Seminars erarbeitet. Die Dokumentation wird den Trainees in hoher Qualität (PDF) und als LibreOffice Draw Dokument für eigene Anpassungen (firmaxy.local) bereitgetstellt.
Hier die Rahmendaten unseres Seminars:
Ort: VHS Braunschweig, Raum 2.11Zeiten: Mo, 12.01. bis Fr, 16.01.2026; jeweils 08.30 - 16.00 UhrDownloads: OneDrive (Trainer Joe Brandes)
Ich werde unser Seminar in diesem Beitrag wieder ausführlich begleiten...Ihr Trainer Joe Brandes
Topics
Im Gegensatz zu vielen anderen Seminaren haben wir für diese Woche eigentlich nur eine Grundidee und wollen uns unseren Roten Faden selber stricken.
Diesen Begriff hört man in meinen Seminaren häufiger ;-).
Unter einem roten Faden versteht man ein Grundmotiv, einen leitenden Gedanken, einen Weg oder auch eine Richtlinie. „Etwas zieht sich wie ein roter Faden durch etwas“ bedeutet beispielsweise, dass man darin eine durchgehende Struktur oder ein Ziel erkennen kann. Quelle: Wikipedia - Roter Faden
Unter einem roten Faden versteht man ein Grundmotiv, einen leitenden Gedanken, einen Weg oder auch eine Richtlinie. „Etwas zieht sich wie ein roter Faden durch etwas“ bedeutet beispielsweise, dass man darin eine durchgehende Struktur oder ein Ziel erkennen kann.
Quelle: Wikipedia - Roter Faden
Gemeint ist hier: Das grundsätzliche Verständnis der fraglichen IT-Techniken. Am Besten gleich so, dass man auch nach einer Zeit ohne Beschäftigung mit diesen Techniken sehr schnell wieder in Fahrt kommen.
Notwendige und/oder mögliche Inhalte in lockerer Schüttung und aus Sammlungen aus Vorseminaren und Trainee-Wünschen:
Schauen wir mal... und wir haben ja auch nur 5 Tage 😜
Für den Linux Workshop benötigen wir "Baupläne / Konfigurationen" für die verschiedenen Service-Umsetzungen (siehe DHCP, Routing, DNS, ...). Und da werden wir uns an einer Distribution orientieren - sozusagen eine Seminardistribution vorgeben.
Wenn man meine Info-Portale zu Linux Seminaren über die Jahre verfolgt hat, dann wird man dort oft openSUSE im Rahmen der Einführungsveranstaltungen finden. Ausnahmen stellten hier nur LPIC-Seminare oder andere vertiefende Linux (Server, Workshop) Seminare dar, in denen wir häufig mehrere Distros installieren, kombinieren und kennenlernen. Und in diesen Bereichen sind wir dann auch sehr schnell bei Debian gelandet!
Meine Hauptentscheidungskriterien für die Auswahl einer (Trainings-)Distribution:
Die aktuellen Entwicklungen bei Suse - und übrigens auch bei vielen anderen Company-driven Distros (siehe CentOS) - führt zu einer stärkeren Verlagerung zu der maßgeblichen Community-driven Distro überhaupt: Debian. Das soll ausdrücklich keine generelle Kritik an Company-drive Distros darstellen.
Debian ist mittlerweile über 30 Jahre verfügbar (Geb. August 1993) und hat über Jahrzehnte seine Zuverlässigkeit und Nutzbarkeit unter Beweis gestellt. Und natürlich stellt Debian die Säule und den Ursprung für Hunderte von Distributionen der Debian-Family dar: Debian Derivate wie Ubuntu(s), Kali, LMDE, MX Linux, Antix Linux, elementary OS,...
Hier also die Vorgaben zu den im Seminar eingesetzten Distros bzw. Betriebssystemen:
Für den Einsatz im (virtuellen) Firmennetzwerk und für die nötigen Infrastrukturen werden wir folgende Standard-Distributionen einsetzen:
Virtualisierungstechniken gibt es viele und jede dieser Lösungen hat seine/ihre Vor- und Nachteile:
Und wieder: diese Aufstellung erhebt nicht den Anspruch auf Vollständigkeit. Und es sollen hier auch keine detaillierten Darstellungen ausgeführt werden. Und überhaupt haben wir für Container (Docker) oder Virtualisierungen entsprechende Seminare im Angebot oder auf Anfrage gerne bereit 😜.
In Seminaren im Dunstkreis der PC Systembetreuer / Fachkraft IT-Systeme und Netzwerke Seminare greifen wir oft zu den Hyper-V-Lösungen für die entsprechenden Windows Host-Systeme. In unserem Linux Workshop wollen wir aber natürlich zur hauseigenen KVM/qemu Technik greifen.
Topics:
Anm. / Testinstallationen Debian 13 vor Seminar Linux August 205 (19.08.2025):
Anm.: durch die Updates während der Installationen wird im Seminar etwas Bandbreite gemindert und die Installzeit könnte sich dadurch vielleicht verlängern.
WICHTIG: Koordination von Wechselplatten für die Woche! Ggf. Wechsel der SSDs am Seminartagende checken!
Die Installationspraxis wird eine UEFI-basierte Installation von Debian 13 Trixie durchführen. Der folgende Screenshot zeigt die erste Debian 13 Variante auf dem Images Repo von Debian.
Technik:
Wie auch die sonstigen digitalen Infos aus dem Seminar kann man alle weiteren digitalen Unterlagen online bei meine bekannten Quellen finden und downloaden. Die TN bekommen eine ausführlichen Darstellung und Praxis für die Installation der Debian 13 Distro.
⏳ Bitte bei der Installation lieber langsam und fragend die einzelnen Schritte mitvollziehen. ⚖️ Die Installation führen wir parallel miteinander durch.🆕 Ein paar Stunden vor Seminarbeginn am 12.01.2026 wurde Debian 13.3 veröffentlicht: 10.01.2026 14:08!
Kurzdarstellung: Installation Debian 13 Bookworm (UEFI) mit Standard Desktop Gnome
Der Enwurf wurde beispielhaft für TN skizziert und als LibreOffice Draw Entwurf online für eigene Anpassungen durch die Trainees bereitgestellt.
‼️WICHTIG: Suffix/Prefix für Techniken mit Hilfe der PC-Platznummern - siehe Dozentenarbeitsplatz: 17
Beispiel für Bezeichner und Syntax am Dozentenplatz PC #17:
firma17.local
router-17
srv-17-01, client-17-01
192.168.17.0 / 24
Das kann dann in einer individuellen virtuellen Umsetzung so aussehen:
Anm.: dieses Szenario wird im Laufe des Seminars erarbeitet und aktualisiert.
‼️WICHTIG: Für die dargestellten Netzwerkumsetzungen müssen wir noch die passenden Netzwerkverbindungen und KVM/qemu-Bridges erstellen!
... ein kurzer Überblick über die wichtigsten Ordner/Dateien:
/etc/networks
/etc/hosts
/etc/resolv.conf
/etc/network/interfaces
Für Netzwerkkonfiguration gibt es verschiedenste technische Umsetzungen mit Linux:
/dev/eth0
eth1
enp0s3
/etc/NetworkManager
/etc/NetworkManager/system-connections/verbindungsdatei
nmcli
nmtui
/etc/sysconfig/network-scripts
ifcfg-eth0
ifcfg-eth1
Im Seminar werden es mit den folgenden Umsetzungen versuchen:
Insbesondere bei der Erstausstattung unseres Host-Trainingssystem müssen uns also bei den nötigen Netzwerkkonfigurationen für die Virtualisierungen mit dem Netzwerkmanager-Tools anfreunden.
Erste Netzwerkanalysen mit Linux nach einer Basisinstallation auf unserem Trainings-PCs:
ip address show
ip a s
/sbin/ifconfig
ip route show
ip r s
/sbin/route -n
cat /etc/resolv.conf
Natürlich gibt es auch diverse Tools/Skripte, die diese Aufgaben/Aufrufe zusammenlegen. Aber wir wollen auch immer die Basics bemühen und "Linux" wirklich verstehen. Durch Analyse von /etc/resolv.conf erhalten wir die Information über welche der möglichen Netzwerkkonfigurationstechniken unser System seine IP-Umgebung erhält
Da wir als Host-System einen Debian Rechner mit Gnome Desktop Environment nutzen erhalten wir als Netzwerkkonfiguration den NetworkManager. Gnome hat ein Progrämmchen in der Taskleister verfügbar für die grundsätzliche Konfiguration mit Benutzerrechten als auch SuperUser-Rechten.
Als Linux-Kenner greifen wir aber natürlich zur Konsole und den NetworkManager-CLI-Tools:
Für die Installation und Inbetriebnahme von KVM/qemu inklusive Tools und Konfigurationen gibt es diverse Anleitungen im Netz.
🔗 Beispiel: https://linuxconfig.org/setting-up-virtual-machines-with-qemu-kvm-and-virt-manager-on-debian-ubuntu
Meine Darstellungen beschränken sich auf das Notwendige, was ich manchmal auch als "Q & D" bezeichne (Quick and Dirty). Auch aus diesem Grund ist eine Abweichung bei den Distros natürlich immer zu bedenken und anzupassen.
# Base Install sudo apt install qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils virt-manager libguestfs-tools # Memberships sudo adduser $USER libvirt sudo adduser $USER kvm sudo adduser $USER libvirt-qemu # Testing / after reboot sudo systemctl status libvirtd virsh list --all
Anm.: gegenüber den meisten Anleitungen habe ich hier das Paket libguestfs-tools hinzugefügt. Es gibt uns zusätzliche libvirt-Tools wie z.B. Werkzeuge zum SystemPreppen oder SystemKonfigurieren (Änderungen an Systemplatte im Shutdown Modus!).
Wenn man gerade am Testen ist, sollte man auch mal den virt-manager starten - die GUI für die KVM/qemu Technik.
virt-manager
Falls man mit virsh Probleme hat dann hier ein Tipp für virsh Umgebungsvariable:
# make virsh *remember* the right qemu context if [ $(command -v qemu-img) ] then export LIBVIRT_DEFAULT_URI='qemu:///system' fi
Ich trage solche Extras gerne in die ~/.bash_aliases ein, die Debian automatisch über die ~/.bashrc einliest.
An dieser Stelle noch ein paar Links zum hier dargestellten Thema "KVM/qemu"
Am Ende der folgenden Vorbereitungen auf dem KVM-Host wollen wir über unseren virt-manager drei Virtuelle Netzwerke auswählen können.
Legende: ❎ muss noch komplett erstellt werden / ✅ muss noch aktiviert/gestartet werden
Für das Netzwerk br0 müssen wir sowohl die physikalische Netzwerktechnik rekonfigurieren und können danach die KVM Netzwerktechnik definieren.
Die Internetanbindung für die neuen VMs werden durch das KVM/qemu Standard-Netzwerk default bereitgestellt. Das ist quasi ein integrierter NAT-Router (siehe heimischer DSL-Router aka FritzBox). Allerdings muss man checken, ob dieses default Netzwerk auch gestartet wurde:
sudo virsh net-list --all
Falls das Netzwerk noch nicht gestartet ist, kann man die nötigen Einstellungen mit virsh CLI vornehmen.
sudo virsh net-start default
sudo virsh net-autostart default
Eine funktionsfähige Auflistung für das "default" Netzwerk sollte wie folgt aussehen.
sudo virsh net-list Name Status Automatischer Start Bleibend ---------------------------------------------------- default Aktiv ja ja
Den zu erwartenden IP-Adressbereich für so angeschlossene Maschinen kann man sich über IP-Adressanalyse innerhalb der VM (ip a s zeigt IP-Adresse des KVM-NAT-Routers) oder auch mit dem virsh Befehl auf dem KVM Host anzeigen lassen: virsh net-dumpxml default.
virsh net-dumpxml
# Weitere Tests / Analysen ip address show sudo virsh net-dumpxml default sudo virsh domifaddr router-17 # IP Analyse für VMs ohne KVM IP-Ausstattung über qemu-agent von Linux-OS sudo virsh domifaddr router-17 --source agent
Die Adress-Analyse erhält man über virsh domifaddr <vm-name>. Wenn IP-Adressen später nicht mehr von den KVM-Mechanismen verteilt werden kann man die IP-Infos über die automatisch auf Linux-Systemen mitinstallierten Qemu-Guest-Agents:
virsh domifaddr <vm-name>
sudo virsh domifaddr <vm-name> --source agent
Die qemu-guest-agent Software ist automatisch auf Linux-Systemen installiert. Auf Windows muss man diese Software eigenständig nachinstallieren/bereitstellen: siehe https://pve.proxmox.com/wiki/Windows_VirtIO_Drivers. Man kann bei Fedora eine ISO mit der Virtio-Win Software herunterladen (Fedora Project: https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/).
💾 STORAGE-Pool: Für die KVM ISOs und Festplatten QCOW2 benötigt man Storage-Pools, die man sich am besten selber konfiguriert: (z.B.) /kvm-storage. Auch diese Umsetzungen werden in diesem Seminar eher Q&D gemacht ‼️Aktuelle Empfehlung nach Q&D Umsetzungen im Seminar: gerne auch einfach Standard-Storage-Pool (Verzeichns: /var/lib/libvirt/images) nutzen. Bei eigenen Ordnerstrukturen kann es nach Snapshots (Technik: extern) zu Berechtigungsproblem kommen. Interne Snapshots zeigten keine Probleme.
💾 STORAGE-Pool: Für die KVM ISOs und Festplatten QCOW2 benötigt man Storage-Pools, die man sich am besten selber konfiguriert: (z.B.) /kvm-storage. Auch diese Umsetzungen werden in diesem Seminar eher Q&D gemacht
/kvm-storage
‼️Aktuelle Empfehlung nach Q&D Umsetzungen im Seminar: gerne auch einfach Standard-Storage-Pool (Verzeichns: /var/lib/libvirt/images) nutzen. Bei eigenen Ordnerstrukturen kann es nach Snapshots (Technik: extern) zu Berechtigungsproblem kommen. Interne Snapshots zeigten keine Probleme.
Wenn die Testaufrufe soweit funktioniert haben, dann können wir bereits eine erste schnelle Testinstallation durchführen.
Erste VM-Installation(en) - Virtuelles Netzwerk 'default': NAT
Nach Download des entsprechenden Debian-Install-ISOs werden diverse Grundsysteme in Betrieb genommen:
Für Basisinstallationen kann man also einfach die VMs an den Swicht "default" (NAT-Router) unseres KVM-Hosts anbinden. Später kann man die Netzwerkverbindungen dann umkonfigurieren.
Für unsere VM-Topologie benötigen wir allerdings noch zwei neue Netzwerke. Im Fall unser "Bridge"-Anbindung an den physikalischen Netzwerkadapter unseres KVM-Hosts müssen wir noch die Ethernet-Connections mittels NetworkManager nmcli vorbereiten.
Die beiden Virtuellen Netzwerke br0 und firma17 aus der unsere Netzwerkliste müssen wir noch erstellen. Auf einem Debian Server ohne Grafikdesktop würden wir einfach schnell die manuelle Netzwerkkonfiguration mittels /etc/network/interfaces anpassen und fertig. In unserem Fall nutzen wir allerdings einen KVM-Host mit Gnome Desktop Environment und müssen mit dem NetworkManager Tool nmcli die Ethernet-Verbindung für den Bridge-Mode speziell vorbereiten.
🔗 Siehe z.B.: https://www.cyberciti.biz/faq/how-to-add-network-bridge-with-nmcli-networkmanager-on-linux/
Als erstes sollten wir die aktuelle Ethernet-Schnittstelle für unsere Netzwerkverbindung herausfinden und uns eine Übersicht zu der genutzten NetworkManager Connections verschaffen. Diese NetworkManager-Connections sind quasi clever oben drauf gesetzt und stellen letztlich die Nutzung der NICs dar. Durch diese klevere Umsetzung kann man denselben NIC über mehrere NetworkManager Connections mit unterschiedlichen Konfigurationen (z.B. individuelle DNS Server) nutzen.
Erstellen wir uns die Bridge-Connections:
# IP Analysis ip address show # Overview NetworkManager Connections nmcli con show # Add a new bridge: nmcli con add type bridge ifname br0 # Create a slave interface / check your adapter nic name! nmcli con add type bridge-slave ifname enp1s0 master br0 # Turn on br0 - that can take a moment in this case! nmcli con up bridge-slave-enp1s0
Für den Bridge-Slave muss man natürlich den Namen des NIC vom System (KVM-Host) nehmen - der könnte also auch enp4s0 oder enp7s0 heißen! Im Grunde erstellen wir uns einen Switch (aka Multiport-Bridge) br0, über den man sich vernetzen kann. Für den KVM-Host wird mittels Bridge-Slave dann eine Ethernet-Verbindung (Connection) erzeugt, die quasi indirekt den Original-NIC nutzt.
Nach diesen Konfigurationen sollte man wieder die Netzwerkkonfiguration auf dem KVM-Host testen und analysieren.
Die Bridge br0 kann man jetzt als Netzwerktechnik für KVM definieren! Hierzu erstellt man sich eine XML-Datei mit der notwendigen Konfigurationsbeschreibung und definiert per virsh net-define den neuen gewünschten KVM-Switch.
virsh net-define
<network> <name>br0</name> <forward mode="bridge"/> <bridge name="br0" /> </network>
Und mit dieser XML-Datei lässt sich dem KVM/qemu System ein neues Virtuelles Netzwerk definieren:
sudo virsh net-define /tmp/br0.xml sudo virsh net-start br0 sudo virsh net-autostart br0 sudo virsh net-list –-all
Die Befehle sollten für sich selbst sprechen! Auch der virt-manager sollte bei der Netzwerkadapterkonfiguration jetzt ein "Virtuelles Netzwerk 'br0': Bridge Netzwerk" anzeigen!
Tipp: Wenn man Netzwerk-"Schleifen/Verweilzeiten" beim Booten/Shutdown durch br0 im KVM-Host System erhält, sollte man die Konfiguration der bridge-br0 für STP auf off stellen. Das kann man am einfachsten über das CLI-Tool nmtui erledigen.
‼️ ACHTUNG: Die "Erstnutzung" einer solchen Virtuellen Bridge kann leider manchmal einen sehr guten Moment (!) dauern. Man bekommt ggf. APIPA 169.254.x.y Adressen angezeigt! Nach einer Weile sollte dann aber der Bridge-Modus funzen!
Jetzt benötigen wir noch unseren privaten, isolierten Layer2-Switch für unsere Testumgebung. Das gestaltet sich deutlich einfacher, da wir uns nur einfach eine Bridge (einen Switch) erfinden.
<network> <name>firma17</name> <bridge name='virbr10' stp='on' delay='0'/> </network>
Danach folgen wieder die Befehle von oben:
sudo virsh net-define ./firma17.xml sudo virsh net-start firma17 sudo virsh net-autostart firma17 sudo virsh net-list –-all
Und auch hier können wir über den virt-manager gerne die Verfügbarkeit prüfen: Virtuelles Netzwerk 'firma17': isoliertes Netzwerk".
Und ja ich weiß: in meinem Beispiel lautet das Netzwerk 'firma17' - ich hatte aber gerade keinen Screenshot parat 😜.
Jetzt haben wir die nötigen Netzwerktechniken für unsere KVM/qemu Technik erstellt. Jetzt können wir mit der Konfiguration des Routers fortsetzen.
Unser Router-VM soll die Außenanbindung unsers Firmennetzes (s.a. Edge-Router) und damit auch die Sicherheit gegenüber dem öffentlichen Netz herstellen. Hierzu bedienen wir uns des modernen Nftables Service.
Außerdem soll die Maschine über eine KEA DHCP Service unser Firmennetz mit passenden IP-Konfigurationen versorgen.
Diese Dienste verlangen nach statischen IP-Konfigurationen für die NICs unseres Routers. Da wir uns hierfür eine Serverinstallation (ohne GUI) installiert haben, müssen wir die Netzwerkkonfiguration manuell über die klassischen Konfigurationsdateien herstellen:
Anmerkung für die späteren Nftables/Firewall Konfigurationen: in der späteren Praxis (Cloud, Enterprise, Virtualisierungsserver) werden die Arbeiten per SSH an den Servern durchgeführt. Da sollte man mit besonderer Vorsicht vorgehen, sodass man sich nicht womöglich selbst den Zugang per SSH verweigert und somit von der Maschine aussperrt. Ähnliche Fragen und Probleme stellen sich auch bei (hauseigenen) Firewalltechniken von ProxmoxVE und Anderen. Da kann man sich schnell mal aus dem Web-Backend und/oder der SSH-Verbindung zum Server aussperren, wenn man mal schnell die falschen Einstellungen commited.
Die Topologie - bzw. deren Umsetzungen - werden mit den Trainees interaktiv erarbeitet und umgesetzt. Wir orientieren uns stets am Anreißerbild zu diesem Beitrag bzw. zur verteilten Dokumentation im Seminar.
An dieser Stelle zur Abwechselung ein älteres Scribble für die technischen Umsetzungen. Im Gegensatz zu unserer aktuellen Umsetzungen mit Debian/KVM handelt es sich bei der folgenden Darstellung um die Kombination openSUSE/VirtualBox.
Aber wie immer gilt: es geht um das Prinzip - den Roten Faden eben!
Soweit die Erinnerung zur Planung anhand klassischer Technikumsetzungen. Wo liegen die Aktualisierungen bzw. Neuerungen und Anpassungen gegenüber diesem Scribble:
Ziel: Umsetzung der Konfiguration der Debian-Systeme mittels klassischer, manueller Konfigurationen mit Hilfe der Konfigurationsdatei /etc/network/interfaces
Es folgt ein Auszug aus der Konfiguration: (Anm.: die Zeile auto ... wird heute oft weggelassen)
... auto enp0s3 allow-hotplug enp0s3 iface enp0s3 inet static address 192.168.17.10 netmask 255.255.255.0 gateway 192.168.17.1 ...
Für die Konfiguration mittels DHCP sieht ein Beispiel wie folgt aus:
... auto enp0s3 allow-hotplug enp0s3 iface enp0s3 inet dhcp ...
Für diese Netze bitte auch weitere Tools kennen: ip,... (klassisch: ifup, ifdown)
ip,... (klassisch: ifup
ifdown)
Beachten: bei Verwendung von NetworkManager (z.B. unter Gnome-Desktop) bitte abweichende Konfigurationsdateien und Tools beachten! Im Grunde genau die umgekehrte Problematik wie beim KVM-Host, wo man eigentlich nur schnell Konfigurationsdateien tunen muss - aber wir mussten über die NetworkManager Tool (nmcli) die richtigen Konfigurationen erstellen.
Den DNS Nameserver stellt man über die /etc/resolv.conf ein. Über Kommentare kann man recht schnell die genutzte Technik erkennen und dann mit eigenen Einträgen ersetzen.
# Use my stuff domain firma17.local search firma17.local nameserver 8.8.8.8 nameserver 1.1.1.1
Später muss man über DHCP bzw. Statische Konfigurationen ggf. eigenen DNS-Service eintragen/verwenden!
Anmerkung nach Tests: (virtuelle) Debian Server-Installationen haben anscheinend ADHS 😜: wenn man die /etc/network/interfaces und die resolv.conf angepasst hat, dann findet sich nach einem (ersten) Neustart immer noch DHCPD Eintrag statt eigener Zeilen. In einem zweiten Rutsch sollte der Mechanismus dann die Finger von unserer /etc/resolv.conf lassen!
Mit einer etwas ernsthafteren Note: die Umstellung auf "statisch" scheint der Debian Server erst nach einem (ersten) Neustart - siehe hiier auch SystemD - zu verstehen. Da scheint es einen dhcpd-Hook zu geben, der die resolv.conf vor dieser Erkenntnis verarbeitet.
Wenn der Router (Server) manuell konfiguriert wird, benötigen wir dieselben Grundkonfigurationen für unsere KVM Netzwerke wie vorab über die NetworkManager und KVM/qemu Techniken beschrieben. Aber wie gesagt: nur mit der Standardkonfiguration /etc/network/interfaces und den Partnertools (z.B. ip route).
ip route
Die folgenden beispielhafte Basiskonfigurationen finden sich auf ProxmoxVE Servern.
Bridged-Technik mit /etc/network/interfaces :
iface enp89s0 inet manual #Bottom Nic of NUC iface enp88s0 inet manual #Top Nic of NUC auto vmbr0 iface vmbr0 inet static address 192.168.2.11/24 gateway 192.168.2.1 bridge-ports enp89s0 bridge-stp off bridge-fd 0 #WAN (over DSL Router)
Man erkennt zwei Adapter enp89s0 und enp88s0 mit Kommentierungen, die man auch über die grafische Verwaltungsoberfläche von ProxmoxVE definieren kann. Die Adapter sind mit manual konfiguriert. Der Server hat anscheinend zwei Netzwerkadapter und diese sind übereinander auf der Rückseite ausgeführt
Danach wird die Bridge vmbr0 definiert. Die Bridge erhält eine IP-Adresse (für die öffentliche Seite), eine Subnetzmaske (hier CIDR /24) und eine Gateway (Router) Definierung. Die Bridge wird mittels bridge-ports enp89s0 an den physikalischen Adapter enp89s0 gebunden. Für die Bridge wird STP (Spanning Tree Protocol) ausgeschaltet und das FD (Forward Delay) auf 0 gesetzt.
Isolierter Switch mit /etc/network/interfaces :
auto vmbr10 iface vmbr10 inet manual bridge-ports none bridge-stp off bridge-fd 0
In Kürze: einfachste Bridge-Technik ohne Anbindungen an physikalische Adapter und ohne weitere Konfigurationen.
Man kann die Terminalauflösungen in /etc/default/grub eintragen: Anm.: eigentlich nicht nötig, da wir einfach SSH nutzen werden.
/etc/default/grub
... GRUB_GFXMODE=1024x768 GRUB_GFXPAYLOAD_LINUX=keep ...
Danach mit update-grub die Grubkonfiguration erneuern und reboot .
update-grub
reboot
Tipp für Trainer: Auf (Trainer-)VMs kann für die bessere Lesbarkeit am Beamer noch mit dpkg-reconfigure console-setup noch eine massigere Schrift für die Konsole definiert werden.
dpkg-reconfigure console-setup
... Paket: kea-dhcp4-server (aus Debian 13 Repo)
Auch dieser DHCP Server stammt vom ISC (Internet Systems Consortium). Das ISC hatte in 2022 das End of Life für den klassischen (wortwörtlichen) ISC DHCP Server verkündet.
Widmen wir uns als der modernen DHCP Server Variante KEA aus dem Hause ISC. Die Software für KEA und andere Programme liegt bei Cloudsmith. Allerdings beziehen wir den KEA Server aus den Debian Original Repos in leicht abgehangener Version. Bitte auf die abweichenden Paketnamen achten: Debian Repo kea-dhcp4-server vs. Cloudsmith isc-kea-dhcp4-server!
Eine Installation und Grundkonfiguration ist mit folgenden Befehlen und Konfigurationsvorlagen schnell erledigt. Die originale kea-dhcp4.conf enthält eine kommentierte Vorlage für alle Einstellungen des KEA Servers.
kea-dhcp4.conf
# Original-Repo Debian nutzen sudo apt install kea-dhcp4-server # Konfigurationsordner KEA - Berechtigungen beachten! cd /etc/kea # oder gleich root mit sudo -i # Original sichern sudo mv kea-dhcp4.conf kea-dhcp4.conf.bak # eigene Konfiguration erstellen sudo nano kea-dhcp4.conf # bereitgestellte Konfig einfügen und anpassen # Rechte für KEA Server korrigieren sudo chown _kea:root kea-dhcp4.conf
Eine beispielhafte Grundkonfiguration nehme ich gerne von der Server-World.info Website.
🔗 KEA Grundkonfiguration - Beispiel: https://www.server-world.info/en/note?os=Debian_13&p=kea&f=1
Diese Konfiguration muss natürlich noch auf unser Szenario angepasst werden.
Und selbstverständlich handelt es sich auch um eine Formatierung (JSON), die man nicht verbasteln darf!
# create new - like www.server-world.info/en/note?os=Debian_13&p=kea&f=1 { "Dhcp4": { "interfaces-config": { # specify network interfaces to listen on "interfaces": [ "enp7s0" ] }, # settings for expired-leases (follows are default) "expired-leases-processing": { "reclaim-timer-wait-time": 10, "flush-reclaimed-timer-wait-time": 25, "hold-reclaimed-time": 3600, "max-reclaim-leases": 100, "max-reclaim-time": 250, "unwarned-reclaim-cycles": 5 }, # T1 timer that govern when the client begins the renewal processes (sec) "renew-timer": 900, # T2 timer that govern when the client begins the rebind processes (sec) "rebind-timer": 1800, # how long the addresses (leases) given out by the server are valid (sec) "valid-lifetime": 3600, "option-data": [ { # specify your DNS server # to specify multiple entries, separate them with commas "name": "domain-name-servers", "data": "8.8.8.8, 1.1.1.1" }, { # specify your domain name "name": "domain-name", "data": "firma17.local" }, { # specify your domain-search base # to specify multiple entries, separate them with commas "name": "domain-search", "data": "firma17.local" } ], "subnet4": [ { "id": 1, # specify subnet that DHCP is used "subnet": "192.168.17.0/24", # specify the range of IP addresses to be leased "pools": [ { "pool": "192.168.17.100 - 192.168.17.199" } ], "option-data": [ { # specify your gateway "name": "routers", "data": "192.168.17.1" } ] } ], # logging settings "loggers": [ { "name": "kea-dhcp4", "output_options": [ { "output": "/var/log/kea/kea-dhcp4.log" } ], "severity": "INFO", "debuglevel": 0 } ] } }
Interessanterweise stört sich der KEA Server nicht an den Kommentaren - bei JSON sind Kommentare gemäß Spezifikation (RFC 8259) ja nicht zulässig. Hier nutzen wir wohl nur die JSON-Schreibweise-Idee (siehe https://leapcell.io/blog/de/json-kommentare-verstehen). Die Original kea-dhcp4.conf kommentiert mit //!
//
Formatierung und Basiskonfiguration: https://kb.isc.org/docs/kea-configuration-sections-explained
Nach der Anpassung der Konfiguration muss der Server neu gestartet werden: systemctl restart kea-dhcp4-server
systemctl restart kea-dhcp4-server
Der KEA Server kann unterstüzt diverse Backends zum Speichern der Verleihinfos.
Der Standard ist Memfile und legt die Daten in einer CSV-Datei ab: /var/lib/kea/kea-leases4.csv
/var/lib/kea/kea-leases4.csv
root@router:~# cat /var/lib/kea/kea-leases4.csv address,hwaddr,client_id,valid_lifetime,expire,subnet_id,fqdn_fwd,fqdn_rev,hostname,state,user_context,pool_id 10.0.10.100,52:54:00:d2:ee:a7,01:52:54:00:d2:ee:a7,3600,1767455442,1,0,0,debiangnome,0,,0 10.0.10.100,52:54:00:d2:ee:a7,01:52:54:00:d2:ee:a7,3600,1767455550,1,0,0,client-17-01,0,,0
Man erkennt die Verteilung an dieselbe Hardware/Machine (siehe MAC bzw. Client-ID) nach erfolgter Namensänderung!
Und selbstverständlich kann man die Ausgabe mit diversen Tools verbessern - sowohl im Terminal als auch mit GUI Tools. Für den Anfang optimieren wir die Ausgabe einfach mal wieder im Terminal.
root@router:~# cat /var/lib/kea/kea-leases4.csv | column -s "," --table address hwaddr client_id valid_lifetime expire subnet_id fqdn_fwd fqdn_rev hostname state user_context pool_id 10.0.10.100 52:54:00:d2:ee:a7 01:52:54:00:d2:ee:a7 3600 1767455442 1 0 0 debiangnome 0 0 10.0.10.100 52:54:00:d2:ee:a7 01:52:54:00:d2:ee:a7 3600 1767455550 1 0 0 client-17-01 0 0 10.0.10.100 52:54:00:d2:ee:a7 01:52:54:00:d2:ee:a7 3600 1767456450 1 0 0 client-17-01 0 0 10.0.10.100 52:54:00:d2:ee:a7 01:52:54:00:d2:ee:a7 3600 1767457350 1 0 0 client-17-01 0 0 10.0.10.101 52:54:00:96:90:6d 01:52:54:00:96:90:6d 3600 1767457394 1 0 0 0 0 10.0.10.100 52:54:00:d2:ee:a7 01:52:54:00:d2:ee:a7 3600 1767457532 1 0 0 client-01 0 0 10.0.10.102 52:54:00:96:90:6d ff:00:96:90:6d:00:01:00:01:30:eb:f3:ce:52:54:00:96:90:6d 3600 1767458143 1 0 0 srv-01 0 0
Dadurch lassen sich die Infos schneller und besser zuordnen! Man erkennt die subnet_id auf, die wir in den Optionen für unser Subnetz deklariert haben! Außerdem kann man für Maschinen während der Installation noch keinen zugeordneten hostname erkennen. Und ganz offensichtlich meldet sich letztlich der Rechner srv-01 mit kompletter Client-ID (und nicht nur HW-Adresse), sodass die VM nochmals eine neue IP erhält!
Wenn man ein Stündchen später nachschaut ist der Verleiheintrag für den Server srv-01 (natürlich statische Konfiguration durchgeführt) verschwunden.
Wir wollen bestimmten Systemen mittels KEA Server dynamisch - also automatisch - IP-Konfigurationen verteilen. Die IP-Adressen wollen wir aber vorab - außerhalb unseres Standard-Scopes - festlegen.
🔗 Anleitung (z.B.): https://www.server-world.info/en/note?os=Debian_13&p=kea&f=3
Das wichtigste ist hier wieder die saubere Integration des nötigen Blocks mit allen richtigen Klammerungen und Kommata. Bitte die Dateien vorab immer sichern/kopieren!
... ], "subnet4": [ { "id": 1, # specify subnet that DHCP is used "subnet": "192.168.17.0/24", # specify the range of IP addresses to be leased "pools": [ { "pool": "192.168.17.100 - 192.168.17.199" } ], "option-data": [ { # specify your gateway "name": "routers", "data": "192.168.17.1" } ], "reservations": [ { "hw-address": "52:54:00:c9:77:00", "ip-address": "192.168.17.40" } ] } ], # logging settings ...
Ich wiederhole: wir müssen den Abschnitt "reservations" exakt positionieren und technisch listen (",") und Klammern (geschweift und eckig).
Eine kleine Linkliste zum KEA DHCP Server
Kurzinfo von Website https://www.isc.org/stork/ - kein Schulungs-/Seminareinsatz - wenn überhaupt für Big-Enterprise interessant.
Überwachung kritischer Netzwerksysteme
Wenn Ihr DHCP-System nicht korrekt konfiguriert ist, Erreichbarkeitsprobleme auftreten oder ein Server ausgefallen ist, handelt es sich um ein dringendes Problem. Es ist entscheidend, die Ursache schnell zu finden und den Dienst wiederherzustellen, bevor andere Netzwerkdienste, die auf DHCP angewiesen sind, ausfallen. Mit Stork können Sie ein DHCP-System mit mehreren Servern schnell überwachen und Statusänderungen sofort erkennen.
Hauptfunktionen
Stork Links:
📢 Es folgen Ausarbeitungen zum Klassischen ISC DHCP Server📚 Anmerkung: aus Info- und Recherche-Gründen hier belassen!
... Paket: isc-dhcp-server
Installation auf vm-router-17 - wichtig: an richtigem Adapter (LAN-Seite) zur Verfügung stellen!
vm-router-17
Vorbereitungen (s.o.) - Konfiguration des Routers auf statische LAN-IP: 192.168.17.1 / 24
Installation mittels apt install isc-dhcp-server - die Installation quittiert am Ende Fehler, da saubere Konfigurationen des DHCP-Servers noch fehlen.Wir beginnen mit der Konfiguration des NIC-Adapters für DHCP: /etc/default/isc-dhcp-server (hier: lanseitiger enp0s8 von vm-router-17)
apt install isc-dhcp-server
/etc/default/isc-dhcp-server
Die eigentliche Konfiguration liegt in Standardverzeichnis: /etc/dhcp/dhcpd.confBeispieleinträge / Konfigurationen (wurden vorher sauber bei Entwurf geplant)
/etc/dhcp/dhcpd.conf
option domain-name "firma17.local"; option domain-name-servers 8.8.8.8, 10.100.200.1; ... subnet 192.168.17.0 netmask 255.255.255.0 { range 192.168.17.100 192.168.17.149; option routers 192.168.17.1; }
Kurzanleitungen im Web (Link) für Debian und den ISC DHCP Server...
Der DHCP-Daemon lässt sich mit den üblichen Target/Runlevel Tools analysieren:systemctl status|restart|stop|enable|disable isc-dhcp-server (Target/Dienst status|...)journalctl -u isc-dhcp-server (Journal / Logging auslesen - Anm.: nicht persistent!)
systemctl status|restart|stop|enable|disable isc-dhcp-server
journalctl -u isc-dhcp-server
Übersicht zu Releases des DHCP-Servers:/var/lib/dhcp/dhcpd.releases (alle Infos inkl. MACs oder Lease-Times)
/var/lib/dhcp/dhcpd.releases
Übung: nach DHCP-Server Implementierung Test mit bereits installierten VM-Client-Rechnern (z.B. debian-gnome) und Analyse der IP-Konfigurationen.
VM centos-server-17 auf reservierte IP 192.168.17.60 / 24 konfigurierenmittels DHCP-Konfigurationsdatei: /etc/dhcp/dhcpd.conf
centos-server-17
192.168.17.60 / 24
... host centos-server-17 { hardware ethernet 08:00:20:A4:89:C1; fixed-address 192.168.17.60; } ...
Und natürlich wieder das Testen nicht vergessen! Tipp: Bei Nutzung von VirtualBox kann man die MAC-Adresse in den Eigenschaften der Maschine nachrecherchieren.
Wir wollen uns gleich wieder auf die praktischen Umsetzungen für unseren Router konzentrieren. Allerdings sollten wir uns auch die Firewall-Entwicklungen kurz im Zeitraffer ansehen.
nft
Die einfachste Nutzung besteht im vorbereiteten nftables.service, dessen Status sich leicht abfragen lässt: systemctl status nftables.service
nftables.service
systemctl status nftables.service
Und natürlich stehen auch die anderen SystemD-Verwaltungsmöglichkeiten wie journalctl und Co zur Verfügung.
journalctl
Wir verdeutlichen uns wieder das Szenario für das NAT-Routing und die Virtuellen Installationen und Vernetzungen.
Anm.: hier wieder eine ältere Darstellung aus Vorseminaren mit Netfilter/iptables - seit 2020/2021 (auch) Umsetzung (direkt) mit Netfilter (nftables.service).
Wie erkennen hier auf jeden Fall das nötige Aktivieren der grundsätzlichen Routing-Fähigkeit. Hinweis: Masquerading ist ein spezielle SNAT-Technik, bei der sich die öffentliche IP ändern dürfte.
Für unsere Umsetzung wollen wir uns auf SNAT konzentrieren. Hierfür benötigen wir auf der öffentlichen NIC-Adresse (WAN) eine feste / statische IP-Adresse, die wir im Vorfeld ja auch konfiguriert haben sollten.
Wie immer gilt: nur weil ein System über mehrere Netzwerkadapter verfügt, werden natürlich nicht einfach alle möglichen Pakete zwischen diesen Adaptern vermittelt! Das wäre ja auch eine Katastrophe! (wie Manousakis sagen würde ;-)
Unsere Linux-System haben für die grundsätzliche Aktivierung des Routens einen Hauptschalter. Es ist ein einfach Boolean Eintrag im /proc-Systemverzeichnis zur Laufzeit. Der Schalter lässt sich mit cat analysieren: cat /proc/sys/net/ipv4/ip_forward.
cat /proc/sys/net/ipv4/ip_forward
Erhalten wir eine 0 dann ist das Routing ausgeschaltet. Bei einer 1 wäre das Routing eingeschaltet! Anmerkung: bei Systemen mit Container-Technik wie Docker sollte das Routing bereits aktiviert sein!
Wir haben zwei temporäre Möglichkeiten den Eintrag für ip_forward auf 1 zu setzen:
# Via procfs: echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward # Via sysctl on command line: sudo sysctl -w net.ipv4.ip_forward=1
Wir fixieren unsere Konfigurations per Konfigurationsdatei sysctl.conf.
sysctl.conf.
Achtung: bei Debian 13 wurde /etc/sysctl.conf in den Unterordner /etc/sysctl.d/sysctl.conf verschoben!
/etc/sysctl.d/sysctl.conf
# Via sysctl configuration file: new path since Debian 13! echo "net.ipv4.ip_forward = 1" | sudo tee /etc/sysctl.d/sysctl.conf # activate via sysctl or reboot/test sudo /sbin/sysctl -p
Bitte einfach mal neustarten und den Inhalt von /proc/sys/net/ipv4/ip_forward checken!
/proc/sys/net/ipv4/ip_forward
Wir erinnern uns an die Statusüberprüfung für den nftables-Servicesystemctl status nftables.service systemctl enable --now nftables.service # Enable and Start service
systemctl enable --now nftables.service # Enable and Start service
Das aktuelle Ruleset gibt ebenfalls Auskunft über den nftables Status:sudo nft list ruleset
sudo nft list ruleset
Auf einer frischen Maschine gibt es Ausgaben zur Tabelle filter, die im Grunde besagen, dass alle Pakete akzeptiert (accept) werden. Eine entsprechende nft-Skript Konfiguration lässt sich unter /etc/nftables.conf finden. Man achte auf den Shebang! Im Grunde also führt der nftables.service beim starten dieses Skript aus.
/etc/nftables.conf
Wir interessieren uns beim NAT-Routing für die Tabellen
Wichtig: die folgenden Strukturen finden sich immer an einem einzelnen Netzwerkadapter!
Mit dem CLI-Tool nft können wir jetzt unsere gewünschten NAT-Routing Regeln hinzufügen und testen. Danach kann man sich mit nft list ruleset die jeweiligen Regelungen (Ruleset) ausgeben lassen. Zusammen mit dem Shebang für nft-Skripting und einem Initialisierungsaufruf zum Flushen (Leeren) aller Regelsätze ergibt sich unsere nftables.conf.
nft list ruleset
# create a Table for nat nft add table nat # Add the prerouting and postrouting chains to the table: nft -- add chain nat prerouting { type nat hook prerouting priority -100 \; } nft add chain nat postrouting { type nat hook postrouting priority 100 \; } # remarks: # Even ifyou do not add a rule to the prerouting chain, the nftables framework requires this chain to match outgoing packet replies. # Note that you must pass the -- option to the nft command to avoid that the shell interprets the negative priority value as an option of the nft command. # Add a rule to the postrouting chain that replaces the source IP of outgoing packets through ens3 with 192.0.2.1: # ens3 and 192.0.2.1 are the WAN Nic and IP nft add rule nat postrouting oifname "ens3" snat to 192.0.2.1
Gegebenfalls ist jetzt der Zeitpunkt gekommen, um den Service zu restarten und mit einem geeignetem Client in unserem Netz zu testen.
Wenn alles wie gewünscht funzt, dann ist es Zeit den aktuellen Regelsatz (ruleset) zu persistieren - also nach Neustarts automatisch wiederherzustellen und zu nutzen. Hierfür kann man sich mit dem CLI-Tool nft die Regeln in eine Textdatei exportieren lassen (z.B.):sudo nft list ruleset > /tmp/myrules.conf
sudo nft list ruleset > /tmp/myrules.conf
In der entstanden Textdatei muss man nur noch den Shebang für nft und das Flushen des Ruleset am Anfang komplettieren. Als Standard erwartet der nftables.service die Datei /etc/nftables.conf als Konfigurationssskript.Hier liegt die Betonung auf Skript! Also bitte bei eigenen neuen Dateien bitte nicht chmod +x /etc/nftables.conf vergessen!
chmod +x /etc/nftables.conf
Beispielhafte nftables.conf:
nftables.conf
#!/usr/sbin/nft -f flush ruleset table inet filter { chain input { type filter hook input priority filter; policy accept; } chain forward { type filter hook forward priority filter; policy accept; } chain output { type filter hook output priority filter; policy accept; } } table ip nat { chain prerouting { type nat hook prerouting priority dstnat; policy accept; } chain postrouting { type nat hook postrouting priority srcnat; policy accept; oifname "enp1s0" snat to 10.100.211.217 } }
Auch für dieses Beispiel muss man natürlich die eigenen Adapternamen und IP-Adressen anpassen! Und man erkennt die postrouting Regel snat. Das bedeutet diese Schnittstelle sollte eine feste, unveränderlichen IP-Adresse besitzen. Sonst müssten wir masquerading benutzen.
Eine Auflistung zum Thema NAT mit nftables ohne Anspruch auf Vollständigkeit:
Klassisches NAT-Routing mit Netfilter/Iptables
Im Laufe der Übungen könnte es mal technisch nötig sein (z.B. Copy & Paste, Editorprobleme, ...) das wir direkt per SSH auf einen Rechner im privaten Netz verbinden wollen. Allerdings haben wir dazwischen einen NAT-Router! Die Lösung: Portforwarding per Nft-Regel.
Die folgende Erweiterung soll nur genau diese Lösung darstellen (wieder Q&D). Im späteren Verlauf müssten die Regelsätze hinsichtlich Sicherheit stark eingeschränkt werden! Das Beispiel soll auch den Einsatz von Variablen beim Definieren von Regeln darstellen. Diese Umsetzungen sind dann später sinnvoll, weil man sonst auf wechselnden Umgebungen viel zu viele manuelle Ersetzungen durchführen müsste. Außerdem erhöht der Einsatz dieser Variablen die Lesbarkeit der Regeln.
#!/usr/sbin/nft -f # Clear all existing rules flush ruleset # Define Adapters of router define WAN = enp1s0 define WANIP = "10.100.211.217" define LAN = enp7s0 define LANIP = "192.168.17.1" # FW table filter table inet filter { chain input { type filter hook input priority filter; policy accept; } chain forward { type filter hook forward priority filter; policy accept; } chain output { type filter hook output priority filter; policy accept; } } # FW table NAT table ip nat { chain prerouting { type nat hook prerouting priority dstnat; policy accept; # DNAT/Portforwarding for SSH Service on srv-01 iifname $WAN tcp dport 2222 dnat to 192.168.17.10:22 comment "SSH Redirect" } chain postrouting { type nat hook postrouting priority srcnat; policy accept; oifname $WAN snat to $WANIP } }
Achtung: dieses Skriptbeispiel passt nicht genau zu unseren Übungsumgebungen. Aber das ist eben auch sehr leicht durch Anpassung im oberen Abschnitt des Nftables-Skript und die SSH-DNAT-Adresse erledigt. Und natürlich sollte es sich am Ende immer noch um ein ausführbares Skript handeln!
Und selbst, wenn die Vorgaben genau der Umsetzung auf meinem Trainer-System entsprechen würden müssten die Trainee-Systeme die Anpassungen auf die jeweiligen Subnetze, Netzwerkadapter, Bezeichner und Namen durchführen.
... Berkeley Internet Name Daemon - Link
Die Umsetzungen erfolgen hier natürlich wieder auf einem Debian System mit Standardeinstellungen nach diversen Anleitungen (z.B. Debian Wiki oder Debian Handbook - DNS ).
Installation auf Debian mit apt install bind9 bind9-doc bind9-dnsutils Anm.: diverse Utilities/Tools mit oft bereits schon installiertem Paket bind9-dnsutils
apt install bind9 bind9-doc bind9-dnsutils
bind9-dnsutils
Der Service hört auf aktuellen Debian Systemen sowohl auf bind9.service als auch auf (klassisch) auf named.service:sudo systemctl status named.service oder sudo systemctl status bind9.service
sudo systemctl status named.service
sudo systemctl status bind9.service
Das trifft allerdings - wieder einmal - nicht auf die Unit zu, die wir für journalctl benötigen:sudo journalctl -u named (derselbe Aufruf mit Unit -u bind9 zeigt keinerlei Einträge!)
sudo journalctl -u named
Dasselbe stellen wir für Servicebezeichner ssdh.service und ssh.service mit Praxis und Analyse fest. Das Ganze ist einfach eine Frage der Definitionen für die SystemD-Services und die symbolischen Verlinkungen, die man im System vorfindet!
Zurück zum Bind9 / named Server: die Konfigurationen des BIND befinden sich in den folgenden Ordnern und Dateien.
/etc/default/bind9
/etc/bind/
/etc/bind/named.conf
⛔️ WICHTIG: mit Debian 13 - und auch auf anderen Distro/Bind9 Combos - wurden die "Default Empty forward and reverse Zones" zu Gunsten der Direktive "empty-zones yes" entfernt. Wir haben also keine Kopiervorlagen mehr für unsere eigenen Zonen! (siehe z.B. Reddit Post). 📁 ZONES: Außerdem wird häufig auch empfohlen die Zonendateien in Unterordner /etc/bind/zones unterzubringen.
⛔️ WICHTIG: mit Debian 13 - und auch auf anderen Distro/Bind9 Combos - wurden die "Default Empty forward and reverse Zones" zu Gunsten der Direktive "empty-zones yes" entfernt. Wir haben also keine Kopiervorlagen mehr für unsere eigenen Zonen! (siehe z.B. Reddit Post).
📁 ZONES: Außerdem wird häufig auch empfohlen die Zonendateien in Unterordner /etc/bind/zones unterzubringen.
/etc/bind/zones
Die Hauptdatei named.conf inkludiert drei weitere conf-Dateien, die ihrerseits Konfigurationen enthalten:
named.conf
named.conf.options
named.conf.local
named.conf.default-zones
Die Inbetriebnahme / Konfigurationen für unser Schulungs-DNS erfolgen in den folgenden drei Phasen:
Während der Umsetzungen sollte der "Firmenplan" (die Doku) genau beachtet und ständig aktualisiert bzw. angepasst werden.
Wir starten mit der Analyse der Konfigurationen in /etc/bind (Organisationsstruktur studieren, includes und Vorlagen)
Plan: Einrichtung DNS als Caching DNS und DNS-Forwarder
Installation und Einrichtung z.B. gemäß Anleitung
Achtung: da wir jetzt einen DNS-Server (host: server-17-01 - 192.168.17.10 / 24) haben - und auch nur diesen als DNS-Ansprechpartner haben wollen - müssen wir natürlich die Konfiguration für den DHCP Server anpassen (option domain-name-servers 192.168.17.10, 8.8.8.8 bzw. die aktuellen Techniken unseres KEA DHCP Servers!
Ausschnitt der Konfiguration für den DNS-Server (hier: /etc/bind/named.conf.options )
/etc/bind/named.conf.options
Als DNS-forwarder wurde der Google-DNS 8.8.8.8 eingetragen. Alternativ wäre natürlich auch der Firmen/VHS DNS denkbar. Allerdings kann man der folgenden Deklaration entnehmen, dass man für DNS Anfragen goodclients definieren kann. Und da könnten wir dann mit unseren Test-IP-Adressen auch mal nicht dazugehören!
acl goodclients { 192.168.17.0/24; localhost; localnets; }; options { directory "/var/cache/bind"; recursion yes; allow-query { goodclients; }; forwarders { 8.8.8.8; 1.1.1.1; }; forward only; # ggf. später auskommentieren! dnssec-validation auto; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; }; };
Anm.: hier handelt es sich nur um einen Auszug aus der Konfiguration. Es folgen Ausführliche Tests der Konfiguration im Netzwerk auf Clients und Servern
‼️ named-checkconf: Vor dem Neustarten des DNS-Servers ( service bind9 restart ) bitte vorher named-checkconf durchführen!
service bind9 restart
named-checkconf
Grund: die Konfigurationen sind sehr empfindlich und man kann sich schnell mal vertippen oder ein ";" vergessen!
Beim DNS-Server debian-srv-17-01 (192.168.17.10) sind die folgenden Anmerkungen wichtig:
Wir dürfen für den DNS-Server selber bitte nicht die /etc/resolv.conf vergessen und dort manuell den "nameserver 192.168.17.10" Eintrag vornehmen und testen!
Anm.: das gilt generell für alle statisch konfigurierten Maschinen (Server)!
Testbefehle: nslookup , dig , host (Nachinstallation Paket dnsutils/Debian, bind-utils/CentOS)
nslookup
dig
host
Es folgt die Vorgehensweise für die beteiligten Konfigurationsdateien in Kürze:
In /etc/bind/named.conf.local eine neue Zone festlegen:
/etc/bind/named.conf.local
zone "firma17.local" { type master; file "/etc/bind/zones/db.firma17.local"; };
Für diese Zone benötigen wir also eine Datei mit den den nötigen Definitionen.
[OLD: Mit einer Kopie von /etc/bind/db.local in /etc/bind/zones/db.firma17.local die neue Master Zone firma17.local definieren.]
/etc/bind/zones/db.firma17.local
Beispiel-Zone aus BIND9 ReadTheDocs: https://bind9.readthedocs.io/en/latest/chapter3.html#example-com-base-zone-file Anm.: bitte sehr konzentriert anpassen! Es kommen auf jedes ";" und jeden "." (Punkt) an!
Forward-Zonenedatei: /etc/bind/zones/db.firma17.local
; ; BIND data file for firma17.local ; $TTL 2d ; default TTL for zone $ORIGIN firma17.local. ; base domain-name @ IN SOA ns1.firma17.local. root.firma17.local. ( 2025123000 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; @ IN NS srv-17-01.firma17.local. @ IN A 192.168.17.10 router-17 IN A 192.168.17.1 srv-17-01 IN A 192.168.17.10 srv-17-02 IN A 192.168.17.20 srv-17-03 IN A 192.168.17.30 client-17-01 IN A 192.168.17.100 ns1 IN CNAME srv-17-01 www IN CNAME srv-17-03
Natürlich liefere ich für die Trainees auch auf Wunsch entsprechende Vorlagen. Allerdings sollen die Teilnetze immer separat sein.
Beispielhafte Screenshots:
Erinnerung: ggf. noch in den BIND-Optionen (/etc/bind/named.conf.options) den Eintrag "forward only;" auskommentieren!
Übungen: Einträge für die "Übungsfirma" einrichten und mit Tools (nslookup, host, dig) testen.
Anm. für die Tests: Wir haben (noch) keine Revers-Lookup-Zone eingerichtet! Das ist allerdings für viele Services - allen voran Mailservices - wünschenswert und soll jetzt auch noch nachgeholt werden.
Wir werden Jetzt also noch für unsere lokale Firma "firma17.local" im Netz 192.168.17.0 / 24 eine Reverse Lookup Zone definieren!
In /etc/bind/named.conf.local eine neue Zone unterhalb der Forward Lookup Zone "firma17.local" festlegen:
zone "17.168.192.in-addr.arpa" { type master; file "/etc/bind/zones/db.192.168.17"; };
Wieder erhalten wir den Verweis auf eine Datei mit der Definition für die Zone und müssen diese erstellen.
Und für die (beispielhafte) Reverse Lookup Zonen Datei /etc/bind/zones/db.192.168.17 ergibt sich folgende Datei:
/etc/bind/zones/db.192.168.17
; BIND reverse data file for LAN-Subnet ; $TTL 604800 @ IN SOA firma17.local. root.firma17.local. ( 2018103100 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; @ IN NS srv-17-01.firma17.local. 1 IN PTR router-17.firma17.local. 10 IN PTR srv-17-01.firma17.local. 20 IN PTR srv-17-02.firma17.local. 30 IN PTR srv-17-03.firma17.local. 100 IN PTR client-17-01.firma17.local.
Erinnerung: bitte wieder genauestens auf die FQDN Schreibweisen mit abschließendem Punkt achten!Beispielhafte Screenshots:
Alles natürlich wollen wir unsere Konfigurationen wieder mit Tools nslookup , host und dig testen!
Aufrufe: (Anm.: hier nur Standardaufrufe - gerne Manpages nutzen)
host srv-17-01
host -a 192.168.17.10
dig router-17
dig -x 192.168.17.1
Hinweis zu Reverse Lookup Zonen und den richtigen Einträgen der Reverse-IPs
Bei Subnetz 10.0.0.0 / 8 haben wir Rechner von 10.0.0.1 ... 10.18.19.20 ... 10.255.255.254 (also ca. 16 Mio Hosts)Die passenden (drei beispielhaften) Einträge in der Reverse-Zone 10.in-addr.arpa lauten:
10.in-addr.arpa
1.0.0 IN PTR router17.firma17.local. 20.19.18 IN PTR server17.firma17.local. 254.255.255 IN PTR centos17.firma17.local.
So ist das mit Reverse halt 😜.
Nameserver - Verarbeitung bei Auflösungen auf Clients
Hinweis zu DNS-Client-/Server-Technik: manche Distributionen haben in der /etc/nsswitch.conf eine ungünstige Auflösungsreihenfolge für die "hosts" eingestellt. Man kann nicht an Namen srv-17-01 und/oder srv-17-01.firma17.local erfolgreich pingen!
/etc/nsswitch.conf
Dann bitte die folgende Zeile der /etc/nsswitch.conf anpassen/ändern:
Dann sollte die Reihenfolge bei der Auflösung von Hosts mit FQDN wie srv-17-01.firma17.local wieder passen.
Anm.: mdns geht in Richtung ZeroConf (Avahi / Bonjour / APIPA) und hilft bei der Auflösung von Namen "ohne echtes DNS" (siehe IPs: 169.254.x.y / 16).
Links zu Bind9
Da Akronym steht für: Linux - Apache - MySQL/MariaDB - PHP; hier: PHP 8.4 (aus den Standard Debian Repos)
Es handelt sich um den am meisten verbreiteten LAMP-Stack für Web-/DB-Services im Internet/Intranet.
Wir wollen auch gleich nach hoch hängenden Trauben greifen und nicht einfach irgendeinen LAMP ausrollen! Unser LAMP Service soll für das Enterprise CMS TYPO3 (ab Version 12 - siehe unsere PHP Version 8.4) eine nutzbare Plattform darstellen.
Die Installation ist im Rahmen unsere Linux Workshop für den Debian-Server srv-17-03 geplant, der über einen Alias/CNAME in unserem Intranet auch über die URL www.firma17.local erreichbar ist.
Für den Einstieg hier ein paar Quellen rund um unsere gewünschte Debian-basierte LAMP-Installation und Infolinks zu TYPO3 Serveranforderungen (Requirements).
Und am Ende wollen wir natürlich auch sichere Websites für unterschiedliche Projekte mit Hilfe von VHosts erhalten.
Geplante TYPO3-Installationen bzw. VHosts:
typo3-13.firma17.local www.typo3-13.firma17.local typo3-demo.firma17.local www.typo3-demo.firma17.local
Dann wollen wir mal mit den Installationen loslegen und starten mit ein paar Basistools:sudo vim mc tree git curl graphicsmagick
sudo vim mc tree git curl graphicsmagick
Und dann kann es auch schon mit der LAMP-Software in mehreren Schritten weitergehen.
Die folgenden Ausarbeitungen orientieren sich an vielen meiner diversen LAMP Installationen der letzten Jahrzehnte.
Installation: Debian Trixie (13.2) mit aktuellen Apache2, MariaDB und PHP 8.4
Die Installation des Apache:
# System aktualisieren sudo apt update && sudo apt upgrade -y # Apache2 installieren - Ausgaben/Rueckmeldungen beachten sudo apt install apache2 # Test Apache2 - Version: Apache/2.4.65 (Debian) sudo apache2 -v
Wenn unser Intranet sauber eingerichtet ist, sollten wir jetzt über (z.B.) client-17-01 im Browser die Adresse www.firma17.local aufrufen können.
Der MariaDB Datenbankserver stellt die Alternative zum klassischen MySQL DB-Server dar. Ich weise darauf hin, dass MySQL über Umwege vor Jahren bei Oracle gelandet ist. Und überhaupt könnte man für die Zukunft überlegen sich auch mit PostgreSQL anzufreunden - quasi dem Linux unter den Datenbanken (sprich: OpenSource, ...).
Wir installieren jetzt die MariaDB Server- und Client-Technik:
# MariaDB installieren sudo apt install mariadb-server mariadb-client # Version ausgeben - Version: 11.8.3-MariaDB, client 15.2 sudo mariadb --version # Absichern der MariaDB ist in aktuellen Debian Version nicht mehr nötig! mariadb-secure-installation NOTE: MariaDB is secure by default in Debian. Running this script is useless at best, and misleading at worst. This script will be removed in a future MariaDB release in Debian. Please read mariadb-server.README.Debian for details. ...
Und testen den Zugang zum MariaDB-Server mit einem mariadb/mysql-Client direkt mit User root:
sudo -imysql -h localhost oder natürlich mariadb -h localhost
sudo -i
Die aktuelle Analyse für die MariaDB-User sieht wie folgt aus:
MariaDB [mysql]> select user, password, plugin from user; +-------------+----------+-----------------------+ | User | Password | plugin | +-------------+----------+-----------------------+ | mariadb.sys | | mysql_native_password | | root | invalid | mysql_native_password | | mysql | invalid | mysql_native_password | +-------------+----------+-----------------------+ 3 rows in set (0,004 sec)
Man erkennt, dass User root sich im Grunde nicht per Passwort anmeldet, sondern direkt aus der Linux Shell Umgebung heraus seine Berechtigung erhält: Password invalid (PW nicht gesetzt!), Plugin mysql_native_password (root Env erlaubt Authentifizierung).
🔗 MariaDB Plugins: https://mariadb.com/docs/server/reference/plugins/authentication-plugins/pluggable-authentication-overview
Mit verschiedenen Best-Practise kann man die Sicherheit eines MariaDB-Servers in diesen User-Auth Belangen verbessern. Wir benötigen später einen MariaDB-User für unsere CMS Systeme und halten es an der nächsten Stelle sehr einfach mit weitreichenden Berechtigungen.
CREATE USER cms@localhost IDENTIFIED BY 'seminar'; SELECT user, password, plugin FROM user; GRANT ALL PRIVILEGES ON *.* TO 'cms'@'localhost'; FLUSH privileges;
Wenigstens haben wir die Berechtigungen für "lokale" Zugriffe konfiguriert. Wir sollten jetzt auch mit einem Standardkonto per CLI Zugriff auf unseren MariaDB Server haben: mariadb -u cms -h localhost -p
mariadb -u cms -h localhost -p
MariaDB [mysql]> select user, password, plugin from user; +-------------+-------------------------------------------+-----------------------+ | User | Password | plugin | +-------------+-------------------------------------------+-----------------------+ | mariadb.sys | | mysql_native_password | | root | invalid | mysql_native_password | | mysql | invalid | mysql_native_password | | cms | *9EA52CB962BFB478F51E8DA44F1305355F3547F4 | mysql_native_password | +-------------+-------------------------------------------+-----------------------+ 4 rows in set (0,004 sec)
Im Seminar werden einige kleine Tests im MySQL-Client durchgeführt!
‼️ ANMERKUNG: Die folgenden Anpassungen sollten auf unserer Debian 13 / MariaDB Kombination nicht mehr nötig sein!
Probleme mit Plugin-Vorkonfigurationen
DB Konfiguration für Benutzer root nach secure-Skript: der Zugang zur MariaDB-Datenbank für den (DB-) User root ist möglicherweise mittel plugin unix_socket konfiguriert. Das verhinderte bei verschiedenen Systemen/Distros das Login aus der Standard-Benutzer Konsole!
Mögliche Reparatur in mysql/mariadb-Konsole: (als DB-root - andere User funzen ja noch nicht ;-)
use mysql; UPDATE user SET plugin='' WHERE user='root'; flush privileges;
Aber so hat man mal ein paar SQL-Zeilen gesehen. Im Seminar hierzu gerne mehr auf Anfrage!
Apache kann PHP auf zwei Arten integrieren:
Für die meisten Neuinstallationen und Produktionsserver ist PHP-FPM die bessere Wahl. Im Gegensatz dazu bleibt mod_php für Entwicklungsumgebungen und kleinere Websites einfacher.
Wir starten also mit der mod_php Variante. Man kann beide Varianten gemeinsam auf Server installieren. Die Betriebsarten lassen sich sogar umschalten.
# PHP (hier in Version 8.4) installieren sudo apt install libapache2-mod-php php php-mysql Installiere: libapache2-mod-php php php-mysql Installiere Abhängigkeiten: libapache2-mod-php8.4 php-common php8.4-cli php8.4-mysql php8.4-readline libargon2-1 php8.4 php8.4-common php8.4-opcache Vorgeschlagene Pakete: php-pear Zusammenfassung: Aktualisiere: 0, Installiere: 12, Entferne: 0, Aktualisiere nicht: 0 Herunterlade-Größe: 5.093 kB Benötigter Platz: 24,4 MB / 16,4 GB verfügbar php -v PHP 8.4.16 (cli) (built: Dec 18 2025 21:19:25) (NTS) Copyright (c) The PHP Group Built by Debian Zend Engine v4.4.16, Copyright (c) Zend Technologies with Zend OPcache v8.4.16, Copyright (c), by Zend Technologies
Anm.: Das PHP-Metapaket installiert automatisch die passende PHP-Version für unsere Debian-Distribution. Das Paket php-mysql ermöglicht die Anbindung an MariaDB/MySQL-Datenbanken.
Es fehlt noch die Vervollständigung der PHP Installation:
sudo apt install php php-mysql libapache2-mod-php php-curl php-gd php-mbstring php-xml php-soap php-intl php-zip curl php-pear
Selbstverständlich muss man jetzt die aktuelle Apache2/PHP Kombination restarten und das Vorhandensein der gewünschten Module überprüfen. Das kann man über eine kleine PHPINFO Skript Datei machen oder über den CLI Aufruf php -m.
php -m
Testing der Apache2-PHP-Konfiguration mit einem kleinen PHP-Skript /var/www/html/info.php
/var/www/html/info.php
<?php echo "Hallo Welt!"; phpinfo(); ?>
Aufruf des Skripts im Browser mittels URL: www.firma17.local/info.php
Und beispielhafte Erweiterung der Apache2 Umgebung: Module aktivieren (z.B. für CMS wie TYPO3):
sudo a2enmod expires sudo a2enmod rewrite sudo a2enmod headers sudo systemctl restart apache2.service
Diese Apache2-Modifikationen benötigen also einen Restart / Reload: systemctl restart apache2
systemctl restart apache2
Anm.: Rückmeldungen/Vorgaben von a2enmod für nötige Apache2 Aktualisierung beachten.
Jetzt noch ein paar Konfigurationen für die PHP-Umgebung: /etc/php/8.4/apache2/php.ini (bitte vorher copy machen)
/etc/php/8.4/apache2/php.ini
Auch für die PHP Konfiguration wurden seitens der TYPO3 Entwickler verschiedene Vorgaben gemacht. Die folgende Liste enthält die jeweiligen Konfigurationsparametr und die alten Originaldaten.
memory_limit = 256M (128M) max_execution_time = 240 (30) max_input_vars = 1500 (uncomment - 1000) pcre.jit = 1 (uncomment) post_max_size = 10M (8M) upload_max_filesize = 10M (2M)
Erinnerung: natürlich bitte wieder Apache2 reloaden/restarten
Für die Umsetzung mit Selbstausgestellten Zertifikaten gibt es diverse Tools und Anleitungen.
Wir entscheiden uns für eine openssl Umsetzung aktivieren erst einmal das SSL-Modul für den Apache2 Webserver.
# PowerOn for SSL: sudo a2enmod ssl sudo systemctl restart apache2
Wir erstellen uns - wieder Q & D - eine Schlüssel-Datei und ein Zertifikat.
# Create Key and Certificate sudo openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout /etc/ssl/private/localhost.key -out /etc/ssl/certs/localhost.crt # you may leave all Options untouched!- Checking: sudo ls -al /etc/ssl/private/ sudo ls -al /etc/ssl/certs/l*
Wir kopieren die Standard-SSL-Site (Backup) Konfiguration.
sudo cp /etc/apache2/sites-available/default-ssl.conf /etc/apache2/sites-available/default-ssl.conf.bak sudo vim /etc/apache2/sites-available/default-ssl.conf
Und dann tragen wir unsere erstellten Key und Certificate Pfade in die Site-Konfiguration ein.
.... SSLEngine on SSLCertificateFile /etc/ssl/certs/localhost.crt SSLCertificateKeyFile /etc/ssl/private/localhost.key .....
Danach können wir die Site aktivieren und testen.
# Enable Site sudo a2ensite default-ssl # Test Apache2 Configuration sudo apachectl configtest sudo systemctl restart apache2
TEST: Site aufrufen mit https-URL - https://www.firma17.local (wenn wir einen CNAME im DNS eingetragen haben für den Webserver!)
Jetzt sollten wir für unsere Webprojekte eigene Verzeichnisstrukturen schaffen.
Eine beispielhafte Verteilunge von TYPO3 Kernsoftware im Zusammenspiel mit den TYPO3-Projekt-Ordnern könnte so aussehen.
seminar@ws-srv-17-03:~$ tree /var/www/ /var/www/ ├── html │ ├── index.html │ ├── info.php │ └── typo3 │ └── typo3-13.firma17.local └── typo3_src
Man erkennt den eigenen Ordner für die TYPO3-Kernsoftware /var/www/typo3_src und für die TYPO3-Projekte /var/www/html/typo3/typo3-13.firma17.local. Bei TYPO3 kann man sauber die CMS-Betriebssoftware und die Projektordner getrennt halten.
/var/www/typo3_src
/var/www/html/typo3/typo3-13.firma17.local
Der Projektordner soll im Intranet mit der Adresse typo3-13.firma17.local aufrufbar werden. Hierfür dürfen wir natürlich den CNAME-Eintrag in unserem DNS-Server nicht vergessen!
Für die VHosts müssen wir wieder eine Konfiguation im Apache2 System vornehmen: /etc/apache2/sites-available/typo3-13.firma17.local.conf
/etc/apache2/sites-available/typo3-13.firma17.local.conf
Die folgende Datei kann selbstverständlich auch eingekürzt werden. Und natürlich muss sie auf unsere Umgebung angepasst sein!
<VirtualHost *:80> ServerAdmin Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein. ServerName typo3-13.firma17.local ServerAlias www.typo3-13.firma17.local DocumentRoot /var/www/html/typo3/typo3-13.firma17.local <Directory /var/www/html/typo3/typo3-13.firma17.local/> Options Indexes FollowSymLinks MultiViews AllowOverride Indexes FileInfo Order allow,deny allow from all </Directory> # Possible values include: debug, info, notice, warn, error, crit, # alert, emerg. LogLevel warn ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined </VirtualHost> <IfModule mod_ssl.c> <VirtualHost _default_:443> ServerAdmin Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein. ServerName typo3-13.firma17.local ServerAlias www.typo3-13.firma17.local DocumentRoot /var/www/html/typo3/typo3-13.firma17.local <Directory /var/www/html/typo3/typo3-demo.lamp8/> Options Indexes FollowSymLinks MultiViews AllowOverride Indexes FileInfo Order allow,deny allow from all </Directory> # Available loglevels: trace8, ..., trace1, debug, info, notice, warn, # error, crit, alert, emerg. # It is also possible to configure the loglevel for particular # modules, e.g. #LogLevel info ssl:warn ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined # For most configuration files from conf-available/, which are # enabled or disabled at a global level, it is possible to # include a line for only one particular virtual host. For example the # following line enables the CGI configuration for this host only # after it has been globally disabled with "a2disconf". #Include conf-available/serve-cgi-bin.conf # SSL Engine Switch: # Enable/Disable SSL for this virtual host. SSLEngine on # A self-signed (snakeoil) certificate can be created by installing # the ssl-cert package. See # /usr/share/doc/apache2/README.Debian.gz for more info. # If both key and certificate are stored in the same file, only the # SSLCertificateFile directive is needed. SSLCertificateFile /etc/ssl/certs/localhost.crt SSLCertificateKeyFile /etc/ssl/private/localhost.key # Server Certificate Chain: # Point SSLCertificateChainFile at a file containing the # concatenation of PEM encoded CA certificates which form the # certificate chain for the server certificate. Alternatively # the referenced file can be the same as SSLCertificateFile # when the CA certificates are directly appended to the server # certificate for convinience. #SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt # Certificate Authority (CA): # Set the CA certificate verification path where to find CA # certificates for client authentication or alternatively one # huge file containing all of them (file must be PEM encoded) # Note: Inside SSLCACertificatePath you need hash symlinks # to point to the certificate files. Use the provided # Makefile to update the hash symlinks after changes. #SSLCACertificatePath /etc/ssl/certs/ #SSLCACertificateFile /etc/apache2/ssl.crt/ca-bundle.crt # Certificate Revocation Lists (CRL): # Set the CA revocation path where to find CA CRLs for client # authentication or alternatively one huge file containing all # of them (file must be PEM encoded) # Note: Inside SSLCARevocationPath you need hash symlinks # to point to the certificate files. Use the provided # Makefile to update the hash symlinks after changes. #SSLCARevocationPath /etc/apache2/ssl.crl/ #SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl # Client Authentication (Type): # Client certificate verification type and depth. Types are # none, optional, require and optional_no_ca. Depth is a # number which specifies how deeply to verify the certificate # issuer chain before deciding the certificate is not valid. #SSLVerifyClient require #SSLVerifyDepth 10 # SSL Engine Options: # Set various options for the SSL engine. # o FakeBasicAuth: # Translate the client X.509 into a Basic Authorisation. This means that # the standard Auth/DBMAuth methods can be used for access control. The # user name is the `one line' version of the client's X.509 certificate. # Note that no password is obtained from the user. Every entry in the user # file needs this password: `xxj31ZMTZzkVA'. # o ExportCertData: # This exports two additional environment variables: SSL_CLIENT_CERT and # SSL_SERVER_CERT. These contain the PEM-encoded certificates of the # server (always existing) and the client (only existing when client # authentication is used). This can be used to import the certificates # into CGI scripts. # o StdEnvVars: # This exports the standard SSL/TLS related `SSL_*' environment variables. # Per default this exportation is switched off for performance reasons, # because the extraction step is an expensive operation and is usually # useless for serving static content. So one usually enables the # exportation for CGI and SSI requests only. # o OptRenegotiate: # This enables optimized SSL connection renegotiation handling when SSL # directives are used in per-directory context. #SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire <FilesMatch "\.(cgi|shtml|phtml|php)$"> SSLOptions +StdEnvVars </FilesMatch> <Directory /usr/lib/cgi-bin> SSLOptions +StdEnvVars </Directory> # SSL Protocol Adjustments: # The safe and default but still SSL/TLS standard compliant shutdown # approach is that mod_ssl sends the close notify alert but doesn't wait for # the close notify alert from client. When you need a different shutdown # approach you can use one of the following variables: # o ssl-unclean-shutdown: # This forces an unclean shutdown when the connection is closed, i.e. no # SSL close notify alert is send or allowed to received. This violates # the SSL/TLS standard but is needed for some brain-dead browsers. Use # this when you receive I/O errors because of the standard approach where # mod_ssl sends the close notify alert. # o ssl-accurate-shutdown: # This forces an accurate shutdown when the connection is closed, i.e. a # SSL close notify alert is send and mod_ssl waits for the close notify # alert of the client. This is 100% SSL/TLS standard compliant, but in # practice often causes hanging connections with brain-dead browsers. Use # this only for browsers where you know that their SSL implementation # works correctly. # Notice: Most problems of broken clients are also related to the HTTP # keep-alive facility, so you usually additionally want to disable # keep-alive for those clients, too. Use variable "nokeepalive" for this. # Similarly, one has to force some clients to use HTTP/1.0 to workaround # their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and # "force-response-1.0" for this. # BrowserMatch "MSIE [2-6]" \ # nokeepalive ssl-unclean-shutdown \ # downgrade-1.0 force-response-1.0 </VirtualHost> </IfModule> # vim: syntax=apache ts=4 sw=4 sts=4 sr noet
Danach muss man wieder mit a2ensite die Site aktivieren und den Apache2 restarten und testen.
a2ensite
Zum Ende sammele ich hier ein paar Topics, die im Rahmen unsere Linux Workshop von Interesse sein könnten.
Extra Topics:
Zusammenstellung von Infoportalen rund um Linux, Linux Server und Co.
Und natürlich verweise ich an dieser Stelle nur auf meine Seminarquellen und ein paar übliche Verdächtige hin. Da erstellt jeder Linux Profi über die Zeit sein eigenes Werkzeug- und Ressourcen-Portfolio - los geht es:
Anderes "Zeug" - in lockerer Schüttung und wie immer ohne Anspruch auf Vollständigkeit
curl cheat.sh/ls
... tbc ...
Ich habe auf diversen Plattformen Anleitungen und Downloads für verschiedenste Tuningmaßnahmen für unsere Linux Betriebssysteme.
An dieser Stelle wollen wir uns auf eine schnelle (Q&D) und effiziente Aufrüstung unserer Bash Shell mit ein paar wenigen Ausstattungen.
Software: sudo apt install curl wget git bat fzf ripgrep eza starship vim -y
sudo apt install curl wget git bat fzf ripgrep eza starship vim -y
Ich werde im Seminar selbstverständlich Erklärungen zu den Installationen und Konfigurationen geben.
Für die weiteren Ausstattungen laden wir uns ein bereitgestelltes Archiv BASH.zip aus einer Trainer-Quelle herunter und werden mit diesen Dateien unser System "aufmotzen".
In Kürze:
In allen Debian basierten Seminare - und auch bei vielen anderen Distros - ist Gnome der Standard Desktop. Über die Jahre habe ich mich auch immer wieder einmal am technischen und konfigurativen Tuning des Gnome versucht.
📛 Anmerkung nach Tests im Seminar: es hilft ja nichts, dass die hier aufgeführten Extensions wohl irgendwie bei mir in meinen Testinstallationen funzen. Bei unseren Seminartests hat nur die Hälfte das getan, was sie sollten und ein "Extension-Kollege" hat auch noch Gnome einfrieren lassen und die Systeme mussten über Terminal 3 (tty) rebooted werden ☹️. ➡️ Hinweis: bitte nur in VMs testen und mit Snapshots.
Insbesondere das vernünftige Handling von Fenstern (Tiling) und Workspaces (verteilen von Anwendungsfenstern) war immer eine Herausforderung. Deswegen präferiere ich in meiner Umgebung ja auch klassische Tiling Window Manager wie i3. Die folgenden Anmerkungen zu Gnome Extensions stellen den aktuellen Stand meiner Versuche dar. Immer noch weit entfernt von optimal - aber immerhin ein Weg in die richtige Richtung.
Hier die Liste der Extensions als URLs:
Bei solchen Gnome Verbesserungen hat natürlich auch wieder jeder User seine eigenen Sichten und Schwerpunkte. Und das ist ja auch das Schöne daran: jeder passt sich sein OS so an wie man will.
In vielen meiner Seminar möchten die Trainees lieber mit Nano als Texteditor arbeiten, statt mit VIm / Neovim sich die echte professionelle Dröhnung zu geben 😜. Da ist im Grunde auch erst einmal nichts daran zu beanstanden, da Nano nahezu überall vorinstalliert ist, wogegen (heute) aus meiner VIm / Neovim Family nur der abgespeckt VI vorhanden ist.
Die Standard-Tastenkombinationen des Nano sind allerdings ein echter Graus. Also stellen wir uns zumindest ein paar Standards auf normal.
Die Konfigurationsdatei: ~/.nanorc
~/.nanorc
set statuscolor blue,white bind ^Q exit main bind ^S savefile main bind ^H help main bind ^F whereis main bind ^N findnext main bind ^C copy main bind ^V paste main bind ^X cut main bind ^U undo main
Damit sollten zumindest mal Copy & Paste wieder funktionieren.
Mit LVM können wir dynamisch Partitionen verwalten/erweitern. Das macht vor Allem die Vergrößerung von Partitionen recht einfach. Für die Umsetzung gibt es diverse Anleitungen und Best Practise.
Ich benutze seit vielen Jahren die Anleitung von Hoster Thomas Krenn. Dessen Wiki finde ich immer wieder passend, solange man nicht die dargestellten Distributionen in den Beispielen aus dem Auge verliert. Aber das gilt natürlich für jede Recherche (siehe Arch Wiki, Ubuntuusers Wiki, Gentoo Wiki, …).
Der Aufbau der Technik basiert auf der folgenden LVM-Hierarchien:
🔗 Thomas Krenn: https://www.thomas-krenn.com/de/wiki/LVM_vergr%C3%B6%C3%9Fern#Schritt-f.C3.BCr-Schritt_Anleitung
Übersicht aus einer Debian-Standard-Installation mit LVM und Partitionen:
root@vm-lpic-router:~# df -hx tmpfs Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf udev 942M 0 942M 0% /dev /dev/mapper/vm--lpic--router--vg-root 23G 887M 21G 5% / /dev/sda2 471M 49M 398M 11% /boot /dev/mapper/vm--lpic--router--vg-var 8,0G 383M 7,2G 5% /var /dev/mapper/vm--lpic--router--vg-tmp 1,4G 44K 1,4G 1% /tmp /dev/mapper/vm--lpic--router--vg-home 91G 52K 86G 1% /home /dev/sda1 511M 3,5M 508M 1% /boot/efi
Tipp: Statt df -h nutzen wir df -hx tmpfs - das ist übersichtlicher!
df -h
df -hx tmpfs
Mount-Situation:
root@vm-lpic-router:~# mount | grep ^/dev /dev/mapper/vm--lpic--router--vg-root on / type ext4 (rw,relatime,errors=remount-ro) /dev/sda2 on /boot type ext2 (rw,relatime,stripe=4) /dev/mapper/vm--lpic--router--vg-var on /var type ext4 (rw,relatime) /dev/mapper/vm--lpic--router--vg-tmp on /tmp type ext4 (rw,relatime) /dev/mapper/vm--lpic--router--vg-home on /home type ext4 (rw,relatime) /dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
Blockgeräte:
root@vm-lpic-router:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 127G 0 disk ├─sda1 8:1 0 512M 0 part /boot/efi ├─sda2 8:2 0 488M 0 part /boot └─sda3 8:3 0 126G 0 part ├─vm--lpic--router--vg-root 254:0 0 23,3G 0 lvm / ├─vm--lpic--router--vg-var 254:1 0 8,2G 0 lvm /var ├─vm--lpic--router--vg-swap_1 254:2 0 976M 0 lvm [SWAP] ├─vm--lpic--router--vg-tmp 254:3 0 1,4G 0 lvm /tmp └─vm--lpic--router--vg-home 254:4 0 92,1G 0 lvm /home sr0 11:0 1 1024M 0 rom
Physical Volumes:
root@vm-lpic-router:~# pvs PV VG Fmt Attr PSize PFree /dev/sda3 vm-lpic-router-vg lvm2 a-- <126,02g 20,00m
Volume Groups:
root@vm-lpic-router:~# vgs VG #PV #LV #SN Attr VSize VFree vm-lpic-router-vg 1 5 0 wz--n- <126,02g 20,00m
Logical Volumes:
root@vm-lpic-router:~# lvs LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert home vm-lpic-router-vg -wi-ao---- 92,12g root vm-lpic-router-vg -wi-ao---- 23,28g swap_1 vm-lpic-router-vg -wi-ao---- 976,00m tmp vm-lpic-router-vg -wi-ao---- <1,45g var vm-lpic-router-vg -wi-ao---- <8,20g
Soweit die Analyse - kommen wir nun zur Erweiterung und Anpassung unseres Systems.
Kurzanleitung - Zusammenfassung der Schritte (von der Website)
Bei den Bezeichnungen (siehe auch /dev/mapper/...) muss man genauestens auf die einfachen und doppelten Bindestriche achten.
🗂️ Die folgenden Ausarbeitungen habe ich aus alten Linux Workshops übernommen. Die Darstellungen erläutern die klassischen Netfilter / iptables Firewalltechniken und enthlaten die Darstellungen zu den Firewall-Basics.
Nachdem die letzten Iptables auch bereits die Netfilter-Techniken der Linux-Kernel nutzten (siehe iptables-nft) haben die meisten Distributionen komplett auf Netfilter umgestellt.
iptables-nft
Wir werden also über (z.B.) dpkg -l | grep nftables die Softwareinstallation vorfinden. Die entscheidende Frage ist aber, ober der nftables.service auch gestartet/genutzt wird?
dpkg -l | grep nftables
root@vm-lpic-router:~# systemctl status nftables.servicenftables.service - nftablesLoaded: loaded (/lib/systemd/system/nftables.service; enabled; vendor preset: enabled)Active: active (exited) since Wed 2021-09-15 17:20:48 CEST; 2min 34s agoDocs: man:nft(8)http://wiki.nftables.orgMain PID: 994 (code=exited, status=0/SUCCESS)Tasks: 0 (limit: 2259)Memory: 0BCPU: 0CGroup: /system.slice/nftables.serviceSep 15 17:20:48 vm-lpic-router systemd[1]: Starting nftables...Sep 15 17:20:48 vm-lpic-router systemd[1]: Finished nftables.
root@vm-lpic-router:~# systemctl status nftables.service
nftables.service - nftables
Loaded: loaded (/lib/systemd/system/nftables.service; enabled; vendor preset: enabled)
Active: active (exited) since Wed 2021-09-15 17:20:48 CEST; 2min 34s ago
Docs: man:nft(8)
http://wiki.nftables.org
Main PID: 994 (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 2259)
Memory: 0B
CPU: 0
CGroup: /system.slice/nftables.service
Die Entwickler von Netfilter und Verwalter der Distributionen schlagen dann auch gleich noch firewalld als Frontend vor. Wir bleiben aber in unseren Seminaren komplett in der Konsole bei den Basistechniken der eigentlichen Software - also (erst einmal) keine Oberfläche für die Firewall oder zusätzliche firewall-cmd Aufrufe!
firewall-cmd
Die Konfiguration für Netfilter ist in
/etc/sysconfig/nftables.conf
Wir sollten auch schauen, ob der Netfilter / nftables - Dienst läuft und ihn gegebenfalls für Starts aktivieren.
root@vm-lpic-router:~# systemctl enable nftables.service Created symlink /etc/systemd/system/sysinit.target.wants/nftables.service → /lib/systemd/system/nftables.service.
Und natürlich kann man das Ganze auch gleich mit einem kombinierten Aufruf systemctl enable nftables.service --now beauftragen.
systemctl enable nftables.service --now
Aktuelle Firewall-Analyse mit Tool nft:
root@vm-lpic-router:~# nft list tables table inet filter root@vm-lpic-router:~# nft list table inet filter table inet filter { chain input { type filter hook input priority filter; policy accept; } chain forward { type filter hook forward priority filter; policy accept; } chain output { type filter hook output priority filter; policy accept; } }
Links zu Netfilter:
Schematische Darstellung aus Link jensd.be:
Aus dem Link für das Simple Ruleset for a Home Router kann man die wichtigsten Einstellungen für ein klassisches NAT-Routing entnehmen.
Im Original: This example shows the configuration of an IPv4-only home router using a ppp interface to go out to the Internet.
Wir ersetzen hier einfach das öffentliche PPP durch unsere WAN-Seite des Routers und passen die anderen Vorgaben/Einstellungen an.
Das wird unsere neue /etc/nftables.conf:
Zu beachten: im nft-Code wurde nur speziell für eine Maschine (10.200.81.1) der Zugang per SSH ermöglicht. Nach dem Aktivieren dieses Regelsatzes (nft list ruleset) kann nur noch dieser PC sich per SSH mit dem Router verbinden.
‼️ Gefahr - Noch ein kleiner Hinweis und Tipp: Bitte niemals SSH-Zugänge komplett zumachen, wenn man keine Möglichkeiten hat noch direkt an die Maschine zu kommen!
Und falls es noch nicht gesagt wurde: Firewalling ist nicht gerade easy ;-) Die Nftables Website schlägt für die Orientierung die folgende Grafik vor:
Link ( https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks ) zum Wiki und der Darstellung mit den sogenannten Netfilter hooks.
Hinweis: Und wie bei den Schemata zu Iptables ist hier auch sehr wichtig, dass man die Darstellung als Schema für einen Netzadapter erkennt. Ein Router hat dann hiervon mindestens zwei!
Siehe: https://jensd.be/1086/linux/forward-a-tcp-port-to-another-ip-or-port-using-nat-with-nftables
Hier mal ein paar beispielhafte Anpassungen / Ergänzungen für das Port-Forwarding (aka "Port öffnen") des Routers auf der WAN-Seite:
... chain forward { type filter hook forward priority 0; policy drop; # Allow traffic from established and related packets, drop invalid ct state vmap { established : accept, related : accept, invalid : drop } # connections from the internal net to the internet or to other # internal nets are allowed iifname $DEV_PRIVATE accept # in case of Port-Forwarding *please* accept forward for WAN-NIC iifname $DEV_WORLD accept # the rest is dropped by the above policy } chain postrouting { type nat hook postrouting priority 100; policy accept; # masquerade private IP addresses # ip saddr $NET_PRIVATE oifname $DEV_WORLD masquerade masquerade } chain prerouting { type nat hook prerouting priority -100; policy accept; ip daddr 192.168.2.254 tcp dport { 8888 } dnat to 172.16.100.10:80 ip daddr 192.168.2.254 tcp dport { 8889 } dnat to 172.16.100.10:443 ip daddr 192.168.2.254 tcp dport { 22222 } dnat to 172.16.100.10:22 ip daddr 192.168.2.254 tcp dport { 22223 } dnat to 172.16.100.50:22 } ...
Bitte beachten: die eigenen IP- und Benennungswerte nehmen.
Eigentliche Technik ist ja Netfilter: eine im Kernel implementierte Softwareschicht
Mit iptables kann man Regelsätze / Konfigurationen für verschiedene Tabellen erzeugen:
Die Tabellen können mit Richtlinien (Policies) zum Behandeln von Paketen versehen werden und haben Ketten (chains) für die Paketvermittlungen.
Wir interessieren uns beim NAT-Routing für die
Wichtig: die folgenden Strukturen finden sich immer an einem einzelnen Netzwerkadapter!Wir arbeiten erst einmal mit einfachen manuellen Inbetriebnahmen der nötigen NAT-Routing-Regeln.
Für die folgenden Befehle bitte die richtigen Router-NICs beachten: (Beachten: hier allgemeine Konfigurationsdaten - nicht die aus dem Seminar!)eth1 : NIC für die WAN-Seite (192.168.3.201 / 24 ; StdGW: 192.168.3.1; DNS: 192.168.3.1)eth0 : NIC für die LAN-Seite (10.0.0.1 / 8)
eth0
1) Forwarding für den Linux-Kernel aktivieren - der Kernel denkt sonst gar nicht daran, Pakete zwischen den Adaptern weiterzuleiten:
echo 1 > /proc/sys/net/ipv4/ip_forward
bzw. persistent - also nachhaltig - in /etc/sysctl.conf einstellen - Zeile: net.ipv4.ip_forward = 1 auskommentieren (Anm.: Logik/Reihenfolge wie in /proc/sys/... hier mit Punkten getrennt)und Rechner neustarten!
/etc/sysctl.conf
net.ipv4.ip_forward = 1
2) Forwarding von Paketen in "table filter" für beide Richtungen (LAN -> WAN und WAN -> LAN):Anm.: Angabe von -t filter kann als Standardtabelle auch weggelassen werden!
iptables -t filter -A FORWARD -i eth1 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -t filter -A FORWARD -i eth0 -o eth1 -j ACCEPT
Die Einstellung -m state bezieht sich auf die Fähigkeit der Netfilter-Kernel-Technik mittels Modul conntrack (Connection Tracking) Pakete auf Grund Ihrer Verbindungseigenschaften (hier: "in Beziehung" und "etabliert") akzeptiert werden können, ohne weiter untersucht zu werden!
3) Für die gewünschte Anbindung eines LAN mit mehreren Hosts müssen wir jetzt noch das NAT-Routing (Masquerading - Kohnle - Masquerading - Erklärung) ermöglichen:
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
Anm.: das sind nur sehr einfache Grundkonfigurationen, die bei weitem nicht alle Sicherheitsaspekte abdecken. (Einblick z.B. bei Red Hat Doku)
Löschen von Tabellen: iptables -F bzw. iptables -F -t nat
iptables -F
iptables -F -t nat
Übung: Umsetzung der Regeln gerne als Skript: (touch nat-routing.sh und chmod u+x nat-routing.sh )
touch nat-routing.sh
chmod u+x nat-routing.sh
#!/bin/bash IPTABLES="$(which iptables)" WANNIC="enp0s3" LANNIC="enp0s8" $IPTABLES -t filter -A FORWARD -i $WANNIC -o $LANNIC -m state --state RELATED,ESTABLISHED -j ACCEPT $IPTABLES -t filter -A FORWARD -i $LANNIC -o $WANNIC -j ACCEPT $IPTABLES -t nat -A POSTROUTING -o $WANNIC -j MASQUERADE
Tipp: iptables Regelsätze auch nach Neustarts und ohne Skriptverwaltungen mit Hilfe von iptables-persistent Paket!
iptables-persistent
Nach der Installation: apt install iptables-persistent kann man mittels: iptables-save > /etc/iptables/rules.v4 die Regeln nachhaltig machen (persistieren)!
apt install iptables-persistent
iptables-save > /etc/iptables/rules.v4
Fragestellung: Könnte man auch aus dem VHS BS Netz (Rechner: os-host-17 mit 10.100.211.117) den Webserver (debian-server-17 mit 192.168.17.50:80) aufrufen?
Lösungen:
Screenshots aus Seminarwoche 2019:
Tag 01:
Tag 02:
Tag 03:
Tag 04:
Tag 05:
Zum Seminarende:
Ihr Trainer Joe Brandes
Sie finden auf dieser Seite - als auch auf meiner privaten Visitenkarte joe-brandes.de einige Hintergrundinformationen zu mir und meinem Background.Natürlich stellt die IT einen Schwerpunkt in meinem Leben dar - aber eben nicht nur ...
Private Visitenkarte / Technik: HTML & CSS joe-brandes.de
Ich erarbeite und konzipiere seit über 30 Jahren IT-Seminare und -Konzepte. Hierfür stehen der "PC-Systembetreuer / FITSN" und der "CMS Online Designer / CMSOD". Ich stehe Ihnen gerne als Ansprechpartner für Ihre Fragen rund um diese und andere IT-Themen zur Verfügung!
BECSS Visitenkarte / Technik: HTML & CSS becss.de
Wer einmal zum Snookerqueue gegriffen hat, der wird es wohl nicht wieder weglegen. Und ich spiele auch immer wieder gerne eine Partie Billard mit den Kumpels und Vereinskameraden. Der Verein freut sich über jeden, der einmal in unserem schicken Vereinsheim vorbeischauen möchte.
Billard Sport BS / nicht mehr von mir betreut billard-sport-braunschweig.de