
NAT traversal के लिए एक हल्का और उच्च-प्रदर्शन वाला रिवर्स प्रॉक्सी, Rust में लिखा गया। frp और ngrok का एक विकल्प।

NAT ट्रैवर्सल के लिए एक सुरक्षित, स्थिर और उच्च-प्रदर्शन वाला रिवर्स प्रॉक्सी, Rust में लिखा गया
rathole, frp और ngrok की तरह, सार्वजनिक IP वाले सर्वर के माध्यम से NAT के पीछे के डिवाइस पर सेवा को इंटरनेट पर एक्सपोज़ करने में मदद कर सकता है।
पूर्ण-शक्ति वाला rathole रिलीज़ पृष्ठ से प्राप्त किया जा सकता है। या अन्य प्लेटफ़ॉर्म के लिए और बाइनरी को छोटा करने के लिए स्रोत से बनाएँ। Docker छवि भी उपलब्ध है।
rathole का उपयोग frp के समान है। यदि आपको बाद का अनुभव है, तो कॉन्फ़िगरेशन आपके लिए बहुत आसान है। एकमात्र अंतर यह है कि एक सेवा का कॉन्फ़िगरेशन क्लाइंट पक्ष और सर्वर पक्ष में विभाजित है, और एक टोकन अनिवार्य है।
rathole का उपयोग करने के लिए, आपको एक सार्वजनिक IP वाले सर्वर की आवश्यकता है, और NAT के पीछे एक डिवाइस, जहाँ कुछ सेवाएँ हैं जिन्हें इंटरनेट पर एक्सपोज़ करने की आवश्यकता है।
मान लें कि आपके पास NAT के पीछे घर पर एक NAS है, और आप इसकी ssh सेवा को इंटरनेट पर एक्सपोज़ करना चाहते हैं:
निम्नलिखित सामग्री के साथ 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
निम्नलिखित सामग्री के साथ 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
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`
[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"
rathole, कई अन्य Rust प्रोग्रामों की तरह, लॉगिंग स्तर को नियंत्रित करने के लिए पर्यावरण चर का उपयोग करता है। info, warn, error, debug, trace उपलब्ध हैं।
RUST_LOG=error ./rathole config.toml
यह केवल त्रुटि स्तर लॉगिंग के साथ rathole चलाएगा।
यदि RUST_LOG मौजूद नहीं है, तो डिफ़ॉल्ट लॉगिंग स्तर info है।
v0.4.7 से, rathole डिफ़ॉल्ट रूप से TCP_NODELAY सक्षम करता है, जो विलंबता और रिमोट डेस्कटॉप प्रोटोकॉल (rdp), Minecraft सर्वर जैसे इंटरैक्टिव अनुप्रयोगों को लाभ पहुँचाना चाहिए। हालाँकि, यह बैंडविड्थ को थोड़ा कम करता है।
यदि बैंडविड्थ अधिक महत्वपूर्ण है, तो nodelay = false के साथ TCP_NODELAY को हटाया जा सकता है।
rathole की विलंबता frp के समान है, लेकिन कम मेमोरी उपयोग के साथ अधिक कनेक्शनों को संभाल सकता है और अधिक बैंडविड्थ प्रदान कर सकता है।
अधिक जानकारी के लिए, अलग पृष्ठ बेंचमार्क देखें।
हालाँकि, यहाँ से यह न समझें कि rathole जादुई रूप से आपकी अग्रेषित सेवा को पहले से कई गुना तेज़ कर सकता है। बेंचमार्क स्थानीय लूपबैक पर किया गया है, जो प्रदर्शन को इंगित करता है जब कार्य CPU-बाउंड होता है। यदि नेटवर्क बाधा नहीं है तो कोई काफी सुधार प्राप्त कर सकता है। दुर्भाग्य से, यह कई उपयोगकर्ताओं के लिए सही नहीं है। उस स्थिति में, मुख्य लाभ कम संसाधन खपत है, जबकि बैंडविड्थ और विलंबता में महत्वपूर्ण सुधार नहीं हो सकता है।

दायरे से बाहर उन सुविधाओं को सूचीबद्ध करता है जिन्हें लागू करने की योजना नहीं है और क्यों।