Tailscale serve और Funnel में क्या अंतर है?

tailscale serve बनाम funnel: URL तक कौन पहुँच सकता है

tailscale serve और tailscale funnel के बीच का अंतर केवल दर्शकों का है, और कुछ नहीं। serve एक लोकल पोर्ट पर HTTPS (hypertext transfer protocol secure) फ्रंट एंड लगाता है और इसे केवल आपके tailnet पर प्रकाशित करता है। funnel उसी लोकल पोर्ट को Tailscale द्वारा संचालित रिले सर्वर के माध्यम से पूरे सार्वजनिक इंटरनेट पर प्रकाशित करता है। दोनों कमांड समान फ्लैग और समान टारगेट लेते हैं। एक निजी डैशबोर्ड और दुनिया के लिए सुलभ डैशबोर्ड के बीच केवल एक शब्द का अंतर है।

दोनों आपको एक ऐसा सर्टिफिकेट देते हैं जिस पर ब्राउज़र पहले से भरोसा करते हैं, जो ts.net पर समाप्त होने वाले नाम पर होता है, और किसी को भी आपके VPS फायरवॉल पर इनबाउंड पोर्ट खोलने की आवश्यकता नहीं होती है। आपका tailscaled डेमन पहले से ही tailnet से कनेक्शन बनाए रखता है, इसलिए ट्रैफ़िक उसी के माध्यम से आता है। किसी सर्वर को tailnet पर लाना एक अलग कार्य है, और VPS को Tailscale exit node के रूप में चलाना या निजी नेटवर्क के लिए subnet router का विज्ञापन करना उस कार्य को पूरा करते हैं। जो सर्विस पहले से ही tailnet पर है, उसे प्रकाशित करना यह कार्य है।

किसी भी कमांड के काम करने से पहले आपको क्या चाहिए

• VPS पर Tailscale 1.38.3 या उससे नया वर्ज़न, जो आपके tailnet में लॉग इन हो। इसे tailscale version और tailscale status के साथ चेक करें।
• MagicDNS सक्षम होना चाहिए। MagicDNS, Tailscale का इन-बिल्ट DNS (डोमेन नेम सिस्टम) है, और यही मशीन को केवल 100.x पते के बजाय blog-vps.your-tailnet.ts.net जैसा नाम देता है।
• एडमिन कंसोल के DNS पेज पर, tailnet के लिए HTTPS सर्टिफिकेट सक्षम होने चाहिए। इसके बिना आपके पोर्ट के सामने लगाने के लिए कोई सर्टिफिकेट नहीं होगा।
• केवल funnel के लिए, tailnet पॉलिसी फ़ाइल में funnel नोड एट्रिब्यूट होना चाहिए। अधिकांश लोग पहली बार में यहीं अटकते हैं, और इसे नीचे समझाया गया है।

यहाँ हर कमांड sudo से शुरू होती है, क्योंकि CLI, tailscaled से एक ऐसे सॉकेट के माध्यम से बात करती है जिसे केवल root ही लिख सकता है। किसी एक यूजर को इसे छोड़ने का अधिकार दें:

sudo tailscale set --operator=$USER

Tailscale serve के साथ अपनी tailnet पर पब्लिश करें

serve को एक local port पर पॉइंट करें और बाकी काम यह खुद कर लेगा।

sudo tailscale serve 3000

Available within your tailnet:
https://amelie-workstation.pango-lin.ts.net

 |-- / proxy http://127.0.0.1:3000

Press Ctrl+C to exit.

साधारण 3000, http://127.0.0.1:3000 का संक्षिप्त रूप है। Tailscale मशीन के tailnet address के port 443 पर listen करता है, ts.net certificate के साथ TLS (transport layer security) को terminate करता है, और plain HTTP को आपके local port पर forward कर देता है। आपके application को यह जानने की आवश्यकता नहीं होती कि certificate मौजूद है, और यही मुख्य कारण है कि आप इसे ऐसे admin panel के सामने उपयोग करते हैं जिसे आप अन्यथा plain HTTP पर छोड़ देते। एक web UI जो केवल 127.0.0.1 पर bind होता है, वह इसका स्पष्ट उदाहरण है, और port 3080 पर dsh Web UI इसका एक अच्छा उदाहरण है: हर बार SSH tunnel खोलने के बजाय, serve को एक बार 3080 पर पॉइंट करें और tailnet पर मौजूद किसी भी device से इसे एक्सेस करें।

