Der Minimalistische Edge: Rust- und Go-Mikro-Proxies

Es gibt einen Nischentrend in der Infrastruktur-Community: Entwickler ersetzen systematisch schwere, kommerzielle Proxy-Dienste durch ultra-minimalistische, Open-Source-Tools, geschrieben in Rust und Go. Seit Jahren war die Standardlösung, um einen lokalen Entwicklungsserver freizugeben oder Carrier-Grade NAT (CGNAT) zu umgehen, ein bekannter Dienst. Doch mit dem Wandel hin zu Enterprise-Features sind diese Plattformen schwerer geworden und die kostenlosen Tarife eingeschränkter.

Hier kommen die Mikro-Proxies ins Spiel.

Open-Source-Tools wie bore, rathole und chisel sprechen vor allem Home-Lab-Interessierte, IoT-Hobbyisten und Edge-Computing-Entwickler an — die Ingenieure, die Tunnel auf Geräten mit wenig RAM wie Raspberry Pis betreiben, bei denen jeder Megabyte RAM zählt. Durch die Nutzung der Speichersicherheit von Rust oder der statischen Kompilierung von Go bieten diese Mikro-Proxies schnelle, selbstgehostete Alternativen, die die Kontrolle wieder in die Hände des Entwicklers legen.

Die Suche nach einer leichten Ngrok-Alternative

Wenn du jemals einem Kunden eine lokale Web-App zeigen, einen Webhook testen oder dein Heimserver aus einem Café erreichen wolltest, hast du einen Tunneling-Dienst genutzt. Diese funktionieren, indem ein Agent auf deinem lokalen Rechner eine Verbindung zu einem öffentlichen Cloud-Server herstellt, der durch deine lokale Firewall durchbricht. Der Cloud-Server gibt dir eine öffentliche URL und leitet eingehenden Traffic durch den Tunnel.

Kommerzielle Lösungen sind ausgereift, aber sie haben Nachteile:

• Verbindungs- und Bandbreitenlimits. Kostenlose Tarife drosseln oft die Bandbreite, beschränken gleichzeitige Verbindungen oder timeout idle Sessions.
• Feature-Paywalls. Roh TCP-Tunnel für SSH oder Datenbanken oder eine persistenten eigenen Domain sind häufig hinter Abonnements versteckt.
• Agent-Überladung. Kommerzielle Agents bündeln Compliance-Features, Auto-Update-Tools und UI-Komponenten, die Ressourcen auf kleinen Edge-Geräten beanspruchen.
• Datenschutz und Kontrolle. Unverschlüsselter lokaler Traffic, der durch einen Drittanbieter-Server geleitet wird, schafft einen Angriffs- oder Abfangpunkt.

Dies hat die Nachfrage nach etwas erhöht, das auf einem günstigen VPS gehostet, als einzelnes Binary deployed und unbegrenzt laufen gelassen werden kann. Schauen wir uns drei Tools an, die diese Nische füllen — und, was noch wichtiger ist, was sie tatsächlich über den Traffic garantieren, sobald er dein Rechner verlässt, denn dort liegt oft die Marketing-Story, die die Defaults übertrifft.

1. Bore: Der unglaublich einfache Rust TCP-Tunnel

Wenn dein Ziel absolute Einfachheit ist, ist bore dafür gemacht. Entwickelt von Eric Zhang, ist es ein modernes, simples TCP-Tunnel-Tool in Rust, das lokale Ports zu einem Remote-Server freigibt, NAT-Firewalls umgeht — cite index=“7-1”, um ein hoch effizientes, unvoreingenommenes Tool für TCP-Weiterleitung zu sein, das leicht zu installieren und selbstzuhosten ist, ohne Schnickschnack/cite. Aktuell hat es 11.4k GitHub-Sterne, 514 Forks und ist MIT-lizenziert, Version 0.6.0 auf crates.io.

Wie Bore funktioniert

