Für mich dienen Artikel auf Pilgermaske immer auch als Dokumentation. Deswegen will ich hier mal schnell zusammen schreiben, was mir bei der Installation und Netzwerkkonfiguration von Ubuntu 18.04 Server LTS auf einen Heimserver aufgefallen ist. Dies wäre gar nicht notwendig, wenn nicht in Ubuntu 18.04 – Server Variante – verschiedene Neuerungen eingebaut wären. Hier soll es um die Punkte Netzwerk und DNS/DHCP Service mit Dnsmasq gehen.

Der Unterschied zwischen der Ubuntu Server und Desktop Variante ist, dass

• es andere Optionen (LVM, …) je nach Variante bei der Installation gibt.
• das Netzwerk in der Server Variante von networkd und bei der Desktop Variante von NetworkManager verwaltet wird.
• standardmäßig keine grafische Oberfläche in der Server Variante installiert wird.

Eine Heimserver Installation hat bei mir keine grafische Oberfläche, zwei Netzwerkkarten sind verbaut und es werden zentrale Netzwerkdienste – mindestens DNS/DHCP, Mailserver und Webserver – betrieben. Der Server ist im Internet über DDNS (mit ipv4) erreichbar. Im Prinzip könnte ich auch ein NAS auf Linux Basis kaufen und hätte das Gleiche – aber wo bleibt da der Spass?

Die Installation läuft eigentlich nach der üblichen Methode: Image auf CD oder SDHC Karte brennen, von Datenträger booten und dann durchklicken. Allerdings testet Ubuntu scheinbar ein neues Setup und damit sieht die Sache optisch anders aus. Ob es Vorteile hat? Naja.

Allerdings ist die Netzwerk Konfiguration jetzt umfassender möglich. Wenn ich mich recht erinnere, konnte in alten Versionen nur die Netzwerkkarte ausgewählt werden und dann suchte Ubuntu einen IP gebenden Server (DHCP) und fertig. Jetzt kann auf eine Netzwerkkarte geklickt werden und schon kommt Admina in ein Formular um DNS, Gateway und sonstige Werte einzutragen.

Und genau das würde ich auch empfehlen, egal ob es brauchbare Werte sind, weil dann unter /etc/netplan/ eine Datei mit diesen Werten erstellt wird, die uns später als Muster dienen kann!

Netplan heißt das Konstrukt, mit dem Ubuntu die Netzwerkschnittstellen konfiguriert. Die damit erstellte Datei 50-cloud-init.yaml kann nachträglich bearbeitet werden und die Einstellungen bleiben auch erhalten. Mit einer Kopie dieser Datei ist der Server nach der nächsten Installation ratzfatz konfiguriert.

Nochmal: Wir reden in der Server Variante vom systemd-networkd als den Netzwerkverwaltungsdienst, dieser dirigiert mit Netplan über .yaml Dateien die Konfiguration. Die yaml Datei liegt in /etc/netplan und ersetzt die /etc/network/interfaces!

Im folgenden Text sind natürlich alle Werte der eigenen Umgebung zu setzen! Meine yaml sieht am Ende so aus:

network:
    ethernets:
        enp16s0:
            addresses:
            - 192.168.1.1/24
            nameservers:
                addresses:
                - 8.8.8.8
                - 8.8.4.4
                search:
                - meinnetz.local
            optional: false
        enp37s0:
            addresses:
            - 192.168.0.2/24
            gateway4: 192.168.0.1
            optional: false
    version: 2

Ja, die Leerzeichen – keine Tabs! – sind wirklich(!) zu beachten und die Systematik der Leerzeichen hat sich mir nicht wirklich erschlossen. Viel Spass damit. Aber im Wesentlichen sind die Werte natürlich keine anderen als sonst auch. Das Rezept bleibt gleich. Doch mal einige Kommentare:

Das optional: false besagt, dass die Netzwerkkarte (also bei mir enp16s0 und enp37s0) beim booten vorhanden und nutzbar sein muss. Eben nicht optional. Das ist notwendig, weil abhängige Serverdienste wie Dnsmasq – ein DNS/DHCP Service – sonst beim booten Fehler anzeigt und es danach zu Nervereien kommen kann. Hier kann die Ausgabe von journalctl -xb hilfreich sein. Damit schaut man sich das letzte boot Protokoll an.

Der gateway4 Eintrag (wobei 4 für ipv4) liegt übrigens immer auf der Netzkarte, die mit dem Provider Router connectet (siehe Bild oben). Die Werte der Karte enp16s0 sind für die Generierung der /etc/resolv.conf wichtig: Vor allem der search Eintrag – also der Domänenteil eines Rechnernames – ist hier besonders zu beachten! Siehe auch die Ausgabe von systemd-resolve --status

Zwei Netzwerkkarten heißt, eine bedient die Rechner und die andere hält den Kontakt zum Internet über den Provider Router (Technicolor, ipv4). Im Router habe ich als DMZ Eintrag die 192.168.0.2 (enp37s0) hinterlegt, d.h. alles wird vom Router ungefiltert an meinen Heimserver, an 192.168.0.2 weiter geroutet.

