54ef4fd4e3
Mango-DNAT fuer TCP/UDP 53 angewandt (fw4 check sauber, Backup auf dem Router). Von aussen aus fremdem Praefix geprueft: SOA und NS ueber UDP und TCP beantwortet, Wildcard aufgeloest, Rekursion REFUSED, AXFR REFUSED, Web und SSH nach dem Reload unveraendert. Delegation bleibt bei Cloudflare, der Kandidat ist also erreichbar, ohne dass die Domain von ihm abhaengt. Probe A des Intent-Schritts 6 gelaufen und bestanden. Echter Neustart (boot_id gewechselt), SSH nach 25 s zurueck, booted == current auf Generation 242 -- BIND hat seinen ersten Bootvorgang ueberlebt. Der Zustandsdiff hat genau zwei Abweichungen. Die Hauptvermutung traf nicht zu: resolv.conf zeigt auch nach dem Boot auf Mango, useLocalResolver = mkForce false haelt auch beim Neuaufbau durch resolvconf. ACME-Zustand hat den Neustart ueberlebt. Echter Fund ist die zweite Abweichung: pinix ist aus dem Tailnet gefallen, weil Headscale auf blunix nur per IPv4 erreichbar ist und pinix keine IPv4-Default-Route hat. NAT64 wuerde den Fall abdecken -- DNS64 liefert 64:ff9b::1758:2189 -- aber Tailscale loest selbst auf und waehlt die IPv4-Adresse direkt. Folgen: das Tailnet ist kein Rueckweg zu pinix, und tailscaled-autoconnect haelt beim Boot 90 s multi-user.target auf. Der saubere Fix ist eine oeffentliche IPv6 fuer blunix, keine Sonderbehandlung in Tailscale. Probe B (Reconnect) steht aus; ein Praefixwechsel braucht eine Handlung am Nokia. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Aw4viUJyXGP8ANocHiF15q
214 lines
9.8 KiB
Markdown
214 lines
9.8 KiB
Markdown
# Reboot- und Reconnect-Probe fuer pinix (Intent Schritt 6)
|
|
|
|
Vorbereitet und Probe A gelaufen am 12.09.2026. **Probe A (Reboot) ist
|
|
bestanden** -- Ergebnis unten. **Probe B (Reconnect) steht aus** und
|
|
braucht eine Handlung am Nokia. Aufbau und Abnahmekriterien stehen hier,
|
|
damit eine Wiederholung ohne Improvisation laeuft.
|
|
|
|
## Warum das der eigentliche Torwaechter ist
|
|
|
|
Der [Intent](intent/pinix-ipv6-traefik-webserver.md) nennt Schritt 6 als
|
|
letzten offenen Punkt, und die
|
|
[Traefik-Uebergabe](session-2026-09-12-pinix-traefik.md) begruendet, warum
|
|
selbst gehosteter DNS bis dahin zurueckgestellt bleibt: ein autoritativer
|
|
Nameserver braucht einen zuverlaessig erreichbaren Host, und genau diese
|
|
Eigenschaft ist fuer pinix nicht nachgewiesen. Die Fehlerfolgen sind
|
|
asymmetrisch -- HTTP-01 kaputt kostet ein Zertifikat, autoritativer DNS
|
|
kaputt kostet die Aufloesung von `0ff.space` samt Mail, XMPP-Foederation
|
|
und ActivityPub. Deshalb vor jeder Delegation diese Probe.
|
|
|
|
## Was konkret noch nie getestet wurde
|
|
|
|
`/run/booted-system` zeigt auf Generation 240
|
|
(`s6fdkprawpswx27pdap5qbwqw146fkcx`), `/run/current-system` auf 242
|
|
(`2fwsvih9vkwlc7whq41dhd2lbz394gmj`). Beide BIND-Generationen (241, 242)
|
|
sind ausschliesslich per `switch` aktiviert worden. **BIND hat also noch
|
|
keinen Bootvorgang erlebt.**
|
|
|
|
Die Hauptvermutung, die die Probe pruefen soll, ist der Resolver.
|
|
`hosts/pinix/localServices/bind.nix` setzt
|
|
`networking.resolvconf.useLocalResolver = lib.mkForce false`, weil das
|
|
BIND-Modul sonst localhost als Resolver eintraegt. Beim laufenden `switch`
|
|
war `/etc/resolv.conf` schon korrekt und blieb es. Beim **Boot** wird
|
|
resolvconf neu erzeugt. Gewinnt dort der localhost-Eintrag, hat pinix
|
|
keinen funktionierenden Resolver mehr: BIND ist autoritativ und rekursiert
|
|
nicht, der Uplink ist IPv6-only ueber Mangos DNS64. Folge waeren
|
|
stillschweigend kaputtes ACME, kaputte Updates und ein fehlschlagender
|
|
`mango-dns`-Timer -- bei laufendem, scheinbar gesundem System.
|
|
|
|
Der Diff dieser Session beruehrt weder Bootloader noch Kernel, initrd
|
|
oder Dateisysteme, sondern nur Dienste und zwei Firewall-Ports. Ein
|
|
"bootet nicht" ist damit unwahrscheinlich; erwartbar sind Dienst- und
|
|
Netzwerkfehler nach dem Boot.
|
|
|
|
## Rueckweg, vor dem Start bekannt
|
|
|
|
Nach Prioritaet:
|
|
|
|
1. **LAN-Zugang von tnix.** `ssh drone@192.168.8.244` bzw. die ULA
|
|
`fdee:3c40:44f0:0:dea6:32ff:fe48:c6c8`. Dieser Weg haengt **nicht** am
|
|
Mobilfunk-Uplink, nicht am Nokia und nicht an Tailscale -- Ethernet ins
|
|
Mango-LAN genuegt. Er muss vor dem Start gesteckt und geprueft sein.
|
|
Damit ist ein Rueckbau auf Generation 240 moeglich:
|
|
|
|
```bash
|
|
sudo /nix/var/nix/profiles/system-240-link/bin/switch-to-configuration switch
|
|
```
|
|
|
|
2. **pinix bootet, Netz kaputt.** Dann bleibt nur Konsole am Geraet
|
|
(HDMI und Tastatur) oder der SD-Karten-Weg.
|
|
|
|
3. **pinix bootet nicht.** SD-Karte in eine andere Maschine und in
|
|
`/boot/extlinux/extlinux.conf` die erste Zeile von
|
|
`DEFAULT nixos-default` auf `DEFAULT nixos-240-default` aendern. Die
|
|
Generationen 233 bis 242 liegen dort als `LABEL` vor. Eine Auswahl
|
|
**beim Boot** gibt es headless nicht -- U-Boot/extlinux nimmt ohne
|
|
Konsole den Default. Das ist der Grund, warum Schritt 1 vorher stehen
|
|
und funktionieren muss.
|
|
|
|
Mango-Firewall-Backups liegen auf dem Router unter
|
|
`/root/ipv6-*-firewall-backup.*/firewall` bzw.
|
|
`/root/pinix-dns-firewall-backup.*/firewall`. Beim Zuruecklegen keine
|
|
spaeteren Firewall-Aenderungen ueberschreiben.
|
|
|
|
## Ablauf
|
|
|
|
Zwei **getrennte** Proben, damit ein Fehlschlag zuordenbar bleibt.
|
|
Reboot zuerst, weil er lokal vollstaendig reparierbar ist.
|
|
|
|
```bash
|
|
# 0. Rueckweg sichern: Ethernet steckt, LAN-Zugang beweisen
|
|
ssh -o HostKeyAlias=pinix drone@192.168.8.244 'echo LAN ok'
|
|
|
|
# 1. Ausgangszustand
|
|
./scripts/pinix-reachability-probe.sh vorher > /tmp/probe-vorher.txt
|
|
|
|
# 2a. Probe A -- Reboot von pinix
|
|
ssh -o HostKeyAlias=pinix drone@192.168.8.244 'sudo reboot'
|
|
# ... warten, bis SSH wieder antwortet
|
|
./scripts/pinix-reachability-probe.sh nachher-reboot > /tmp/probe-reboot.txt
|
|
diff -u /tmp/probe-vorher.txt /tmp/probe-reboot.txt
|
|
|
|
# 2b. Probe B -- Nokia-Reconnect (Praefixwechsel), separat
|
|
# Nokia neu verbinden, dann mindestens 60 s fuer den mango-dns-Timer
|
|
./scripts/pinix-reachability-probe.sh nachher-reconnect > /tmp/probe-reconnect.txt
|
|
diff -u /tmp/probe-vorher.txt /tmp/probe-reconnect.txt
|
|
```
|
|
|
|
`scripts/pinix-reachability-probe.sh` ist rein lesend, hat pro Schritt ein
|
|
Timeout und laeuft absichtlich ohne `set -e` durch -- ein Fehlschlag ist
|
|
das Messergebnis. Die externen Tests gehen zwingend ueber `--interface
|
|
wlan0`, weil tnix gleichzeitig im Mango-LAN haengt und die DNAT-Regeln
|
|
`reflection=0` tragen; ein Test ohne Interface-Bindung nimmt den LAN-Weg
|
|
und meldet einen Fehlschlag, der keiner ist.
|
|
|
|
## Abnahmekriterien
|
|
|
|
| Pruefung | Erwartung |
|
|
|---|---|
|
|
| `booted` vs `current` | **identisch**, beide Generation 242 |
|
|
| `is-system-running` | `running` bzw. `degraded` nur wegen `tailscaled-autoconnect` (siehe unten); kein anderer Fehler |
|
|
| `/etc/resolv.conf` | Mango (`192.168.8.1`), **nicht** `127.0.0.1` |
|
|
| stabile SLAAC-ULA | `…:dea6:32ff:fe48:c6c8` vorhanden |
|
|
| IPv6-Default-Route | per `proto ra` auf `end0` vorhanden |
|
|
| `bind` / `traefik` | active, BIND liefert SOA ueber `::1` |
|
|
| Mango-Weiterleitungen | `pinix_web_*`, `pinix_ssh` weiter `DNAT` |
|
|
| extern | `https=200`, `http=301`, `ssh2222=offen` |
|
|
| Cloudflare-AAAA | stimmt mit der tatsaechlichen Adresse ueberein |
|
|
|
|
## Was im Diff legitim abweicht
|
|
|
|
Nicht jede Abweichung ist ein Fehler:
|
|
|
|
- Zeitstempel in der Kopfzeile.
|
|
- Die Quelladresse von tnix' `wlan0` (Privacy Extensions).
|
|
- Bei Probe B die oeffentliche Mango-Adresse -- **aber** dann muss der
|
|
Cloudflare-AAAA innerhalb einer Timer-Periode nachziehen. Tut er das
|
|
nicht, hat `mango-dns` sein Ziel verfehlt und der Punkt ist ein Fehler.
|
|
- `pinix_dns=FEHLT`, solange `scripts/configure-mango-dns.sh` nicht
|
|
gelaufen ist, und entsprechend der DNS-Timeout im externen Test. Seit
|
|
dem 12.09.2026 ist die Regel gesetzt, das sollte also nicht mehr
|
|
auftreten.
|
|
- `degraded` mit fehlgeschlagenem `tailscaled-autoconnect.service`: ein
|
|
bestehender, von BIND unabhaengiger Fehler, unten erklaert. Erst wenn
|
|
eine *andere* Unit auftaucht, ist es ein Befund.
|
|
|
|
## Bekannter Nebenbefund
|
|
|
|
Die Probe liest auch Aussteller und Restlaufzeit des Zertifikats. Aktuell
|
|
`issuer=CN=YR1`, `notAfter=Dec 11 12:20:18 2026 GMT` -- das ist die aus
|
|
der Traefik-Uebergabe bekannte Kette ueber `ISRG Root YR`, die auf
|
|
Clients mit aelterem CA-Bundle scheitert. Die Entscheidung ueber
|
|
`preferredChain` steht weiterhin aus und ist **nicht** Teil dieser Probe.
|
|
|
|
## Ergebnis Probe A (Reboot), 12.09.2026
|
|
|
|
**Bestanden.** `systemctl reboot` um 17:50:09, SSH nach etwa 25 s wieder
|
|
da, neue `boot_id` (`97119559…` -> `13253402…`), also ein echter
|
|
Neustart. Der Diff der beiden Aufnahmen enthaelt genau zwei
|
|
Abweichungen.
|
|
|
|
Die erwuenschte: `booted` entspricht jetzt `current`, beide Generation
|
|
242 (`2fwsvih9…`). **BIND hat damit seinen ersten Bootvorgang
|
|
ueberlebt.**
|
|
|
|
Unveraendert und damit bestanden: `bind`, `traefik`, `mango-dns.timer`
|
|
und `tailscaled` aktiv, stabile SLAAC-ULA vorhanden, RA-Default-Route
|
|
auf `end0` vorhanden, BIND antwortet autoritativ, alle Mango-Regeln
|
|
inklusive `pinix_dns` und `dport 53` persistent, Cloudflare-AAAA deckt
|
|
sich mit der tatsaechlichen Adresse, extern `https=200`, `http=301`,
|
|
Port 2222 offen, DNS-SOA von aussen beantwortet, Zertifikat unveraendert
|
|
(`notAfter=Dec 11`) -- der ACME-Zustand in `/var/lib/traefik` hat den
|
|
Neustart also ueberlebt.
|
|
|
|
**Die Hauptvermutung hat sich nicht bestaetigt, und das ist die gute
|
|
Nachricht:** `/etc/resolv.conf` zeigt auch nach dem Boot auf Mango und
|
|
nicht auf localhost. `networking.resolvconf.useLocalResolver =
|
|
lib.mkForce false` haelt also nicht nur beim `switch`, sondern auch beim
|
|
Neuaufbau durch resolvconf im Boot.
|
|
|
|
### Der eine echte Fund: pinix ist aus dem Tailnet gefallen
|
|
|
|
Die zweite Abweichung ist `running` -> `degraded` mit fehlgeschlagenem
|
|
`tailscaled-autoconnect.service`. Das ist **nicht** von BIND verursacht
|
|
-- die Unit war bereits am Anfang dieser Sitzung auf der Generation vor
|
|
BIND fehlgeschlagen. Der Boot hat den Fehler nur wieder sichtbar
|
|
gemacht, inklusive 90 s Timeout, die `multi-user.target` aufhalten.
|
|
|
|
Die Ursache ist strukturell und hat mit Tailscale selbst wenig zu tun:
|
|
|
|
```
|
|
You are logged out. The last login error was: fetch control key:
|
|
Get "https://head.0ff.space/key?v=142": dial tcp 23.88.33.137:443:
|
|
connect: network is unreachable
|
|
```
|
|
|
|
pinix hat **keine IPv4-Default-Route** und erreicht `23.88.33.137`
|
|
(blunix, der Headscale-Host) nicht. Dass blunix ausschliesslich per IPv4
|
|
erreichbar ist, ist am selben Tag unabhaengig aufgefallen: der Host hat
|
|
ueberhaupt keine oeffentliche IPv6, nur die Tailnet-ULA.
|
|
|
|
Bemerkenswert ist, dass NAT64 den Fall eigentlich abdeckt --
|
|
`getent hosts head.0ff.space` liefert `64:ff9b::1758:2189`. Tailscale
|
|
loest aber selbst auf, nimmt den A-Eintrag und waehlt die
|
|
IPv4-Adresse direkt, womit es an DNS64 vorbeilaeuft.
|
|
|
|
Zwei Folgerungen:
|
|
|
|
1. **Das Tailnet ist kein Rueckweg zu pinix.** Der Abschnitt oben nennt
|
|
den LAN-Zugang als Weg 1 -- das war richtig, aber aus einem
|
|
schwaecheren Grund als dem tatsaechlichen. Es bleiben LAN und die
|
|
oeffentliche DNAT-Weiterleitung.
|
|
2. **blunix eine oeffentliche IPv6 geben** ist der saubere Fix, nicht
|
|
eine Sonderbehandlung in Tailscale: dann bekommt `head.0ff.space`
|
|
einen echten AAAA, pinix verbindet sich native, die Unit hoert auf zu
|
|
scheitern und der Boot verliert 90 s Verzoegerung. Das haengt mit der
|
|
Frage nach einem Sekundaeren fuer die Zone zusammen -- siehe
|
|
[pinix-bind.md](pinix-bind.md).
|
|
|
|
### Noch offen: Probe B (Reconnect)
|
|
|
|
Nicht gelaufen. Ein Praefixwechsel setzt voraus, dass sich das Nokia neu
|
|
am Mobilfunknetz anmeldet; das Bouncen des Mango-Uplinks erzwingt kein
|
|
neues Praefix und pruefte daher die eigentliche Frage nicht. Diese Probe
|
|
braucht also eine Handlung am Nokia.
|