iroh-forward/recherche-vpn-vs-p2p-netzwerk.md

Recherche: VPN vs. P2P-Netzwerk

---

Teil 1 – Vergleichende Übersicht

Klassifikation nach Betriebsmodell

Begriff	Bedeutung
Netzwerk-Tunnel / Daemon	Läuft als System-Dienst, erzeugt ein virtuelles Netzwerkinterface (tun/tap). Routing erfolgt OS-seitig.
Overlay-Netzwerk / Mesh	Spannt ein virtuelles Netz über bestehende Infrastruktur auf. Jeder Knoten kennt (ggf. über Koordination) alle anderen.
App-Konnektivität / P2P-SDK	Keine Netzwerkschnittstelle im OS. Konnektivität wird direkt in die Applikation eingebettet. Verbindung über kryptographische Schlüssel, nicht IPs.

---

Protokoll-Vergleich

Protokoll	OSI-Schicht	Betriebsmodell	Koordination	Verschlüsselung	Besonderheiten
IPSec	L3–L4 (Netzwerk/Transport)	Netzwerk-Tunnel / Kernel	Manuell (IKEv2/IKEv1) oder PKI	AES-GCM, ChaCha20 (via Suite B)	Standard in Enterprise-Firewalls; komplex in Konfiguration; NAT-Probleme (NAT-T nötig); zwei Modi: Transport (L4-Header bleibt) und Tunnel (ganzes IP-Paket)
OpenVPN	L4-Tunnel → präsentiert L2/L3	Netzwerk-Tunnel / Daemon	CA-basiert (TLS-Zertifikate)	TLS (OpenSSL/mbedTLS)	TUN=L3, TAP=L2; läuft über UDP oder TCP; sehr verbreitet, aber langsam (Userspace); gut durch Firewalls tunnelbar (TCP:443)
WireGuard	L3 (Netzwerk)	Overlay-Netzwerk / Kernel-Modul	Manuell (Pre-shared Keys + Public Keys)	ChaCha20-Poly1305, Curve25519	Minimaler Kernel-Code (~4000 Zeilen); kein Handshake-Overhead im Betrieb; keine eingebaute Key-Discovery; bildet Basis für Tailscale/Netbird
Yggdrasil	L3-Overlay (IPv6)	Overlay-Netzwerk / Mesh-Daemon	Selbstorganisierend (distributed routing)	X25519 + Ed25519	Adresse = Hash des Public Key; kein zentraler Koordinator; schlechte Performance bei sehr großem Mesh; experimentell
Tailscale	L3-Overlay	Overlay-Netzwerk / Managed Mesh	Zentraler Koordinations-Server (control plane)	WireGuard darunter	„Zero-config VPN"; DERP-Relay-Netz von Tailscale für NAT-Traversal; SaaS-Modell (oder Headscale self-hosted); gut für Team-Zugriff auf interne Dienste
Iroh	L4–L7 (QUIC/Application)	App-Konnektivität / P2P-SDK	Relay-Server (optional, betreibbar)	TLS 1.3 über QUIC	Kein Netzwerkinterface; Bibliothek (Rust, Python, Node.js, Swift, Kotlin); Adressierung über Public Keys; 95 % direkte Verbindungen; QUIC Multipath; kein Flottenmanagement eingebaut

---

L4 vs. L7 – was bedeutet das hier konkret?

L4 (Transport):

• IPSec Tunnel-Modus, OpenVPN, WireGuard und Tailscale operieren auf dieser Ebene oder darunter
• Das OS erhält ein virtuelles Interface (wg0, tun0) und routet IP-Traffic darüber
• Alle Anwendungen profitieren automatisch – keine Code-Änderung nötig

L7 (Applikation):

• Iroh arbeitet ausschließlich auf Applikationsebene
• Die Anwendung selbst öffnet eine Iroh-Verbindung (QUIC-Session) zu einem Remote-Node via dessen Public Key
• Kein System-Routing, kein Interface – die App muss Iroh aktiv nutzen
• Vergleichbar mit WebRTC: im Browser transparent, aber nur für eingebettete Anwendungen sinnvoll

---

Wann welches Modell?

