mike
78beedeabc
Found and fixed a second, uncontrolled DHCP server on the LAN (a WiFi router still in router mode instead of access-point mode) that was intermittently handing out wrong DNS/IP config to clients. log-dhcp was key to spotting it via the 'wrong server-ID' DHCPNAK pattern, so keeping it enabled going forward; log-queries (diagnostic-only, noisy) was removed again.
249 lines
11 KiB
Markdown
249 lines
11 KiB
Markdown
# 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/`](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`](tools/ipadm/) (`/usr/local/bin/ipadm` auf narcissus), siehe
|
||
[tools/ipadm/README.md](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`](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`](config/sysctl.d/99-router-forwarding.conf) |
|
||
| NAT | Masquerading `10.0.0.0/24` → raus über `enp3s0` | `/etc/nftables.conf` | [`config/nftables.conf`](config/nftables.conf) |
|
||
| Port-Forwarding-Include | `/etc/nftables.conf` bindet `/etc/nftables.d/*.conf` ein (dort generiert `ipadm` die Port-Forward-Regeln) | `/etc/nftables.conf` (Zeile am Ende) | [`config/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`](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) |
|
||
| DHCP-Logging | `log-dhcp` aktiviert (zeigt DHCPDISCOVER/OFFER/REQUEST/ACK/NAK in `journalctl -u dnsmasq`) — war entscheidend, um am 2026-08-19 einen rogue DHCP-Server im LAN zu finden | `/etc/dnsmasq.d/90-logging.conf` | [`config/dnsmasq.d/90-logging.conf`](config/dnsmasq.d/90-logging.conf) |
|
||
| 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/`](tools/ipadm/)) |
|
||
| Port-Forwards (WAN → LAN-Host) | von `ipadm` generiert, **nicht** von Hand editieren | `/etc/nftables.d/portforward.conf` (generiert) + `/etc/ipadm/portforwards` (Datenbank) | – (live Daten, siehe [`tools/ipadm/`](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`](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`).
|
||
|
||
### Port-Forwarding (WAN → LAN-Host)
|
||
|
||
Wird über `ipadm` verwaltet, siehe [tools/ipadm/README.md](tools/ipadm/README.md).
|
||
Kurzform: Zielhost muss zuerst als Host in `ipadm` angelegt sein, dann:
|
||
|
||
```sh
|
||
ipadm -pa <hostname> <wan-port> [lan-port] [tcp|udp|both]
|
||
ipadm -u # generiert /etc/nftables.d/portforward.conf neu + reloadet nftables
|
||
```
|
||
|
||
Nicht mehr von Hand in `/etc/nftables.conf` eintragen — die Datei bindet
|
||
dafür `/etc/nftables.d/*.conf` ein, das ist der von `ipadm` verwaltete Teil.
|
||
|
||
⚠️ 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
|
||
|
||
```sh
|
||
# 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
|
||
|
||
```sh
|
||
# 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
|
||
```
|
||
|
||
### Rogue DHCP-Server erkennen (z.B. "falscher Nameserver"-Symptom)
|
||
|
||
Am 2026-08-19 kam die Meldung "DHCP liefert falschen Nameserver aus". Ursache
|
||
war kein Config-Fehler, sondern ein **zweiter DHCP-Server im LAN** (ein
|
||
WLAN-Router, der noch im Router- statt Access-Point-Modus lief und parallel
|
||
eigenes DHCP anbot). Erkennbar in `journalctl -u dnsmasq` (braucht `log-dhcp`,
|
||
siehe oben) an folgendem Muster:
|
||
|
||
```
|
||
DHCPOFFER(enp7s0) 10.0.0.157 <mac> ← unser Angebot
|
||
DHCPREQUEST(enp7s0) 10.0.0.151 <mac> ← Client nimmt eine andere IP an
|
||
DHCPNAK(enp7s0) 10.0.0.151 <mac> wrong server-ID ← wir lehnen zu Recht ab
|
||
```
|
||
|
||
Client hat also ein Angebot von einer fremden Quelle angenommen. Gerät mit
|
||
aktiver Web-Verwaltung im LAN suchen (z.B. `curl -I http://<verdächtige-ip>/`)
|
||
und dessen DHCP-Server deaktivieren / in Access-Point-Modus umschalten —
|
||
narcissus soll der einzige DHCP-Server im `10.0.0.0/24`-Netz sein.
|
||
|
||
## 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.
|