Bore ist konsequent unvoreingenommen. cite index=“7-1” Das Projekt umfasst etwa 400 Zeilen sicheren, asynchronen Rust-Codes und ist trivial aufzusetzen — einfach ein Binary für Client und Server starten.cite Es verwaltet keine TLS-Zertifikate, bietet kein Dashboard und inspiziert keinen HTTP-Traffic. Es leitet Bytes von A nach B weiter, nutzt einen impliziten Steuerport 7835 für die Verhandlung neuer Verbindungen.

Wichtig vorweg: bore verschlüsselt deinen Traffic nicht standardmäßig, und die ursprüngliche Version dieses Artikels implizierte das fälschlicherweise. Bore unterstützt eine optionale --secret-Flag, aber laut offizieller Dokumentation dient dieses nur der Authentifizierung des Handshakes — es verschlüsselt nicht die Daten. Laut eigener Authentifizierungssektion: Das Protokoll erfordert, dass Clients den Besitz des Secrets via HMAC-Challenges bei jeder Verbindung nachweisen; “keinerlei weiterer Traffic ist standardmäßig verschlüsselt.” Wenn du sensible Daten über bore leitest, musst du TLS selbst layern (siehe Sicherheitsabschnitt unten).

Schnelleinrichtung

cargo install bore-cli

Um einen lokalen Webserver auf Port 8000 freizugeben:

bore local 8000 --to bore.pub

Das Terminal zeigt einen zufällig zugewiesenen Remote-Port bei bore.pub. Du kannst einen bestimmten Port mit --port festlegen und einen anderen LAN-Host als localhost mit --local-host freigeben.

Für Self-Hosting: Starte bore server auf deinem VPS (optional mit --secret für Handshake-Authentifizierung und --min-port/--max-port, um den freigegebenen Bereich zu beschränken), dann zeige deinem lokalen Client den --to-Flag auf die Adresse deines VPS. Das ist ein Plug-and-Play-Tool, wenn du sofort einen Tunnel brauchst und keine Konfigurationsdatei schreiben möchtest.

2. Rathole: Hochleistungs-NAT-Traversal in Rust

Während bore gut für schnelle, temporäre Tests ist, zielt rathole auf etwas Dauerhaftes: das sichere und kontinuierliche Freigeben eines Heim-NAS oder IoT-Sensornetzwerks. Ein wichtiger Hinweis: Das Projekt hat den organisatorischen Sitz gewechselt, von rapiz1/rathole zu rathole-org/rathole (die alte URL leitet noch weiter). Es hat aktuell etwa 14k Sterne, 809 Forks und ist Apache-2.0-lizenziert, beschreibt sich selbst als cite index=“16-1” “ein leichter und leistungsstarker Reverse-Proxy für NAT-Traversal, geschrieben in Rust, eine Alternative zu frp und ngrok”.

Das Sicherheitsmodell — und eine Korrektur

Hier ist der zweite Punkt, bei dem der ursprüngliche Entwurf übertriebene Angaben machte. Das README von Rathole bewirbt die Unterstützung des Noise-Protokolls: cite index=“16-1” “Tokens sind für Dienste obligatorisch, und mit dem optionalen Noise-Protokoll kann die Verschlüsselung einfach konfiguriert werden, ohne ein selbstsigniertes Zertifikat zu erstellen — TLS wird ebenfalls unterstützt”. Aber zwei Details sind hier wichtig, die im ersten Entwurf zusammengefasst wurden:

1. Das token-Feld ist nur die Dienst-Authentifizierung, nicht die Transportverschlüsselung. Es beweist, dass ein Client berechtigt ist, einen Dienst zu binden; es schützt nicht die Bytes auf der Leitung.
2. Verschlüsselung ist optional, nicht automatisch. Es muss explizit eine [client.transport]/[server.transport]-Sektion mit type = "noise" (oder "tls") hinzugefügt werden, sonst defaultet Rathole auf unverschlüsseltes type = "tcp". Der Noise-Block benötigt außerdem ein local_private_key/remote_public_key-Paar (oder das Default-Muster Noise_NK_25519_ChaChaPoly_BLAKE2s) — es wird nicht aktiviert, nur weil du ein Token setzt.

