jpillora/chiselSchneller TCP/UDP-Tunnel über HTTP mit SSH-Verschlüsselung, der Reverse-Port-Forwarding, SOCKS5-Proxy und Client-Authentifizierung für sichere Netzwerkdurchquerung und Firewall-Umgehung unterstützt.
# Chisel
[](https://godoc.org/github.com/jpillora/chisel) [](https://github.com/jpillora/chisel/actions?workflow=CI)
Chisel ist ein schneller TCP/UDP-Tunnel, der über HTTP transportiert und mittels SSH abgesichert wird. Eine einzige ausführbare Datei, die sowohl Client als auch Server enthält. Geschrieben in Go (golang). Chisel ist hauptsächlich nützlich, um Firewalls zu durchqueren, kann aber auch verwendet werden, um einen sicheren Endpunkt in Ihr Netzwerk bereitzustellen.
## Inhaltsverzeichnis
- [Funktionen](#features)
- [Installation](#install)
- [Demo](#demo)
- [Verwendung](#usage)
- [Mitwirken](#contributing)
- [Changelog](#changelog)
- [Lizenz](#license)
## Funktionen
- Einfach zu bedienen
- [Leistungsstark](https://github.com/jpillora/chisel/blob/master/test/bench/perf.md)\*
- [Verschlüsselte Verbindungen](#security) unter Verwendung des SSH-Protokolls (über `crypto/ssh`)
- [Authentifizierte Verbindungen](#authentication); authentifizierte Client-Verbindungen mit einer Benutzerkonfigurationsdatei, authentifizierte Server-Verbindungen mit Fingerprint-Abgleich.
- Client verbindet sich automatisch neu mit [exponentiellem Backoff](https://github.com/jpillora/backoff) (einstellbar über `--min/max-retry-interval`); Keepalive-Pings laufen ab, sodass stillschweigend tote Verbindungen (Sleep/Wake, NAT-Timeouts, Server-Neustarts) erkannt und wiederhergestellt werden
- Clients können mehrere Tunnel-Endpunkte über eine einzige TCP-Verbindung erstellen
- Clients können optional SOCKS- oder HTTP-CONNECT-Proxys durchlaufen
- Reverse-Port-Weiterleitung (Verbindungen gehen durch den Server und hinaus zum Client)
- Server kann optional auch als [Reverse-Proxy](http://golang.org/pkg/net/http/httputil/#NewSingleHostReverseProxy) dienen
- Server erlaubt optional [SOCKS5](https://en.wikipedia.org/wiki/SOCKS)-Verbindungen (siehe [Anleitung unten](#socks5-guide))
- Clients erlauben optional [SOCKS5](https://en.wikipedia.org/wiki/SOCKS)-Verbindungen von einer umgekehrten Port-Weiterleitung
- Client-Verbindungen über stdio, was `ssh -o ProxyCommand` unterstützt und SSH über HTTP ermöglicht
## Installation
### Binärdateien
[](https://github.com/jpillora/chisel/releases) [](https://github.com/jpillora/chisel/releases)
Siehe [das neueste Release](https://github.com/jpillora/chisel/releases/latest) oder laden Sie es jetzt herunter und installieren Sie es mit `curl https://i.jpillora.com/chisel! | bash`
Binärdateien werden mit der neuesten Go-Version erstellt, was die minimalen Betriebssystemversionen festlegt: Windows 10 / Server 2016, macOS 12, Linux-Kernel 3.2, FreeBSD 12.2. Für ältere Systeme (z. B. Windows 7) verwenden Sie [Release v1.8.1](https://github.com/jpillora/chisel/releases/tag/v1.8.1) oder früher.
### Docker
[](https://hub.docker.com/r/jpillora/chisel/) [](https://hub.docker.com/r/jpillora/chisel/tags)
```sh
docker run --rm -it jpillora/chisel --help
```
Images sind Multi-Arch und werden sowohl auf Docker Hub (`jpillora/chisel`) als auch auf der GitHub Container Registry (`ghcr.io/jpillora/chisel`) veröffentlicht.
### Fedora
Das Paket wird von der Fedora-Community gepflegt. Wenn Probleme bei der Verwendung des RPM auftreten, verwenden Sie bitte diesen [Issue-Tracker](https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&classification=Fedora&component=chisel&list_id=11614537&product=Fedora&product=Fedora%20EPEL).
```sh
sudo dnf -y install chisel
```
### Quelle
```sh
$ go install github.com/jpillora/chisel@latest
```
## Demo
Sie können Ihren eigenen Demo-Server in Minuten betreiben (das alte Heroku-Demo verschwand mit dem kostenlosen Tarif von Heroku). [`example/fly.toml`](https://github.com/jpillora/chisel/blob/master/example/fly.toml) stellt diesen `chisel server` auf dem kostenlosen Kontingent von [fly.io](https://fly.io) bereit:
```sh
$ chisel server --port $PORT --backend http://example.com
# listens on $PORT, proxies normal web requests to http://example.com
```
Stelle es mit `fly launch --copy-config` aus dem Verzeichnis `example/` bereit und tunnle dann zu einem beliebigen Dienst, der neben dem Server läuft, z. B.:
```sh
$ chisel client https://<your-app>.fly.dev 3000
# connects to your chisel server,
# tunnels your localhost:3000 to the server's localhost:3000
```
Wenn Sie die URL Ihrer App in einem Browser aufrufen, wird der Standard-Backend-Proxy des Servers angesprochen und eine Kopie von [example.com](http://example.com) angezeigt.
## Verwendung
<!-- render these help texts by hand,
or use https://github.com/jpillora/md-tmpl
with $ md-tmpl -w README.md -->
<!--tmpl,code=plain:echo "$ chisel --help" && go run main.go --help | sed 's#0.0.0-src (go1\..*)#X.Y.Z#' -->
``` plain
$ chisel --help
Usage: chisel [command] [--help]
Version: X.Y.Z
Commands:
server - runs chisel in server mode
client - runs chisel in client mode
Read more:
https://github.com/jpillora/chisel
```
<!--/tmpl-->
<!--tmpl,code=plain:echo "$ chisel server --help" && go run main.go server --help | cat | sed 's#0.0.0-src (go1\..*)#X.Y.Z#' -->
``` plain
$ chisel server --help
Usage: chisel server [options]
Options:
--host, Defines the HTTP listening host – the network interface
(defaults the environment variable HOST and falls back to 0.0.0.0).
--port, -p, Defines the HTTP listening port (defaults to the environment
variable PORT and falls back to port 8080).
--key, (deprecated use --keygen and --keyfile instead)
An optional string to seed the generation of a ECDSA public
and private key pair. All communications will be secured using this
key pair. Share the subsequent fingerprint with clients to enable detection
of man-in-the-middle attacks (defaults to the CHISEL_KEY environment
variable, otherwise a new key is generate each run).
--keygen, A path to write a newly generated PEM-encoded SSH private key file.
If users depend on your --key fingerprint, you may also include your --key to
output your existing key. Use - (dash) to output the generated key to stdout.
--keyfile, An optional path to a PEM-encoded SSH private key. When
this flag is set, the --key option is ignored, and the provided private key
is used to secure all communications. (defaults to the CHISEL_KEY_FILE
environment variable). Since ECDSA keys are short, you may also set keyfile
to the inline key string itself, exactly as printed by --keygen (a base64
string with a "ck-" prefix); no extra base64 encoding is needed.
--authfile, An optional path to a users.json file. This file should
be an object with users defined like:
{
"<user:pass>": ["<addr-regex>","<addr-regex>"]
}
when <user> connects, their <pass> will be verified and then
each of the remote addresses will be compared against the list
of address regular expressions for a match. Patterns are NOT
anchored by default: "10.0.0.1:80" also matches
"210.0.0.1:8080", and "." matches any character. Anchor your
patterns, e.g. "^10\.0\.0\.1:80$". The empty string ""
matches every address. Addresses will
always come in the form "<remote-host>:<remote-port>" for normal remotes,
"R:<local-interface>:<local-port>" for reverse port forwarding
remotes, and "socks" for SOCKS5 proxy access. Note that SOCKS5
access previously bypassed this list; existing authfiles which
should allow SOCKS5 must add an entry matching "socks" (the
empty wildcard "" matches everything, including "socks"). This
file will be automatically reloaded on change. Reloads apply
to new connections and to new tunnels of connected clients;
established tunnels are not interrupted.
--auth, An optional string representing a single user with full
access, in the form of <user:pass>. It is equivalent to creating an
authfile with {"<user:pass>": [""]}. If unset, it will use the
environment variable AUTH.
--keepalive, An optional keepalive interval. Since the underlying
transport is HTTP, in many instances we'll be traversing through
proxies, often these proxies will close idle connections. You must
specify a time with a unit, for example '5s' or '2m'. Defaults
to '25s' (set to 0s to disable).
--backend, Specifies another HTTP server to proxy requests to when
chisel receives a normal HTTP request. Useful for hiding chisel in
plain sight. --proxy is accepted as an alias for this flag.
--socks5, Allow clients to access the internal SOCKS5 proxy. See
chisel client --help for more information.
--reverse, Allow clients to specify reverse port forwarding remotes
in addition to normal remotes.
--tls-key, Enables TLS and provides optional path to a PEM-encoded
TLS private key. When this flag is set, you must also set --tls-cert,
and you cannot set --tls-domain.
--tls-cert, Enables TLS and provides optional path to a PEM-encoded
TLS certificate. When this flag is set, you must also set --tls-key,
and you cannot set --tls-domain.
--tls-domain, Enables TLS and automatically acquires a TLS key and
certificate using LetsEncrypt. Setting --tls-domain requires port 443.
You may specify multiple --tls-domain flags to serve multiple domains.
The resulting files are cached in the "$HOME/.cache/chisel" directory.
You can modify this path by setting the CHISEL_LE_CACHE variable,
or disable caching by setting this variable to "-". You can optionally
provide a certificate notification email by setting CHISEL_LE_EMAIL.
--tls-ca, a path to a PEM encoded CA certificate bundle or a directory
holding multiple PEM encode CA certificate bundle files, which is used to
validate client connections. The provided CA certificates will be used
instead of the system roots. This is commonly used to implement mutual-TLS.
--pid Generate pid file in current working directory
-v, Enable verbose logging
--help, This help text
Signals:
The chisel process is listening for:
a SIGINT or SIGTERM to begin a graceful shutdown
(a second signal forces an immediate exit),
a SIGUSR2 to print process stats, and
a SIGHUP to short-circuit the client reconnect timer
Version:
X.Y.Z
Read more:
https://github.com/jpillora/chisel
```
<!--/tmpl-->
<!--tmpl,code=plain:echo "$ chisel client --help" && go run main.go client --help | sed 's#0.0.0-src (go1\..*)#X.Y.Z#' -->
``` plain
$ chisel client --help
Usage: chisel client [options] <server> <remote> [remote] [remote] ...
<server> is the URL to the chisel server.
<remote>s are remote connections tunneled through the server, each of
which come in the form:
<local-host>:<local-port>:<remote-host>:<remote-port>/<protocol>
■ local-host defaults to 0.0.0.0 (all interfaces).
■ local-port defaults to remote-port.
■ remote-port is required*.
■ remote-host defaults to 127.0.0.1 (server localhost).
■ protocol defaults to tcp.
which shares <remote-host>:<remote-port> from the server to the client
as <local-host>:<local-port>, or:
R:<local-interface>:<local-port>:<remote-host>:<remote-port>/<protocol>
which does reverse port forwarding, sharing <remote-host>:<remote-port>
from the client to the server's <local-interface>:<local-port>.
example remotes
3000
example.com:3000
3000:google.com:80
192.168.0.5:3000:google.com:80
socks
5000:socks
udpsocks
5000:udpsocks
R:2222:localhost:22
R:socks
R:5000:socks
R:5000:udpsocks
stdio:example.com:22
1.1.1.1:53/udp
When the chisel server has --socks5 enabled, remotes can
specify "socks" or "udpsocks" in place of remote-host and
remote-port. Both default to the local host and port
127.0.0.1:1080. Connections to this remote will terminate
at the server's internal SOCKS5 proxy. When the server also
has --authfile set, SOCKS5 access requires an entry matching
the token "socks" in the user's address list.
When the chisel server has --reverse enabled, remotes can
be prefixed with R to denote that they are reversed. That
is, the server will listen and accept connections, and they
will be proxied through the client which specified the remote.
Reverse remotes specifying "R:socks" will listen on the server's
default socks port (1080) and terminate the connection at the
client's internal SOCKS5 proxy.
The "socks" remote supports TCP CONNECT only. Use "udpsocks"
for TCP CONNECT and UDP ASSOCIATE, including "R:udpsocks".
It binds TCP and UDP on the same configured interface and port;
the UDP relay never uses a randomly allocated listening port.
UDP requires support on both Chisel peers. Destination names are
resolved at the exit node. If UDP cannot bind, TCP remains available
and UDP ASSOCIATE fails; no alternate port is used. Clients using
a zero UDP source port allow one pending association per source IP
until the first valid datagram pins it. BIND, UDP fragmentation,
and udpsocks over stdio are not supported.
When stdio is used as local-host, the tunnel will connect standard
input/output of this program with the remote. This is useful when
combined with ssh ProxyCommand. You can use
ssh -o ProxyCommand='chisel client chiselserver stdio:%h:%p' \
[email protected]
to connect to an SSH server through the tunnel.
Options:
--fingerprint, A *strongly recommended* fingerprint string
to perform host-key validation against the server's public key.
Fingerprint mismatches will close the connection.
Fingerprints are generated by hashing the ECDSA public key using
SHA256 and encoding the result in base64.
Fingerprints must be 44 characters containing a trailing equals (=).
Legacy MD5 colon fingerprints (deprecated) are still accepted,
but only in their full 16-octet form; truncated prefixes are
rejected.
--auth, An optional username and password (client authentication)
in the form: "<user>:<pass>". These credentials are compared to
the credentials inside the server's --authfile. defaults to the
AUTH environment variable.
--keepalive, An optional keepalive interval. Since the underlying
transport is HTTP, in many instances we'll be traversing through
proxies, often these proxies will close idle connections. You must
specify a time with a unit, for example '5s' or '2m'. Defaults
to '25s' (set to 0s to disable).
--max-retry-count, Maximum number of times to retry before exiting.
Defaults to unlimited.
--min-retry-interval, Minimum wait time before retrying after a
disconnection. Defaults to 1 second.
--max-retry-interval, Maximum wait time before retrying after a
disconnection. Defaults to 5 minutes.
--proxy, An optional HTTP CONNECT or SOCKS5 proxy which will be
used to reach the chisel server. Authentication can be specified
inside the URL. Credentials must be URL-encoded; for example a
"#" in the password must be written as "%23".
For example, http://admin:[email protected]:8081
or: socks://admin:[email protected]:1080
The socks://, socks5:// and socks5h:// schemes are equivalent:
DNS is always resolved by the proxy.
--header, Set a custom header in the form "HeaderName: HeaderContent".
Can be used multiple times. (e.g --header "Foo: Bar" --header "Hello: World")
--hostname, Optionally set the 'Host' header (defaults to the host
found in the server url).
--sni, Override the ServerName when using TLS (defaults to the
hostname).
--tls-ca, An optional root certificate bundle used to verify the
chisel server. Only valid when connecting to the server with
"https" or "wss". By default, the operating system CAs will be used.
--tls-skip-verify, Skip server TLS certificate verification of
chain and host name (if TLS is used for transport connections to
server). If set, client accepts any TLS certificate presented by
the server and any host name in that certificate. This only affects
transport https (wss) connection. Chisel server's public key
may be still verified (see --fingerprint) after inner connection
is established.
--tls-key, a path to a PEM encoded private key used for client
authentication (mutual-TLS).
--tls-cert, a path to a PEM encoded certificate matching the provided
private key. The certificate must have client authentication
enabled (mutual-TLS).
--pid Generate pid file in current working directory
-v, Enable verbose logging
--help, This help text
Signals:
The chisel process is listening for:
a SIGINT or SIGTERM to begin a graceful shutdown
(a second signal forces an immediate exit),
a SIGUSR2 to print process stats, and
a SIGHUP to short-circuit the client reconnect timer
Version:
X.Y.Z
Read more:
https://github.com/jpillora/chisel
```
<!--/tmpl-->
### Sicherheit
Verschlüsselung ist immer aktiviert. Wenn Sie einen Chisel-Server starten, generiert er ein ECDSA-Public/Private-Schlüsselpaar im Speicher. Der Fingerabdruck des öffentlichen Schlüssels (base64-kodiertes SHA256) wird beim Start des Servers angezeigt. Anstatt einen zufälligen Schlüssel zu generieren, kann der Server optional eine Schlüsseldatei mit der Option `--keyfile` angeben. Wenn sich Clients verbinden, zeigen sie ebenfalls den Fingerabdruck des öffentlichen Schlüssels des Servers an. Der Client kann einen bestimmten Fingerabdruck mit der Option `--fingerprint` erzwingen. Legacy-MD5-Fingerabdrücke werden weiterhin akzeptiert, müssen jedoch die vollständige 16-Oktett-Doppelpunkt-Form haben — abgeschnittene Präfixe werden abgelehnt. Weitere Informationen finden Sie in der `--help` oben.
Der Server begrenzt außerdem die Größe eingehender Websocket-Nachrichten vor der Authentifizierung (`CHISEL_WS_READ_LIMIT`, Standard 512 KiB), sodass nicht authentifizierte Peers den Speicher nicht mit übergroßen Nachrichten erschöpfen können. Der Standardwert liegt komfortabel über dem maximalen Transportpaket von 256 KiB von `x/crypto/ssh`, sodass kein gültiges SSH-Paket jemals abgelehnt wird. Nur `0` deaktiviert das Limit; negative Werte fallen auf den sicheren Standardwert zurück.
### Authentifizierung
Mit der Option `--authfile` kann der Server optional eine `user.json`-Konfigurationsdatei bereitstellen, um eine Liste akzeptierter Benutzer zu erstellen. Der Client authentifiziert sich dann mit der Option `--auth`. Siehe [users.json](https://github.com/jpillora/chisel/blob/master/example/users.json) für ein Beispiel einer Authentifizierungskonfigurationsdatei. Weitere Informationen finden Sie in der `--help` oben.
Hinweise zum Verhalten von authfile:
- Die Datei wird überwacht und **live neu geladen** — einschließlich Editor-Speicherungen via Umbenennen (vim) und Kubernetes-Configmap-Updates. Neuladungen gelten für neue Verbindungen und für neue Tunnel bereits verbundener Clients; entfernte Benutzer verlieren sofort den Zugriff auf neue Tunnel, wobei bestehende Tunnel nicht unterbrochen werden.
- Adressmuster sind reguläre Ausdrücke und sind **nicht verankert** — verankern Sie sie mit `^` und `$` (der Server warnt beim Laden vor nicht verankerten Mustern). Die leere Zeichenkette `""` stimmt mit allem überein.
- SOCKS5-Zugriff wird durch einen Eintrag gesteuert, der mit dem Token `socks` übereinstimmt. **Breaking**: SOCKS5 umging zuvor die authfile vollständig; Server, die `--socks5` mit `--authfile` ausführen, müssen `socks` für Benutzer gewähren, die den Proxy-Zugriff behalten sollen (Wildcard-`""`-Einträge funktionieren weiterhin).
- Auth-Strings ohne Doppelpunkt (`user:pass`) sind jetzt ein **fataler Startfehler** sowohl auf dem Server als auch auf dem Client — zuvor deaktivierten sie stillschweigend die Authentifizierung.
- Der `--auth`-Benutzer überlebt authfile-Neuladungen und gewinnt bei Namenskonflikten mit Dateibenutzern.
Intern erfolgt dies mithilfe der _Password_-Authentifizierungsmethode, die von SSH bereitgestellt wird. Erfahren Sie mehr über `crypto/ssh` hier http://blog.gopheracademy.com/go-and-ssh/. Sitzungsöffnungen/-schließungen (mit Benutzer, Quelladresse und Remotes) und fehlgeschlagene Anmeldeversuche werden auf Info-Level protokolliert.
### TLS-Leitfaden
Das einfachste sichere Setup ist `--tls-domain`, das automatisch ein LetsEncrypt-Zertifikat bereitstellt (erfordert Port 443 und einen DNS-Eintrag, der auf den Server zeigt):
```sh
chisel server --port 443 --tls-domain chisel.example.com --auth user:pass
chisel client --auth user:pass https://chisel.example.com R:2222:localhost:22
```
Um ein eigenes Zertifikat zu verwenden (selbstsigniert oder interne CA), generieren Sie ein Schlüssel-/Zertifikatspaar und verweisen Sie beide Seiten auf die richtigen Dateien:
```sh
chisel server --port 443 --tls-key key.pem --tls-cert cert.pem
chisel client --tls-ca ca.pem https://chisel.example.com 3000
```
Für gegenseitiges TLS übergeben Sie außerdem `--tls-ca` an den Server und `--tls-cert`/`--tls-key` an jeden Client. Beachten Sie, dass TLS chisels Transport von außen umschließt; die innere SSH-Schicht verschlüsselt und authentifiziert weiterhin, sodass die `--fingerprint`-Validierung mit oder ohne TLS funktioniert.
### SOCKS5-Anleitung mit Docker
1. Einen neuen privaten Schlüssel im Terminal ausgeben
```sh
chisel server --keygen -
# oder auf der Festplatte speichern --keygen /path/to/mykey
```
1. Den chisel-Server starten
```sh
jpillora/chisel server --keyfile '<ck-base64 string or file path>' -p 9312 --socks5
```
1. Den chisel-Client verbinden (unter Verwendung des Server-Fingerabdrucks)
```sh
chisel client --fingerprint '<see server output>' <server-address>:9312 socks
```
1. Die SOCKS5-Clients (z. B. Betriebssystem/Browser) auf Folgendes verweisen:
```
<client-address>:1080
```
1. Nun verfügen Sie über eine verschlüsselte, authentifizierte SOCKS5-Verbindung über HTTP
Hinweis: Wenn der Server außerdem `--authfile` verwendet, benötigen Benutzer einen Eintrag, der zum Token `socks` passt, um den Proxy zu nutzen (siehe [Authentifizierung](#authentication)).
Einrichtungsbefehle, den Reverse-Modus und ein UDP-Client-Beispiel finden Sie im [SOCKS5-UDP-Benutzerhandbuch](https://github.com/jpillora/chisel/blob/master/example/udpsocks.md).
Gewöhnliche `socks`-Remotes unterstützen nur TCP CONNECT und binden keinen UDP-Socket. Um sowohl TCP CONNECT als auch UDP ASSOCIATE zu aktivieren, verwenden Sie `udpsocks` (oder `R:udpsocks` für den Reverse-Modus), zum Beispiel `1080:udpsocks`. Beide Typen verwenden standardmäßig `127.0.0.1:1080` und dieselben SOCKS-Zugriffsberechtigungen. Ein `udpsocks`-Listener bindet TCP und UDP auf derselben konfigurierten Schnittstelle und demselben Port und teilt einen UDP-Relay-Socket über Assoziationen hinweg, ohne zufällige Listening-Ports zuzuweisen. UDP-Clients halten ihre TCP-Steuerverbindung offen und senden SOCKS-gekapselte Datagramme an diesen Port. Datagramm-Zielnamen werden am Exit-Knoten aufgelöst, und der UDP-Datenverkehr läuft durch den verschlüsselten SSH-Tunnel. Aktualisieren Sie beide Chisel-Peers für UDP; TCP SOCKS bleibt mit älteren Peers kompatibel.
Wenn Sie einen `udpsocks`-Listener durch eine Firewall oder einen Container freigeben, erlauben Sie sowohl TCP als auch UDP auf seinem konfigurierten Port. UDP ASSOCIATE gibt die lokale IP zurück, die die TCP-Verbindung annimmt, und diese muss vom SOCKS-Client erreichbar sein. Verwenden Sie für Linux-Docker-Listener `--network host` mit dem Remote `0.0.0.0:1080:udpsocks`, um die Bekanntgabe einer isolierten Container-Adresse zu vermeiden. Container-Portzuordnungen benötigen sowohl `-p 1080:1080/tcp` als auch `-p 1080:1080/udp` sowie Erreichbarkeit der angekündigten Relay-IP. Wenn der UDP-Port belegt ist, protokolliert Chisel, dass UDP nicht verfügbar ist, behält den TCP-Dienst bei und lehnt UDP ASSOCIATE ab, ohne einen alternativen Port zu verwenden; starten Sie den Proxy nach dem Freigeben des Ports neu.
Eine Assoziation akzeptiert Pakete von der IP ihres TCP-Peers. Ein deklarierter UDP-Quellport reserviert diesen Endpunkt; ein Quellport von null wird durch sein erstes gültiges Datagramm festgelegt. Pro IP ist nur eine nicht festgelegte Assoziation erlaubt, daher sollten Clients, die sich eine IP teilen, ihre UDP-Quellports deklarieren oder das erste Datagramm senden, bevor sie eine weitere Assoziation öffnen. Doppelte Quellport-Reservierungen werden abgelehnt. Das Schließen der Steuerverbindung oder der Verlust von SSH beendet die Assoziation; eine erneute Verbindung erfordert ein neues UDP ASSOCIATE. BIND, UDP-Fragmentierung und `stdio:udpsocks` werden nicht unterstützt.
### Reverse SOCKS mit einer Authfile
Um einen bestimmten Client als SOCKS-Exit-Knoten agieren zu lassen, gewähren Sie ihm die Reverse-Socks-Listener-Adresse (`R:socks` lauscht auf dem `127.0.0.1:1080` des Servers):
```json
{
"exituser:password": ["^R:127\\.0\\.0\\.1:1080$"]
}
```
```sh
chisel server --reverse --authfile users.json
chisel client --auth exituser:password <server-address> R:socks
# server-side consumers point SOCKS5 clients at 127.0.0.1:1080,
# and their traffic exits via the chisel client's network
```
Verwende `R:udpsocks` im Client-Befehl, um zusätzlich UDP ASSOCIATE auf demselben Server-Port zu aktivieren; die authfile-Gewährung bleibt dieselbe.
Siehe auch das Schritt-für-Schritt-[Reverse-Tunneling-Beispiel](https://github.com/jpillora/chisel/blob/master/example/reverse-tunneling-authenticated.md).
### Betrieb hinter einem CDN (Cloudflare)
chisel funktioniert durch CDNs, die WebSockets unterstützen. Für Cloudflare: WebSockets aktivieren, den DNS-Eintrag proxyen (Orange-Cloud) und Clients mit `https://` verbinden. Das CDN terminiert TLS, aber die innere SSH-Schicht bedeutet, dass die `--fingerprint`-Validierung deinen chisel-Server weiterhin Ende-zu-Ende authentifiziert — das CDN kann den getunnelten Datenverkehr weder lesen noch verändern. Behalte `--keepalive` bei seinem Standardwert `25s`, um unter den Idle-Timeouts des CDN zu bleiben, und beachte, dass Proxys, die `Upgrade`-Header entfernen, chisel überhaupt nicht übertragen können.
### Tuning mit Umgebungsvariablen
Seltenere Stellschrauben sind Umgebungsvariablen, alle mit dem Präfix `CHISEL_` gelesen (z. B. `CHISEL_WS_TIMEOUT=10s`):
| Variable | Seite | Standard | Zweck |
| --------------- | ----------- | ------------------ | -------------------------------------------------- |
| `WS_TIMEOUT` | client | `45s` | Websocket-Handshake-Timeout |
| `SSH_TIMEOUT` | client | `30s` | SSH-Handshake-Timeout |
| `CONFIG_TIMEOUT`| server | `10s` | Warten auf die Konfigurationsanfrage des Clients |
| `SSH_WAIT` | beide | `35s` | wie lange neue Tunnel auf eine aktive Verbindung warten |
| `PING_TIMEOUT` | beide | Keepalive-Intervall | Timeout für die Antwort auf den Keepalive-Ping (keine Pings bei `--keepalive 0`) |
| `DIAL_TIMEOUT` | beide | `30s` | TCP-Ziel-Dial, SOCKS-Handshake und SOCKS-UDP-DNS-Timeout |
| `WS_READ_LIMIT` | beide | `524288` | maximale Bytes eingehender Websocket-Nachrichten (0 = kein Limit; negativ = Standard) |
| `WS_BUFF_SIZE` | beide | Go-Standard | Websocket-Lese-/Schreib-Puffergrößen |
| `UDP_MAX_SIZE` | beide | `9012` | maximale UDP-Paket-Bytes (inklusive SOCKS-UDP-Header) |
| `UDP_DEADLINE` | beide | `15s` | UDP-Flow-Lese-Deadline und Return-Peer-Ablauf; SOCKS-UDP-Ziel-Idle-Timeout |
| `UDP_MAX_CONNS` | beide | `100` | maximale UDP-Flows oder Return-Peers; SOCKS-UDP-Assoziationen pro Listener und Ziele pro Assoziation |
| `SHUTDOWN_GRACE`| server | `5s` | HTTP-Request-Drain-Zeit beim Herunterfahren |
`HOST`, `PORT`, `AUTH` und `CHISEL_KEY`/`CHISEL_KEY_FILE` sind in den `--help`-Texten oben dokumentiert.
SOCKS UDP verwendet harte Assoziations- und Ziel-Limits und verwirft Pakete darüber hinaus. Jede Assoziation reiht bis zu 16 ausgehende Datagramme ein; volle Warteschlangen verwerfen Pakete, ohne andere Clients zu blockieren. Für SOCKS UDP verwenden nichtpositive Größen-/Verbindungslimits oder Idle-Deadlines die Standardwerte, und die Paketgröße ist auf 65507 Bytes begrenzt. Betriebssysteme können ein kleineres UDP-Sende-Limit auferlegen: macOS verwendet standardmäßig 9216 Bytes (`net.inet.udp.maxdgram`). Das Standardlimit von Chisel von 9012 Bytes passt in diese Grenze.
#### Einschränkungen
Da WebSocket-Unterstützung erforderlich ist:
- IaaS-Anbieter unterstützen alle WebSockets (es sei denn, ein nicht unterstützender HTTP-Proxy wurde dir zwangsweise vorgeschaltet, in welchem Fall ich behaupten würde, dass du auf PaaS herabgestuft wurdest)
- PaaS-Anbieter unterscheiden sich in ihrer Unterstützung für WebSockets
- Heroku hat vollständige Unterstützung
- Openshift hat vollständige Unterstützung, obwohl Verbindungen nur auf den Ports 8443 und 8080 akzeptiert werden
- Google App Engine Standard hat **keine** Unterstützung (die flexible Umgebung schon)
## Mitwirken
- http://golang.org/doc/code.html
- http://golang.org/doc/effective_go.html
- `github.com/jpillora/chisel/share` enthält das gemeinsame Paket
- `github.com/jpillora/chisel/server` enthält das Server-Paket
- `github.com/jpillora/chisel/client` enthält das Client-Paket
## Changelog
- `1.0` - Erstveröffentlichung
- `1.1` - Einfache symmetrische Verschlüsselung durch ECDSA SSH ersetzt
- `1.2` - SOCKS5- (Server) und HTTP-CONNECT-Unterstützung (Client) hinzugefügt
- `1.3` - Reverse-Tunneling-Unterstützung hinzugefügt
- `1.4` - Unterstützung für beliebige HTTP-Header hinzugefügt
- `1.5` - Reverse-SOCKS-Unterstützung hinzugefügt (von @aus)
- `1.6` - Client-stdio-Unterstützung hinzugefügt (von @BoleynSu)
- `1.7` - UDP-Unterstützung hinzugefügt
- `1.8` - Umstellung auf ein `scratch`-Docker-Image
- `1.9` - Aktualisierung auf Go 1.21. Wechsel von `--key`-Seed zu P256-Schlüsselstrings mit `--key{gen,file}` (von @cmenginnz)
- `1.10` - Aktualisierung auf Go 1.22. `.rpm`, `.deb` und `.apk` zu den Releases hinzugefügt. Fehlerhaften Versionsvergleich behoben.
- `1.11` - Aktualisierung auf Go 1.25.1. Alle Abhängigkeiten aktualisiert.
- `1.12` - Zuverlässigkeits- und Sicherheitsdurchgang:
- Keepalive-Pings laufen jetzt in einen Timeout (`CHISEL_PING_TIMEOUT`), sodass tote Verbindungen nach Sleep/Wake, NAT-Timeouts und Server-Neustarts zügig neu verbinden
- authfile-Neuladungen überstehen Editor-Umbenennungen und Kubernetes-Configmap-Austausche und werden live auf verbundene Clients angewendet (neue Tunnel; bestehende Tunnel werden nicht unterbrochen)
- **breaking**: mit `--socks5` + `--authfile` erfordert der SOCKS5-Zugriff jetzt einen authfile-Eintrag, der zu `socks` passt (Wildcard-`""`-Einträge funktionieren weiterhin)
- **breaking**: abgeschnittene Legacy-MD5-Fingerprints werden abgelehnt — `--fingerprint` muss die vollständige SHA256-Form sein (oder die vollständige 16-Oktett-MD5-Doppelpunktform)
- **breaking**: Auth-Strings ohne Doppelpunkt (z. B. `--auth user`) sind ein fataler Startfehler, anstatt die Authentifizierung stillschweigend zu deaktivieren
- TCP-Half-Close wird durch Tunnel weitergegeben, und unerreichbare Ziele lehnen den Tunnel ab, anstatt eine tote Verbindung darzustellen (`CHISEL_DIAL_TIMEOUT`, Standard 30s)
- Graceful Shutdown bei SIGTERM mit HTTP-Request-Draining (`CHISEL_SHUTDOWN_GRACE`); ein zweites Signal erzwingt den Exit
---
[Read more](https://github.com/jpillora/chisel)