jpillora/chiselTúnel rápido TCP/UDP sobre HTTP com criptografia SSH, suportando encaminhamento de porta reverso, proxy SOCKS5 e autenticação de cliente para travessia segura de rede e evasão de firewall.
# Chisel
[](https://godoc.org/github.com/jpillora/chisel) [](https://github.com/jpillora/chisel/actions?workflow=CI)
Chisel é um túnel TCP/UDP rápido, transportado sobre HTTP, protegido via SSH. Executável único incluindo tanto cliente quanto servidor. Escrito em Go (golang). Chisel é principalmente útil para atravessar firewalls, embora também possa ser usado para fornecer um endpoint seguro para sua rede.
## Índice
- [Recursos](#features)
- [Instalação](#install)
- [Demonstração](#demo)
- [Uso](#usage)
- [Contribuindo](#contributing)
- [Changelog](#changelog)
- [Licença](#license)
## Recursos
- Fácil de usar
- [Performático](https://github.com/jpillora/chisel/blob/master/test/bench/perf.md)\*
- [Conexões criptografadas](#security) usando o protocolo SSH (via `crypto/ssh`)
- [Conexões autenticadas](#authentication); conexões de cliente autenticadas com um arquivo de configuração de usuários, conexões de servidor autenticadas com correspondência de fingerprint.
- O cliente se reconecta automaticamente com [backoff exponencial](https://github.com/jpillora/backoff) (ajustável via `--min/max-retry-interval`); pings de keepalive expiram, então conexões silenciosamente mortas (sleep/wake, timeouts de NAT, reinicializações do servidor) são detectadas e restabelecidas
- Clientes podem criar múltiplos endpoints de túnel sobre uma única conexão TCP
- Clientes podem opcionalmente passar por proxies SOCKS ou HTTP CONNECT
- Encaminhamento de porta reverso (Conexões passam pelo servidor e saem pelo cliente)
- O servidor opcionalmente também funciona como um [proxy reverso](http://golang.org/pkg/net/http/httputil/#NewSingleHostReverseProxy)
- O servidor opcionalmente permite conexões [SOCKS5](https://en.wikipedia.org/wiki/SOCKS) (Veja [guia abaixo](#socks5-guide))
- Clientes opcionalmente permitem conexões [SOCKS5](https://en.wikipedia.org/wiki/SOCKS) a partir de um encaminhamento de porta reverso
- Conexões de cliente sobre stdio que suporta `ssh -o ProxyCommand` fornecendo SSH sobre HTTP
## Instalação
### Binários
[](https://github.com/jpillora/chisel/releases) [](https://github.com/jpillora/chisel/releases)
Veja [a versão mais recente](https://github.com/jpillora/chisel/releases/latest) ou baixe e instale agora com `curl https://i.jpillora.com/chisel! | bash`
Os binários são compilados com a versão mais recente do Go, que define as versões mínimas de SO: Windows 10 / Server 2016, macOS 12, kernel Linux 3.2, FreeBSD 12.2. Para sistemas mais antigos (por exemplo, Windows 7), use a [versão v1.8.1](https://github.com/jpillora/chisel/releases/tag/v1.8.1) ou anterior.
### Docker
[](https://hub.docker.com/r/jpillora/chisel/) [](https://hub.docker.com/r/jpillora/chisel/tags)
```sh
docker run --rm -it jpillora/chisel --help
```
As imagens são multi-arquitetura e publicadas tanto no Docker Hub (`jpillora/chisel`) quanto no GitHub Container Registry (`ghcr.io/jpillora/chisel`).
### Fedora
O pacote é mantido pela comunidade Fedora. Se você encontrar problemas relacionados ao uso do RPM, por favor use este [rastreador de issues](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
```
### Fonte
```sh
$ go install github.com/jpillora/chisel@latest
```
## Demonstração
Você pode executar seu próprio servidor de demonstração em minutos (a antiga demonstração no Heroku desapareceu junto com o plano gratuito do Heroku). [`example/fly.toml`](https://github.com/jpillora/chisel/blob/master/example/fly.toml) implanta este `chisel server` na [fly.io](https://fly.io) dentro da cota gratuita:
```sh
$ chisel server --port $PORT --backend http://example.com
# listens on $PORT, proxies normal web requests to http://example.com
```
Implante-o com `fly launch --copy-config` a partir do diretório `example/`, depois faça túnel para qualquer serviço em execução ao lado do servidor, por exemplo:
```sh
$ chisel client https://<your-app>.fly.dev 3000
# connects to your chisel server,
# tunnels your localhost:3000 to the server's localhost:3000
```
Visitar a URL do seu app em um navegador acessa o proxy de backend padrão do servidor e mostra uma cópia de [example.com](http://example.com).
## Uso
<!-- 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-->
### Segurança
A criptografia está sempre ativada. Quando você inicia um servidor chisel, ele gera um par de chaves ECDSA público/privado em memória. A impressão digital da chave pública (SHA256 codificada em base64) será exibida quando o servidor iniciar. Em vez de gerar uma chave aleatória, o servidor pode opcionalmente especificar um arquivo de chave, usando a opção `--keyfile`. Quando os clientes se conectam, eles também exibem a impressão digital da chave pública do servidor. O cliente pode forçar uma impressão digital específica usando a opção `--fingerprint`. Impressões digitais MD5 legadas ainda são aceitas, mas devem estar na forma completa de 16 octetos separados por dois-pontos — prefixos truncados são rejeitados. Consulte o `--help` acima para mais informações.
O servidor também limita os tamanhos das mensagens websocket de entrada antes da autenticação (`CHISEL_WS_READ_LIMIT`, padrão 512 KiB), para que pares não autenticados não possam esgotar a memória com mensagens superdimensionadas. O padrão fica confortavelmente acima do pacote de transporte máximo de 256 KiB do `x/crypto/ssh`, então nenhum pacote SSH válido é rejeitado. Apenas `0` desativa o limite; valores negativos recorrem ao padrão seguro.
### Autenticação
Usando a opção `--authfile`, o servidor pode opcionalmente fornecer um arquivo de configuração `user.json` para criar uma lista de usuários aceitos. O cliente então se autentica usando a opção `--auth`. Consulte [users.json](https://github.com/jpillora/chisel/blob/master/example/users.json) para um exemplo de arquivo de configuração de autenticação. Consulte o `--help` acima para mais informações.
Notas sobre o comportamento do authfile:
- O arquivo é monitorado e **recarregado ao vivo** — incluindo salvamentos do editor via renomeação (vim) e atualizações de configmap do kubernetes. As recargas se aplicam a novas conexões e a novos túneis de clientes já conectados; usuários removidos perdem o acesso a novos túneis imediatamente, embora túneis estabelecidos não sejam interrompidos.
- Os padrões de endereço são expressões regulares e **não são ancorados** — ancore-os com `^` e `$` (o servidor avisa sobre padrões não ancorados no carregamento). A string vazia `""` corresponde a tudo.
- O acesso SOCKS5 é controlado por uma entrada que corresponde ao token `socks`. **Breaking**: o SOCKS5 anteriormente ignorava completamente o authfile; servidores executando `--socks5` com `--authfile` devem conceder `socks` aos usuários que devem manter o acesso ao proxy (entradas com curinga `""` continuam funcionando).
- Strings de autenticação sem dois-pontos (`user:pass`) agora são um **erro fatal na inicialização** tanto no servidor quanto no cliente — anteriormente elas desativavam silenciosamente a autenticação.
- O usuário `--auth` sobrevive às recargas do authfile e vence conflitos de nome com usuários do arquivo.
Internamente, isso é feito usando o método de autenticação _Password_ fornecido pelo SSH. Saiba mais sobre `crypto/ssh` aqui http://blog.gopheracademy.com/go-and-ssh/. Aberturas/fechamentos de sessão (com usuário, endereço de origem e remotos) e tentativas de login falhas são registrados no nível info.
### Guia TLS
A configuração segura mais simples é `--tls-domain`, que provisiona um certificado LetsEncrypt automaticamente (requer porta 443 e um registro DNS apontando para o servidor):
```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
```
Para usar seu próprio certificado (autoassinado ou de CA interna), gere um par de chave/certificado e aponte ambos os lados para os arquivos corretos:
```sh
chisel server --port 443 --tls-key key.pem --tls-cert cert.pem
chisel client --tls-ca ca.pem https://chisel.example.com 3000
```
Para mutual TLS, também passe `--tls-ca` para o servidor e `--tls-cert`/`--tls-key` para cada cliente. Note que o TLS envolve o transporte do chisel pelo exterior; a camada SSH interna continua a cifrar e autenticar, pelo que a validação `--fingerprint` funciona com ou sem TLS.
### Guia SOCKS5 com Docker
1. Imprima uma nova chave privada no terminal
```sh
chisel server --keygen -
# or save it to disk --keygen /path/to/mykey
```
1. Inicie o seu servidor chisel
```sh
jpillora/chisel server --keyfile '<ck-base64 string or file path>' -p 9312 --socks5
```
1. Ligue o seu cliente chisel (usando a fingerprint do servidor)
```sh
chisel client --fingerprint '<see server output>' <server-address>:9312 socks
```
1. Aponte os seus clientes SOCKS5 (por exemplo, SO/Navegador) para:
```
<client-address>:1080
```
1. Agora tem uma ligação SOCKS5 cifrada e autenticada sobre HTTP
Nota: se o servidor também usar `--authfile`, os utilizadores precisam de uma entrada correspondente ao token `socks` para usar o proxy (ver [Authentication](#authentication)).
Para comandos de configuração, modo reverso e um exemplo de cliente UDP, consulte o [guia de utilizador SOCKS5 UDP](https://github.com/jpillora/chisel/blob/master/example/udpsocks.md).
Os remotes `socks` comuns suportam apenas TCP CONNECT e não vinculam nenhum socket UDP. Para ativar tanto TCP CONNECT como UDP ASSOCIATE, use `udpsocks` (ou `R:udpsocks` para modo reverso), por exemplo `1080:udpsocks`. Ambos os tipos usam por omissão `127.0.0.1:1080` e as mesmas permissões de acesso SOCKS. Um listener `udpsocks` vincula TCP e UDP na mesma interface e porta configuradas, partilhando um único socket de relay UDP entre associações sem alocar portas de escuta aleatórias. Os clientes UDP mantêm a sua ligação de controlo TCP aberta e enviam datagramas encapsulados em SOCKS para essa porta. Os nomes de destino dos datagramas são resolvidos no nó de saída, e o tráfego UDP viaja através do túnel SSH cifrado. Atualize ambos os pares Chisel para UDP; o SOCKS TCP permanece compatível com pares mais antigos.
Ao expor um listener `udpsocks` através de uma firewall ou contentor, permita tanto TCP como UDP na sua porta configurada. O UDP ASSOCIATE devolve o IP local que aceita a ligação TCP, que deve ser alcançável pelo cliente SOCKS. Para listeners Docker em Linux, use `--network host` com o remote `0.0.0.0:1080:udpsocks` para evitar anunciar um endereço de contentor isolado. Os mapeamentos de portas do contentor precisam tanto de `-p 1080:1080/tcp` como de `-p 1080:1080/udp`, além de alcançabilidade para o IP de relay anunciado. Se a porta UDP estiver ocupada, o Chisel regista que o UDP está indisponível, mantém o serviço TCP e rejeita o UDP ASSOCIATE sem usar uma porta alternativa; reinicie o proxy após libertar a porta.
Uma associação aceita pacotes do IP do seu par TCP. Uma porta de origem UDP declarada reserva esse endpoint; uma porta de origem zero é fixada pelo seu primeiro datagrama válido. Apenas uma associação não fixada por IP é permitida, pelo que os clientes que partilham um IP devem declarar as suas portas de origem UDP ou enviar o primeiro datagrama antes de abrir outra associação. Reservas duplicadas de porta de origem são rejeitadas. Fechar a ligação de controlo ou perder o SSH termina a associação; reconectar requer um novo UDP ASSOCIATE. BIND, fragmentação UDP e `stdio:udpsocks` não são suportados.
### SOCKS Reverso com um Authfile
Para permitir que um cliente específico atue como nó de saída SOCKS, conceda-lhe o endereço do listener reverse-socks (`R:socks` escuta em `127.0.0.1:1080` do servidor):
```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
```
Use `R:udpsocks` no comando do cliente para também habilitar UDP ASSOCIATE na mesma porta do servidor; a concessão do authfile permanece a mesma.
Veja também o [exemplo passo a passo de tunelamento reverso](https://github.com/jpillora/chisel/blob/master/example/reverse-tunneling-authenticated.md).
### Executando atrás de um CDN (Cloudflare)
O chisel funciona através de CDNs que suportam WebSockets. Para o Cloudflare: habilite WebSockets, faça proxy (orange-cloud) do registro DNS e conecte os clientes com `https://`. O CDN termina o TLS, mas a camada SSH interna significa que a validação `--fingerprint` ainda autentica seu servidor chisel de ponta a ponta — o CDN não pode ler ou modificar o tráfego tunelado. Mantenha `--keepalive` em seu padrão de `25s` para ficar abaixo dos timeouts de inatividade do CDN, e observe que proxies que removem cabeçalhos `Upgrade` não conseguem transportar o chisel de forma alguma.
### Ajuste com variáveis de ambiente
Opções menos comuns são variáveis de ambiente, todas lidas com o prefixo `CHISEL_` (por exemplo, `CHISEL_WS_TIMEOUT=10s`):
| Variável | Lado | Padrão | Propósito |
| --------------- | ----------- | ------------------ | -------------------------------------------------- |
| `WS_TIMEOUT` | cliente | `45s` | timeout do handshake websocket |
| `SSH_TIMEOUT` | cliente | `30s` | timeout do handshake ssh |
| `CONFIG_TIMEOUT`| servidor | `10s` | aguarda a requisição de configuração do cliente |
| `SSH_WAIT` | ambos | `35s` | quanto tempo novos túneis aguardam uma conexão ativa |
| `PING_TIMEOUT` | ambos | intervalo de keepalive | timeout de resposta do ping de keepalive (sem pings se `--keepalive 0`) |
| `DIAL_TIMEOUT` | ambos | `30s` | dial do alvo tcp, handshake SOCKS e timeout de DNS UDP do SOCKS |
| `WS_READ_LIMIT` | ambos | `524288` | máximo de bytes de mensagem websocket de entrada (0 = sem limite; negativo = padrão) |
| `WS_BUFF_SIZE` | ambos | padrão do go | tamanhos de buffer de leitura/escrita do websocket |
| `UDP_MAX_SIZE` | ambos | `9012` | máximo de bytes de pacote udp (inclui o cabeçalho UDP do SOCKS) |
| `UDP_DEADLINE` | ambos | `15s` | prazo de leitura do fluxo udp e expiração do return-peer; timeout de inatividade do destino UDP do SOCKS |
| `UDP_MAX_CONNS` | ambos | `100` | máximo de fluxos udp ou return peers; associações UDP do SOCKS por listener e destinos por associação |
| `SHUTDOWN_GRACE`| servidor | `5s` | tempo de drenagem de requisições http no desligamento |
`HOST`, `PORT`, `AUTH` e `CHISEL_KEY`/`CHISEL_KEY_FILE` estão documentados nos textos de `--help` acima.
O SOCKS UDP usa limites rígidos de associação e destino e descarta pacotes além deles. Cada associação enfileira até 16 datagramas de saída; filas cheias descartam pacotes sem bloquear outros clientes. Para SOCKS UDP, limites não positivos de tamanho/conexões ou prazos de inatividade usam os padrões, e o tamanho do pacote é limitado a 65507 bytes. Os sistemas operacionais podem impor um limite menor de envio UDP: o macOS usa por padrão 9216 bytes (`net.inet.udp.maxdgram`). O limite padrão de 9012 bytes do Chisel cabe dentro desse limite.
#### Ressalvas
Como o suporte a WebSockets é necessário:
- Todos os provedores de IaaS suportarão WebSockets (a menos que um proxy HTTP sem suporte tenha sido forçado à sua frente, caso em que eu diria que você foi rebaixado para PaaS)
- Provedores de PaaS variam em seu suporte a WebSockets
- Heroku tem suporte completo
- Openshift tem suporte completo, embora as conexões sejam aceitas apenas nas portas 8443 e 8080
- Google App Engine standard **não** tem suporte (o ambiente flexível tem)
## Contribuindo
- http://golang.org/doc/code.html
- http://golang.org/doc/effective_go.html
- `github.com/jpillora/chisel/share` contém o pacote compartilhado
- `github.com/jpillora/chisel/server` contém o pacote do servidor
- `github.com/jpillora/chisel/client` contém o pacote do cliente
## Changelog
- `1.0` - Versão inicial
- `1.1` - Substituída a criptografia simétrica simples por ECDSA SSH
- `1.2` - Adicionado suporte a SOCKS5 (servidor) e HTTP CONNECT (cliente)
- `1.3` - Adicionado suporte a tunelamento reverso
- `1.4` - Adicionado suporte a cabeçalhos HTTP arbitrários
- `1.5` - Adicionado suporte a SOCKS reverso (por @aus)
- `1.6` - Adicionado suporte a stdio no cliente (por @BoleynSu)
- `1.7` - Adicionado suporte a UDP
- `1.8` - Migração para uma imagem Docker `scratch`
- `1.9` - Atualizado para Go 1.21. Mudança de seed `--key` para strings de chave P256 com `--key{gen,file}` (por @cmenginnz)
- `1.10` - Atualizado para Go 1.22. Adicionados `.rpm` `.deb` e `.apk` às releases. Corrigida comparação de versão defeituosa.
- `1.11` - Atualizado para Go 1.25.1. Atualizadas todas as dependências.
- `1.12` - Passada de confiabilidade e segurança:
- pings de keepalive agora expiram (`CHISEL_PING_TIMEOUT`), então conexões mortas se reconectam prontamente após sleep/wake, timeouts de NAT e reinicializações do servidor
- recarregamentos do authfile sobrevivem a renomeações do editor e trocas de configmap do kubernetes, e se aplicam ao vivo a clientes conectados (novos túneis; túneis estabelecidos não são interrompidos)
- **breaking**: com `--socks5` + `--authfile`, o acesso SOCKS5 agora requer uma entrada no authfile correspondente a `socks` (entradas curinga `""` continuam funcionando)
- **breaking**: fingerprints MD5 legados truncados são rejeitados — `--fingerprint` deve ser a forma completa SHA256 (ou a forma completa MD5 de 16 octetos com dois-pontos)
- **breaking**: strings de auth sem dois-pontos (por exemplo, `--auth user`) são um erro fatal na inicialização em vez de desabilitar silenciosamente a autenticação
- o half-close de TCP é propagado através dos túneis, e alvos inalcançáveis rejeitam o túnel em vez de apresentar uma conexão morta (`CHISEL_DIAL_TIMEOUT`, padrão 30s)
- desligamento gracioso em SIGTERM com drenagem de requisições HTTP (`CHISEL_SHUTDOWN_GRACE`); um segundo sinal força a saída
- nós de saída UDP não quebram nem vazam além de 100 fluxos concorrentes (`CHISEL_UDP_MAX_CONNS`)
- mensagens websocket de entrada têm tamanho limitado antes da autenticação (`CHISEL_WS_READ_LIMIT`)
- o servidor não entra mais em pânico quando um cliente se desconecta entre o handshake SSH e sua requisição de configuração (#608)
- o cliente sai com código não-zero quando `--max-retry-count` é esgotado; novo `--min-retry-interval` (padrão 1s); `socks5://` aceito para `--proxy`
- builds via `go install` reportam sua versão real; sessões e logins falhos são registrados no nível info
---
[Read more](https://github.com/jpillora/chisel)