Lightweight ngrok Alternatives: Rust b6 Go Micro-Proxies

In der sich schnell entwickelnden Welt des Edge-Computing, Home-Labors und Internet der Dinge (IoT) ist das sichere Exponieren lokaler Dienste an das öffentliche Internet schon immer eine zentrale Herausforderung gewesen. Seit Jahren verlassen sich Entwickler auf kommerzielle, zentrale Dienste, um Löcher durch Network Address Translation (NAT)-Firewalls zu punchern. Doch mit der Reifung des Ökosystems im Jahr 2026 entsteht ein Nischen- aber äußerst leidenschaftlicher Trend: Entwickler ersetzen schwere, kommerzielle Proxy-Dienste durch ultra-minimalistische Tools, geschrieben in Rust und Go.

Diese Micro-Proxies streben keine Unternehmensplattformen an. Sie sind kompromisslos klein, blitzschnell und vollständig Open Source. Für IoT-Hobbyisten und Edge-Netzwerkarchitekten, die Anwendungen auf Low-Memory-Geräten betreiben, ist die Suche nach einer leichtgewichtigen ngrok-Alternative zu einem Muss geworden.

Dieser Artikel beleuchtet den Aufstieg dieser spezialisierten Netzwerktools, taucht tief in die Architekturen und praktischen Anwendungen von Tools wie Bore, Rathole und Chisel ein. Wir untersuchen, warum Entwickler den Wechsel vollziehen, wie man einen robusten Raspberry Pi localhost Tunnel einrichtet, und klären abschließend die Debatte bore vs rathole für dein nächstes Embedded-Projekt.

---

Das Ballast der modernen Tunneling-Tools

Bevor wir zu den minimalistischen Alternativen kommen, ist es wichtig zu verstehen, was diesen Wandel vorangetrieben hat. Das Exponieren eines lokalen Entwicklungsservers, eines Home-Assistant-Dashboards oder eines entfernten IoT-Sensors erfordert das Umgehen von NAT und strengen Firewalls.

Historisch wurde dies durch komplexe SSH-Reverse-Port-Forwardings (ssh -R) erreicht. Effektiv, aber anfällig für Verbindungsabbrüche und erforderte einen dedizierten VPS mit spezifischen sshd_config-Änderungen. Dann kam die Ära der SaaS-Tunnelanbieter. Diese Dienste boten ein magisches Entwickler-Erlebnis: einen einzigen Befehl, der sofort eine öffentliche, HTTPS-gesicherte URL zu einem lokalen Rechner bereitstellte.

Mit dem Wachstum dieser Plattformen wandelten sie sich jedoch von einfachen Entwickler-Tools zu massiven Edge-Delivery-Netzwerken. Diese Entwicklung brachte Unternehmensfunktionen—Authentifizierungsebenen, Traffic-Inspektion, Lastverteilung und WAFs—mit sich, führte aber auch zu Friktionen:

1. Ressourcen-Overhead: Die Daemons für vollwertige Edge-Plattformen können ressourcenintensiv sein. Während auf einem M3 MacBook vernachlässigbar, ist dieser Overhead auf einem Raspberry Pi Zero oder einem eingeschränkten Embedded-Linux-Gerät im Edge-Bereich spürbar.
2. Bandbreiten- und Verbindungsbegrenzungen: Kostenlose Tiers bei kommerziellen Plattformen werden zunehmend restriktiv, begrenzen Bandbreite, Anzahl der aktiven Tunnel oder rotierende Domains, was automatisierte Workflows stört.
3. Geschlossene Ökosysteme: Viele moderne Tunneling-Clients sind Closed-Source. Für sicherheitsbewusste Home-Lab-Betreiber, die persönliche Infrastruktur (wie Sicherheitskameras oder private NAS-Daten) routen, ist der Betrieb geschlossener Netzwerk-Daemons ein No-Go.

Die Antwort auf diese Beschränkungen ist eine Renaissance der Open-Source-Micro-Proxies. Basierend auf modernen, systemnahen Sprachen wie Rust und Go bieten diese Tools Single-Binary-Deployments, speichersichere Ausführung und nahezu keine Laufzeitabhängigkeiten.

