125 lines
6.2 KiB
Markdown
125 lines
6.2 KiB
Markdown
# tnix am Mango-Uplink: IPv6-only mit NAT64
|
||
|
||
Stand: 12.09.2026. Ersetzt den iPhone-Hotspot als Internetzugang für tnix.
|
||
|
||
Der Hotspot war nur Gerüst für die Einwärts-Erreichbarkeitstests
|
||
([IPv6-Webtest auf tnix](ipv6-test-tnix.md)) und ist jetzt aus dem Pfad.
|
||
tnix kann das Mango-WLAN `idea` oder das Ethernet-Kabel als Uplink nutzen.
|
||
|
||
## Aufbau
|
||
|
||
```
|
||
tnix (wlan0/idea oder enp0s31f6) → Mango → Nokia 6300 4G → Telekom festip.telekom → Internet
|
||
```
|
||
|
||
Der Mango-Uplink ist **IPv6-only**. Ausgehend ins IPv4-Internet gibt es
|
||
ausschließlich Telekoms NAT64 über `64:ff9b::/96`, angesteuert durch die
|
||
DNS64-Antworten des Mango-Resolvers.
|
||
|
||
## Gemessener Istzustand
|
||
|
||
Alles am 12.09.2026 auf tnix bzw. dem Mango nachgemessen:
|
||
|
||
- Mango-WAN (`usb0`): IPv6 funktioniert (`ping6` zu Cloudflare 3/3).
|
||
IPv4 endet tot — das Nokia vergibt zwar ein LAN `192.168.0.0/24` und
|
||
antwortet auf `192.168.0.1`, aber `ping -4 1.1.1.1` bleibt bei 100 %
|
||
Verlust. Es gibt hinter dem Nokia keine IPv4-Route ins Internet.
|
||
- Mango-LAN verteilt per RA SLAAC aus dem ULA-Präfix
|
||
`fdee:3c40:44f0::/64`, Default-Route und sich selbst als DNS
|
||
(`dhcp.lan.ra='server'`, `ra_slaac='1'`, `ra_default='1'`).
|
||
NAT66 (`firewall.wan6.masq_src`) übersetzt das ULA auf die öffentliche
|
||
Telekom-Adresse. WLAN `idea` (`ra0`) liegt in derselben `br-lan`-Bridge
|
||
wie das Ethernet, Clients beider Wege sind also gleichgestellt.
|
||
- DNS64 ist nachgewiesen: `ipv4only.arpa` und `github.com` liefern über
|
||
`192.168.8.1` bzw. `fdee:3c40:44f0::1` Adressen aus `64:ff9b::/96`,
|
||
echte Dual-Stack-Namen dagegen ihre normalen AAAA.
|
||
- Der komplette Weg funktioniert von einem LAN-Client aus: `github.com`
|
||
(IPv4-only) antwortet mit HTTP 200 über `64:ff9b::8c52:7904`,
|
||
`api.anthropic.com` und Wikipedia nativ über IPv6.
|
||
- Gegenprobe auf dem iPad im WLAN `idea`: YouTube lädt. Apple-Geräte
|
||
kommen mit NAT64/DNS64 out of the box zurecht.
|
||
|
||
## Konfiguration auf tnix
|
||
|
||
In `hosts/tnix/configuration.nix`:
|
||
|
||
- `wireless.networks.idea` aktiv, `iPhone` auskommentiert.
|
||
- **Keine IPv4-Default-Route.** Der Mango bietet per DHCPv4
|
||
`192.168.8.1` als Gateway an, das ist hinter dem Nokia ein schwarzes
|
||
Loch: Pakete verschwinden still, Anwendungen laufen in Timeouts statt
|
||
sauber auf IPv6 zurückzufallen. `nooption routers` für `wlan0` wirft
|
||
diese Route weg; die IPv6-Default-Route kommt weiterhin regulär per
|
||
Router Advertisement.
|
||
- `enp0s31f6` verwendet ebenfalls `nooption routers`: IPv4-Default-Route
|
||
verwerfen, IPv6-Default-Route per RA übernehmen. Das frühere `nogateway`
|
||
unterdrückte auch die IPv6-Default-Route und verhinderte Internet über
|
||
das Kabel. Die ULA-Adressen bleiben davon unberührt.
|
||
|
||
### Fehlerdiagnose am 12.09.2026 (abends)
|
||
|
||
Mit Mango am Ethernet und iPhone-Hotspot am WLAN hatte tnix ausschließlich
|
||
eine IPv6-Default-Route über das iPhone. Der Mango selbst erreichte das
|
||
IPv6-Internet und lieferte DNS64-Antworten. Zwei temporäre Zielrouten über
|
||
`enp0s31f6` und Mangos Link-Local-Gateway belegten den funktionierenden
|
||
Kabel-Uplink: HTTPS zu Cloudflare (natives IPv6) und GitHub (NAT64) jeweils
|
||
HTTP 200. Die Testrouten wurden anschließend entfernt. Deshalb ersetzt
|
||
`nooption routers` das bisherige `nogateway` für Ethernet.
|
||
|
||
Validierung: `nix flake check --no-build` und tnix-Systembuild erfolgreich;
|
||
`dry-activate` kündigte ausschließlich den Neustart von `dhcpcd.service`
|
||
an. Anschließend erfolgreich aktiviert mit `nixos-rebuild switch
|
||
--no-reexec --store-path <gebauter Systempfad>`. Danach erschien die
|
||
Ethernet-Default-Route automatisch als `proto ra`; HTTPS zu GitHub über
|
||
`curl --interface enp0s31f6 -6` lieferte erneut HTTP 200. ChatGPT war beim
|
||
vorherigen Kabeltest per HTTPS erreichbar (HTTP 403 auf den anonymen
|
||
curl-Aufruf); ein authentifizierter Codex-Aufruf wurde nicht getestet.
|
||
|
||
Ein erster Versuch mit einer statisch deklarierten Default-Route
|
||
(`interfaces.wlan0.ipv6.routes`) schlug fehl: `network-addresses-wlan0`
|
||
setzt die Route, bevor der Nachbar erreichbar ist, und scheitert mit
|
||
„No route to host". Deshalb die RA-Route, nicht die statische.
|
||
|
||
## DNS und Tailscale
|
||
|
||
`services.tailscale` läuft mit `--accept-dns=false`. MagicDNS würde
|
||
AdGuard auf blunix befragen, das echte A-Records ohne DNS64-Synthese
|
||
liefert — von hier aus nicht routbar. DNS64 stattdessen global in AdGuard
|
||
zu aktivieren wäre kein Ersatz, weil Tailnet-Clients mit IPv4 dann
|
||
synthetische AAAA für nativ erreichbare Ziele bekämen.
|
||
|
||
Ersatz für die verlorenen MagicDNS-Namen ist `networking.hosts`, gespeist
|
||
aus `config.tailnetIPs` — `ssh blunix` und `ssh pinix` funktionieren
|
||
weiterhin.
|
||
|
||
Tailscale selbst bleibt verbunden, aber **nur noch über DERP-Relay**:
|
||
blunix hat keine öffentliche IPv6-Adresse und tnix kein IPv4, ein direkter
|
||
Tunnel ist damit unmöglich. Beide erreichen den DERP jeweils in ihrer
|
||
eigenen Familie. `tailscale ping blunix` antwortet über DERP(nue) in
|
||
56–75 ms. Randnotiz: `derp4.tailscale.com` (Frankfurt) ist über IPv6
|
||
nicht erreichbar — auch nicht über den iPhone-Uplink, also ein Problem
|
||
auf Tailscale-Seite, nicht hier.
|
||
|
||
## Grenzen
|
||
|
||
- **Keine IPv4-Literale.** Es läuft kein CLAT. Anwendungen, die Namen
|
||
auflösen, sind über DNS64 versorgt; eine fest eingetragene IPv4-Adresse
|
||
ist von tnix aus nicht erreichbar. Falls das stört, wäre `clatd` der
|
||
nächste Schritt.
|
||
- Die öffentliche Testseite ist **aus dem eigenen LAN heraus nicht**
|
||
abrufbar: Die Mango-DNAT-Regeln stehen auf `reflection=0`, Anfragen an
|
||
die öffentliche Adresse landen darum auf der Weboberfläche des Routers
|
||
(TLS-Fehler). Von außen ist sie unverändert erreichbar, nginx liefert
|
||
eine vollständige Kette (`Verify return code: 0 (ok)`).
|
||
- Wird das Ethernet gezogen, fällt `ipv6-test.0ff.space` aus — das DNAT
|
||
zeigt auf die statische Adresse von `enp0s31f6`. Der geplante Umzug des
|
||
Eingangs auf pinix
|
||
([Intent](intent/pinix-ipv6-traefik-webserver.md)) löst das auf.
|
||
- Reboot- und USB-Reconnect-Festigkeit des Gesamtaufbaus sind weiterhin
|
||
ungetestet, ebenso die Stabilität der öffentlichen Interface-ID.
|
||
|
||
## Rückweg zum Hotspot
|
||
|
||
In `hosts/tnix/configuration.nix` die Zeile `wireless.networks.iPhone`
|
||
wieder einkommentieren und `idea` auskommentieren, dann neu bauen. Für
|
||
vollen IPv4-Betrieb zusätzlich `nooption routers` entfernen und
|
||
`tailscale set --accept-dns=true` setzen.
|