Tailscale serve की funnel: कोणता पर्याय वापरावा?
Tailscale serve HTTPS URL फक्त tailnet साठी ठेवते, तर funnel तोच port सार्वजनिक इंटरनेटवर उघडते. funnel रोखणारी policy gate कोणती आणि योग्य पर्याय कोणता ते जाणून घ्या.
tailscale serve विरुद्ध funnel: URL पर्यंत कोण पोहोचू शकतो
tailscale serve आणि tailscale funnel यांच्यातील फरक फक्त वापरकर्त्यांच्या व्याप्तीचा आहे. serve स्थानिक पोर्टसमोर HTTPS (hypertext transfer protocol secure) front end ठेवते आणि ते फक्त तुमच्या tailnet साठी प्रकाशित करते. funnel तोच स्थानिक पोर्ट Tailscale चालवत असलेल्या relay servers द्वारे संपूर्ण सार्वजनिक इंटरनेटवर प्रकाशित करते. दोन्ही commands मध्ये समान flags आणि समान targets घेतले जातात. Private dashboard आणि संपूर्ण जगातून पोहोचता येणाऱ्या dashboard मध्ये फक्त एक शब्दाचा फरक असतो.
दोन्ही पद्धती browsers ना आधीपासून trusted असलेले certificate देतात. हे certificate ts.net ने समाप्त होणाऱ्या नावावर असते. तसेच, VPS firewall वर inbound port उघडण्याची गरज कोणत्याही पद्धतीला नसते. तुमचा tailscaled daemon आधीपासून tailnet कडे बाहेर जाणारे connection ठेवतो. त्यामुळे traffic त्याच connection वरून येतो. Server ला tailnet वर आणणे हे एक स्वतंत्र काम आहे. VPS ला Tailscale exit node म्हणून चालवणे किंवा private network साठी subnet router advertise करणे यामध्ये त्याचा समावेश होतो. Tailnet वर आधीपासून असलेली service प्रकाशित करणे हा या विभागाचा विषय आहे.
या दोन्ही commands कार्य करण्यापूर्वी आवश्यक बाबी
- VPS वर Tailscale 1.38.3 किंवा त्यानंतरची आवृत्ती स्थापित असावी आणि तुम्ही तुमच्या tailnet मध्ये लॉग इन केलेले असावे.
tailscale versionआणिtailscale statusवापरून तपासा. - MagicDNS सक्षम असावे. MagicDNS हा Tailscale मधील अंगभूत DNS (domain name system) आहे. त्याद्वारे मशीनला फक्त
100.xaddress ऐवजीblog-vps.your-tailnet.ts.netसारखे नाव मिळते. - Admin console मधील DNS page वर tailnet साठी HTTPS certificates सक्षम केलेले असावेत. ते नसल्यास तुमच्या port समोर ठेवण्यासाठी certificate उपलब्ध नसते.
- फक्त
funnelसाठी tailnet policy file मध्येfunnelnode attribute आवश्यक आहे. पहिल्या प्रयत्नांमध्ये बहुतेक वेळा येथेच अडथळा येतो. याचे वर्णन खाली केले आहे.
येथील प्रत्येक command sudo ने सुरू होते, कारण CLI अशा socket द्वारे tailscaled शी संवाद साधते, ज्यावर लिहिण्याचा अधिकार फक्त root कडे असतो. हा अधिकार एका user ला देण्यासाठी पुढील command वापरा:
sudo tailscale set --operator=$USERtailscale serve वापरून तुमच्या tailnet वर publish करा
serve ला स्थानिक पोर्टकडे निर्देशित करा. पुढील काम ते आपोआप करते.
sudo tailscale serve 3000Available 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 वर ऐकते, ts.net certificate वापरून TLS (transport layer security) termination करते आणि plain HTTP तुमच्या स्थानिक पोर्टकडे forward करते. Certificate अस्तित्वात आहे हे तुमच्या application ला माहीत असण्याची गरज नसते. Plain HTTP वर ठेवावे लागणाऱ्या admin panel समोर हे वापरण्याचे हेच मुख्य कारण आहे.
आता शेवटची ओळ पाहा: Press Ctrl+C to exit. हा command foreground मध्ये चालतो आणि mapping त्या process मध्येच राहते. Terminal बंद केल्यावर URL काम करणे थांबवतो, कारण कोणतीही माहिती disk वर लिहिलेली नसते. --bg जोडा. त्यामुळे mapping node च्या serve config मध्ये जतन होते आणि terminal बंद केल्यानंतर तसेच reboot नंतरही कायम राहते.
sudo tailscale serve --bg 3000Serve केवळ port number पुरते मर्यादित नाही. --set-path एखादी service subpath अंतर्गत mount करते. त्यामुळे अनेक apps एकच hostname share करू शकतात:
sudo tailscale serve --bg --set-path=/grafana 3000
sudo tailscale serve --bg --set-path=/metrics 9090Target static files असलेली directory देखील असू शकते. तसेच, आधीपासून TLS वापरणारा असा backend देखील असू शकतो ज्याचे 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 termination करते आणि plaintext पुढे पाठवते. त्यामुळे HTTP अजिबात न वापरणाऱ्या service समोर trusted certificate ठेवता येते:
sudo tailscale serve --bg --tls-terminated-tcp=443 tcp://127.0.0.1:9899Funnel नोड attribute सेट केलेला नाही असे का सांगते?
Funnel संपूर्ण tailnet साठी default ने बंद असते. पहिल्यांदा चालवल्यावर हा संदेश दिसतो आणि प्रक्रिया थांबते:
Funnel not available; "funnel" node attribute not set. See https://tailscale.com/kb/1223/tailscale-funnel/.Command योग्य होता. tailnet policy ने या node ला publish करण्याची परवानगी दिलेली नाही. त्यामुळे client relay शी संपर्क करण्यापूर्वीच नकार देतो. Admin console मधील Access Controls अंतर्गत tailnet policy file संपादित करा आणि पुढील attribute जोडा:
"nodeAttrs": [
{
"target": ["autogroup:member"],
"attr": ["funnel"],
},
],autogroup:member हा attribute tailnet मधील प्रत्येक member ला देतो. फक्त एका machine ने publish करावे असे असल्यास, त्या machine ला tag द्या आणि त्याऐवजी तो tag वापरा. उदाहरणार्थ, tag:public. Policy save करा आणि funnel command पुन्हा चालवा.
तुमचे account tailnet admin असल्यास, अलीकडील clients एक shortcut देतात: CLI login.tailscale.com वर consent URL दाखवते. त्या URL चे अनुसरण केल्याने HTTPS certificates enable होतात आणि attribute आपोआप जोडला जातो. तुम्ही admin नसल्यास, तो URL उपयोगी ठरणार नाही. Policy access असलेल्या व्यक्तीने हा बदल करणे आवश्यक आहे.
Tailscale funnel वापरून इंटरनेटवर प्रकाशित करा
Attribute सेट केल्यानंतर, command तोच राहतो जो तुम्हाला आधीपासून माहीत आहे; फक्त verb वेगळा असतो.
sudo tailscale funnel --bg 3000Available 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 यांमधील एकमेव दृश्य फरक आहे, आणि ते तयार करणारे commands एका शब्दाने वेगळे आहेत.
August 2026 पर्यंत, funnel फक्त port 443, 8443 किंवा 10000 वर listen करतो; इतर कोणत्याही port वर नाही. Default port 443 आहे आणि --https=8443 किंवा --https=10000 हे पर्याय आहेत. इतर कोणताही port नाकारला जातो, कारण funnel relay फक्त याच port वर connections स्वीकारतात. म्हणून funnel URL नेहमी bare hostname असतो किंवा शेवटी :8443 जोडलेला hostname असतो.
आत्ता काय प्रकाशित आहे ते कसे पाहावे?
अंदाज केल्यामुळे dashboard महिनाभर सार्वजनिक राहू शकतो. त्याऐवजी node कडून माहिती घ्या.
tailscale serve status
tailscale funnel status
tailscale serve status --jsonदोन्ही status commands एकच configuration वाचतात. त्यामुळे त्यांपैकी कोणताही command संपूर्ण स्थिती दाखवतो. script किंवा scheduled check मध्ये --json form वापरा, कारण साधा output माणसांनी वाचण्यासाठी तयार केलेला असतो. काहीही configure केलेले नसल्यास एक ओळ दिसते:
No serve configसेटअप यशस्वी झाल्याचे माहीत असताना हा output दिसत असेल, तर mapping foreground मध्ये तयार झाले होते आणि process आता बंद झाला आहे. ते --bg वापरून पुन्हा तयार करा.
एक mapping काढण्यासाठी ते तयार करणारा command पुन्हा चालवा आणि शेवटी off जोडा. node वरील सर्व serve आणि funnel mappings काढण्यासाठी reset वापरा.
sudo tailscale funnel --https=443 3000 off
sudo tailscale serve resetयांपैकी कोणताही command चालवल्यानंतर पुन्हा tailscale serve status चालवा आणि उरलेली माहिती वाचा. command ने तुमच्या अपेक्षेप्रमाणे काम केले असे गृहीत धरू नका.
तुम्हाला काय मिळते आणि काय सोडावे लागते
हे फायदे वास्तविक आहेत. म्हणूनच काही जण reverse proxy ऐवजी हा पर्याय निवडतात.
- Browsers विश्वास ठेवतात असे certificate तुम्हाला मिळते आणि त्याचे renewal आपोआप होते. 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) मागे असलेल्या machine साठी हीच मुख्य अडचण असते.
याचे खर्चही तितकेच वास्तविक आहेत. funnel मुळे हे सर्व खर्च येतात.
- नाव तुमचे नसते. Public visitors ना
host.your-tailnet.ts.netदिसते. Funnel मध्ये custom domain support नाही. त्यामुळे त्यापुढेapp.example.comठेवता येत नाही. - path तुमचा नसतो. Traffic आधी Tailscale relay पर्यंत पोहोचते. त्यानंतर relay tailnet मार्फत stream तुमच्या node कडे proxy करते. Funnel traffic वर प्रकाशित न केलेल्या आणि configure न करता येणाऱ्या bandwidth limits लागू होतात, असे Tailscale सांगते. त्यामुळे एखाद्या निश्चित throughput वर अवलंबून राहण्यापूर्वी तुमचा स्वतःचा throughput मोजा.
- controls उपलब्ध नसतात. तुम्ही चालवलेल्या reverse proxy मुळे access logs, rate limits, request size caps आणि authentication ठेवण्यासाठी जागा मिळते. Funnel तुम्हाला फक्त URL देते. उरलेल्या सर्व गोष्टी तुमच्या application मध्येच लागू कराव्या लागतात.
- वरीलप्रमाणे port list निश्चित असते.
दोन्ही features Tailscale चालवत असलेल्या infrastructure वरही अवलंबून असतात: ts.net नावासाठी certificate issuance आणि funnel relays स्वतः. तुम्ही self-hosted Headscale control server वापरण्याचा विचार करत असाल, तर यापैकी कोणतीही सुविधा तुमच्यासोबत येईल असे गृहीत धरू नका. तुम्ही चालवण्याची योजना असलेल्या Headscale version च्या release notes तपासा.
मी कोणते वापरावे?
नियम सोपा आहे.
अंतर्गत वापरासाठी serve वापरा: admin interfaces, dashboards, indexed होऊ नये अशी metrics UI किंवा साइटची staging प्रत. tailnet चे सदस्यत्व access control म्हणून काम करते आणि ते प्रभावी आहे. tailnet वर नसलेले device हे नाव resolve देखील करू शकत नाही.
demo link, तृतीय पक्षाने POST करणे आवश्यक असलेला webhook receiver किंवा development दरम्यानचा OAuth callback यांसाठी funnel वापरा. सार्वजनिक HTTPS URL मिळवण्याचा हा सर्वात जलद मार्ग आहे आणि एका off command ने तो बंद करता येतो. मात्र public म्हणजे publicच: hostname हे secret नसते आणि login नसलेल्या app समोरील funnel ही open service असते. त्यामागील कोणतीही सेवा स्वतःच्या requests चे authentication करणे आवश्यक आहे. यासाठी उघड्या Ollama API endpoint ला आवश्यक असते तितकीच काळजी घ्या.
production साठी वापरायच्या कोणत्याही सेवेकरिता वास्तविक reverse proxy वापरा. तुमचे domain, तुमचे certificate, तुमचे logs, तुमच्या rate limits आणि request path मध्ये इतर कोणीही नसणे. reverse proxy म्हणून nginx, Caddy आणि Traefik ची तुलना यांपैकी एक निवडण्यास मदत करते.
अपयशाच्या स्थिती आणि दिसणारे संदेश
Funnel सुरू होण्यास नकार देतो. Funnel not available; "funnel" node attribute not set. ही policy ची समस्या आहे, command ची नाही. tailnet policy file मध्ये funnel attribute जोडा, ती save करा आणि पुन्हा प्रयत्न करा.
ते कार्यरत होते, पण आता tailscale serve status मध्ये No serve config दिसत आहे. Mapping foreground मध्ये तयार केले गेले होते आणि ती process समाप्त झाली. --bg वापरून तोच command पुन्हा चालवा.
नाव resolve होते, पण कोणताही प्रतिसाद मिळत नाही. Serve तुम्ही निर्दिष्ट केलेल्या target कडे proxy करते. त्यामुळे तिथे कोणतीही सेवा listen करत नसेल, तर proxy करण्यासाठी काहीही उपलब्ध नसते. tailscaled चालवणाऱ्या त्याच मशीनवर ss -ltnp | grep 3000 वापरून पडताळा. नेहमीचे कारण म्हणजे container आपला port Docker bridge address वर publish करतो, 127.0.0.1 वर नाही. त्यामुळे अपेक्षित ठिकाणी host ला कोणताही listener दिसत नाही. Docker Compose networking कसे कार्य करते यामध्ये publish केलेला port प्रत्यक्षात कुठे उपलब्ध होतो हे दाखवले आहे.
ts.net नावासाठी certificate errors. tailnet साठी HTTPS certificates बहुधा enable केलेले नाहीत. Admin console मध्ये ते enable करा. त्यानंतर certificate step स्वतंत्रपणे चालवा, म्हणजे त्यातील errors serve output मध्ये मिसळणार नाहीत:
sudo tailscale cert your-host.your-tailnet.ts.netMobile data वर funnel लोड होते, पण तुमच्या laptop पेक्षा वेगळे वर्तन करते. तुमचा laptop tailnet वर आहे. त्यामुळे MagicDNS हे नाव 100.x address वर resolve करते आणि relay न वापरता तुम्ही थेट सेवेशी जोडले जाता. हे अपेक्षित वर्तन आहे. याचा अर्थ तुमचा laptop public reachability ची चाचणी अजिबात करू शकत नाही. tailnet वर नसलेल्या मशीनवरून curl वापरा.
FAQ
tailscale serve आणि tailscale funnel यांच्यात काय फरक आहे?
परिणामापर्यंत कोण पोहोचू शकते यावर फरक असतो. tailscale serve स्थानिक पोर्ट HTTPS URL वर प्रकाशित करते. हा URL फक्त तुमच्या tailnet मधील उपकरणांनाच उपलब्ध असतो. tailscale funnel तोच पोर्ट इंटरनेटवरील कोणालाही उपलब्ध असलेल्या URL वर प्रकाशित करते. हा traffic Tailscale चालवत असलेल्या relay servers मार्फत route केला जातो. दोन्हींमध्ये flags आणि targets समान असतात. पहिली output line तुम्हाला कोणते वापरले गेले ते सांगते: Available within your tailnet किंवा Available on the internet.
tailscale funnel node attribute set केलेले नाही असे का सांगते?
कारण कोणी ते enable करेपर्यंत tailnet साठी funnel disabled असते. हा संदेश Funnel not available; "funnel" node attribute not set. असा असतो. कोणत्याही relay शी संपर्क करण्यापूर्वी तो तुमचा स्वतःचा client दाखवतो. Access Controls अंतर्गत tailnet policy file मध्ये nodeAttrs entry जोडा. या entry मध्ये funnel attribute autogroup:member ला द्या. फक्त एका machine ने publish करायचे असल्यास tag वापरा. त्याऐवजी tailnet admin CLI ने दाखवलेल्या consent URL चे अनुसरण करू शकतो.
Tailscale Funnel कोणते ports वापरू शकते?
फक्त 443, 8443 आणि 10000. Default port 443 आहे. --https=8443 किंवा --https=10000 वापरून दुसरा port निवडता येतो. ही मर्यादा funnel relays ची आहे, तुमच्या server ची नाही. त्यामुळे VPS वरील कोणताही firewall change किंवा configuration change ही मर्यादा दूर करू शकत नाही. 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 वापरून तपासा. काहीही set केलेले नसल्यास ते No serve config दाखवते.
funnel चालू ठेवणे सुरक्षित आहे का?
Transport च्या दृष्टीने ते सुरक्षित आहे. Connection HTTPS असते आणि तुमच्या firewall वर कोणताही port open केला जात नाही. मात्र सामान्य अर्थाने ते सुरक्षित नाही, कारण URL public असतो आणि त्यामुळे त्यामागील application देखील public होते. स्वतःच्या requests चे authentication करणाऱ्या सेवेसमोरच funnel चालू ठेवा. Demo किंवा webhook test पूर्ण झाल्यावर ते बंद करा. यासाठी funnel तयार करणारीच command वापरा आणि शेवटी off जोडा.
वरील command behaviour साठी स्रोत: Tailscale Serve आणि Funnel documentation तसेच CLI reference, tailscale.com/docs.