---

Chisel: Das Schweizer Taschenmesser der Go-Proxies

Bei modernen NetzwerktTools ist Go (Golang) meist die erste Sprache, die einem in den Sinn kommt, dank seines außergewöhnlichen Concurrency-Modells und der robusten Standardbibliothek. Im Bereich der minimalistischen Tunneling-Tools ist der chisel reverse proxy das ultimative Schweizer Taschenmesser.

Was ist Chisel?

Chisel ist ein schneller TCP/UDP-Tunnel, transportiert über HTTP und gesichert via SSH. Entwickelt von Jaime Pillora und unter MIT-Lizenz veröffentlicht, ist es vollständig in Go geschrieben und bündelt sowohl Client als auch Server in einer einzigen ausführbaren Datei. Stand Mitte 2026 verzeichnet das Projekt etwa 16.500 GitHub-Sterne und 1.600 Forks, mit der neuesten Version (v1.11.8), gebaut mit Go 1.27.0 — ein Beweis dafür, dass es sich noch um ein aktiv gepflegtes Projekt handelt.

Wie funktioniert Chisel?

Das “über HTTP”-Framing ist etwas spezifischer als es klingt: Chisel öffnet eine einzelne WebSocket-Verbindung über eine HTTP(S)-Anfrage und multiplext eine SSH-authentifizierte Sitzung — inklusive eigener verschlüsselter Kanäle — über diese Verbindung. Da der initiale Handshake wie eine normale HTTP-Anfrage mit einem Upgrade-Header aussieht, kann Chisel die meisten Unternehmens-Proxies und CDNs passieren. Es funktioniert hinter Cloudflare (mit WebSockets aktiviert) und Heroku, zum Beispiel. Der Haken ist, dass jede Zwischenstation, die den Upgrade-Header entfernt — einige strenge Unternehmens-Proxies tun dies — Chisel vollständig blockiert, es ist also kein universelles DPI-Umgehungswerkzeug.

Verschlüsselung ist Pflicht, nicht optional: Beim Start generiert der Server ein in-memory ECDSA-Schlüsselpaar und gibt den Fingerabdruck aus. Clients können diesen mit --fingerprint pinnen, um Man-in-the-Middle-Angriffe zu erkennen. Das ist die empfohlene Methode, es außerhalb eines vertrauenswürdigen Netzwerks zu betreiben.

Wichtige Features, geprüft anhand des aktuellen README:

• Single Executable: Kein separates Server- und Client-Paket notwendig.
• Transport über HTTP (WebSocket-Upgrade): Funktioniert durch die meisten Firewalls und CDNs, die WebSockets unterstützen; blockiert durch solche, die den Upgrade-Header entfernen.
• Integrierter SOCKS5: Der Server kann als voll funktionsfähiger SOCKS5-Proxy agieren, sodass ein Client ganze Browser-Sitzungen oder Systemverkehr durch den Tunnel leiten kann.
• Reverse Port Forwarding: Der Server kann einen Port exponieren, der auf den lokalen Dienst des Clients zurückverweist, aktiviert mit --reverse auf der Serverseite.
• Automatischer Wiederaufbau: Der Client reconnectet automatisch mit exponentiellem Backoff.

Sicherheit im Jahr 2026: Auch minimalistische Tools brauchen Patches

Open-Source macht ein Tool nicht immun gegen Bugs, und Chisel hatte im Jahr 2026 eine bemerkenswerte Sicherheitslage. Zwei hochkritische Advisories wurden veröffentlicht: eine ACL-Umgehung bei der Authfile durch Injection von “ExtraData” im SSH-Post-Handshake (GHSA-24fp-5v3p-rvpw, Mai 2026) und eine verwandte Umgehung, bei der ein eingeschränkter, authentifizierter Client beliebige TCP-Services im Server-Innenbereich erreichen konnte, weil der SOCKS5-Zugriff nicht gegen die Authfile geprüft wurde (GHSA-397r-r4gr-x5pg, Juni 2026).