अब अंतिम पंक्ति पढ़ें: Press Ctrl+C to exit. यह command foreground में चलती है, और mapping उस process के भीतर ही रहती है। terminal बंद करें और URL काम करना बंद कर देगा, क्योंकि disk पर कुछ भी नहीं लिखा गया था। --bg जोड़ें और mapping node के serve config में चली जाएगी, जो terminal बंद होने और reboot होने के बाद भी बनी रहती है।

sudo tailscale serve --bg 3000

Serve केवल port number से अधिक काम करता है। --set-path एक service को subpath के अंतर्गत mount करता है, ताकि कई apps एक ही hostname साझा कर सकें:

sudo tailscale serve --bg --set-path=/grafana 3000
sudo tailscale serve --bg --set-path=/metrics 9090

Target static files की एक directory भी हो सकती है, या ऐसा backend जो पहले से ही TLS का उपयोग करता है और आप नहीं चाहते कि उस certificate की जाँच हो:

sudo tailscale serve --bg /srv/reports
sudo tailscale serve --bg https+insecure://localhost:8443

यह केवल HTTP तक सीमित नहीं है। --tcp=<port> एक raw TCP (transmission control protocol) stream को forward करता है, और --tls-terminated-tcp=<port> आपके node पर TLS को समाप्त करके plaintext को आगे भेज देता है, जो एक trusted certificate को ऐसी service के सामने रखता है जो HTTP का उपयोग नहीं करती है:

sudo tailscale serve --bg --tls-terminated-tcp=443 tcp://127.0.0.1:9899

Funnel यह क्यों कहता है कि node attribute सेट नहीं है?

Funnel डिफ़ॉल्ट रूप से पूरे tailnet के लिए बंद रहता है। पहली बार चलाने पर यह संदेश दिखता है और प्रक्रिया रुक जाती है:

Funnel not available; "funnel" node attribute not set. See https://tailscale.com/kb/1223/tailscale-funnel/.

कमांड सही थी। tailnet policy ने इस node को publish करने की अनुमति नहीं दी है, इसलिए relay से संपर्क करने से पहले ही client इसे अस्वीकार कर देता है। admin console में Access Controls के अंतर्गत tailnet policy फ़ाइल को edit करें और यह attribute जोड़ें:

"nodeAttrs": [
  {
    "target": ["autogroup:member"],
    "attr":   ["funnel"],
  },
],

autogroup:member इसे tailnet के प्रत्येक सदस्य को अनुमति देता है। यदि केवल एक machine को ही publish करना चाहिए, तो उस machine को tag करें और उस tag को target करें, उदाहरण के लिए tag:public। Policy को save करें, फिर funnel कमांड को दोबारा चलाएँ।

यदि आपका account tailnet admin का है, तो हाल के clients एक शॉर्टकट प्रदान करते हैं: CLI, login.tailscale.com पर एक consent URL प्रिंट करता है, और उस पर जाने से HTTPS certificates सक्षम हो जाते हैं और यह attribute आपके लिए जुड़ जाता है। यदि आप admin नहीं हैं, तो वह URL आपकी मदद नहीं करेगा। किसी ऐसे व्यक्ति को, जिसके पास policy access है, यह बदलाव करना होगा।

Tailscale funnel के साथ इंटरनेट पर पब्लिश करें

एक बार attribute सेट हो जाने के बाद, कमांड वही है जिसे आप पहले से जानते हैं, बस इसमें verb अलग है।

sudo tailscale funnel --bg 3000

Available on the internet:
https://amelie-workstation.pango-lin.ts.net

 |-- / proxy http://127.0.0.1:3000

Press Ctrl+C to exit.

हर बार उस पहली लाइन को पढ़ें। Available within your tailnet और Available on the internet ही एक private service और public service के बीच एकमात्र दृश्य अंतर हैं, और उन्हें उत्पन्न करने वाली कमांड्स में केवल एक शब्द का अंतर होता है।

अगस्त 2026 तक, funnel केवल port 443, 8443 या 10000 पर listen करता है, किसी और पर नहीं। डिफ़ॉल्ट port 443 है, और --https=8443 या --https=10000 इसके विकल्प हैं। किसी अन्य port को अस्वीकार कर दिया जाता है, क्योंकि funnel relays केवल इन्हीं ports पर connections स्वीकार करते हैं। यही कारण है कि funnel URL हमेशा केवल hostname होता है, या फिर अंत में :8443 के साथ जुड़ा हुआ hostname होता है।

अभी क्या पब्लिश है, यह कैसे देखें?