Szenario	Empfehlung
Site-to-Site zwischen Firewalls	IPSec (native OPNsense-Support)
Remote-Access für Mitarbeiter	Tailscale oder WireGuard
Self-hosted Mesh ohne SaaS	WireGuard + Netbird/Headscale
P2P in eigener Anwendung gebaut	Iroh
Gerät soll von überall erreichbar sein, ohne feste IP	Iroh oder Tailscale
Experimentelles dezentrales Netz	Yggdrasil

---

Teil 2 – Iroh-Integration in bestehendes Setup

Ausgangslage

Internet
   │
[OPNsense] ──── Firewall / Router
   │
[Nginx] ──── Reverse Proxy (terminiert TLS, routet vhosts)
   │
[Serving Host] ──── Anwendungsserver (bisher feste IP / internes Netz)

Das Problem: Der Serving Host muss derzeit über ein geroutetes Netz (VPN oder direkt) erreichbar sein. Ziel ist es, ihn standortunabhängig zu betreiben – ohne VPN-Konfiguration auf Netzwerkebene.

---

Iroh-Konzept: Dial by Key, not by IP

Jeder Iroh-Node hat ein Ed25519-Schlüsselpaar. Der Public Key ist die Adresse. Solange ein Node seinen Relay kennt (oder direkten QUIC-Hole-Punch schafft), ist er erreichbar – unabhängig von Netzwerkposition, NAT oder dynamischer IP.

---

Verfügbare Iroh-Tools (ohne eigenen Code)

Tool	Funktion	Einsatzbarkeit
dumbpipe	Bidirektionale Byte-Pipe zwischen zwei Iroh-Nodes (wie nc über Iroh)	Ja – als TCP-Tunnel mit socat kombinierbar
sendme	Einmalige Dateiübertragung	Nein – kein dauerhafter Dienst
iroh-relay	Eigener Relay-Server (DERP-ähnlich)	Ja – für selbst-gehostetes Setup

dumbpipe ist die einzige Komponente, die einen dauerhaften Kanal aufbauen kann – aber sie überträgt einen Byte-Stream, kein TCP-Multiplexing. Für einen HTTP-Upstream im Nginx braucht man ein TCP-Forward-Setup.

---

Architektur-Optionen

Option A: dumbpipe + socat als TCP-Proxy-Kette

[Client]
   ↓ HTTPS
[Nginx] → upstream: localhost:8080
   ↓
socat LISTEN:8080 → dumbpipe connect <serving-host-key>
   ↓ [Iroh-Netz]
dumbpipe listen → socat → localhost:3000 (App)
[Serving Host]

Vorgehen:

# Serving Host
dumbpipe listen | socat - TCP:localhost:3000
# → gibt Node-Key aus, z.B. "ki2..."

# Nginx-Host
socat TCP-LISTEN:8080,fork EXEC:"dumbpipe connect ki2..."
# Nginx: proxy_pass http://127.0.0.1:8080;

Problem: dumbpipe ist eine Single-Connection-Pipe, kein TCP-Listener. Für parallele HTTP-Verbindungen müsste man pro Request eine neue Pipe öffnen oder ein Connection-Multiplexer vorschalten. Für produktiven Einsatz ungeeignet ohne eigenen Code.

---

Option B: Eigenes Iroh-TCP-Forward-Tool (empfohlen)

Ein kleines Tool in Rust oder Python (ca. 100–200 Zeilen), das:

• Serving Host: Iroh-Endpunkt öffnet, akzeptiert Verbindungen, leitet an lokalen Port weiter
• Nginx-Host: Lauscht auf lokalem TCP-Port, öffnet pro Verbindung eine neue Iroh-QUIC-Stream

Iroh unterstützt nativ multiple Streams pro Connection (QUIC), daher skaliert das ohne Tricks.

[Nginx]
  proxy_pass http://127.0.0.1:9080
       ↓
[iroh-forward-client] lauscht :9080, öffnet QUIC-Stream zu Serving Host
       ↓ QUIC / Iroh
[iroh-forward-server] auf Serving Host, leitet weiter an :3000
       ↓
[App]

