Dnsmasq: getestete Konfigurationsdateien und -beispiele

Einleitung

Dnsmasq ist ein kleiner Dienst für Linux/MAC OS, der drei Basisdienste bereitstellen kann und dabei sehr wenig Ressourcen verbraucht. Er kann poblemlos auch aus einem RaspberryPI betrieben werden. Bei den Diensten handelt es sich um

Übersicht einiger Basiskommandos

Debuggen ohne als Dienst in den Hintergrund zu fallen

dnsmasq --no-daemon --log-queries

Konfiguration auf Syntaxfehlern testen

dnsmasq --test

Version von Dnsmasq ermitteln

dnsmasq -v
 
Dnsmasq Version 2.76  Copyright (c) 2000-2016 Simon Kelley
Kompilierungs-Optionen IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC loop-detect inotify

DHCP-Proxy

Wofür?

Einen DHCP-Proxy benötigt man, wenn man via PXE über das Netzwerk booten möchte, aber der DHCP-Server im Netz diese Funktion nicht unterstützt (z.B. eine AVM FritzBox oder die meisten andern Konsumer Router) oder man keine Rechte hat auf dem DHCP-Server die notwendigen Einstellungen vorzunehmen.

Mininmalkonfiguration für den Einsatz mit einem externen TFTP-Server

Die Beispielkonfiguration /etc/dnsmasq.conf ist run 20kb groß und enthält deutlich mehr Optionen, als man für einen DHCP-Proxy benötigt. Dieses Beispiel ist dafür gedacht, wenn man bereits einen Network Attached Storage in Betrieb hat und dieser auch als TFTP-Server genutzt werden soll. DNSmasq kann selbst auch als TFTP-Server agieren, aber das ist in diesem, speziellen Beispiel nicht aktiviert.

# DNS Dienst abschalten
port=0
 
# Falls man mehr als eine NIC hat, kann man hier gestlegen auf welchem Interface der Proxy Dienst arbeiten soll
# interface=eth0
bind-dynamic
bogus-priv
domain-needed
no-resolv
no-poll
 
# Hier die IP-Adresse des Servers eintragen, auf dem Dnsmasq läuft. Es kann auch die Basisadresse eines Subnetzes
# angegeben werden. z.B. 192.168.0.0
dhcp-range=192.168.1.10,proxy
dhcp-no-override
 
# Falls der folgende Parameter pxe-prompt fehlt, funktioniert kein Netzwerkboot mehr.
pxe-prompt="", 0
 
# Extra logging für DHCP: loggt alle Options die zu den DHCP clients gesendet wurde und auch die tags, die für die ermittlung verwendet wurden
# Beim Debugging von PXE-Problemen und dem Tagging extrem hilfreich!
log-dhcp
 
# Pfad zur Logdatei. Falls dieser nicht definiert ist, wird stattdessen im Syslog protokolliert.
log-facility=/var/log/dnsmasq.log
 
 
### Tagging und Tagabhängige operationen #####################################
dhcp-userclass=set:iPXE,iPXE
# iPXE: optional. Überträgt die Adresse des iSCSI Targets. In diesem Beispiel die von einem FreeNAS-Server.
#dhcp-option-force=203,iqn.2017-01.filer.ctl
 
# iPXE: IP-Adresse des TFTP-Servers und der Name der zu bootenden Datei. Kann z.B. auch pxelinux.0 sein.
dhcp-boot=tag:!iPXE,undionly.kpxe,,192.168.1.10
 
# iPXE: Wenn das iPXE ROM aktiv ist, dann hier den Namen der zu ladenden Konfigurationsdatei an den Client senden.
dhcp-boot=tag:iPXE,boot.ipxe,,192.168.1.10

Wenn alles funktioniert, muss beim Versuch über das Netzwerk zu booten der gelb markierte Abschnitt zu sehen sein. In diesem Beispiel wird iPXE gestartet, aber es könnte auch genauso gut pxelinux sein.

Auffallend ist, das die IP-Adresse des DHCP-Proxys nicht dieselbe ist, wie die des DHCP-Servers.

Tagging von Clients

Was ist Tagging?

DNSMasq macht es dem Administrator relativ einfach Clients im Netz mit einem sogenannten Tag zu versehen. Dieses Tagging erleichtert dann eine Gruppierung um dann letztlich für eben diese Gruppe von Clients mit demselben Tag gewissen Aktionen oder auch andere Informationen per DHCP zuzuweisen.

Clients anhand ihrer MAC-Adresse taggen

In ESXI beginnen alle MAC-Adressen mit 00:0c:29. Mit der folgenden Zeile kann man mittels Wildcards alle Clients mit dem Tag vmware versehen.

dhcp-mac=set:vmware,00:0c:29:*:*:*       # vmware

Taggen von iPXE Clients (Chainlooping)

Booten über das Netzwerk via iPXE stellt besondere Ansprüche an die Konfiguration. Denn bei der ersten Bootanfrage eines Clients muss als Dateiname der Name des iPXE Roms an den Client übermittelt werden. Nachdem dann das iPXE ROM beim Client angekommen und gestartet wurde, sendet iPXE wiederum wieder ein Anfrage an den DHCP-Server bzw. DHCP-Proxy um einen Dateinamen für die Konfiguration zu erhalten. Wenn nun wieder das iPXE ROM ausgeliefert wird, dreht sich das ganze im Kreis.

Die Kunst für den DHCP Server ist es nun zu erkennen, wer will einen Dateinamen erhalten? iPXE sendet bei der Abfrage nach einem Dateinamen eine UserClass mit dem Inhalt iPXE (Hexadezimal 0x69 0x50 0x58 0x45) an den DHCP-Server. Und anhand dieser Klasse kann erkannt werden, das es sich um ein iPXE Client handelt und diesem dann abweichend einen anderen Dateinamen ausliefern. Auch hier kommt Tagging zum Einsatz. Der Name des Tags ist frei wählbar und unterscheidet zwischen Groß-/leinschreibung

dhcp-userclass=set:iPXE,iPXE  # iPXE sendet eine User-Klasse iPXE
 
# Alles was NICHT iPXE ist, bekommt undionly.kpxe als FILENAME (Option 67)
# Siehe auch https://tools.ietf.org/html/rfc2132#page-27 Kapitel 9.5
dhcp-boot=tag:!iPXE,undionly.kpxe,,<TFTPSERVER-IP>
 
# Alles was den Tag iPXE besitzt, bekommt das Bootmenü
dhcp-boot=tag:iPXE,http://boot.ipxe.org/demo/boot.php,,<TFTPSERVER-IP>

Anhang

Liste der in DNSmasq bekannten Optionen

Mittels des Parameters dhcp-option kann man auch benamte Optionen an den Client senden. In dieser Tabelle, die man auch auf der Konsole mit

dnsmasq --help dhcp

bekommt, sind alle bekannten Optionen aufgelistet. Gleichzeitig bekommt man so auch eine Idee, welche Option welcher Nummer zugeordnet ist.

DHCP-Proxy in Docker

docker run \
        -d \
        --name dnsmasq \
        --net host \
        --restart unless-stopped \
        -v $(pwd)/dnsmasq.conf:/etc/dnsmasq.conf \
        -v /tftproot:/tftproot \
        --log-opt "max-size=100m" \
        -e "HTTP_USER=admin" \
        -e "HTTP_PASS=1234" \
        jpillora/dnsmasq

siehe auch → https://github.com/jpillora/docker-dnsmasq