अनुमान लगाने से ही डैशबोर्ड महीनों तक पब्लिक रह जाते हैं। इसके बजाय सीधे नोड से पूछें।

tailscale serve status
tailscale funnel status
tailscale serve status --json

दोनों status कमांड एक ही कॉन्फ़िगरेशन को पढ़ते हैं, इसलिए कोई भी एक कमांड आपको पूरी स्थिति दिखा देगा। स्क्रिप्ट या शेड्यूल किए गए चेक के अंदर --json फॉर्म का उपयोग करें, क्योंकि सामान्य आउटपुट इंसानों के पढ़ने के लिए लिखा गया है। जब कुछ भी कॉन्फ़िगर नहीं होता है, तो आपको एक लाइन दिखाई देगी:

No serve config

सेटअप के बाद इसे देखने का मतलब है कि मैपिंग फोरग्राउंड में बनाई गई थी और प्रोसेस अब समाप्त हो चुकी है। इसे --bg के साथ दोबारा बनाएँ।

एक मैपिंग को हटाने के लिए, उसे बनाने वाले कमांड को दोहराएँ और अंत में off लगाएँ। नोड पर सभी serve और funnel मैपिंग को हटाने के लिए, reset का उपयोग करें।

sudo tailscale funnel --https=443 3000 off
sudo tailscale serve reset

इनमें से किसी भी कमांड के बाद tailscale serve status को फिर से चलाएँ और देखें कि क्या बचा है, यह मानने के बजाय कि उसने वही किया जो आप चाहते थे।

आपको क्या मिलता है, और आप क्या छोड़ते हैं

इसके लाभ वास्तविक हैं, और यही कारण है कि लोग reverse proxy के बजाय इसे चुनते हैं।

• ब्राउज़र द्वारा विश्वसनीय certificate, जो आपके लिए स्वतः renew होता है। आपको कोई ACME (automatic certificate management environment) client install करने की आवश्यकता नहीं है, और न ही renewal job को याद रखने की।
• VPS firewall पर कोई inbound port खोलने की जरूरत नहीं है। tailscaled बाहर की ओर connection बनाता है, इसलिए आपके VPS पर default-deny ufw firewall पहले की तरह ही सुरक्षित रह सकता है।
• कोई DNS record खरीदने, point करने या उसके अपडेट होने का इंतज़ार करने की आवश्यकता नहीं है।
• कोई port forwarding नहीं, जो कि public IP वाले VPS के बजाय NAT (network address translation) के पीछे स्थित मशीन के लिए पूरी कहानी है।

इसकी सीमाएं भी उतनी ही वास्तविक हैं, और funnel में ये सभी शामिल हैं।

• domain नाम आपका नहीं है। सार्वजनिक आगंतुक host.your-tailnet.ts.net देखते हैं। Funnel में custom domain का समर्थन नहीं है, इसलिए आप इसके आगे app.example.com नहीं लगा सकते।
• path आपका नहीं है। traffic पहले Tailscale relay तक पहुँचता है, और relay उस stream को tailnet के माध्यम से आपके node तक proxy करता है। Tailscale का कहना है कि funnel traffic उन bandwidth सीमाओं के अधीन है जो प्रकाशित नहीं हैं और जिन्हें configure नहीं किया जा सकता है, इसलिए किसी संख्या पर निर्भर होने से पहले अपने throughput को स्वयं मापें।
• नियंत्रण का अभाव है। आपके द्वारा चलाए जाने वाले reverse proxy में आपको access logs, rate limits, request size caps और authentication लगाने की सुविधा मिलती है। Funnel आपको केवल एक URL देता है। बाकी सब कुछ आपके application के भीतर ही होना चाहिए।
• port की सूची निश्चित है, जैसा कि ऊपर बताया गया है।

दोनों सुविधाएँ उस infrastructure पर भी निर्भर करती हैं जिसे Tailscale संचालित करता है: ts.net नाम के लिए certificate issuance और स्वयं funnel relays। यह dependency आपको चिंतित करनी चाहिए या नहीं, यह इस बात पर निर्भर करता है कि वे servers आपके traffic के साथ क्या कर सकते हैं और क्या नहीं। यही बात Tailscale के trust model में स्पष्ट की गई है। इनमें से किसी सुविधा का उपयोग करने के लिए कोई शुल्क नहीं है, क्योंकि free plan में अधिकतम छह users शामिल हैं और प्रत्येक के लिए unlimited devices मिलते हैं। बाद में tailnet को paid plan पर ले जाने वाला कारक feature list नहीं, बल्कि seat count होता है। इसके बाद bill machines के बजाय users की संख्या के आधार पर आता है। इसलिए serve या funnel के load-bearing बनने से पहले paid plan पर tailnet की वास्तविक लागत जाँच लेना उचित है। यदि आप self-hosted Headscale control server पर विचार कर रहे हैं, तो यह न मानें कि इनमें से कोई सुविधा आपके साथ स्वतः उपलब्ध रहेगी। जिस Headscale version को चलाने की योजना है, उसके release notes जाँचें।