Der Fix, ab Version 1.11.7, ist eine Breaking Change: Der Zugriff auf SOCKS5 ist jetzt durch ein socks-Token in der users.json-Authdatei geregelt. Wenn du --socks5 zusammen mit --authfile nutzt, braucht jeder Nutzer, der SOCKS-Zugriff behalten soll, einen expliziten Eintrag mit socks (ein Wildcard ""-Eintrag funktioniert weiterhin). Die Version 1.11.8 (Juli 2026) hat außerdem die Abhängigkeit golang.org/x/crypto/ssh auf v0.55.0 erhöht, um eine SSH-Sicherheitslücke (GO-2026-6303) zu schließen. Wenn du eine ältere Chisel-Binärdatei im Einsatz hast, ist das ein guter Zeitpunkt, sie zu aktualisieren.

Anwendungsfall: Der Penetration Tester und der Edge-Entwickler

Der chisel reverse proxy ist in der Cybersicherheits-Community sehr beliebt—aus dem gleichen Grund, warum es für Home-Lab-Betreiber nützlich ist: Es tunnelt leise über gewöhnliche Web-Ports. Diese Popularität hat zwei Seiten. Chisel taucht in “living-off-the-tunnels”-Listen von Binärdateien auf, die Angreifer für Netzwerk-Pivoting verwenden, und seine Windows-Binaries werden regelmäßig von Microsoft Defender als generischer Trojaner erkannt — nicht, weil der Code bösartig ist, sondern weil die Einfachheit der Binärdatei sie zu einem attraktiven Pivot-Tool macht. Für Verteidiger ist es wichtig, Chisels Traffic-Signatur (WebSocket-Handshake zu einem unbekannten Host auf ⁸⁰⁄₄₄₃, gefolgt von langlebigen Verbindungen) zu kennen, ebenso wie seine Funktion als Builder.

Für Edge-Entwickler eignet sich Chisel gut für Remote-Management. Wenn du eine Flotte smarter Verkaufsautomaten betreibst, kannst du auf jedem Gerät einen Chisel-Client laufen lassen. Sie rufen deinen zentralen Server über HTTP an und bieten dir auf Abruf, verschlüsselten Reverse-SSH-Zugang zu jedem Gerät, ohne Ports auf den Automaten selbst zu öffnen.

Starten eines Chisel-Servers auf deinem VPS:

chisel server -p 8080 --reverse

Verbindung vom lokalen Edge-Gerät:

chisel client vps-ip:8080 R:80:localhost:3000

Dieses Beispiel mappt Port 80 auf deinem VPS auf Port 3000 deines lokalen Edge-Geräts (R:-Präfix und remote-port:local-host:local-port-Reihenfolge sind die tatsächliche Syntax von Chisel).

---

Die Rust-Heavyweights: Bore vs. Rathole

Während Go Concurrency hervorragend meistert, bietet Rust unvergleichliche Kontrolle über Speicher und CPU-Auslastung. Für den absolut niedrigsten Ressourcenverbrauch greifen Entwickler auf Rust-basierte Tunnel zurück. Im Rust-Ökosystem dominieren zwei Tools die Diskussion: Bore und Rathole.

Die Entscheidung zwischen beiden hängt oft von einer Debatte um Einfachheit versus Leistung ab. Hier die Gegenüberstellung bore vs rathole.

Bore: Das Paradebeispiel für Einfachheit

Bore, entwickelt von Eric Zhang und unter MIT-Lizenz veröffentlicht, ist dafür gemacht, eine Sache perfekt zu tun: einen lokalen TCP-Port ins Internet zu exponieren. Aktuell in Version 0.6.0, besteht das gesamte Tool, wie seine Philosophie es vorsieht, aus etwa 400 Zeilen asynchronem Rust, gebaut auf Tokio.

Philosophie: Bore folgt einer Null-Barrier-Philosophie. Es verlangt keine Konfigurationsdateien, keine komplexen Routing-Regeln oder Zertifikate. Es soll eine sofort einsatzbereite Alternative zu kommerziellen Tunneling-Diensten sein.

