narcissus – Router-Konfiguration

Dieses Repo dokumentiert die Router-Konfiguration des Servers narcissus (narcissus.fhi.mpg.de). Der Server hat zwei Netzwerkinterfaces und übernimmt für ein kleines internes Netz die Rollen Router, Default-Gateway, Nameserver und DHCP-Server.

Die Dateien unter config/ sind 1:1-Kopien der aktiven Konfiguration auf dem Server (Stand: siehe Git-Log). Das Repo ist reine Dokumentation/Backup – es gibt kein automatisches Deployment. Änderungen müssen manuell auf dem Server vorgenommen werden (siehe unten) und sollten danach hier eingecheckt werden, damit Doku und Realität übereinstimmen.

Statische Host-Einträge (feste IP/DHCP-Reservierung + DNS-Name) werden nicht mehr von Hand in dnsmasq.d gepflegt, sondern über das Tool ipadm (/usr/local/bin/ipadm auf narcissus), siehe tools/ipadm/README.md.

Netzwerk-Topologie

                    Internet
                        │
                enp3s0 (WAN, öffentlich)
              141.14.140.128/20
                Gateway: 141.14.128.128
                        │
              ┌─────────────────────┐
              │   narcissus (Router) │
              │  ip_forward=1, NAT   │
              └─────────────────────┘
                        │
                enp7s0 (LAN)
                 10.0.0.1/24
                        │
              ┌─────────┴─────────┐
              │   10.0.0.0/24     │
              │  DHCP: .100–.200  │
              │  Clients          │
              └───────────────────┘

• WAN: enp3s0, statische öffentliche IP, unverändert wie vorher.
• LAN: enp7s0, neu eingerichtet, 10.0.0.1/24, Router = Gateway = DNS für alle Clients im Netz.

Was wurde eingerichtet

Bereich	Was	Datei auf dem Server	Kopie in diesem Repo
LAN-Interface	enp7s0 statisch auf 10.0.0.1/24	/etc/network/interfaces	config/network-interfaces
IP-Forwarding	net.ipv4.ip_forward=1, persistent über Reboot	/etc/sysctl.d/99-router-forwarding.conf	config/sysctl.d/99-router-forwarding.conf
NAT	Masquerading 10.0.0.0/24 → raus über enp3s0	/etc/nftables.conf	config/nftables.conf
DHCP + DNS	dnsmasq: DHCP-Pool, Gateway/DNS-Option, DNS-Forwarding	/etc/dnsmasq.d/lan.conf	config/dnsmasq.d/lan.conf
DNS-Includes aktiviert	eine Zeile in /etc/dnsmasq.conf einkommentiert: conf-dir=/etc/dnsmasq.d/,*.conf	/etc/dnsmasq.conf	– (Rest der Datei ist Debian-Standard, nicht gespiegelt)
Statische Hosts (DHCP-Reservierung + DNS)	von ipadm generiert, nicht von Hand editieren	/etc/dnsmasq.d/hosts.conf (generiert) + /etc/ipadm/hosts (Datenbank)	– (live Daten, siehe tools/ipadm/)
dnsmasq-Resilienz	Restart=on-failure (Default war no), damit dnsmasq bei einem Boot-Race mit enp7s0 nicht dauerhaft tot bleibt	/etc/systemd/system/dnsmasq.service.d/override.conf	config/systemd/dnsmasq.service.d/override.conf

Installiertes Paket: dnsmasq (übernimmt sowohl DHCP- als auch DNS-Server-Rolle). nftables war bereits installiert, wurde aber aktiviert (systemctl enable --now nftables).

Details zur dnsmasq-Konfiguration (config/dnsmasq.d/lan.conf)

• interface=enp7s0 + bind-interfaces + except-interface=enp3s0: dnsmasq lauscht ausschließlich auf dem LAN-Interface. Das ist absichtlich so restriktiv, damit auf der öffentlichen WAN-Seite kein offener DNS-Resolver/DHCP-Server erreichbar ist (Missbrauchsrisiko, z.B. DNS-Amplification).
• dhcp-range=10.0.0.100,10.0.0.200,255.255.255.0,12h: DHCP-Pool, 12h Lease. .2–.99 bleiben frei für statische Reservierungen/Server, .201–.254 als Puffer.
• dhcp-option=option:router,10.0.0.1 / dhcp-option=option:dns-server,10.0.0.1: Clients bekommen den Router selbst als Gateway und als DNS-Server.
• domain=fhi.mpg.de / server=141.14.128.1 / no-resolv: DNS-Anfragen aus dem LAN werden an den institutseigenen DNS-Server weitergeleitet (gleicher Resolver wie auf der WAN-Seite), interne fhi.mpg.de-Hosts bleiben auflösbar. no-resolv verhindert, dass dnsmasq zusätzlich /etc/resolv.conf als Upstream-Quelle einliest (Eindeutigkeit).

Details zur nftables-Konfiguration (config/nftables.conf)

• table inet filter: unverändert (keine Regeln, Policy accept auf input/forward/output) – die WAN-Seite wurde bewusst nicht gehärtet/eingeschränkt, um die bestehende Erreichbarkeit des Servers nicht zu verändern.
• table inet nat / chain postrouting: NAT-Masquerading für Traffic aus 10.0.0.0/24, der über enp3s0 rausgeht. Das ist die einzige Regel, die tatsächlich nötig ist, damit LAN-Clients ins Internet kommen.