मुझे किसका उपयोग करना चाहिए?

नियम संक्षिप्त है।

आंतरिक उपयोग की किसी भी चीज़ के लिए serve का उपयोग करें: एडमिन इंटरफेस, डैशबोर्ड, ऐसी मेट्रिक्स UI जिसे आप इंडेक्स नहीं करवाना चाहते, या किसी साइट की स्टेजिंग कॉपी। Tailnet की सदस्यता ही एक्सेस कंट्रोल है, और यह एक प्रभावी तरीका है। जो डिवाइस Tailnet पर नहीं है, वह नाम को रिजॉल्व भी नहीं कर सकता।

डेमो लिंक, किसी ऐसे वेबहुक रिसीवर जिसे किसी थर्ड पार्टी को POST करना हो, या डेवलपमेंट के दौरान OAuth कॉलबैक के लिए funnel का उपयोग करें। यह पब्लिक HTTPS URL प्राप्त करने का सबसे तेज़ तरीका है, और एक off कमांड इसे समाप्त कर देती है। हालाँकि, पब्लिक का अर्थ पब्लिक ही है: होस्टनेम कोई गुप्त जानकारी नहीं है, और बिना लॉगिन वाली किसी ऐप के सामने फनल का मतलब एक ओपन सर्विस है। इसके पीछे जो भी सर्विस हो, उसे अपने अनुरोधों को स्वयं ऑथेंटिकेट करना चाहिए, उसी सावधानी के साथ जिसकी एक एक्सपोज्ड Ollama API endpoint को आवश्यकता होती है।

जिसे आप प्रोडक्शन कहेंगे, उसके लिए एक वास्तविक reverse proxy का उपयोग करें। आपका डोमेन, आपका सर्टिफिकेट, आपके लॉग्स, आपकी रेट लिमिट्स, और रिक्वेस्ट पाथ में आपके अलावा कोई और नहीं। nginx, Caddy और Traefik की reverse proxy के रूप में तुलना में यह बताया गया है कि किसी एक को कैसे चुनें।

विफलता के प्रकार और वे संदेश जो आपको दिखाई देंगे

Funnel शुरू होने से मना कर देता है। Funnel not available; "funnel" node attribute not set. एक पॉलिसी संबंधी समस्या है, कमांड संबंधी नहीं। tailnet पॉलिसी फ़ाइल में funnel एट्रिब्यूट जोड़ें, इसे सेव करें और पुनः प्रयास करें।

यह काम कर गया, और अब tailscale serve status कहता है No serve config। मैपिंग को फ़ोरग्राउंड में बनाया गया था और वह प्रक्रिया समाप्त हो गई। उसी कमांड को --bg के साथ दोबारा चलाएं।

नाम रिज़ॉल्व हो जाता है लेकिन कोई जवाब नहीं मिलता। Serve आपके द्वारा नामित लक्ष्य पर प्रॉक्सी करता है, इसलिए यदि वहां कुछ भी लिसन नहीं कर रहा है, तो प्रॉक्सी करने के लिए कुछ भी नहीं है। उसी मशीन पर ss -ltnp | grep 3000 के साथ पुष्टि करें जो tailscaled चलाती है। इसका सामान्य कारण यह है कि कोई कंटेनर अपने पोर्ट को 127.0.0.1 के बजाय Docker ब्रिज एड्रेस पर पब्लिश कर रहा है, जिसका अर्थ है कि होस्ट को वहां कोई लिसनर नहीं दिखता जहां आपने उम्मीद की थी। Docker Compose नेटवर्किंग कैसे काम करती है यह दिखाता है कि पब्लिश किया गया पोर्ट वास्तव में कहां जाता है।

ts.net नाम पर सर्टिफिकेट त्रुटियां। HTTPS सर्टिफिकेट संभवतः tailnet के लिए सक्षम नहीं हैं। उन्हें एडमिन कंसोल में चालू करें, फिर सर्टिफिकेट स्टेप को अलग से चलाएं ताकि इसकी त्रुटियां serve आउटपुट के साथ न उलझें:

