Tailscale Peer Relays: अपने डिवाइस को हाई-स्पीड रिले के रूप में इस्तेमाल करें

 (tailscale.com)
2 पॉइंट द्वारा GN⁺ 2026-02-19 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Tailscale Peer Relays अब औपचारिक रूप से उपलब्ध है, जिससे उपयोगकर्ता अपने डिवाइस को हाई-परफॉर्मेंस रिले नोड के रूप में इस्तेमाल कर सकते हैं
  • फ़ायरवॉल, NAT, क्लाउड नेटवर्क सीमाओं जैसी परिस्थितियों में, जहाँ direct connection मुश्किल हो, वहाँ भी स्थिर और तेज़ ट्रैफ़िक रिलेइंग को सपोर्ट करता है
  • थ्रूपुट सुधार, lock contention में कमी, और UDP sockets का वितरित प्रोसेसिंग के कारण कई clients के कनेक्ट होने पर performance में बड़ा सुधार होता है
  • static endpoint integration के ज़रिए, auto-discovery संभव न होने वाले क्लाउड environments में भी AWS NLB आदि के पीछे रिले चलाना संभव है
  • visibility और monitoring integration के साथ ट्रैफ़िक path, latency, और relay status को स्पष्ट रूप से समझा जा सकता है, जो बड़े नेटवर्क ऑपरेशंस के लिए महत्वपूर्ण है

Tailscale Peer Relays का अवलोकन

  • Peer Relays एक ऐसा फीचर है जो अपने डिवाइस पर हाई-परफॉर्मेंस रिले फ़ंक्शन चलाने की सुविधा देता है
    • मौजूदा DERP relays के अलावा, उपयोगकर्ता अपने द्वारा deploy किए गए nodes को भी relay के रूप में इस्तेमाल कर सकते हैं
    • beta के बाद performance, stability, और visibility में बड़े सुधार हुए हैं, और यह production स्तर तक पहुँच चुका है
  • यह फीचर जटिल NAT environments को bypass करने के लिए शुरू हुआ था, लेकिन अब बड़े नेटवर्क कनेक्टिविटी विकल्प के रूप में विस्तृत हो चुका है
    • यह teams को performance, control, और flexibility सुनिश्चित करने वाली संरचना देता है

performance और reliability में सुधार

  • जब कई clients relay के माध्यम से connect होते हैं, तो थ्रूपुट में बड़ा सुधार होता है
    • clients relay के भीतर सबसे उपयुक्त interface और address family को अपने-आप चुन लेते हैं
    • relay lock contention में कमी और multiple UDP sockets के distributed processing के ज़रिए packet processing efficiency बढ़ाता है
  • इन सुधारों से रोज़मर्रा के ट्रैफ़िक में भी performance और stability बेहतर होती है, और direct connection संभव न होने पर भी mesh network के क़रीब performance मिलता है

static endpoint support

  • public cloud environments में auto endpoint discovery कई बार मुश्किल होती है
    • firewall rules, port forwarding, और load balancer जैसी वजहों से मनचाहे ports खोलना संभव नहीं होता
  • Peer Relays --relay-server-static-endpoints फ़्लैग के माध्यम से fixed IP:port pairs को advertise कर सकता है
    • AWS Network Load Balancer जैसी infrastructure के पीछे होने पर भी external clients relay के ज़रिए traffic forward कर सकते हैं
  • इस फीचर से सीमित cloud environments में भी हाई-स्पीड कनेक्शन सुनिश्चित किया जा सकता है, और subnet router को replace करके full mesh configuration संभव हो जाती है

visibility और monitoring integration

  • Peer Relays Tailscale के observability tools के साथ सीधे integrated है, जिससे relay behavior को स्पष्ट रूप से समझा जा सकता है
    • tailscale ping कमांड से यह देखा जा सकता है कि relay इस्तेमाल हो रहा है या नहीं, reachability क्या है, और latency व reliability पर उसका क्या असर है
    • समस्या होने पर तुरंत पता लगाया जा सकता है कि traffic relay से गुजर रहा है या नहीं, और relay की स्थिति सामान्य है या नहीं
  • monitoring metrics के रूप में tailscaled_peer_relay_forwarded_packets_total, tailscaled_peer_relay_forwarded_bytes_total उपलब्ध हैं
    • Prometheus, Grafana आदि के साथ जोड़कर traffic pattern analysis, anomaly detection, और network status monitoring संभव है

सामान्य उपलब्धता और deployment मॉडल

  • औपचारिक रूप से जारी Peer Relays अब Tailscale scalability का एक मुख्य घटक बन गया है
    • direct path संभव न होने पर हाई-स्पीड और low-latency connectivity देता है
    • static endpoint आधारित deployment के कारण सीमित cloud environments में भी काम करता है
    • private subnets में full mesh configuration और ingress/egress control paths सेट करना सपोर्ट करता है
  • end-to-end encryption, least-privilege access, और predictable behavior जैसे Tailscale के मूल security principles बरकरार रहते हैं
  • CLI के माध्यम से सभी supported nodes पर इसे enable किया जा सकता है, और ACL आधारित नियंत्रण व gradual rollout को सपोर्ट करता है
  • Peer Relays सभी plans, including free Personal plan, में उपलब्ध है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2026-02-19
