Tailscale Serve बनाम Funnel: लिंक असल में कौन खोल सकता है?

दोनों कमांड एक स्थानीय सेवा को Tailscale HTTPS नाम के ज़रिए प्रकाशित करते हैं, और जिस मशीन पर वे चलते हैं वहाँ से वे लगभग एक जैसे दिखते हैं। अंतर यह है कि बाद में URL तक कौन पहुँच सकता है, और यही अंतर तय करता है कि आपके एप्लिकेशन को अभी भी कौन-से नियंत्रण चाहिए। Serve दर्शकों को tailnet के भीतर रखता है, जबकि Funnel उसे खुले इंटरनेट पर ले जाता है। पहले दर्शक चुनें, फिर वह कमांड चुनें जो उससे मेल खाता है।

Serve आपके tailnet के भीतर एक सवाल का जवाब देता है

Serve किसी स्थानीय पोर्ट को प्रॉक्सी करता है या आपके tailnet के डिवाइसों को स्थानीय सामग्री परोसता है, और tailnet के एक्सेस नियम हर अनुरोध पर लागू रहते हैं। पोर्ट 3000 पर एक डैशबोर्ड ऐसे HTTPS नाम पर पहुँचने योग्य हो जाता है जिसे केवल आपके डिवाइस ही हल कर सकते हैं और उससे जुड़ सकते हैं। आंतरिक उपकरणों के लिए यह सही डिफ़ॉल्ट है, क्योंकि दर्शक पहले से tailnet द्वारा प्रमाणित हैं और आप कोई सार्वजनिक सतह नहीं जोड़ रहे। URL एक सामान्य वेबसाइट जैसा दिखता है, और ठीक इसी कारण लोग इसे वही मान लेते हैं।

Serve अपने फ़ॉरवर्ड किए गए अनुरोधों के साथ ऐसे पहचान हेडर भी जोड़ सकता है जो tailnet उपयोगकर्ता का वर्णन करते हैं। अगर आपका एप्लिकेशन उन हेडरों पर प्रमाणीकरण के रूप में भरोसा करता है, तो बैकएंड को localhost से बाँधें ताकि कोई और सीधे उस तक न पहुँच सके; रूट करने योग्य पते पर सुनने वाला बैकएंड ऐसे अनुरोध पा सकता है जो कभी प्रॉक्सी से नहीं गुज़रे।

Funnel दर्शकों को खुले इंटरनेट में बदल देता है

Funnel किसी चुनी हुई सेवा को उस हर व्यक्ति के लिए प्रकाशित करता है जिसके पास URL है, और आगंतुकों को क्लाइंट, खाता या आपके tailnet की सदस्यता की ज़रूरत नहीं होती। इसलिए संसाधन को वह प्रमाणीकरण, दर-सीमा और पैच चाहिए जो आप किसी भी सार्वजनिक सेवा पर लगाते। सार्वजनिक अनुरोध Serve के tailnet पहचान हेडर नहीं ले जाते, इसलिए जो एप्लिकेशन उन पर निर्भर था, Funnel के अंतर्गत उसकी कोई उपयोगकर्ता पहचान ही नहीं है। अलग प्रकाशन कमांड चुनने से प्रमाणीकरण का सवाल आपकी जगह हल नहीं होता।

Funnel की कुछ सीमाएँ भी हैं जिनका ज़िक्र पुराने संस्करण का ट्यूटोरियल शायद न करे। यह नाम के लिए Tailscale द्वारा लिए गए प्रमाणपत्र के साथ TLS समाप्त करता है, और केवल कुछ निश्चित सुनने वाले पोर्टों का समर्थन करता है, जैसा कि Funnel दस्तावेज़ीकरण बताता है। अगर आपकी सेवा उन पोर्टों में से किसी पर HTTPS के अलावा कोई प्रोटोकॉल चाहती है, तो Funnel कॉन्फ़िगरेशन की पहेली नहीं, बल्कि गलत उपकरण है।

मोड को पोर्ट से नहीं, क्लाइंट से पढ़ें

कुछ भी साझा करने से पहले मौजूदा स्थिति जाँचें, क्योंकि दोनों मोड अलग-अलग समय पर एक ही स्थानीय पोर्ट के लिए कॉन्फ़िगर किए जा सकते हैं। स्थिति कमांड बताते हैं कि वास्तव में क्या प्रकाशित हुआ है और किसके लिए। URL के जवाब देने के तथ्य से दर्शकों का अनुमान न लगाएँ।

tailscale serve status
tailscale funnel status
tailscale status --json | head -40

कमांड का सिंटैक्स क्लाइंट संस्करणों के बीच बदला है, इसलिए कॉपी किया गया कोई आह्वान आपके इरादे से अलग मोड चुन सकता है। जिस संस्करण को आप चलाते हैं उसके लिए प्रलेखित रूप को प्राथमिकता दें, और मान लेने के बजाय क्लाइंट जो पुष्टि छापता है उसे पढ़ें। अगर Serve और Funnel दोनों का कॉन्फ़िगरेशन मौजूद है, तो सार्वजनिक वाला ही एक्सपोज़र के लिए मायने रखता है। जो कॉन्फ़िगरेशन आपका इरादा नहीं था उसे उसके ऊपर दूसरा रखने के बजाय रीसेट करें।

अगर आउटपुट दर्शकों का नाम नहीं बताता तो रुकें और स्थिति दोबारा पढ़ें। बिना घोषित दर्शकों के प्रकाशित URL एक अंदाज़ा है, और अंदाज़े ही वह रास्ता हैं जिससे आंतरिक डैशबोर्ड खुले इंटरनेट पर पहुँचते हैं।

उन दर्शकों के साथ परीक्षण करें जिनका आपने सच में इरादा किया था

tailnet के बाहर से परीक्षण करें, उस मशीन से नहीं जिसने सेवा प्रकाशित की। tailnet डिवाइस से आया अनुरोध साबित करता है कि प्रॉक्सी काम करता है, पर यह साबित नहीं करता कि कोई अजनबी बाहर रखा गया है। ऐसा नेटवर्क इस्तेमाल करें जिसमें कोई Tailscale क्लाइंट न हो और tailnet तक कोई रूट न हो।

curl -sI https://host.tailnet-name.ts.net
curl -sI https://host.tailnet-name.ts.net --resolve host.tailnet-name.ts.net:443:203.0.113.10

आंतरिक डैशबोर्ड के लिए बाहरी अनुरोध कनेक्ट होने में विफल होना चाहिए या प्राधिकरण में विफल होना चाहिए, और आंतरिक अनुरोध उस पहचान के साथ सफल होना चाहिए जिसकी आप अपेक्षा करते हैं। सार्वजनिक सेवा के लिए बाहरी अनुरोध सफल होना चाहिए और एप्लिकेशन को अपने स्वयं के क्रेडेंशियल माँगने चाहिए। इन दोनों में से कौन-सा परिणाम आपने देखा, यह दर्ज करें, क्योंकि केवल URL यह नहीं बताता। अगर परिणाम इरादे के विपरीत है, तो पहले सार्वजनिक कॉन्फ़िगरेशन हटाएँ और बाद में जाँच करें।

सेवा प्रकाशित करना वही निर्णय नहीं है जो exit node चुनना है, जो नियंत्रित करता है कि आपका बहिर्गामी ट्रैफ़िक कहाँ से निकलता है। Serve और Funnel बताते हैं कि आप जो चलाते हैं उस तक कौन पहुँच सकता है; exit node बताता है कि आपके अपने कनेक्शन कहाँ से आते दिखते हैं। दोनों सवालों को अलग रखें और तुलना सरल बनी रहती है।