Skip to content
KitploitKITPLOIT
FerramentasBlog
Enviar
FerramentasBlog
Enviar

Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!

Kitploit é um diretório de ferramentas de hacking, cibersegurança e pentesting. Descubra as últimas atualizações de projetos para encontrar vulnerabilidades, analisar sistemas, automatizar testes e fortalecer sua segurança.

··Feeds·Contato·Privacidade·© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
rathole — Um proxy reverso leve e de alto desempenho para travessia NAT, escrito em Rust. Uma alternativa ao frp e ngrok. | Kitploit
Ferramentas/GitHubGitHub/rathole-org/rathole
Utilitários de Propósito GeralSegurança de RedeUtilitários e Frameworks
GitHubrathole-org/rathole

rathole

Um proxy reverso leve e de alto desempenho para travessia NAT, escrito em Rust. Uma alternativa ao frp e ngrok.

Ver Repositório
14.0k804há 1 anoRevisado pelo Kitploit

Mais Populares

Ver todos →

Descubra as ferramentas mais usadas pela nossa comunidade.

Explore todas as ferramentas

Navegue pela nossa coleção de ferramentas

Ver todas as ferramentas →
Compartilhar

rathole

rathole-logo

GitHub stars GitHub release (latest SemVer) GitHub Workflow Status (branch) GitHub all releases Docker Pulls Join the chat at https://gitter.im/rapiz1/rathole

English | 简体中文

Um proxy reverso seguro, estável e de alto desempenho para travessia NAT, escrito em Rust

O rathole, assim como frp e ngrok, pode ajudar a expor o serviço no dispositivo atrás do NAT para a Internet, através de um servidor com um IP público.

  • rathole
    • Funcionalidades
    • Início Rápido
    • Configuração
      • Registo de Log
      • Ajuste
    • Benchmark
    • Planeamento

Funcionalidades

  • Alto Desempenho É possível obter uma taxa de transferência muito maior do que com o frp, e mais estável ao lidar com um grande volume de conexões. Consulte Benchmark
  • Baixo Consumo de Recursos Consome muito menos memória do que ferramentas semelhantes. Consulte Benchmark. O binário pode ser tão pequeno quanto ~500 KiB para caber nas restrições de dispositivos, como dispositivos embarcados como routers.
  • Segurança Os tokens dos serviços são obrigatórios e específicos para cada serviço. O servidor e os clientes são responsáveis pelas suas próprias configurações. Com o opcional Protocolo de Ruído (Noise), a encriptação pode ser configurada facilmente. Sem necessidade de criar um certificado auto-assinado! TLS também é suportado.
  • Recarregamento a Quente Os serviços podem ser adicionados ou removidos dinamicamente recarregando a quente o ficheiro de configuração. A API HTTP está em desenvolvimento.

Início Rápido

Um rathole completo pode ser obtido na página de lançamentos. Ou compilar a partir do código fonte para outras plataformas e minimizar o binário. Uma imagem Docker também está disponível.

O uso do rathole é muito semelhante ao do frp. Se tem experiência com este último, a configuração é muito fácil para si. A única diferença é que a configuração de um serviço é dividida entre o lado do cliente e o lado do servidor, e um token é obrigatório.

Para usar o rathole, precisa de um servidor com um IP público e de um dispositivo atrás do NAT, onde estejam alguns serviços que precisam de ser expostos à Internet.

Supondo que tem um NAS em casa atrás do NAT e deseja expor o seu serviço ssh para a Internet:

  1. No servidor que tem um IP público

Crie server.toml com o seguinte conteúdo e adapte-o às suas necessidades.

root@kitploit:~
# server.toml
[server]
bind_addr = "0.0.0.0:2333" # `2333` specifies the port that rathole listens for clients

[server.services.my_nas_ssh]
token = "use_a_secret_that_only_you_know" # Token that is used to authenticate the client for the service. Change to an arbitrary value.
bind_addr = "0.0.0.0:5202" # `5202` specifies the port that exposes `my_nas_ssh` to the Internet

Depois execute:

root@kitploit:~
./rathole server.toml
  1. No anfitrião que está atrás do NAT (o seu NAS)

Crie client.toml com o seguinte conteúdo e adapte-o às suas necessidades.

root@kitploit:~
# client.toml
[client]
remote_addr = "myserver.com:2333" # The address of the server. The port must be the same with the port in `server.bind_addr`

[client.services.my_nas_ssh]
token = "use_a_secret_that_only_you_know" # Must be the same with the server to pass the validation
local_addr = "127.0.0.1:22" # The address of the service that needs to be forwarded

Depois execute:

root@kitploit:~
./rathole client.toml
  1. Agora o cliente tentará ligar-se ao servidor myserver.com na porta 2333, e qualquer tráfego para myserver.com:5202 será reencaminhado para a porta 22 do cliente.

Assim, pode ssh myserver.com:5202 para aceder por ssh ao seu NAS.

Para executar o rathole como um serviço em segundo plano no Linux, consulte os exemplos systemd.

Configuração

O rathole pode determinar automaticamente se deve executar no modo servidor ou cliente, de acordo com o conteúdo do ficheiro de configuração, se apenas um dos blocos [server] e [client] estiver presente, como no exemplo em Início Rápido.

Mas os blocos [client] e [server] também podem ser colocados num único ficheiro. Então, no lado do servidor, execute rathole --server config.toml e no lado do cliente, execute rathole --client config.toml para indicar explicitamente ao rathole o modo de execução.

Antes de passar à especificação completa da configuração, é recomendado folhear os exemplos de configuração para ter uma ideia do formato da configuração.

Consulte Transporte para mais detalhes sobre encriptação e o bloco transport.

Aqui está a especificação completa da configuração:

root@kitploit:~
[client]
remote_addr = "example.com:2333" # Necessary. The address of the server
default_token = "default_token_if_not_specify" # Optional. The default token of services, if they don't define their own ones
heartbeat_timeout = 40 # Optional. Set to 0 to disable the application-layer heartbeat test. The value must be greater than `server.heartbeat_interval`. Default: 40 seconds
retry_interval = 1 # Optional. The interval between retry to connect to the server. Default: 1 second

[client.transport] # The whole block is optional. Specify which transport to use
type = "tcp" # Optional. Possible values: ["tcp", "tls", "noise"]. Default: "tcp"

[client.transport.tcp] # Optional. Also affects `noise` and `tls`
proxy = "socks5://user:[email protected]:1080" # Optional. The proxy used to connect to the server. `http` and `socks5` is supported.
nodelay = true # Optional. Determine whether to enable TCP_NODELAY, if applicable, to improve the latency but decrease the bandwidth. Default: true
keepalive_secs = 20 # Optional. Specify `tcp_keepalive_time` in `tcp(7)`, if applicable. Default: 20 seconds
keepalive_interval = 8 # Optional. Specify `tcp_keepalive_intvl` in `tcp(7)`, if applicable. Default: 8 seconds

[client.transport.tls] # Necessary if `type` is "tls"
trusted_root = "ca.pem" # Necessary. The certificate of CA that signed the server's certificate
hostname = "example.com" # Optional. The hostname that the client uses to validate the certificate. If not set, fallback to `client.remote_addr`

[client.transport.noise] # Noise protocol. See `docs/transport.md` for further explanation
pattern = "Noise_NK_25519_ChaChaPoly_BLAKE2s" # Optional. Default value as shown
local_private_key = "key_encoded_in_base64" # Optional
remote_public_key = "key_encoded_in_base64" # Optional

[client.transport.websocket] # Necessary if `type` is "websocket"
tls = true # If `true` then it will use settings in `client.transport.tls`

[client.services.service1] # A service that needs forwarding. The name `service1` can change arbitrarily, as long as identical to the name in the server's configuration
type = "tcp" # Optional. The protocol that needs forwarding. Possible values: ["tcp", "udp"]. Default: "tcp"
token = "whatever" # Necessary if `client.default_token` not set
local_addr = "127.0.0.1:1081" # Necessary. The address of the service that needs to be forwarded
nodelay = true # Optional. Override the `client.transport.nodelay` per service
retry_interval = 1 # Optional. The interval between retry to connect to the server. Default: inherits the global config

[client.services.service2] # Multiple services can be defined
local_addr = "127.0.0.1:1082"

[server]
bind_addr = "0.0.0.0:2333" # Necessary. The address that the server listens for clients. Generally only the port needs to be change.
default_token = "default_token_if_not_specify" # Optional
heartbeat_interval = 30 # Optional. The interval between two application-layer heartbeat. Set to 0 to disable sending heartbeat. Default: 30 seconds

[server.transport] # Same as `[client.transport]`
type = "tcp"

[server.transport.tcp] # Same as the client
nodelay = true
keepalive_secs = 20
keepalive_interval = 8

[server.transport.tls] # Necessary if `type` is "tls"
pkcs12 = "identify.pfx" # Necessary. pkcs12 file of server's certificate and private key
pkcs12_password = "password" # Necessary. Password of the pkcs12 file

[server.transport.noise] # Same as `[client.transport.noise]`
pattern = "Noise_NK_25519_ChaChaPoly_BLAKE2s"
local_private_key = "key_encoded_in_base64"
remote_public_key = "key_encoded_in_base64"

[server.transport.websocket] # Necessary if `type` is "websocket"
tls = true # If `true` then it will use settings in `server.transport.tls`

[server.services.service1] # The service name must be identical to the client side
type = "tcp" # Optional. Same as the client `[client.services.X.type]
token = "whatever" # Necessary if `server.default_token` not set
bind_addr = "0.0.0.0:8081" # Necessary. The address of the service is exposed at. Generally only the port needs to be change.
nodelay = true # Optional. Same as the client

[server.services.service2]
bind_addr = "0.0.0.1:8082"

Registo de Log

O rathole, como muitos outros programas Rust, utiliza variáveis de ambiente para controlar o nível de registo. Estão disponíveis info, warn, error, debug, trace.

root@kitploit:~
RUST_LOG=error ./rathole config.toml

executará o rathole apenas com registo ao nível de erro.

Se RUST_LOG não estiver presente, o nível de registo predefinido é info.

Ajuste

A partir da v0.4.7, o rathole ativa TCP_NODELAY por predefinição, o que deve beneficiar a latência e aplicações interativas como rdp, servidores Minecraft. No entanto, diminui ligeiramente a largura de banda.

Se a largura de banda for mais importante, TCP_NODELAY pode ser desativado com nodelay = false.

Benchmark

O rathole tem latência semelhante ao frp, mas pode lidar com mais conexões, fornecer maior largura de banda, com menos uso de memória.

Para mais detalhes, consulte a página separada Benchmark.

No entanto, não conclua daqui que o rathole pode magicamente tornar o seu serviço reencaminhado várias vezes mais rápido do que antes. O benchmark é feito em loopback local, indicando o desempenho quando a tarefa está limitada pela CPU. Pode-se obter uma melhoria considerável se a rede não for o gargalo. Infelizmente, isso não é verdade para muitos utilizadores. Nesse caso, o principal benefício é o menor consumo de recursos, enquanto a largura de banda e a latência podem não melhorar significativamente.

http_throughput tcp_bitrate udp_bitrate mem

Planeamento

  • APIs HTTP para configuração

Fora do Âmbito lista funcionalidades que não estão planeadas para ser implementadas e porquê.

Baixar ferramenta