Daher ist die frühere Aussage, “Verkehr ist automatisch Ende-zu-Ende verschlüsselt” nach Setzen eines gemeinsamen Tokens, falsch. So sieht eine Konfiguration aus, die Verschlüsselung tatsächlich aktiviert:

Konfiguration via TOML

server.toml auf deinem VPS:

[server]
bind_addr = "0.0.0.0:2333"

[server.transport]
type = "noise"

[server.services.my_ssh]
token = "super_secret_string"
bind_addr = "0.0.0.0:5202"

client.toml auf deinem Heimserver:

[client]
remote_addr = "vps_ip_address:2333"

[client.transport]
type = "noise"

[client.services.my_ssh]
token = "super_secret_string"
local_addr = "127.0.0.1:22"

Ohne [transport]-Sektion auf beiden Seiten fällt das auf unverschlüsseltes, unautentifiziertes TCP zurück — gut für einen schnellen lokalen Test, ungeeignet für das Internet. Rathole unterstützt auch UDP-Dienste (type = "udp" unter einem Service-Block) und das Hot-Reloading der Konfigurationsdatei ohne Neustart. Laut eigener Benchmark-Dokumentation cite index=“16-1” kann Rathole deutlich höhere Durchsatzraten als frp erreichen, ist stabiler bei großen Verbindungszahlen und verbraucht weniger Speicher, mit Binärgrößen um 500 KiB.

3. Chisel: Der vielseitige Go-basierte SSH-Tunnel

Für stark eingeschränkte Unternehmensnetzwerke oder komplexe Proxy-Anforderungen ist chisel die Go-Option. Aktuell in Version v1.11.5 (März 2026 veröffentlicht), mit 16.1k Sternen, 1.6k Forks, MIT-Lizenz, beschreibt es sich klar: cite index=“23-1” “ein schneller TCP/UDP-Tunnel, transportiert über HTTP, gesichert via SSH, einzelnes Binary inklusive Client und Server, geschrieben in Go”.

Im Gegensatz zu bore und rathole setzt chisel von Anfang an auf Verschlüsselung — das ist der Punkt, bei dem der ursprüngliche Entwurf Recht hatte. Es generiert beim Start ein in-memory ECDSA-Schlüsselpaar (oder lädt eines aus --keyfile) und sichert den Traffic mit crypto/ssh. Der Server zeigt beim Start den öffentlichen Schlüssel-Fingerprint; Clients sollten diesen mit --fingerprint pinnen, um MITM zu verhindern.

Umgehung restriktiver Firewalls

Der Trick liegt im Transportlayer. Viele Firmennetzwerke blockieren rohes TCP oder SSH-Verkehr, aber fast nie HTTP/HTTPS. Chisel wickelt den TCP/UDP-Tunnel in HTTP ein, das auf WebSockets upgradet — für eine restriktive Firewall sieht der Tunnel wie normaler Web-Traffic aus. Sobald er den Chisel-Server erreicht, ist der Payload darunter mit SSH gesichert.

Setup

chisel server -p 8080 --reverse

Auf dem eingeschränkten lokalen Rechner:

chisel client https://your-vps-domain.com R:80:localhost:3000

Dieser einzelne Befehl öffnet eine HTTP-Verbindung, verhandelt eine SSH-gesicherte Session und reverse-forwarded Port 3000 lokal auf Port 80 des Servers. Chisel unterstützt auch SOCKS5-Proxy (--socks5 auf dem Server, socks-Remote auf dem Client), passwortbasierte Authentifizierung via --authfile und native TLS-Beendigung mit automatischer Let’s Encrypt-Zertifikatsverwaltung via --tls-domain — eine Funktion, die im ursprünglichen Entwurf nicht erwähnt wurde und die wichtig ist, wenn Chisel HTTPS selbst terminieren soll, statt hinter Nginx oder Caddy zu sitzen. UDP-Unterstützung kam in Version 1.7.

Vergleich: bore vs. rathole vs. chisel

Der “bore vs rathole”-Vergleich ist bei Rust-Enthusiasten üblich; chisel bleibt eher in seiner eigenen Kategorie für Firewall-Umgehung. Die folgende Tabelle zeigt, was du standardmäßig bekommst, bevor du zusätzliche Konfigurationen vornimmst:

	Bore	Rathole	Chisel