Wichtige Features von Bore: * Zero-Config CLI: Sofortiger Start mit intuitiven Argumenten. * Raw TCP: Es verarbeitet rohen TCP-Verkehr, ist also Protokoll-unabhängig. Egal, ob HTTP, SSH, MySQL oder Minecraft-Server-Traffic, Bore behandelt alles transparent. * Öffentlicher Community-Server: Standardmäßig kannst du, wenn du nur einen Webhook testen willst, auf den Community-Server bore.pub zeigen, ohne eigenen VPS zu benötigen. (Ältere Anleitungen erwähnen manchmal bore.digital — das ist nicht mehr aktuell; bore.pub ist der offizielle Server.)

Sicherheits-Hinweis: Das optionale --secret-Flag von Bore authentifiziert nur den initialen Handshake via HMAC-Challenge-Response — es verschlüsselt den Tunnel selbst nicht. Wenn der Dienst, den du exponierst, kein TLS (HTTPS) spricht, sind die Bytes im Klartext unterwegs. Für sensible Anwendungen solltest du Bore hinter einem TLS-terminierenden Reverse-Proxy betreiben oder es über eine bereits verschlüsselte Verbindung wie WireGuard laufen lassen. Das ist ein echter Kompromiss für seine Einfachheit, kein Fehler — aber eine andere Sicherheitshaltung als Chisel oder Rathole, die standardmäßig verschlüsseln.

Wie Chisel ist Bore minimalistisch, was auch eine Schattenseite hat: Es wird in der Offensive Security manchmal als Werkzeug für Firewall-Bypass-Pivots missbraucht, weil eine einzelne kleine, legitime Binärdatei leicht auf einem kompromittierten Host platziert werden kann.

Wann Bore verwenden: Wenn du eine Webanwendung lokal entwickelst und eine Webhook-URL für Stripe oder GitHub brauchst, ist Bore dein bester Freund. Es erfordert keinen mentalen Overhead.

Starten eines selbstgehosteten Bore-Servers:

bore server

Exponieren eines lokalen Ports mit deinem eigenen Server:

bore local 8000 --to myserver.com

Rathole: Der sichere, leistungsstarke Arbeitstier

