rathole

English | 简体中文

NAT ट्रैवर्सल के लिए एक सुरक्षित, स्थिर और उच्च-प्रदर्शन वाला रिवर्स प्रॉक्सी, Rust में लिखा गया

rathole, frp और ngrok की तरह, सार्वजनिक IP वाले सर्वर के माध्यम से NAT के पीछे के डिवाइस पर सेवा को इंटरनेट पर एक्सपोज़ करने में मदद कर सकता है।

• rathole
  • सुविधाएँ
  • त्वरित आरंभ
  • कॉन्फ़िगरेशन
    • लॉगिंग
    • ट्यूनिंग
  • बेंचमार्क
  • योजना

सुविधाएँ

• उच्च प्रदर्शन frp की तुलना में कहीं अधिक थ्रूपुट प्राप्त किया जा सकता है, और बड़ी संख्या में कनेक्शनों को संभालते समय अधिक स्थिर रहता है। बेंचमार्क देखें।
• कम संसाधन खपत समान टूल्स की तुलना में बहुत कम मेमोरी की खपत करता है। बेंचमार्क देखें। बाइनरी को लगभग ~500KiB जितना छोटा बनाया जा सकता है ताकि राउटर जैसे एम्बेडेड डिवाइसों की सीमाओं में फिट हो सके।
• सुरक्षा सेवाओं के टोकन अनिवार्य हैं और सेवा-वार हैं। सर्वर और क्लाइंट अपने स्वयं के कॉन्फ़िगरेशन के लिए जिम्मेदार हैं। वैकल्पिक Noise Protocol के साथ, एन्क्रिप्शन को आसानी से कॉन्फ़िगर किया जा सकता है। स्व-हस्ताक्षरित प्रमाणपत्र बनाने की कोई आवश्यकता नहीं! TLS भी समर्थित है।
• हॉट रीलोड कॉन्फ़िगरेशन फ़ाइल को हॉट-रीलोड करके सेवाओं को गतिशील रूप से जोड़ा या हटाया जा सकता है। HTTP API कार्य प्रगति पर है।

त्वरित आरंभ

पूर्ण-शक्ति वाला rathole रिलीज़ पृष्ठ से प्राप्त किया जा सकता है। या अन्य प्लेटफ़ॉर्म के लिए और बाइनरी को छोटा करने के लिए स्रोत से बनाएँ। Docker छवि भी उपलब्ध है।

rathole का उपयोग frp के समान है। यदि आपको बाद का अनुभव है, तो कॉन्फ़िगरेशन आपके लिए बहुत आसान है। एकमात्र अंतर यह है कि एक सेवा का कॉन्फ़िगरेशन क्लाइंट पक्ष और सर्वर पक्ष में विभाजित है, और एक टोकन अनिवार्य है।

rathole का उपयोग करने के लिए, आपको एक सार्वजनिक IP वाले सर्वर की आवश्यकता है, और NAT के पीछे एक डिवाइस, जहाँ कुछ सेवाएँ हैं जिन्हें इंटरनेट पर एक्सपोज़ करने की आवश्यकता है।

मान लें कि आपके पास NAT के पीछे घर पर एक NAS है, और आप इसकी ssh सेवा को इंटरनेट पर एक्सपोज़ करना चाहते हैं:

1. सार्वजनिक IP वाले सर्वर पर

निम्नलिखित सामग्री के साथ server.toml बनाएँ और इसे अपनी आवश्यकता के अनुसार अनुकूलित करें।

# server.toml
[server]
bind_addr = "0.0.0.0:2333" # `2333` वह पोर्ट निर्दिष्ट करता है जिस पर rathole क्लाइंट के लिए सुनता है

[server.services.my_nas_ssh]
token = "use_a_secret_that_only_you_know" # सेवा के लिए क्लाइंट को प्रमाणित करने के लिए उपयोग किया जाने वाला टोकन। एक मनमाना मान में बदलें।
bind_addr = "0.0.0.0:5202" # `5202` वह पोर्ट निर्दिष्ट करता है जो `my_nas_ssh` को इंटरनेट पर एक्सपोज़ करता है

फिर चलाएँ:

./rathole server.toml

2. NAT के पीछे वाले होस्ट पर (आपका NAS)

निम्नलिखित सामग्री के साथ client.toml बनाएँ और इसे अपनी आवश्यकता के अनुसार अनुकूलित करें।

# client.toml
[client]
remote_addr = "myserver.com:2333" # सर्वर का पता। पोर्ट `server.bind_addr` में पोर्ट के समान होना चाहिए

[client.services.my_nas_ssh]
token = "use_a_secret_that_only_you_know" # मान्यता पास करने के लिए सर्वर के समान होना चाहिए
local_addr = "127.0.0.1:22" # उस सेवा का पता जिसे आगे भेजने की आवश्यकता है

फिर चलाएँ:

./rathole client.toml

3. अब क्लाइंट पोर्ट 2333 पर सर्वर myserver.com से कनेक्ट करने का प्रयास करेगा, और myserver.com:5202 पर कोई भी ट्रैफ़िक क्लाइंट के पोर्ट 22 पर अग्रेषित किया जाएगा।

तो आप अपने NAS पर ssh करने के लिए ssh myserver.com:5202 कर सकते हैं।

Linux पर rathole को पृष्ठभूमि सेवा के रूप में चलाने के लिए, systemd उदाहरण देखें।

कॉन्फ़िगरेशन

rathole स्वचालित रूप से कॉन्फ़िगरेशन फ़ाइल की सामग्री के अनुसार सर्वर मोड या क्लाइंट मोड में चलने का निर्धारण कर सकता है, यदि केवल [server] या [client] ब्लॉक में से एक मौजूद है, जैसा कि त्वरित आरंभ में उदाहरण है।

लेकिन [client] और [server] ब्लॉक को एक फ़ाइल में भी रखा जा सकता है। फिर सर्वर पक्ष पर, rathole --server config.toml चलाएँ और क्लाइंट पक्ष पर, rathole --client config.toml चलाएँ ताकि rathole को स्पष्ट रूप से रनिंग मोड बताया जा सके।

पूर्ण कॉन्फ़िगरेशन विनिर्देश पर जाने से पहले, कॉन्फ़िगरेशन प्रारूप की समझ पाने के लिए कॉन्फ़िगरेशन उदाहरण को देखने की अनुशंसा की जाती है।

एन्क्रिप्शन और transport ब्लॉक के बारे में अधिक जानकारी के लिए परिवहन देखें।

यहाँ पूर्ण कॉन्फ़िगरेशन विनिर्देश है:

[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`