Und damit muss natürlich auch mein Server so konfiguriert sein, dass er umgekehrt den Internet- Traffic aus dem Heimnetz an den Router in das Internet routet. Bitte beachten: Bei diesen Konstrukt – weiterleiten an DMZ Server – kann der Provider Router im Wohnzimmer keinerlei Schutz bieten, die Firewall greift nicht. Also entsprechende Sicherheitsmaßnahmen auf dem Ubuntu Server einrichten!

Für die Weiterleitung des Traffics müssen wir Folgendes durchführen:

• In der /etc/sysctl.conf aktivieren wir die Funktion net.ipv4.ip_forward=1 also die #Raute vor dieser Option entfernen.
• Wir ‘maskieren’ den Traffic der Clients mit der öffentlichen IP des Provider Routers. Hier gibt es verschiedene Lösungen, dies ist die Einfachste. Wir erstellen die Datei /etc/rc.local mit folgenden Inhalt und machen sie mit chmod 755 ausführbar:

#!/bin/sh -e
/sbin/iptables -t nat -A POSTROUTING -o enp37s0 -j MASQUERADE
exit 0

Mit Punkt 1 werden z.B. Webseiten Anfragen der Clients von enp16s0 – der Netzkarte, mit Kontakt zu unseren Clients – weitergereicht (forward) an enp37s0 und an den Provider Router weitergegeben, der den Traffic als eigenen Traffic im Internet deklarieren soll (MASQUERADE).

Jetzt wollen wir Dnsmasq – den DNS und DHCP Service – einrichten:

• Installiere Dnsmasq mit apt install dnsmasq
• Trage in /etc/hosts alle möglichen Namen des Servers ein. Die hosts ist eine zentrale Datei für Dnsmasq!
• Wir schalten die Verwaltung der /etc/resolv.conf durch systemd ab.
• Dazu setzen wir in /etc/systemd/resolved.conf folgenden Wert: DNSStubListener=no (siehe diese Hilfe und Kommentar hier unten)
• Wir vergessen nicht, dass # Zeichen vor dem Eintrag zu entfernen und führen nacheinander (stop/start) die folgenden Befehle zur Aktivierung der Änderung aus:
• systemctl stop[start] systemd-networkd.service und systemctl stop[start] systemd-resolved.service

Im nächsten Schritt erstellen wir die Datei /etc/dnsmasq.d/meinnetz.conf mit folgenden Inhalt:

domain-needed
bogus-priv
filterwin2k
local=/meinnetz.local/
server=8.8.8.8
server=8.8.4.4
interface=enp16s0
expand-hosts
domain=meinnetz.local
dhcp-range=192.168.1.50,192.168.1.150,12h

Das sind die gängigen Optionen, die Admina für einen funktionierenden Dnsmasq Service braucht. Interessant sind hier eigentlich nur die Einträge für server=8.8.8.8 und weitere, da damit, dem Dnsmasq gesagt wird, dass er die Google Server ansprechen soll, wenn er eine Namensauflösung anders nicht herbeiführen kann. Das interface=enp16s0 ist hier die Netzkarte mit Kontakt zu den Clients, z.B. über einen switch (siehe Bild oben). Mit dhcp-range= vergeben wir IP Adressen an die Clients im aufgeführten Bereich (hier also 100 mögliche Adressen) mit einer Gültigkeit von 12 Stunden (leasetime).

Genau wegen diesen interface= Eintrag muss oben in der yaml der Eintrag optional= false gesetzt werden. Er ermöglicht ein fehlerfreies Starten des Dnsmasq beim booten des Servers. Damit sollten Clients in deinen Netzwerk eine IP bekommen und den Weg in das Internet finden.

Beachte: Wenn Du diese Anleitung umgesetzt hast, teste und teste. Hilfreich sind die üblichen Befehle: route -n, iptables -L -n -t nat, nslookup, netstat -tulpen, htop, ps -ax, tracert (unter windows), tracepath, ifconfig, ipconfig (unter windows). Auf jeden Fall würde ich mich umfassend mit journalctl, systemctl und networkctl beschäftigen, weil diese Befehle wirklich tolle Diagnosen ermöglichen, die bisher nicht oder nur umständlich möglich waren.

Warum dieser Roman? Einfache Sache. Eigentlich ja, aber wer schon etwas gebastelt hat, merkt, dass die neue Netzwerkverwaltung einen ständig die resolv.conf ‘kaputt’ macht, oder in der resolv.conf plötzlich 127.0.0.53:53 steht und nicht wie gewohnt 127.0.0.1. Auch kann das Starten des Dnsmasq Probleme machen, weil ja schon der systemd-resolved an port 53 lauscht.

Manche Kollegen definieren mühselig Routen (in der yaml), weil alles im eigenen Lan funktioniert, nur der Internet Verkehr nicht – an das Masquerade (Artikel im blog) denkt Admina nicht sofort. Und Netplan/yaml ist eben was anderes als das alt- bewährte /etc/network/interfaces.

### Kommentar zu DNSStubListener=no

Im oben verlinkten Forenbeitrag zum Thema argumentiert ein Admin, dass es bei ihm ausreichte, die Option bind-interfaces in die dnsmasq.conf einzutragen und die /etc/systemd/resolved.conf so zu lassen, wie sie ist (alle Werte #inaktiv). Auf meinen Server – eingerichtet wie hier beschrieben – haben beide Lösungen funktioniert.

Viel Spass beim basteln.

---