Hacker News टिप्पणियाँ

  • अगर Tailscale पर इसलिए भरोसा किया जाता है कि यह “open” है, तो यह भी जानना चाहिए कि इसके कुछ clients proprietary हैं
    इन्हें सिर्फ आधिकारिक distribution channels (जैसे Apple App Store) के ज़रिए वितरित किया जाता है, और ये पूरी तरह उनके नियंत्रण में हैं
    इस रुख को सही ठहराने की दलील अजीब है: “अगर उपयोगकर्ता के लिए proprietary OS इस्तेमाल करना ठीक है, तो Tailscale का proprietary होना भी ठीक है” जैसी बात
    ऐसी संरचना पर सीमित connectivity वाले environments में भरोसा करना मुश्किल है
    तकनीकी रूप से यह competitors से बेहतर हो सकता है, लेकिन अंत में यह business ही है। संभव हो तो free software alternatives का समर्थन करना चाहिए
    संबंधित GitHub issue

    • मैं यह स्पष्ट करना चाहता हूँ कि कुछ platforms पर सिर्फ GUI proprietary है (Tailscalar)
    • मेरे लिए performance से ज़्यादा control महत्वपूर्ण है
      अगर उपयोगकर्ता source से सीधे build कर सकते हैं, तो performance improvements भी संभव हैं, लेकिन control न हो तो असंतोषजनक हिस्सों को ठीक करने का कोई तरीका नहीं रहता
      commercial software अक्सर कम गुणवत्ता वाला होता है, updates पर निर्भर रहता है, और completeness से ज़्यादा release speed को प्राथमिकता देता है
    • macOS के लिए CLI client source से सीधे build किया जा सकता है
      इसे go install tailscale.com/cmd/tailscale{,d}@latest कमांड से install किया जा सकता है, और official wiki में इसका विवरण है
      GUI proprietary है, लेकिन CLI पूरी तरह open है, इसलिए restricted network environments में भी इस्तेमाल किया जा सकता है
    • ज़्यादातर Mac apps proprietary ही होते हैं, इसलिए Tailscale का एक menubar icon मुझे परेशान नहीं करता
      अगर सच में असुविधा हो, तो brew या CLI से control कर सकते हैं
    • मुझे लगता है open source और commercial का hybrid model एक व्यावहारिक समझौता है
      मैं भी इसी तरह की संरचना वाला एक app बना रहा हूँ, जिसमें CLI पूरी तरह open source होगा और GUI paid रूप में बेचा जाएगा
      इससे development जारी रखा जा सकता है और जीविका भी चल सकती है
      मैं validate library के आधार पर GUI और CLI साथ में विकसित कर रहा हूँ

  • मैंने हाल ही में Tailscale सेट किया, और ping 16ms से घटकर 10ms हो गया तथा bandwidth तीन गुना बढ़ गई
    Moonlight/Sunshine के साथ इस्तेमाल करने पर MacBook से Linux desktop पर Windows games को 50Mbps/10ms पर stream करना संभव हुआ
    port forwarding के बिना, सिर्फ router को peer node के रूप में सेट किया

    • Sunshine के संदर्भ में Apollo आज़माने लायक हो सकता है
    • यह दिलचस्प use case है, लेकिन असल में यह NAT traversal और port forwarding को एक automated protocol के हवाले करना है
    • अगर game streaming को सामान्य उपयोगकर्ताओं के लिए public करना हो, तो क्या सामने वाले को भी Tailscale install करना पड़ेगा?
      मैं जानना चाहता हूँ कि क्या Tailscale मूल रूप से विश्वसनीय उपयोगकर्ताओं के बीच sharing पर केंद्रित है
    • मैंने OpenWRT router के साथ ऐसा ही setup करने की कोशिश की थी, लेकिन मुझे लगा कि फिर भी ports खोलने पड़ेंगे
      अगर ऐसा है, तो क्या यह अब भी internet पर exposed नहीं रहेगा? यही भ्रम है

  • मैं Tailscale के revenue model को लेकर जिज्ञासु हूँ। सेवा पसंद है, लेकिन long-term sustainability की चिंता होती है
    कभी-कभी rate limit लगने जैसा महसूस होता है

    • हमारी कंपनी business plan इस्तेमाल कर रही है, जिसकी कीमत $18/यूज़र प्रति माह है
      टीम का आकार बढ़ने पर paid plan ज़रूरी हो जाता है, और serve/funnel, SSH जैसी सुविधाएँ उपयोगी हैं
      पहले हम Zerotier इस्तेमाल करते थे, और कई साल free में उपयोग करने के बाद उपयोगकर्ता बढ़ने पर सिर्फ लगभग $5 प्रति माह चुकाते थे
    • मूल रूप से Tailscale शुरुआती connection के बाद P2P WireGuard connection बनाता है, इसलिए rate limit नहीं होनी चाहिए
      हालांकि network environment के अनुसार relay की ज़रूरत पड़ सकती है
      open source alternatives में Headscale और Netbird हैं
    • official blog की free plan explanation देखने लायक है
    • यह उस freemium model का एक सामान्य उदाहरण है जिसमें पहले developer free plan से लोकप्रियता मिलती है, फिर कंपनियाँ paid plan में convert होती हैं
    • क्योंकि P2P connection की लागत लगभग नहीं के बराबर होती है, इसलिए free tier के ज़रिए developer loyalty बढ़ाने की रणनीति प्रभावी है

  • Peer Relay पर स्विच होना NAT environments में self-hosters के लिए बड़ी जीत है
    अब खुद DERP server सेट करने की ज़रूरत नहीं, इसलिए UX बेहतर हुआ है

    • (Tailscale कर्मचारी Alex) हमें भी यही समस्या हुई थी
      Peer Relay को मौजूदा subnet router और exit node infrastructure का reuse करके लागू किया गया, इसलिए implementation burden ज़्यादा नहीं था
      AWS जैसे सीमित NAT environments में stable connection के लिए यह ज़रूरी है
      नतीजतन latency और user experience दोनों बेहतर हुए
    • पहले central DERP traffic को black hole की तरह निगल लेने की समस्या थी, लेकिन हाल में यह स्थिर रहा है
      Peer Relay आने से ऐसी समस्या की संभावना और कम होगी

  • Peer Relay का UDP support होना मुख्य बात है
    DERP TCP-आधारित है, इसलिए game streaming या voice communication में latency की समस्या थी
    Peer Relay UDP का उपयोग करता है, इसलिए यह real-time traffic के लिए कहीं अधिक उपयुक्त है
    अलग DERP instance सेट किए बिना, मौजूदा subnet router पर ही इसे सीधे enable किया जा सकता है

    • लेकिन नए accounts से लगातार positive comments आना, और उनमें से कुछ पर Tailscale कर्मचारियों का जवाब देना, यह AI-आधारित PR जैसा लगता है
      इस तरह के AI comments community trust को नुकसान पहुँचाते हैं, इसलिए इन्हें टाला जाना चाहिए

  • जब कई Relay हों, तो क्या Tailscale अपने आप सबसे कम latency वाले node का चयन करता है?

  • वास्तविक CGNAT environment में Tailscale बहुत मददगार रहा
    मैं Google Cloud Run पर AI vision system चला रहा हूँ, और ISP port forwarding को block कर रहा था
    Tailscale की मदद से Cloud Run container और camera एक ही LAN की तरह communicate कर सके
    Peer Relay की वजह से container के बार-बार restart होने पर आने वाली latency समस्या भी कम होने की उम्मीद है
    हालांकि, ephemeral nodes वाले environment में Relay selection कैसे काम करता है, यह जानना चाहूँगा

  • मैं पहले से खुद configured WireGuard network इस्तेमाल कर रहा हूँ, और जानना चाहता हूँ कि Tailscale अंदरूनी तौर-तरीके से क्या करता है
    DNS, routing, firewall आदि को अपने आप adjust करने वाली बहुत सी “magic” सुविधाएँ हैं, जो मुझे असहज करती हैं
    मैंने official docs देखे, लेकिन उनमें विस्तार कम है
    मैं जानना चाहता हूँ कि क्या यह जटिल network setups में भी अच्छी तरह काम करता है

    • (Tailscale कर्मचारी) पूर्ण documentation बनाए रखना कठिन है, लेकिन हम जहाँ तक संभव हो environment-adaptive heuristics को document करने की कोशिश करते हैं
      Linux में अलग-अलग configuration patterns होने के कारण यह जटिल है
      इसका विवरण संबंधित blog post में भी है
      मुख्य व्यवहार इस प्रकार हैं
      • टकराव से बचने के लिए rule-based routing
      • पहले systemd-resolved के साथ integration, और अगर वह न हो तो /etc/resolv.conf में बदलाव
      • iptables और nftables दोनों का support, और ufw/firewalld के साथ compatibility बनाए रखने वाला configuration
      • SSH login को distribution-specific अंतर ध्यान में रखकर अधिकतम compatible तरीके से implement किया गया है
      • स्थिर communication के लिए 1360-byte MTU path की आवश्यकता
        बहुत अधिक custom environments में समस्या आ सकती है, लेकिन support के ज़रिए इसे हल किया जा सकता है
    • client open source है, और कुछ कर्मचारी Headscale जैसे reverse-engineering servers में भी योगदान देते हैं
    • Headscale एक open source alternative के रूप में देखने लायक है

  • मैंने mobile पर पेज खोला, लेकिन close button दिखा नहीं, इसलिए modal बंद नहीं कर पाया
    screenshot देखें
    बाद में मिल गया, लेकिन उसकी position अजीब थी

    • modal के नीचे दाईं तरफ नीले बॉक्स के अंदर सफेद X button ही close button है