d7698b26e7
Korrektur zu 7f54fb4. Ursache war nicht das Schluesselformat, sondern
zwei gleichzeitig auf wlan0 laufende wpa_supplicant-Instanzen: die
manuelle aus /tmp/iphone.conf und die per switch gestartete Unit. Das
Journal zeigt "SME: Trying to authenticate" gefolgt von "Authentication
request to the driver failed" und reason=CONN_FAILED -- der Treiber
lehnt ab, weil die Schnittstelle belegt ist. Ein falscher PSK ergaebe
WRONG_KEY, und ext_password_backend akzeptiert auch eine Passphrase von
8 bis 63 Zeichen, also greift der Verdacht auf pskRaw nicht.
Ob die Deklaration allein verbindet, ist weiter offen: nach dem Beenden
der Handinstanz blieb wlan0 DOWN, die neu gestartete Unit kam nicht mehr
ueber die Initialisierung hinaus. Vorgehen fuer den naechsten Versuch
steht jetzt als Reihenfolge im Dokument.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Aw4viUJyXGP8ANocHiF15q
93 lines
4.1 KiB
Markdown
93 lines
4.1 KiB
Markdown
# tnix SSH ueber Mango
|
|
|
|
Stand: 12.09.2026. Vom iPhone erfolgreich bestaetigt.
|
|
|
|
```sh
|
|
ssh -p 2223 builder@ipv6-test.0ff.space
|
|
```
|
|
|
|
Mango leitet TCP 2223 auf tnix' Ethernet-SLAAC-Adresse
|
|
`fdee:3c40:44f0:0:ca5b:76ff:fe96:e24`, Port 22, weiter. Vorher zeigte
|
|
die Regel auf die nicht mehr vorhandene Mango-WLAN-Adresse von tnix.
|
|
|
|
Die gezielte SNAT-Regel `tnix_ssh_return` ersetzt globale IPv6-Quelladressen
|
|
bei TCP 22 zu diesem Ziel durch Mangos LAN-Adresse `fdee:3c40:44f0::1`.
|
|
Damit gehen SSH-Antworten ueber Ethernet zurueck, waehrend tnix den
|
|
iPhone-Hotspot als Internetzugang behaelt. Im SSH-Log erscheint fuer diese
|
|
Verbindungen Mango als Client.
|
|
|
|
Umsetzung: `scripts/configure-mango-ipv6-ssh.sh` mit `HOSTS=tnix`.
|
|
Nur Firewall-Reload, kein Router-Reboot, kein Netzwerk-Neustart und kein
|
|
NixOS-Rebuild. Pinix-Regeln unveraendert.
|
|
|
|
Validierung: `fw4 check` erfolgreich; Mango erreicht das Internet;
|
|
oeffentlicher SSH-Login auf Port 2223 liefert `tnix`, Host-Key gegen den
|
|
lokalen ED25519-Key geprueft; Nutzer bestaetigt Login vom iPhone.
|
|
|
|
Backup auf Mango: `/root/ipv6-ssh-firewall-backup.CKoKpD/firewall`.
|
|
Fuer einen unmittelbaren Rueckbau diese Datei nach `/etc/config/firewall`
|
|
kopieren und die Firewall neu laden. Spaetere Firewall-Aenderungen dabei
|
|
nicht ueberschreiben.
|
|
|
|
## WLAN deklarativ: gescheiterter Versuch am 12.09.2026
|
|
|
|
Der Versuch, tnix' Hotspot-Verbindung deklarativ zu machen, ist
|
|
fehlgeschlagen und hat tnix vom Netz genommen:
|
|
|
|
```nix
|
|
wireless.networks.iPhone.pskRaw = "ext:psk_iphone";
|
|
```
|
|
|
|
Die Aenderung ist zurueckgenommen. Der Grund ist aber **nicht** die
|
|
Konfiguration, sondern der Ablauf beim Umstellen -- das ist der
|
|
eigentliche Merkposten.
|
|
|
|
### Ursache: zwei wpa_supplicant-Instanzen auf `wlan0`
|
|
|
|
Die Verbindung lief zu diesem Zeitpunkt ueber eine **von Hand**
|
|
gestartete Instanz (`wpa_supplicant -B -i wlan0 -c /tmp/iphone.conf`),
|
|
weil `wpa_supplicant.service` gar nicht lief. Der `switch` startete die
|
|
Unit zusaetzlich, und beide Instanzen hielten `wlan0` gleichzeitig:
|
|
|
|
```
|
|
wlan0: SME: Trying to authenticate with ea:3b:f5:d2:bc:67 (SSID='iPhone' freq=5220 MHz)
|
|
wlan0: SME: Authentication request to the driver failed
|
|
wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=1 ssid="iPhone" auth_failures=1 duration=10 reason=CONN_FAILED
|
|
```
|
|
|
|
Die deklarative Instanz hat den AP also gefunden und die
|
|
Authentifizierung angefordert; **der Treiber** hat sie abgelehnt, weil
|
|
die Schnittstelle bereits belegt war. Das wiederholte sich dreimal mit
|
|
steigendem Backoff, danach war das Netz temporaer deaktiviert.
|
|
|
|
Wichtig zur Abgrenzung: das ist **kein** Schluesselproblem. Ein falscher
|
|
PSK ergibt `WRONG_KEY` bzw. einen gescheiterten 4-Way-Handshake, nicht
|
|
`Authentication request to the driver failed`. Der zuerst naheliegende
|
|
Verdacht -- `pskRaw` verlange den rohen 32-Byte-PSK, im Secrets-File
|
|
liege aber eine Klartext-Passphrase (`psk_iphone` 9 Zeichen) -- trifft
|
|
nicht zu: wpa_supplicant akzeptiert ueber den `ext_password_backend`
|
|
auch eine Passphrase von 8 bis 63 Zeichen, und die Logzeilen belegen,
|
|
dass es bis zur Authentifizierungsanfrage gekommen ist.
|
|
|
|
### Was offen bleibt
|
|
|
|
Ob die Deklaration allein auf der Schnittstelle sauber verbindet, ist
|
|
**nicht erwiesen**. Nach dem Abschiessen der manuellen Instanz blieb
|
|
`wlan0` DOWN, und die daraufhin neu gestartete Unit kam ueber
|
|
Initialisierung und Regulatory-Domain nicht hinaus -- ohne einen
|
|
einzigen weiteren Authentifizierungsversuch. Der Zustand war zu kaputt,
|
|
um daraus etwas zu schliessen.
|
|
|
|
### Vorgehen fuer den naechsten Versuch
|
|
|
|
1. **Ethernet zum Mango stecken.** Schlaegt das WLAN fehl, ist der
|
|
Hotspot sonst die einzige Uplink-Quelle und die Maschine isoliert.
|
|
2. **Erst die manuelle Instanz beenden, dann die Unit starten** -- nicht
|
|
beide gleichzeitig laufen lassen. `pgrep -a wpa_supplicant` vorher
|
|
und nachher pruefen; es darf genau eine Instanz uebrig bleiben.
|
|
3. Nach dem Beenden der Handinstanz `wlan0` explizit hochholen
|
|
(`ip link set wlan0 up`), bevor Schluesse aus einem DOWN-Interface
|
|
gezogen werden.
|
|
4. Erst wenn es dann noch scheitert, das Schluesselformat verdaechtigen
|
|
und `wpa_passphrase iPhone '<passphrase>'` in
|
|
`secrets/wirelessSecretsFile.age` hinterlegen.
|