Sprache	Rust	Rust	Go
Standardmäßig verschlüsselt	Nein	Nein (optional via Noise/TLS)	Ja (immer aktiv: ECDSA/SSH)
Konfigurationsformat	CLI-Flags	TOML	CLI-Flags
UDP-Unterstützung	Nein	Ja	Ja
Für was geeignet	Sofortige, temporäre Tunnel	Dauerhafte, hochdurchsatzfähige Heim-Lab-Services	HTTP-only Firewalls überwinden
Lizenz	MIT	Apache-2.0	MIT

Fazit: Nutze bore für einen null-Config, disposable Tunnel, bei dem du bei Bedarf TLS selbst layern kannst. Rathole eignet sich für dauerhafte, ressourcenschonende Heim-Lab-Infrastruktur — aber aktiviere explizit den Noise-Transport. Chisel ist die Wahl bei strengen HTTP-only Firewalls, wenn Verschlüsselung ohne viel Konfiguration gefragt ist.

Tutorial: Raspberry Pi Localhost-Tunnel einrichten

Viele Hobbyisten betreiben Dienste auf Raspberry Pis. Das Problem: Die meisten Heimanschlüsse sitzen hinter CGNAT, also gibt es keine öffentliche IP für Port-Forwarding. Hier kommt Rathole ins Spiel, diesmal mit aktivierter Noise-Verschlüsselung.

Schritt 1 — Server (VPS) vorbereiten

Lade das Rathole-Binary von der offiziellen Release-Seite. Erstelle server.toml:

[server]
bind_addr = "0.0.0.0:2333"

[server.transport]
type = "noise"

[server.services.pi_web]
token = "MySecureToken123!"
bind_addr = "0.0.0.0:8080"

Starte es: ./rathole server.toml

Schritt 2 — Client (Raspberry Pi) vorbereiten

Lade das ARM-Binary (Rust cross-kompiliert sauber für ARM). Erstelle client.toml:

[client]
remote_addr = "YOUR_VPS_IP:2333"

[client.transport]
type = "noise"

[client.services.pi_web]
token = "MySecureToken123!"
local_addr = "127.0.0.1:80"

Starte es: ./rathole client.toml

Da nur eine [client]- oder [server]-Sektion in jeder Datei vorhanden ist, erkennt Rathole automatisch, in welchem Modus es laufen soll — kein --client/--server-Flag nötig, außer beide Blöcke sind in einer Datei.

Schritt 3 — Persistenz mit systemd

Erstelle /etc/systemd/system/rathole.service:

[Unit]
Description=Rathole Client Tunnel
After=network.target

[Service]
Type=simple
User=pi
ExecStart=/home/pi/rathole /home/pi/client.toml
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Aktiviere und starte es:

sudo systemctl enable rathole
sudo systemctl start rathole

(Das Projekt liefert auch fertige systemd-Beispiele im examples/systemd-Verzeichnis, die du gegen deine eigenen Optionen prüfen kannst, z.B. LimitNOFILE.)

Der Zugriff auf http://YOUR_VPS_IP:8080 leitet jetzt durch den Noise-verschlüsselten Tunnel zum Pi.

Sicherheitsüberlegungen für Edge-Proxies

Wenn du kommerzielle Tools durch selbstgehostete Binärdateien ersetzt, übernimmst du die Verantwortung, die früher die Tools übernommen haben. Mit den oben korrigierten Defaults gilt:

• Verschlüsselung nur, wenn du sie konfigurierst. Bore und Rathole senden standardmäßig unverschlüsselten Traffic. Wenn du SSH weiterleitest, ist dieser verschlüsselt — aber bei unverschlüsseltem HTTP-Admin-Panel oder unverschlüsseltem Datenbankport kann jeder auf der Route lesen. Chisel verschlüsselt standardmäßig.
• Keine unautentifizierten Dienste öffentlich zugänglich machen. Wenn deine lokale App keinen Login hat, setze sie nicht auf einen offenen Port. Bots scannen offene Ports innerhalb von Minuten.
• Einen echten Reverse-Proxy vor den exponierten Port setzen. Nutze Nginx oder Caddy auf deinem VPS, terminieren TLS mit Let’s Encrypt auf 443 und proxy intern zu bore/rathole/chisel, statt deren Ports direkt zu öffnen (Chisel kann --tls-domain nutzen, um HTTPS zu terminieren). UDP-Unterstützung kam in Version 1.7.
• Fingerprints pinnen, wo unterstützt. Das --fingerprint-Flag bei Chisel ist der Unterschied zwischen “verschlüsselt” und “verschlüsselt und verifiziert” — ohne es bist du anfällig für MITM bei der ersten Verbindung.
• Bleib auf dem neuesten Stand. Rust und Go beheben viele Speicherfehler, aber Logikfehler (z.B. Auth-Bypass, Port-Range-Fehler) können trotzdem passieren. Überwache die Release-Seiten — z.B. ist Chisel bei Version 1.11.5 bereits bei seinem 35. Release.

Fazit

Die Infrastruktur erlebt eine minimalistische Renaissance, und die drei Tools oben sind echte Alternativen — bore für disposable Tunnel, rathole für dauerhafte Heim-Lab-Infrastruktur, chisel für Firewalls, die nur HTTP erlauben. Aber “selbstgehostet” und “sicher standardmäßig” sind nicht dasselbe. Zwei der drei Tools verschlüsseln standardmäßig nicht, sondern nur, wenn du es aktiv einschaltest. Das ist kein Kritikpunkt, sondern eine Folge der schlanken Binary (ca. 400 Zeilen, ohne Schnickschnack). Wichtig ist das Wissen, bevor du eines auf etwas Wichtiges richtest.

---

Changelog

Korrekturen und Ergänzungen am ursprünglichen Entwurf, geprüft anhand offizieller Quellen (GitHub-Repositories, READMEs, Release-Seiten) bis August 2026:

1. Bore’s Verschlüsselungskorrektur durch Ergänzung. Der ursprüngliche Entwurf erwähnte nicht, dass bore keine Standardverschlüsselung hat; explizit wurde auf die eigene Authentication-Sektion verwiesen, die besagt, dass --secret nur den Handshake schützt. Quelle: github.com/ekzhang/bore.
2. Ratholes Sicherheitsanspruch korrigiert. Der Entwurf behauptete, der Traffic sei “automatisch Ende-zu-Ende verschlüsselt” nach Setzen eines gemeinsamen Tokens. Das ist falsch, da das Token nur die Authentifizierung ist, die Verschlüsselung aber explizit aktiviert werden muss ([transport] mit type = "noise"). Die Konfigs und das Raspberry-Pi-Tutorial wurden entsprechend angepasst. Quelle: rathole-org/rathole README und docs/transport.md.
3. Ratholes Repo-Location aktualisiert. Von rapiz1/rathole zu rathole-org/rathole. Die Links wurden angepasst.
4. Aktuelle Statistiken ergänzt. Sterne, Forks, Lizenzen für bore (11.4k, MIT), rathole (~14k, Apache-2.0), chisel (16.1k, MIT, v1.11.5). Quellen: GitHub.
5. Chisel’s Sicherheitsmodell klargestellt. Verschlüsselung ist immer aktiv, mit crypto/ssh und generiertem Schlüssel. Das --fingerprint-Flag hilft bei MITM-Vermeidung; --tls-domain automatisiert Let’s Encrypt. Quellen: chisel README.
6. UDP-Unterstützung und Hot-Reload bei Rathole, UDP in chisel (ab v1.7). Nicht im Original erwähnt.
7. Systemd ExecStart korrigiert. Der Befehl nutzt nur client.toml, da Rathole den Modus anhand der Sektionen erkennt.
8. Bore’s Control-Port und CLI-Details direkt übernommen. (Port 7835, --local-host, --min-port/--max-port)
9. Sicherheitsabschnitt spezifisch angepasst. Vergleichstabelle für Standard-Sicherheits-Posture der Tools.
10. Frontmatter entfernt, nur reiner Text/Markdown.