Aufwand: ~1–2 Tage Entwicklung in Rust mit der iroh-Crate. Python-Bindings sind verfügbar, aber QUIC-Performance ist in Rust besser.

---

Option C: OPNsense bleibt unberührt, Iroh nur Nginx ↔ Serving Host

Dies ist das sauberste Setup: OPNsense braucht nichts von Iroh zu wissen. Der Iroh-Tunnel existiert nur auf Applikationsebene zwischen Nginx-Host und Serving Host.

Internet → OPNsense → Nginx (Port 443) → iroh-forward-client → [Iroh] → Serving Host

OPNsense sieht nur: Nginx-Host macht ausgehende QUIC-Verbindungen (UDP) zu Iroh-Relays. Kein eingehender Traffic auf dem Serving Host nötig.

---

Credential-Verteilung

Komponente	Credential	Wo gespeichert	Übergabe
Iroh Node Key (Serving Host)	Ed25519-Keypair	/etc/iroh/node.key (Serving Host)	Public Key wird einmalig aus dem Log extrahiert
Iroh Node Key (Nginx-Host)	Ed25519-Keypair	/etc/iroh/client.key (Nginx-Host)	Automatisch generiert beim ersten Start
Serving Host Public Key	Public Key (String)	Nginx-Host Config / .env	Out-of-band: z.B. über Ansible/Vault, Gitea-Secret, o.ä.
Relay-URL	URL	beide Hosts	Im iroh-config oder Env-Variable
App-Credentials	DB-Passwörter etc.	Serving Host lokal	Unverändert – Iroh ändert nichts daran

Wichtig: Der Public Key des Serving Host muss sicher und authentisch übertragen werden – er ist der einzige Vertrauensanker. Wird er kompromittiert (Man-in-the-Middle beim Austausch), kann ein Angreifer eine eigene Verbindung vortäuschen.

---

Vor- und Nachteile

Vorteile

• Standortunabhängigkeit: Serving Host kann in Hetzner, Zuhause, AWS oder hinter CGNAT laufen – kein eingehender Port nötig
• Kein VPN-Daemon: Keine WireGuard-Konfiguration, keine IKEv2-PKI – Aufwand sinkt deutlich
• OPNsense bleibt unberührt: Firewall-Regeln, Routing-Tabellen – alles unverändert
• Ende-zu-Ende-verschlüsselt: TLS 1.3 über QUIC; Relay sieht nur verschlüsselte Bytes
• Selbst-hostbarer Relay: Kein SaaS-Abhängigkeit wie bei Tailscale; iroh-relay ist Open Source
• Direkte Verbindungen wo möglich: 95 % der Verbindungen gehen ohne Relay-Hop durch (Iroh-Angabe)

Nachteile

• L7-only: Nginx muss explizit konfiguriert werden; kein transparentes OS-Routing
• Kein Flottenmanagement: Key-Rotation, Revocation, Inventar – alles selbst gebaut
• dumbpipe reicht nicht für HTTP-Upstream: Eigene Entwicklung nötig (Option B)
• QUIC-Firewall-Probleme: Manche Netze blockieren UDP; WebSocket-Fallback existiert, aber nicht alle Clients unterstützen ihn
• Relay-Abhängigkeit bei symmetrischem NAT: Eigener Relay nötig für vollständige Unabhängigkeit
• Fehlerdiagnose schwieriger: Kein tcpdump auf dem Iroh-Interface; Debugging läuft über Iroh-eigene Logs
• Nginx kennt keine echte Client-IP: Bei Relay-Routing kommt Traffic von der Relay-IP; X-Forwarded-For muss manuell gesetzt werden

---

Empfehlung

Für ein produktives Setup ist Option B (eigenes Iroh-Forward-Tool) der richtige Weg. Der Aufwand ist überschaubar und man bekommt ein sauberes TCP-Forwarding mit QUIC-Multiplexing, ohne auf dumbpipe-Hacks angewiesen zu sein.

Für einen ersten Proof of Concept reicht Option A mit dumbpipe + socat aus, um die Prinzipien zu validieren, bevor eigener Code entsteht.

OPNsense und Nginx müssen in keinem der Szenarien strukturell verändert werden – Iroh ist eine reine Ergänzung auf Applikationsebene.