362 lines
11 KiB
Markdown
362 lines
11 KiB
Markdown
# 09 · MetalLB + Pi-hole Installation
|
||
|
||
**Datum:** 2026-03-18
|
||
|
||
---
|
||
|
||
## Was wurde installiert
|
||
|
||
- **MetalLB** v0.14.x — Layer-2 Load Balancer für den k3s-Cluster
|
||
- **Pi-hole** (pihole/pihole:latest) — DNS-Adblocker mit Web-UI
|
||
|
||
---
|
||
|
||
## Vorbereitungen
|
||
|
||
### Klipper (k3s ServiceLB) deaktiviert
|
||
|
||
k3s hat einen eingebauten Load-Balancer (Klipper/ServiceLB), der mit MetalLB kollidiert.
|
||
Deaktiviert durch Ergänzung in `/etc/systemd/system/k3s.service`:
|
||
|
||
```
|
||
'--disable=servicelb' \
|
||
```
|
||
|
||
Dann: `systemctl daemon-reload && systemctl restart k3s`
|
||
|
||
### DNS-Fix auf rnk-wrk02
|
||
|
||
`systemd-resolved` Stub-Resolver (127.0.0.53) war defekt → containerd konnte keine Images pullen.
|
||
|
||
Fix: `/etc/resolv.conf` Symlink auf direkte DNS-Auflösung umgestellt:
|
||
```bash
|
||
ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf
|
||
```
|
||
Nameserver ist nun direkt `192.168.11.1`.
|
||
|
||
---
|
||
|
||
## Ausgeführte Befehle
|
||
|
||
### MetalLB
|
||
|
||
```bash
|
||
helm repo add metallb https://metallb.github.io/metallb
|
||
helm repo update
|
||
helm upgrade --install metallb metallb/metallb \
|
||
--namespace metallb-system \
|
||
--create-namespace \
|
||
--wait
|
||
kubectl apply -f ~/homelab/k8s/metallb/metallb-config.yaml
|
||
```
|
||
|
||
### Pi-hole
|
||
|
||
```bash
|
||
kubectl create namespace pihole
|
||
kubectl apply -f ~/homelab/k8s/pihole/secret.yaml
|
||
kubectl apply -k ~/homelab/k8s/pihole/
|
||
```
|
||
|
||
---
|
||
|
||
## IP-Adressen
|
||
|
||
| Service | IP | Protokoll |
|
||
|---|---|---|
|
||
| Traefik (Ingress) | 192.168.11.180 | TCP 80/443 |
|
||
| Pi-hole DNS | 192.168.11.181 | TCP+UDP 53 |
|
||
|
||
MetalLB Pool: `192.168.11.180 – 192.168.11.199`
|
||
|
||
---
|
||
|
||
## Ergebnis
|
||
|
||
```
|
||
NAME READY STATUS RESTARTS
|
||
pod/pihole-f7d664fd-v65wn 1/1 Running 0
|
||
|
||
NAME TYPE CLUSTER-IP EXTERNAL-IP
|
||
pihole-dns-tcp LoadBalancer 10.43.200.43 192.168.11.181
|
||
pihole-dns-udp LoadBalancer 10.43.65.201 192.168.11.181
|
||
pihole-web ClusterIP 10.43.25.107 <none>
|
||
```
|
||
|
||
---
|
||
|
||
## Zugang
|
||
|
||
- **Web-UI:** http://pihole.192.168.11.181.nip.io/admin
|
||
- **DNS-Server:** `192.168.11.181` (Port 53 TCP+UDP)
|
||
- **Passwort:** in Secret `pihole/pihole-secret`
|
||
|
||
---
|
||
|
||
## Dateien
|
||
|
||
```
|
||
~/homelab/k8s/metallb/
|
||
metallb-config.yaml # IPAddressPool + L2Advertisement
|
||
|
||
~/homelab/k8s/pihole/
|
||
kustomization.yaml
|
||
namespace.yaml
|
||
secret.yaml # WEBPASSWORD (nicht ins Git!)
|
||
deployment.yaml
|
||
services.yaml # DNS TCP/UDP LoadBalancer + Web ClusterIP
|
||
ingress.yaml # Traefik Ingress für Web-UI
|
||
```
|
||
|
||
---
|
||
|
||
## Nächste Schritte
|
||
|
||
- Router/DHCP auf DNS `192.168.11.181` umstellen
|
||
- Pi-hole Blocklisten konfigurieren
|
||
- ~~Ggf. Persistent Volume für `/etc/pihole` hinzufügen~~ → erledigt (siehe unten)
|
||
|
||
---
|
||
|
||
## Troubleshooting 2026-03-19
|
||
|
||
### Problem 1: Web-UI nicht erreichbar
|
||
|
||
**Symptom:** Browser kann `http://pihole.192.168.11.180.nip.io/admin/` nicht laden.
|
||
|
||
**Diagnose:**
|
||
```bash
|
||
kubectl get pods -n pihole # Pod läuft (Running)
|
||
kubectl logs -n pihole deployment/pihole --tail=50 # FTL startet normal
|
||
```
|
||
|
||
**Ursache:** Pi-hole v6 verwendet keinen lighttpd mehr — der Webserver ist direkt in FTL integriert (Port 80/443). `service lighttpd status` schlägt in v6 fehl.
|
||
|
||
**Ergebnis:** Web-UI war tatsächlich erreichbar, Ingress funktionierte korrekt (HTTP 302 → `/admin/login`).
|
||
|
||
---
|
||
|
||
### Problem 2: DNS antwortet nicht (192.168.11.181:53)
|
||
|
||
**Symptom:** `dig @192.168.11.181 google.com` läuft in Timeout. `nc -vzu 192.168.11.181 53` zeigt Port als offen.
|
||
|
||
**Diagnose:**
|
||
```bash
|
||
kubectl exec -n pihole <POD> -- grep -v "^#" /etc/pihole/pihole.toml | grep listeningMode
|
||
# → listeningMode = "LOCAL"
|
||
```
|
||
|
||
**Ursache:** Pi-hole v6 FTL startet standardmäßig mit `dns.listeningMode = "LOCAL"`. In Kubernetes kommt LoadBalancer-Traffic (192.168.11.0/24) nicht direkt vom Pod-Interface → dnsmasq verwirft alle Anfragen (logged: `ignoring query from non-local network`).
|
||
|
||
**Fix:** `DNSMASQ_LISTENING=all` in `deployment.yaml` hinzugefügt:
|
||
```yaml
|
||
env:
|
||
- name: DNSMASQ_LISTENING
|
||
value: "all"
|
||
```
|
||
|
||
```bash
|
||
kubectl patch deployment pihole -n pihole --type=json \
|
||
-p='[{"op":"add","path":"/spec/template/spec/containers/0/env/-","value":{"name":"DNSMASQ_LISTENING","value":"all"}}]'
|
||
kubectl rollout status deployment/pihole -n pihole
|
||
```
|
||
|
||
**Verifikation:**
|
||
```bash
|
||
dig @192.168.11.181 google.com +short
|
||
# → 142.250.201.78 ✓
|
||
```
|
||
|
||
**Persistenz:** Fix ist in `~/homelab/k8s/pihole/deployment.yaml` und in etcd gespeichert — überlebt Pod-Neustarts.
|
||
|
||
---
|
||
|
||
### Problem 3: HTTPS-Zugriff auf Web-UI schlägt fehl (2026-03-19)
|
||
|
||
**Symptom:** `https://pihole.192.168.11.180.nip.io/admin` nicht erreichbar — Ingress war nur auf HTTP (Port 80) konfiguriert.
|
||
|
||
**Ursache:** `ingress.yaml` hatte `traefik.ingress.kubernetes.io/router.entrypoints: web` — nur HTTP-Entrypoint.
|
||
|
||
**Fix:** Ingress auf `websecure` umgestellt + TLS aktiviert (Traefik Default-Zertifikat):
|
||
```yaml
|
||
annotations:
|
||
traefik.ingress.kubernetes.io/router.entrypoints: websecure
|
||
traefik.ingress.kubernetes.io/router.tls: "true"
|
||
spec:
|
||
tls:
|
||
- hosts:
|
||
- pihole.192.168.11.180.nip.io
|
||
```
|
||
|
||
```bash
|
||
kubectl apply -f ~/homelab/k8s/pihole/ingress.yaml
|
||
```
|
||
|
||
**Hinweis:** Browser zeigt Zertifikatswarnung (self-signed) — Ausnahme hinzufügen.
|
||
|
||
**Zugang:** `https://pihole.192.168.11.180.nip.io/admin`
|
||
|
||
---
|
||
|
||
### Problem 4: Claude Code ConnectionRefused wenn Pi-hole als DNS-Proxy gesetzt (2026-03-19)
|
||
|
||
**Symptom:** `API Error: Unable to connect to API (ConnectionRefused)` in Claude Code wenn `192.168.11.181` als DNS-Proxy in Omada gesetzt ist.
|
||
|
||
**Ursache:** Pi-hole gibt für `api.anthropic.com` auch eine IPv6-Adresse (`2607:6bc0::10`) zurück. Der Node hat kein funktionierendes globales IPv6 → Verbindungsversuch auf IPv6 schlägt mit ConnectionRefused fehl.
|
||
|
||
**Fix:** IPv4 in `/etc/gai.conf` bevorzugen:
|
||
```bash
|
||
echo "precedence ::ffff:0:0/96 100" >> /etc/gai.conf
|
||
```
|
||
|
||
**Verifikation:**
|
||
```bash
|
||
curl --connect-timeout 5 https://api.anthropic.com
|
||
# → Anthropic API erreichbar ✓
|
||
```
|
||
|
||
**Persistenz:** `/etc/gai.conf` ist persistent auf `rnk-cp01`.
|
||
|
||
---
|
||
|
||
## Migration von altem Pi-hole (2026-03-19)
|
||
|
||
### Ausgangslage
|
||
|
||
Altes Pi-hole lief als Docker-Container (`Pihole-DoT-DoH`, Image `devzwf/pihole-dot-doh:latest`) auf Unraid (`192.168.11.124`), erreichbar unter `192.168.11.123`.
|
||
|
||
### Vorgehen: Teleporter-Backup via HTTP-API
|
||
|
||
Pi-hole v6 änderte die CLI-Syntax — `pihole -a -t` funktioniert nicht mehr. Shell-Umleitung (`>`) korrumpiert Binärdaten (null bytes). Lösung: Backup direkt über die REST-API laden.
|
||
|
||
```bash
|
||
# 1. Authentifizieren und Backup als gültige ZIP herunterladen
|
||
SID=$(curl -s -X POST http://192.168.11.123/api/auth \
|
||
-H "Content-Type: application/json" \
|
||
-d '{"password":"<altes-passwort>"}' | grep -o '"sid":"[^"]*"' | cut -d'"' -f4)
|
||
|
||
curl -s -X GET http://192.168.11.123/api/teleporter \
|
||
-H "sid: $SID" \
|
||
-o /tmp/pihole-backup.zip
|
||
|
||
# 2. In neuen Pod kopieren und importieren
|
||
POD=$(kubectl get pods -n pihole -l app=pihole -o jsonpath='{.items[0].metadata.name}')
|
||
kubectl cp /tmp/pihole-backup.zip pihole/$POD:/tmp/pihole-backup.zip
|
||
|
||
SID=$(kubectl exec -n pihole $POD -- curl -s -X POST \
|
||
http://localhost/api/auth \
|
||
-H "Content-Type: application/json" \
|
||
-d '{"password":"<neues-passwort>"}' | grep -o '"sid":"[^"]*"' | cut -d'"' -f4)
|
||
|
||
kubectl exec -n pihole $POD -- curl -s -X POST \
|
||
http://localhost/api/teleporter \
|
||
-H "sid: $SID" \
|
||
-F "file=@/tmp/pihole-backup.zip"
|
||
```
|
||
|
||
**Importierte Objekte:** pihole.toml, gravity.db (adlists, domainlists, clients, groups), dhcp.leases, hosts
|
||
|
||
### Ingress-URL korrigiert
|
||
|
||
`nip.io`-Hostname enthält die eingebettete IP — `pihole.192.168.11.181.nip.io` löst auf die DNS-IP (Port 53) auf, nicht auf Traefik.
|
||
|
||
**Fix:** `ingress.yaml` Host auf Traefik-IP geändert:
|
||
```
|
||
pihole.192.168.11.180.nip.io → Traefik (192.168.11.180) → pihole-web Service
|
||
```
|
||
|
||
---
|
||
|
||
## DNS-Loop-Fix: Pod nutzt direkt 1.1.1.1 (2026-03-19)
|
||
|
||
### Problem
|
||
|
||
Pi-hole Pod nutzte CoreDNS (10.43.0.10) als Upstream → DNS-Loop, da CoreDNS intern Pi-hole anfragen kann.
|
||
|
||
### Fix: dnsPolicy auf None
|
||
|
||
```bash
|
||
kubectl patch deployment pihole -n pihole --patch '
|
||
spec:
|
||
template:
|
||
spec:
|
||
dnsPolicy: "None"
|
||
dnsConfig:
|
||
nameservers:
|
||
- 1.1.1.1
|
||
- 8.8.8.8
|
||
searches: []
|
||
'
|
||
```
|
||
|
||
**Hinweis:** Bei RWO-Volumes (Longhorn) kann der neue Pod beim Rollout auf einem anderen Node landen → `Multi-Attach error`. Lösung: alten Pod manuell löschen, danach ggf. stuck Pod ebenfalls löschen damit Scheduler neu plant.
|
||
|
||
```bash
|
||
kubectl delete pod <alter-pod> -n pihole
|
||
kubectl delete pod <stuck-pod> -n pihole # falls ContainerCreating auf falschem Node
|
||
```
|
||
|
||
**Verifikation:**
|
||
```bash
|
||
kubectl exec -n pihole <POD> -- cat /etc/resolv.conf
|
||
# nameserver 1.1.1.1
|
||
# nameserver 8.8.8.8
|
||
```
|
||
|
||
**Persistenz:** In `deployment.yaml` gespeichert + in etcd.
|
||
|
||
---
|
||
|
||
## Fix: Echte Client-IPs in Pi-hole (2026-03-19)
|
||
|
||
### Problem
|
||
|
||
Alle DNS-Queries in Pi-hole zeigten als Client `10.42.0.0` (Kubernetes Pod-Netzwerk) statt der echten Geräte-IPs (192.168.11.x).
|
||
|
||
### Ursache
|
||
|
||
kube-proxy führt SNAT (Source NAT) durch wenn Traffic über einen LoadBalancer-Service läuft — die Original-Source-IP wird durch die Pod-Netzwerk-IP ersetzt.
|
||
|
||
Zusätzlich: Der **Omada DNS-Proxy** leitet alle Client-Anfragen über sich selbst weiter → Pi-hole sieht nur die Router-IP als Client. Auch wenn der DNS-Proxy aktiv bleibt, muss kube-proxy die echte Router-IP durchreichen.
|
||
|
||
### Fix: externalTrafficPolicy: Local
|
||
|
||
```bash
|
||
kubectl patch svc pihole-dns-tcp -n pihole -p '{"spec":{"externalTrafficPolicy":"Local"}}'
|
||
kubectl patch svc pihole-dns-udp -n pihole -p '{"spec":{"externalTrafficPolicy":"Local"}}'
|
||
```
|
||
|
||
In `~/homelab/k8s/pihole/services.yaml` für beide LoadBalancer-Services ergänzt:
|
||
|
||
```yaml
|
||
spec:
|
||
type: LoadBalancer
|
||
externalTrafficPolicy: Local
|
||
```
|
||
|
||
**Verifikation:**
|
||
```bash
|
||
# Queries aus Unraid (192.168.11.124) testen
|
||
dig @192.168.11.181 google.com +short
|
||
# Pi-hole Query Log zeigt danach: 192.168.11.124 → google.com ✓
|
||
```
|
||
|
||
**Hinweis:** `externalTrafficPolicy: Local` bedeutet, dass Traffic nur an Nodes weitergeleitet wird auf denen der Pod läuft. Ist der Pod auf einem anderen Node, gibt es keinen Fallback — dies ist bei Pi-hole gewünscht (kein NAT, echte IPs).
|
||
|
||
### Omada DNS-Proxy Konfiguration
|
||
|
||
- DNS-Proxy in Omada leitet Anfragen weiter an `192.168.11.181` (Pi-hole)
|
||
- Clients erhalten die Router-IP als DNS → alle Queries gehen über den Proxy
|
||
- Pi-hole sieht die Router-IP als Client (nicht einzelne Geräte) — **akzeptabler Kompromiss**
|
||
- Secondary DNS (8.8.8.8) wurde entfernt damit Pi-hole Blocking nicht umgangen wird
|
||
|
||
### Finaler Status
|
||
|
||
| Komponente | Status |
|
||
|---|---|
|
||
| Pi-hole DNS `192.168.11.181:53` | ✓ Erreichbar |
|
||
| Web-UI `https://pihole.192.168.11.180.nip.io/admin` | ✓ Erreichbar (HTTPS, self-signed) |
|
||
| Blocking aktiv | ✓ |
|
||
| Echte Client-IPs sichtbar | ✓ (nach externalTrafficPolicy: Local) |
|
||
| Queries heute | ~40.000 |
|