rathole

Englisch | Vereinfachtes Chinesisch

Ein sicherer, stabiler und leistungsstarker Reverse-Proxy für NAT-Traversal, geschrieben in Rust

rathole kann, ähnlich wie frp und ngrok, dabei helfen, den Dienst auf einem Gerät hinter dem NAT über einen Server mit einer öffentlichen IP ins Internet zu bringen.

• rathole
  • Funktionen
  • Schnellstart
  • Konfiguration
    • Protokollierung
    • Optimierung
  • Benchmark
  • Planung

Funktionen

• Hohe Leistung Es kann ein deutlich höherer Durchsatz als bei frp erreicht werden, und es ist stabiler bei der Verarbeitung einer großen Anzahl von Verbindungen. Siehe Benchmark
• Geringer Ressourcenverbrauch Verbraucht viel weniger Speicher als ähnliche Werkzeuge. Siehe Benchmark. Die Binärdatei kann auf etwa 500 KiB verkleinert werden, um den Beschränkungen von Geräten wie Routern oder Embedded-Geräten zu entsprechen.
• Sicherheit Tokens für Dienste sind obligatorisch und dienstspezifisch. Server und Clients sind für ihre eigenen Konfigurationen verantwortlich. Mit dem optionalen Noise-Protokoll kann die Verschlüsselung problemlos konfiguriert werden. Es ist kein selbstsigniertes Zertifikat erforderlich! TLS wird ebenfalls unterstützt.
• Hot Reload Dienste können dynamisch durch Hot-Reload der Konfigurationsdatei hinzugefügt oder entfernt werden. HTTP-API ist in Arbeit.

Schnellstart

Ein vollwertiges rathole kann von der Release-Seite bezogen werden. Oder aus dem Quellcode erstellen für andere Plattformen und zum Minimieren der Binärdatei. Ein Docker-Image ist ebenfalls verfügbar.

Die Verwendung von rathole ist frp sehr ähnlich. Wenn Sie Erfahrung mit letzterem haben, ist die Konfiguration sehr einfach. Der einzige Unterschied besteht darin, dass die Konfiguration eines Dienstes in Client- und Server-Seite aufgeteilt ist und ein Token obligatorisch ist.

Um rathole zu verwenden, benötigen Sie einen Server mit einer öffentlichen IP und ein Gerät hinter dem NAT, auf dem einige Dienste laufen, die ins Internet freigegeben werden sollen.

Angenommen, Sie haben ein NAS zu Hause hinter dem NAT und möchten dessen SSH-Dienst ins Internet freigeben:

1. Auf dem Server mit einer öffentlichen IP

Erstellen Sie server.toml mit folgendem Inhalt und passen Sie ihn entsprechend an.

# server.toml
[server]
bind_addr = "0.0.0.0:2333" # `2333` gibt den Port an, auf dem rathole auf Clients hört

[server.services.my_nas_ssh]
token = "use_a_secret_that_only_you_know" # Token zur Authentifizierung des Clients für den Dienst. Ändern Sie es auf einen beliebigen Wert.
bind_addr = "0.0.0.0:5202" # `5202` gibt den Port an, der `my_nas_ssh` für das Internet freigibt

Dann ausführen:

./rathole server.toml

2. Auf dem Host hinter dem NAT (Ihr NAS)

Erstellen Sie client.toml mit folgendem Inhalt und passen Sie ihn entsprechend an.

# client.toml
[client]
remote_addr = "myserver.com:2333" # Die Adresse des Servers. Der Port muss mit dem Port in `server.bind_addr` übereinstimmen

[client.services.my_nas_ssh]
token = "use_a_secret_that_only_you_know" # Muss mit dem Server übereinstimmen, um die Validierung zu bestehen
local_addr = "127.0.0.1:22" # Die Adresse des Dienstes, der weitergeleitet werden soll

Dann ausführen:

./rathole client.toml

3. Nun wird der Client versuchen, sich mit dem Server myserver.com auf Port 2333 zu verbinden, und jeglicher Datenverkehr zu myserver.com:5202 wird an den Client-Port 22 weitergeleitet.

Sie können also ssh myserver.com:5202 verwenden, um sich per SSH mit Ihrem NAS zu verbinden.

Um rathole als Hintergrunddienst unter Linux auszuführen, finden Sie die systemd-Beispiele.

Konfiguration

rathole kann automatisch erkennen, ob es im Server- oder Client-Modus ausgeführt werden soll, basierend auf dem Inhalt der Konfigurationsdatei, wenn nur einer der Blöcke [server] und [client] vorhanden ist, wie im Beispiel im Schnellstart.

Die Blöcke [client] und [server] können jedoch auch in einer Datei zusammengefasst werden. Führen Sie dann auf der Serverseite rathole --server config.toml und auf der Clientseite rathole --client config.toml aus, um rathole den Ausführungsmodus explizit mitzuteilen.

Bevor Sie zur vollständigen Konfigurationsspezifikation übergehen, empfiehlt es sich, die Konfigurationsbeispiele zu überfliegen, um ein Gefühl für das Format der Konfiguration zu bekommen.

Weitere Details zur Verschlüsselung und zum transport-Block finden Sie unter Transport.

Hier ist die vollständige Konfigurationsspezifikation:

[client]
remote_addr = "example.com:2333" # Notwendig. Die Adresse des Servers
default_token = "default_token_if_not_specify" # Optional. Das Standard-Token für Dienste, falls diese kein eigenes definieren
heartbeat_timeout = 40 # Optional. Auf 0 setzen, um den Heartbeat-Test auf Anwendungsebene zu deaktivieren. Der Wert muss größer als `server.heartbeat_interval` sein. Standard: 40 Sekunden
retry_interval = 1 # Optional. Das Intervall zwischen erneuten Verbindungsversuchen zum Server. Standard: 1 Sekunde

[client.transport] # Der gesamte Block ist optional. Gibt an, welcher Transport verwendet werden soll
type = "tcp" # Optional. Mögliche Werte: ["tcp", "tls", "noise"]. Standard: "tcp"

[client.transport.tcp] # Optional. Wirkt sich auch auf `noise` und `tls` aus
proxy = "socks5://user:[email protected]:1080" # Optional. Der Proxy, der zur Verbindung mit dem Server verwendet wird. `http` und `socks5` werden unterstützt.
nodelay = true # Optional. Legt fest, ob TCP_NODELAY aktiviert werden soll, falls zutreffend, um die Latenz zu verbessern, aber die Bandbreite zu verringern. Standard: true
keepalive_secs = 20 # Optional. Gibt `tcp_keepalive_time` in `tcp(7)` an, falls zutreffend. Standard: 20 Sekunden
keepalive_interval = 8 # Optional. Gibt `tcp_keepalive_intvl` in `tcp(7)` an, falls zutreffend. Standard: 8 Sekunden