Wenn Bore ein Roller ist, ist Rathole ein hochgetuntes Sportauto. Rathole ist ein leichter, leistungsstarker Reverse Proxy für NAT-Traversal, explizit als Alternative zu frp und ngrokpositioniert. Ursprünglich von Yujia Qiao (rapiz1) entwickelt, ist das Projekt inzwischen in der Community-Organisationrathole-org` aktiv gepflegt — mit etwa 14.000 Sternen und aktuellen Commits. Es ist unter Apache-2.0 lizenziert.

Philosophie: Rathole ist für Dauerbetrieb und Sicherheit gebaut. Es soll einmal eingerichtet und auf Edge-Geräten, Routern und NAS-Systemen dauerhaft laufen.

Wichtige Features von Rathole: * Noise Protocol Verschlüsselung: Rathole nutzt das Noise Protocol Framework als Alternative zu TLS. Das Standard-Handshake-Muster ist Noise_NK_25519_ChaChaPoly_BLAKE2s, das den Server mit einem statischen Keypair authentifiziert — ähnlich SSH-Host-Key-Pinning — ohne die Verwaltung von X.509-Zertifikaten. (Frühere Versionen nutzten NN, was keine Server-Authentifizierung bietet und MITM-anfällig ist; NK ist das aktuelle Standardmuster.) * Token-basierte Authentifizierung: Dienste sind strikt authentifiziert. Der Server legt fest, welche Dienste erlaubt sind, und Clients müssen sich mit per-Service-Tokens authentifizieren. * Höhere Durchsatzrate als frp: Die eigenen Benchmarks zeigen deutlich höhere Durchsätze und bessere Stabilität unter Last im Vergleich zu frp. * Kleines Footprint: Ein minimaler Rathole-Build ohne unnötige Features kann auf ca. 500 KB kommen; eine voll ausgestattete Binary (mit TLS, Noise und WebSocket-Transport) liegt im niedrigen Megabyte-Bereich. Das ist ein Bruchteil der Größe einer JVM-basierten Alternative und passt gut auf Embedded-Router wie OpenWrt. * WebSocket-Transport: Eine neuere Ergänzung erlaubt Rathole, auch über WebSockets zu tunneln, was bei restriktiven Proxies hilft.

Das Urteil: bore vs rathole Die Entscheidung ist klar: Wenn du ein temporäres, frictionless, optional verschlüsseltes Tunnel für lokale Entwicklung oder schnelles Testen brauchst, nimm Bore. Die CLI ist intuitiv, und es stört kaum.

Wenn du eine dauerhafte Infrastruktur aufbauen willst — z.B. eine selbstgehostete Nextcloud, entfernte IoT-Knoten oder einen vollwertigen VPN — wähle Rathole. Die Konfiguration ist initial etwas aufwändiger, aber die Performance, Stabilität und kryptografische Authentifizierung machen es zur robusteren Wahl für den Produktionseinsatz.

---

Raspberry Pi localhost Tunnel bereitstellen

Um die Kraft dieser Micro-Proxies zu verdeutlichen, betrachten wir eine praktische Anwendung: das Einrichten eines Raspberry Pi localhost Tunnels.

Millionen Entwickler nutzen Raspberry Pis als Heimserver. Sie betreiben Home Automation (Home Assistant), netzwerkweite Adblocker (Pi-hole) und private Mediaserver. Der Zugriff auf diese Dienste außerhalb des Heimnetzwerks ist jedoch schwierig, weil ISPs dynamische IPs vergeben (Dynamic IP) und hinter strengen NAT-Routern verstecken.

Statt Ports am Heimrouter zu öffnen (was das ganze Netzwerk für automatisierte Internet-Scanner exponiert), kann man einen Micro-Proxy nutzen, um eine sichere, ausgehende Verbindung vom Pi zu einem günstigen Cloud-VPS für 5 USD/Monat zu erstellen.

Setup: Rathole für einen dauerhaften Pi-Tunnel

Für ein dauerhaftes Home-Lab ist Rathole ideal. Hier die Architektur, unter Verwendung der tatsächlichen Noise-Transport-Konfiguration (die ein generiertes Keypair erfordert, im Gegensatz zu den Platzhalter-Konfigurationen in früheren Entwürfen):

1. Keypair auf dem VPS generieren

./rathole --genkey
# Private Key: cQ/vwIqNPJZmuM/OikglzBo/+jlYGrOt9i0k5h5vn1Q=
# Public Key:  GQYTKSbWLBUSZiGfdWPSgek9yoOuaiwGD/GIX8Z1kkE=

Den privaten Key auf dem VPS behalten; den öffentlichen Key in die Pi-Konfiguration in Schritt 3 einfügen.

2. Der Cloud-VPS (Das öffentliche Gateway)

Miete einen kleinen, kostengünstigen virtuellen Server (z.B. DigitalOcean, Linode, Hetzner) mit statischer IP und installiere die Rathole-Binärdatei.

Erstelle server.toml:

[server]
bind_addr = "0.0.0.0:2333" # Port, auf dem Rathole auf den Pi hört

[server.transport]
type = "noise"

[server.transport.noise]
local_private_key = "cQ/vwIqNPJZmuM/OikglzBo/+jlYGrOt9i0k5h5vn1Q=" # aus --genkey

[server.services.home_assistant]
token = "super_secure_random_string"
bind_addr = "0.0.0.0:8123" # Der öffentliche Port, auf den du per Webbrowser zugreifst

Server starten: ./rathole --server server.toml

3. Das Raspberry Pi (Das Edge-Gerät)

Auf deinem Raspberry Pi lädst du die Rathole-Binärdatei herunter. Das Pi stellt eine verschlüsselte, server-authentifizierte Verbindung zum VPS her.

Erstelle client.toml:

[client]
remote_addr = "DEINE_VPS_IP:2333"

[client.transport]
type = "noise"

[client.transport.noise]
remote_public_key = "GQYTKSbWLBUSZiGfdWPSgek9yoOuaiwGD/GIX8Z1kkE=" # vom Schritt 1

[client.services.home_assistant]
token = "super_secure_random_string" # Muss mit dem Server-Token übereinstimmen
local_addr = "127.0.0.1:8123" # Der lokale Port von Home Assistant

Client starten: ./rathole --client client.toml

Das Ergebnis: Dein Raspberry Pi hat erfolgreich einen hochsicheren, verschlüsselten, server-authentifizierten Tunnel vom Wohnzimmer zum Cloud-Server aufgebaut. Du kannst jetzt von überall auf der Welt auf dein Home Assistant Dashboard zugreifen, indem du http://DEINE_VPS_IP:8123 aufrufst.

Wichtig: Da dies eine leichtgewichtige ngrok-Alternative ist, verbraucht der Rathole-Daemon auf deinem Pi nur wenige Megabyte RAM und nahezu 0% CPU im Leerlauf. Ressourcen werden für echte Anwendungen frei gehalten. Zudem, weil die Verbindung vom Pi zum VPS initiiert wird, braucht dein Heimrouter keine eingehenden Regeln, was die Sicherheit erhöht.

---

Die breiteren Implikationen für IoT und Edge-Netzwerke

Der Trend zu diesen Micro-Proxies spiegelt eine größere Entwicklung in der Software-Philosophie wider: eine Rückkehr zum Unix-Prinzip. Statt monolithischer Tools, die alles von Tunneling bis Identitätsprüfung managen, bevorzugen Entwickler modulare, hochperformante Utilities, die genau eine Aufgabe erfüllen.

Im IoT- und industriellen Edge-Bereich ist das besonders relevant. Stellen dir ein Netzwerk von tausenden solarbetriebenen Umweltsensoren vor, verteilt in einem Wald. Diese Geräte laufen auf winzigen Mikrocontrollern oder minimalistischen Linux-Boards. Sie haben intermittierende 4G/LTE-Verbindung, strenge Energieeinschränkungen und keine eingehende Netzwerk-Routing-Fähigkeit.

Der Einsatz eines kommerziellen Tunneling-Agents auf diesen Geräten ist oft unpraktisch wegen Binary-Größe und Speicherverbrauch. Ein statisch kompilierter Rust-Binary wie Rathole — deutlich unter einigen Megabyte, oft um 500 KB im Minimalmodus — kann direkt ins Firmware-Image eingebaut werden. Wenn ein Techniker Diagnosedaten abrufen muss, kann das Gerät temporär einen Noise-verschlüsselten Tunnel aufbauen, Daten übertragen und den Tunnel wieder schließen, um Energie zu sparen.

Sicherheitslage am Edge

Ein entscheidender Vorteil dieser Open-Source-Tools ist die Kontrolle, die sie in Bezug auf Sicherheit bieten. Bei Closed-Source-Proxies muss man implicit vertrauen, dass der Anbieter keine Klartext-Daten protokolliert (besonders, wenn SSL-Entschlüsselung auf deren Servern erfolgt).

Indem man eine leichtgewichtige ngrok-Alternative selbst hostet, z.B. mit Chisel oder Rathole, kontrolliert man beide Enden der Verbindung. Aber “Open-Source” und “selbst gehostet” sind keine Synonyme für “automatisch sicher” — die Sicherheitslücken in den Advisories von 2026 zeigen, dass diese Tools genauso patchpflichtig sind wie andere netzwerkexponierte Dienste. Der Vorteil von Open-Source-Tools ist, dass Schwachstellen offen gelegt, behoben und in kleinen, auditierbaren Codebasen ausgeliefert werden, anstatt hinter verschlossenen Vendor-Releases zu sitzen. In einer Welt, in der Datenschutz höchste Priorität hat, ist das Eliminieren des Man-in-the-Middle (selbst bei einem wohlwollenden SaaS-Anbieter) eine echte Sicherheitsverbesserung, vorausgesetzt, du hältst die Binärdateien aktuell.

---

Fazit: Dein minimalistisches Toolbelt

Die Ära, in der man auf schwere, enterprise-orientierte Tunneling-Plattformen für einfache Port-Weiterleitungen setzte, neigt sich dem Ende zu. Die Entwickler-Community hat eine goldene Ära an effizienten, sicheren und vollständig Open-Source-Netzwerk-Tools eingeläutet.

Ob du ein Web-Entwickler bist, der die sofortige Einfachheit von Bore sucht, ein Home-Lab-Enthusiast, der einen stabilen Raspberry Pi localhost Tunnel mit Rathole aufsetzt, oder ein Sicherheitsforscher (oder -verteidiger), der einen chisel reverse proxy im Netzwerk verfolgt — es gibt ein Tool, das genau zu deinen Anforderungen passt.

Rust und Go haben sich als die perfekten Sprachen für diese Netzwerk-Revolution erwiesen. Sie ermöglichen es Entwicklern, Software zu bauen, die nicht nur außergewöhnlich schnell, sondern auch erstaunlich leicht ist. Während Edge-Computing die Verarbeitungskraft aus zentralen Rechenzentren in unsere Häuser, Fahrzeuge und eingebettete Geräte verlagert, werden diese Micro-Proxies die unsichtbaren Fäden sein, die das dezentrale Web verbinden.

Verabschiede dich vom Ballast. Reclaim your RAM. Halte die Binärdateien aktuell. Umfasse den minimalistischen Edge.

---

Redaktionsänderungen

Dieses Draft wurde anhand der offiziellen GitHub-Repositories, README-Dateien und (für Chisel) Sicherheitsadvisories geprüft, anschließend um neu verifizierte Entwicklungen 2026 erweitert. Änderungen gegenüber dem Originalentwurf:

Korrekturen - Bore’s Community-Server ist bore.pub, nicht bore.digital — überall korrigiert. - Ratholes Standard-Noise-Muster ist Noise_NK_25519_ChaChaPoly_BLAKE2s (Server-Authentifizierung), nicht Noise_NN_25519_ChaChaPoly_BLAKE2s (ohne Authentifizierung, MITM-anfällig), wie im ursprünglichen Beispiel. - Ratholes Raspberry Pi-Konfiguration war unvollständig: Noise-Transport erfordert ein generiertes Keypair (local_private_key auf dem Server, remote_public_key auf dem Client, erzeugt via rathole --genkey). Die ursprünglichen client.toml/server.toml-Beispiele waren ohne diese Keys, was so nicht funktionierte. Ersetzt durch funktionierende, korrekt geknüpfte Beispiele. - Chisel-Transport wurde als “inside standard HTTP(S) requests” beschrieben; korrigiert zu WebSocket-Upgrade über HTTP(S), mit Hinweis, dass Proxies, die den Upgrade-Header entfernen, Chisel komplett blockieren. - Der Abschnitt IoT-Firmware wurde abgeschwächt: Rathole ist kein 3MB-Tool, sondern im Minimalbau etwa 500 KB, im vollen Umfang einige MB, je nach Features.

Neue Inhalte (sourcenbasiert) - Chisel: aktuelle Projektstatistiken (Autor Jaime Pillora, MIT-Lizenz, ca. 16.5k Sterne, Version v1.11.8 auf Go 1.27.0). - Chisel: zwei Sicherheitsadvisories 2026 (GHSA-24fp-5v3p-rvpw, Mai; GHSA-397r-r4gr-x5pg, Juni) wegen ACL- und SOCKS5-Bypass, die ab v1.11.7 gelten, inklusive der Änderung bei socks-Token. - Rathole: Projektwechsel von rapiz1/rathole zu rathole-org, ca. 14k Sterne, Apache-2.0, WebSocket-Transport. - Neue Hinweise zur Sicherheit: Open-Source bedeutet nicht automatisch sicher, aber Schwachstellen sind offen und patchbar.

Bestätigt (keine Änderungen notwendig) - Chisel CLI-Beispiele (chisel server -p 8080 --reverse / chisel client vps-ip:8080 R:80:localhost:3000) und Funktion. - Bore CLI-Beispiele und die ca. 400 Zeilen async Rust mit Tokio. - Ratholes Kernfunktion: höherer Durchsatz, geringerer Ressourcenverbrauch, Token-Authentifizierung.