Konfiguration anpassen

Alle Änderungen werden direkt auf dem Server in den Dateien unter /etc/... gemacht (Pfade siehe Tabelle oben), dann der jeweilige Dienst neu geladen (siehe Befehle unten). Bitte die Änderung danach auch hier ins Repo übernehmen (Datei in config/ anpassen + committen), damit die Doku aktuell bleibt.

DHCP-Pool / Lease-Zeit ändern

In /etc/dnsmasq.d/lan.conf die Zeile anpassen, z.B.:

dhcp-range=10.0.0.50,10.0.0.250,255.255.255.0,24h

Danach: systemctl restart dnsmasq

Statische IP-Reservierung für ein Gerät (per MAC)

In /etc/dnsmasq.d/lan.conf (oder eine eigene Datei /etc/dnsmasq.d/hosts.conf) ergänzen:

dhcp-host=aa:bb:cc:dd:ee:ff,10.0.0.10,mein-server,infinite

Danach: systemctl restart dnsmasq

DNS-Upstream ändern (z.B. auf öffentliche Resolver)

In /etc/dnsmasq.d/lan.conf die server=-Zeile anpassen/ergänzen, z.B.:

server=9.9.9.9
server=1.1.1.1

Mehrere server=-Zeilen sind möglich (Round-Robin/Fallback). Danach: systemctl restart dnsmasq

Lokale Domain / eigene Hostnamen im LAN

dnsmasq kann zusätzlich als einfacher lokaler DNS-Server für das LAN dienen. Beispiel in /etc/dnsmasq.d/lan.conf:

address=/server1.lan/10.0.0.10

Oder Einträge über /etc/hosts-Syntax in einer eigenen Datei einbinden (addn-hosts=/etc/dnsmasq.d/lan-hosts).

Weitere Firewall-/Portfreigaben (z.B. Port-Forwarding vom WAN ins LAN)

In /etc/nftables.conf, table inet nat, eine chain prerouting ergänzen, z.B. um Port 8080 vom WAN auf einen LAN-Host weiterzuleiten:

chain prerouting {
	type nat hook prerouting priority dstnat;
	iifname "enp3s0" tcp dport 8080 dnat to 10.0.0.10:8080
}

Danach: nft -c -f /etc/nftables.conf (Syntaxcheck) und dann systemctl reload nftables bzw. nft -f /etc/nftables.conf.

⚠️ Falls künftig auch der WAN-Eingang gefiltert werden soll (aktuell bewusst offen gelassen), unbedingt zuerst SSH-Zugriff (und alle anderen aktiv genutzten Dienste) explizit erlauben, bevor eine restriktive policy drop auf chain input gesetzt wird – sonst sperrt man sich ggf. selbst aus.

LAN-Netz/IP-Bereich komplett ändern (z.B. auf ein anderes /24)

1. /etc/network/interfaces: address der enp7s0-Zeile anpassen.
2. /etc/dnsmasq.d/lan.conf: dhcp-range und beide dhcp-option-Zeilen (Router/DNS-IP) anpassen.
3. /etc/nftables.conf: ip saddr 10.0.0.0/24 in der NAT-Regel anpassen.
4. Anwenden: ifreload -a (oder ifdown enp7s0 && ifup enp7s0), systemctl restart dnsmasq, nft -f /etc/nftables.conf.

Befehle zum Anwenden von Änderungen

# dnsmasq-Konfig auf Syntaxfehler prüfen, dann neu laden
dnsmasq --test
systemctl restart dnsmasq

# nftables-Konfig auf Syntaxfehler prüfen, dann neu laden
nft -c -f /etc/nftables.conf
nft -f /etc/nftables.conf
# bzw. systemctl reload nftables (lädt /etc/nftables.conf neu ein)

# Netzwerk-Interface-Änderungen anwenden (ifupdown)
ifdown enp7s0 && ifup enp7s0

# sysctl-Änderungen anwenden
sysctl --system

Troubleshooting / nützliche Befehle

# Aktive nftables-Regeln anzeigen
nft list ruleset

# dnsmasq-Status und Logs
systemctl status dnsmasq
journalctl -u dnsmasq -f

# Wer bekommt gerade welche DHCP-Lease
cat /var/lib/misc/dnsmasq.leases

# DNS-Auflösung über den Router testen
dig @10.0.0.1 www.example.com

# Lauscht dnsmasq wirklich NUR auf enp7s0 (nicht auf der WAN-IP)?
ss -tulpn | grep -E ':53|:67'

# IP-Forwarding aktiv?
sysctl net.ipv4.ip_forward

# Interface-/Carrier-Status (z.B. wenn Kabel nicht erkannt wird)
ip -brief addr
ip link show enp7s0
cat /sys/class/net/enp7s0/carrier

Sicherheitshinweise

• dnsmasq ist bewusst so konfiguriert, dass es nur auf enp7s0 lauscht (interface=, bind-interfaces, except-interface=enp3s0). Vor jeder Änderung an dieser Konfiguration prüfen, dass diese Einschränkung erhalten bleibt – sonst entsteht ein von außen erreichbarer DNS-/DHCP-Dienst.
• Die WAN-Seite (enp3s0) wurde absichtlich nicht gefiltert/gehärtet, um die bestehende Erreichbarkeit (u.a. SSH) nicht zu verändern. Das war eine bewusste Entscheidung bei der Einrichtung, keine Vergesslichkeit.