Idee: VPN #7

New issue

Closed

opened 2026-10-20 23:34:18 +02:00 by vincent · 1 comment

vincent commented

2026-10-20 23:34:18 +02:00

Owner

WireGuard-kompatibles VPN für HAPNET OS, Installation mit pkg install wireguard.

Ziel

HAPNET erreicht den eigenen Server (und das spätere Intranet) über einen verschlüsselten Tunnel. Brückenprotokoll, pkg, update, Wiki und Bugreports laufen durch den Tunnel.

Ansatz

WireGuard braucht Noise (Variante IK) mit Curve25519, ChaCha20-Poly1305 und BLAKE2s über UDP und einen IP-Stack im Tunnel. Der Pico hat keinen eigenen.
Deshalb läuft WireGuard auf dem ESP32 (ESP-IDF-Komponente esp_wireguard, baut auf lwIP auf), als C-Modul in einer eigenen MicroPython-Firmware für das ESP32. Der Pico merkt davon nichts.
Leistung: einige Mbit/s auf dem ESP32, die UART zum Pico schafft etwa 90 KB/s. Das reicht für Terminal, Wiki und Updates.
Verworfen: WireGuard auf dem Pico selbst (bräuchte lwIP in der Firmware, PPP/SLIP zum ESP32 und Kryptografie in C).

Pico-Seite

Befehle etwa wg up, wg down, wg status; Konfiguration (Schlüssel, Gegenstelle, erlaubte IPs) in /etc.
Schlüssel liegen auf dem ESP32. Später Flash-Verschlüsselung (ESP32) oder OTP-Speicher (RP2350) prüfen.

Gemeinsame Grundlage (gilt auch für das andere Issue)

Das ESP32 wird ein Erweiterungsmodul, das seine Updates und Erweiterungen über den Pico bekommt:

Drei Ebenen: ESP32-Basisfirmware (MicroPython + eingebaute C-Module: lwIP-WireGuard, Krypto wie Monocypher, wolfSSH) · ESP32-Pakete (.py/.mpy) · Pico-Pakete (Befehle, Oberfläche).
Eine Basisfirmware mit allen C-Bausteinen statt Varianten pro Funktion; Pakete aktivieren nur Python-Teile und Konfiguration.
Paketkopf mit Abhängigkeit, z. B. requires esp32-fw >= 1.2 feature wg. Das ESP32 meldet beim Handshake Version und Fähigkeiten (hapnet-esp32 fw 1.2 features wg,ssh); pkg bietet bei Bedarf zuerst das Firmware-Update an.
Firmware-Update, Normalfall: Der Pico gibt Version und SHA-256 vor, das ESP32 lädt das Image selbst vom HAPNET-Server in den freien App-Bereich (esp32.Partition, OTA-Variante von MicroPython) und bestätigt sich erst nach erfolgreichem Handshake (mark_app_valid_cancel_rollback), sonst automatischer Rückfall.
Rettung: Der Pico flasht das ESP32 über dessen ROM-Bootloader (SLIP-Protokoll von esptool, Vorlage esp-serial-flasher). Dafür zwei Leitungen vom Pico auf EN und IO0 im Hardware-Entwurf vorsehen.
Sicherheit: Images auf dem Server mit Ed25519 signieren und vor dem Flashen prüfen; optional Secure Boot v2 (ESP32 ab Chip-Revision 3). Keine eigene Kryptografie schreiben, nur geprüfte Bibliotheken.
Flash: Zwei App-Bereiche mit MicroPython + WireGuard + wolfSSH sind mit 4 MB knapp, 8 MB ist sicher.
Der Server baut die ESP32-Firmware aus Git-Tags (z. B. esp32-v1.3), wie heute das System.

WireGuard-kompatibles VPN für HAPNET OS, Installation mit `pkg install wireguard`. ## Ziel HAPNET erreicht den eigenen Server (und das spätere Intranet) über einen verschlüsselten Tunnel. Brückenprotokoll, `pkg`, `update`, Wiki und Bugreports laufen durch den Tunnel. ## Ansatz - WireGuard braucht Noise (Variante IK) mit Curve25519, ChaCha20-Poly1305 und BLAKE2s über UDP **und einen IP-Stack im Tunnel**. Der Pico hat keinen eigenen. - Deshalb läuft WireGuard **auf dem ESP32** (ESP-IDF-Komponente `esp_wireguard`, baut auf lwIP auf), als C-Modul in einer eigenen MicroPython-Firmware für das ESP32. Der Pico merkt davon nichts. - Leistung: einige Mbit/s auf dem ESP32, die UART zum Pico schafft etwa 90 KB/s. Das reicht für Terminal, Wiki und Updates. - Verworfen: WireGuard auf dem Pico selbst (bräuchte lwIP in der Firmware, PPP/SLIP zum ESP32 und Kryptografie in C). ## Pico-Seite - Befehle etwa `wg up`, `wg down`, `wg status`; Konfiguration (Schlüssel, Gegenstelle, erlaubte IPs) in `/etc`. - Schlüssel liegen auf dem ESP32. Später Flash-Verschlüsselung (ESP32) oder OTP-Speicher (RP2350) prüfen. ## Gemeinsame Grundlage (gilt auch für das andere Issue) Das ESP32 wird ein Erweiterungsmodul, das seine Updates und Erweiterungen über den Pico bekommt: - **Drei Ebenen:** ESP32-Basisfirmware (MicroPython + eingebaute C-Module: lwIP-WireGuard, Krypto wie Monocypher, wolfSSH) · ESP32-Pakete (`.py`/`.mpy`) · Pico-Pakete (Befehle, Oberfläche). - **Eine** Basisfirmware mit allen C-Bausteinen statt Varianten pro Funktion; Pakete aktivieren nur Python-Teile und Konfiguration. - **Paketkopf** mit Abhängigkeit, z. B. `requires esp32-fw >= 1.2 feature wg`. Das ESP32 meldet beim Handshake Version und Fähigkeiten (`hapnet-esp32 fw 1.2 features wg,ssh`); `pkg` bietet bei Bedarf zuerst das Firmware-Update an. - **Firmware-Update, Normalfall:** Der Pico gibt Version und SHA-256 vor, das ESP32 lädt das Image selbst vom HAPNET-Server in den freien App-Bereich (`esp32.Partition`, OTA-Variante von MicroPython) und bestätigt sich erst nach erfolgreichem Handshake (`mark_app_valid_cancel_rollback`), sonst automatischer Rückfall. - **Rettung:** Der Pico flasht das ESP32 über dessen ROM-Bootloader (SLIP-Protokoll von esptool, Vorlage `esp-serial-flasher`). Dafür **zwei Leitungen vom Pico auf `EN` und `IO0`** im Hardware-Entwurf vorsehen. - **Sicherheit:** Images auf dem Server mit Ed25519 signieren und vor dem Flashen prüfen; optional Secure Boot v2 (ESP32 ab Chip-Revision 3). Keine eigene Kryptografie schreiben, nur geprüfte Bibliotheken. - **Flash:** Zwei App-Bereiche mit MicroPython + WireGuard + wolfSSH sind mit 4 MB knapp, 8 MB ist sicher. - Der Server baut die ESP32-Firmware aus Git-Tags (z. B. `esp32-v1.3`), wie heute das System.