sudo tailscale cert your-host.your-tailnet.ts.net

Funnel मोबाइल डेटा पर लोड होता है लेकिन आपके लैपटॉप से अलग व्यवहार करता है। आपका लैपटॉप tailnet पर है, इसलिए MagicDNS नाम को 100.x एड्रेस पर रिज़ॉल्व करता है और आप बिना किसी रिले को छुए सीधे सर्विस तक पहुँच जाते हैं। यह सही व्यवहार है, और इसका मतलब है कि आपका लैपटॉप सार्वजनिक पहुंच (public reachability) का परीक्षण बिल्कुल नहीं कर सकता है। ऐसी मशीन से curl का उपयोग करें जो tailnet पर नहीं है।

FAQ

tailscale serve और tailscale funnel में क्या अंतर है?

यह इस पर निर्भर करता है कि परिणाम तक कौन पहुँच सकता है। tailscale serve एक local port को एक HTTPS URL पर प्रकाशित करता है जिसे केवल आपके tailnet पर मौजूद डिवाइस ही एक्सेस कर सकते हैं। tailscale funnel उसी port को एक ऐसे URL पर प्रकाशित करता है जिसे इंटरनेट पर कोई भी व्यक्ति एक्सेस कर सकता है, जिसे Tailscale द्वारा संचालित relay servers के माध्यम से रूट किया जाता है। इनके flags और targets समान होते हैं। आउटपुट की पहली पंक्ति आपको बताती है कि आपको क्या मिला है: Available within your tailnet या Available on the internet।

tailscale funnel यह क्यों कहता है कि node attribute सेट नहीं है?

क्योंकि funnel तब तक tailnet के लिए अक्षम रहता है जब तक कोई इसे सक्षम न करे। संदेश Funnel not available; "funnel" node attribute not set. है और यह आपके अपने client से आता है, किसी भी relay से संपर्क करने से पहले। Access Controls के अंतर्गत tailnet policy file में एक nodeAttrs प्रविष्टि जोड़ें जो autogroup:member को, या यदि केवल एक मशीन को प्रकाशित करना हो तो किसी tag को, funnel attribute प्रदान करे। एक tailnet admin इसके बजाय उस consent URL का पालन कर सकता है जिसे CLI प्रिंट करता है।

Tailscale Funnel किन ports का उपयोग कर सकता है?

केवल 443, 8443 और 10000। डिफ़ॉल्ट 443 है, और आप --https=8443 या --https=10000 के साथ दूसरा चुन सकते हैं। यह funnel relays की सीमा है, न कि आपके सर्वर की, इसलिए VPS पर कोई firewall परिवर्तन या configuration परिवर्तन इसे नहीं हटा सकता। tailscale serve में ऐसी कोई सीमा नहीं है, क्योंकि यह कभी भी आपके tailnet से बाहर नहीं जाता है।

क्या serve या funnel URL reboot के बाद भी बना रहता है?

केवल तभी यदि आपने --bg का उपयोग किया हो। इसके बिना command foreground में चलती है, Press Ctrl+C to exit. प्रिंट करती है, और process के साथ ही mapping भी समाप्त हो जाती है। --bg के साथ mapping node की serve config में लिख दी जाती है और reboot के बाद tailscaled के साथ वापस आ जाती है। tailscale serve status के साथ जाँचें, जो कुछ भी सेट न होने पर No serve config प्रिंट करता है।

क्या funnel को चालू छोड़ना सुरक्षित है?

यह transport के अर्थ में सुरक्षित है: कनेक्शन HTTPS है और आपके firewall पर कोई port खुला नहीं है। यह उस अर्थ में सुरक्षित नहीं है जिसका लोग आमतौर पर मतलब निकालते हैं, क्योंकि URL सार्वजनिक है, इसलिए इसके पीछे का application भी सार्वजनिक है। funnel को केवल ऐसी चीज़ के सामने चालू रखें जो अपने स्वयं के अनुरोधों को प्रमाणित (authenticate) करती है, और जब डेमो या webhook टेस्ट समाप्त हो जाए, तो इसे उस command का उपयोग करके हटा दें जिससे इसे बनाया गया था, अंत में off जोड़कर।

उपरोक्त command व्यवहार के स्रोत: Tailscale Serve और Funnel दस्तावेज़ीकरण और tailscale.com/docs पर CLI संदर्भ।