क्या Tailscale सुरक्षित है? इसका Trust Model समझें

क्या Tailscale सुरक्षित है? संक्षिप्त उत्तर

क्या Tailscale सुरक्षित है? जिस बात की चिंता अधिकांश लोग करते हैं, उसके लिए उत्तर है: हाँ। आपकी tailnet को चलाने वाला coordination server कभी भी उन private keys को नहीं रखता जो आपके traffic को encrypt करती हैं, इसलिए यह नहीं देख सकता कि आपके devices एक-दूसरे को क्या भेज रहे हैं। Tailscale का security page इसे सीधे तौर पर स्पष्ट करता है: "Private keys कभी भी device से बाहर नहीं जातीं। सारा traffic हमेशा end-to-end encrypted रहता है।" उपयोगी प्रश्न कुछ और है। यदि कोई coordination server breach हो जाए, या किसी कानूनी आदेश से बाध्य हो, तो उसे आपके packets पढ़ने की आवश्यकता नहीं है। वह यह तय करता है कि आपके devices किन public keys पर भरोसा करते हैं, इसलिए वह ऐसे device को शामिल (enrol) कर सकता है जिसे आपने कभी मंजूरी नहीं दी थी।

यह एक वाक्य में trust model है: encryption डेटा की सुरक्षा करता है, और control plane सदस्यता तय करता है। नीचे दिया गया प्रत्येक भाग उस एक पक्ष का नाम बताता है जिस पर आपको भरोसा करना होगा, यह बताता है कि वह पक्ष वास्तव में क्या कर सकता है, और वह नियंत्रण देता है जो उसे सीमित करता है। यदि यह product आपके लिए नया है, तो Tailscale क्या है और इसका mesh कैसे काम करता है से शुरुआत करें।

Control plane और data plane अलग-अलग हैं

Tailscale एक mesh VPN (virtual private network) है जो WireGuard पर आधारित है। यह वही protocol है जिसे आप self-hosted WireGuard VPS पर मैन्युअल रूप से configure करते हैं। हर device स्थानीय रूप से अपनी WireGuard key pair generate करता है। Tailscale का how it works लेख coordination server को "public keys के लिए एक साझा drop box" कहता है और स्पष्ट करता है कि "private key कभी भी अपने node से बाहर नहीं जाती है।"

Data plane आपके devices के बीच का encrypted traffic है। यह सीधे एक device से दूसरे device तक जाता है, जब भी network इसकी अनुमति देता है। Control plane बाकी सब कुछ है: कौन से devices tailnet का हिस्सा हैं, किस device की कौन सी public key है, access policy, DNS settings और relay list। Tailscale control plane को एक hosted service के रूप में चलाता है। आप data plane को अपनी मशीनों पर चलाते हैं।

इन दोनों को अलग रखें, तो यहाँ सुरक्षा से जुड़ा हर सवाल हल हो जाता है। Encryption data plane का एक गुण है। Membership control plane का एक निर्णय है। Encryption की मात्रा यह नहीं बताती कि किसे peer बनने की अनुमति है।

एक compromised coordination server क्या कर सकता है?

यह आपके traffic को decrypt नहीं कर सकता। encryption करने वाली keys आपके devices पर generate होती हैं और कभी upload नहीं की जातीं, इसलिए ऐसी कोई जानकारी नहीं है जिसे जब्त या leak करके tunnel को खोला जा सके। यह relayed traffic पर भी लागू होता है, जिसके बारे में आगे विस्तार से बताया गया है।

यह एक node को enrol कर सकता है। जब Tailscale ने tailnet lock की घोषणा की, तो कंपनी ने इस जोखिम का वर्णन अपने शब्दों में किया: एक malicious server "आपके मौजूदा nodes को traffic भेजने या उनसे traffic प्राप्त करने के लिए गुप्त रूप से जोड़े गए node का उपयोग कर सकता है", और उस स्थिति में "यह मायने नहीं रखेगा कि traffic encrypted है क्योंकि peer स्वयं malicious होगा"। आपका device किसी peer पर भरोसा करता है क्योंकि control plane ने उसे बताया है कि वह key tailnet का हिस्सा है।

यह बदल सकता है कि आपके devices किन चीजों तक पहुँच सकते हैं। access policy control plane में रहती है और nodes को वितरित की जाती है। Tailscale का tailnet lock white paper कहता है कि tailnet lock "एक compromised control plane को आपके network में connectivity तोड़ने से नहीं रोकता है, जैसे कि नए node keys को वितरित करने में विफल होकर, या ऐसी access control policy वितरित करके जो सभी nodes तक पहुँच को अस्वीकार कर दे।"

यह किसी भी स्थिति में connection metadata देख सकता है। Tailscale के network flow logs हर machine-to-machine connection के लिए open और close events को record करते हैं। documentation में कहा गया है कि उन logs में "client operations या network traffic की सामग्री के बारे में कोई जानकारी नहीं होती है"। इसलिए control plane यह जान सकता है कि आपके किन devices ने किससे बात की, और कब की। यह नहीं जानता कि उन्होंने क्या कहा।

उस सूची में केवल एक item encryption के बारे में है। बाकी सब इस बारे में हैं कि कौन सदस्य है और policy क्या कहती है, यही कारण है कि जिन controls पर आपको ध्यान देना चाहिए, वे वे हैं जो enrolment को नियंत्रित करते हैं।

आपका identity provider आपके tailnet के लिए विश्वास का मूल (root of trust) है

Tailscale का अपना कोई password database नहीं है। इसके documentation में स्पष्ट रूप से कहा गया है कि Tailscale के कोई passwords नहीं होते हैं, और sign-in की प्रक्रिया एक identity provider (IdP) को सौंपी जाती है: जैसे Apple, Google, GitHub, Microsoft, Okta, OneLogin, या कोई custom OpenID Connect provider।

इसे एक security statement के रूप में देखें, क्योंकि यह वास्तव में वही है। जो कोई भी आपके Google या Microsoft account में sign-in कर सकता है, वह आपके tailnet में भी sign-in कर सकता है। आपका multi-factor authentication (MFA) वही होता है जिसे आपका IdP लागू करता है। किसी व्यक्ति के संस्था छोड़ने पर offboarding की प्रक्रिया वही होती है जो आपका IdP अपनाता है। यदि किसी IdP account को phish किया जाता है, तो वह एक tailnet account बन जाता है, और हमलावर को कभी भी WireGuard पर हमला करने की आवश्यकता नहीं होती: वे बस एक device जोड़ते हैं और आपकी policy उस user को जो भी अधिकार देती है, उसे प्राप्त कर लेते हैं।

एक चोरी हुए identity account और आपके tailnet के भीतर एक सक्रिय device के बीच दो नियंत्रण (controls) काम करते हैं: device approval और key expiry। Tailnet lock तीसरा नियंत्रण है, और इसका उद्देश्य account के बजाय control plane को सुरक्षित करना है।

डिवाइस अप्रूवल: जब तक कोई व्यक्ति अनुमति न दे, तब तक कुछ भी नेटवर्क से नहीं जुड़ता

Tailscale का डॉक्यूमेंटेशन डिवाइस अप्रूवल को एक ऐसी सुविधा के रूप में वर्णित करता है जो "Tailscale नेटवर्क एडमिनिस्ट्रेटर को नए डिवाइसों को Tailscale नेटवर्क में शामिल होने से पहले उनकी समीक्षा करने और उन्हें मंजूरी देने की अनुमति देता है"। एक Owner, Admin, या IT admin इसे मंजूरी दे सकते हैं। जब तक कोई इस पर कार्रवाई नहीं करता, तब तक एक नया डिवाइस Machines पेज पर "Needs approval" बैज दिखाता है।

इसे चालू करने पर, चोरी हुए अकाउंट वाली स्थिति बदल जाती है। हमलावर साइन इन करता है, डिवाइस रजिस्टर होता है, और फिर वह प्रतीक्षा करता है। वह किसी भी चीज़ तक नहीं पहुँच पाता, और आपके एडमिन कंसोल में एक बैज दिखाई देता है जो आपको बताता है कि एक ऐसी मशीन जिसे आप नहीं पहचानते, वह जुड़ने की अनुमति मांग रही है। ऑटोमेशन अभी भी काम करता है, क्योंकि auth key को जनरेट करते समय उसे pre-approved के रूप में चिह्नित किया जा सकता है, और डिवाइसों को API के माध्यम से भी मंजूरी दी जा सकती है।

Auth keys अंदर आने का दूसरा रास्ता हैं, इसलिए उन्हें क्रेडेंशियल्स की तरह ही समझें। Tailscale का डॉक्यूमेंटेशन जोखिम भरे प्रकार के बारे में स्पष्ट है: "Reusable keys के साथ बहुत सावधान रहें! यदि ये चोरी हो जाएं तो बहुत खतरनाक हो सकते हैं। इन्हें विशेष रूप से इसी उद्देश्य के लिए डिज़ाइन किए गए key vault प्रोडक्ट में रखना सबसे अच्छा है।" अगस्त 2026 तक, डॉक्यूमेंटेड key expiry रेंज 1 से 90 दिन है, और यदि कोई expiry निर्दिष्ट नहीं की जाती है, तो यह डिफ़ॉल्ट रूप से अधिकतम 90 दिन होती है। One-off keys को प्राथमिकता दें, आने-जाने वाली मशीनों के लिए उन्हें ephemeral के रूप में चिह्नित करें, और किसी भी reusable key को Ansible Vault के साथ एन्क्रिप्ट करके रखें या शेल स्क्रिप्ट के बजाय किसी secrets manager में रखें।

Key expiry: वह टाइमर जो अन्य सभी गलतियों को सीमित करता है

Node keys की समय-सीमा समाप्त हो जाती है, जो एक चोरी हुए या भूले हुए डिवाइस को एक अस्थायी समस्या में बदल देती है। Tailscale का documentation बताता है कि "डिफ़ॉल्ट रूप से, नए domains 180 दिनों की समाप्ति अवधि के साथ सेट होते हैं", और यह कि "यदि reauthentication नहीं होता है, तो keys समाप्त हो जाती हैं और दिए गए endpoint से/तक कनेक्शन काम करना बंद कर देंगे।" आप स्वयं किसी डिवाइस को reauthenticate कर सकते हैं:

tailscale up --force-reauth

Documentation चेतावनी देता है कि यह "tailnet कनेक्शन को बंद कर सकता है और इसलिए यदि कनेक्शन खो जाने पर लॉग इन करने का कोई वैकल्पिक साधन न हो, तो इसे दूरस्थ रूप से SSH या RDP के माध्यम से नहीं किया जाना चाहिए।" इसे console access खुला रखकर, या मशीन में प्रवेश के दूसरे रास्ते से चलाएं, क्योंकि आप उस नेटवर्क को बाधित करने वाले हैं जिसका आप उपयोग कर रहे हैं।

Servers पर यह नियंत्रण बदल जाता है। एक मशीन जिसे हर 180 दिनों में reauthenticate करना पड़ता है, वह रात के 3 बजे tailnet से हट जाएगी जब कोई उसे देख नहीं रहा होगा, इसलिए administrators उस पर key expiry को disable कर देते हैं। यह उस टाइमर को हटा देता है जो अंततः एक चोरी हुई key को काट देता। एक tagged device सर्वर के लिए बेहतर उत्तर है, क्योंकि एक tag किसी व्यक्ति के बजाय मशीन का स्वामी होता है, इसलिए वह मशीन उस व्यक्ति के कंपनी छोड़ने के बाद भी बनी रहती है। आप जो भी निर्णय लें, उन मशीनों की एक सूची रखें जिन पर expiry disable की गई है: वे keys तब तक वैध रहती हैं जब तक आप डिवाइस को delete नहीं कर देते।

Tailnet lock: coordination server को trust chain से बाहर करना

Tailnet lock सीधे enrolment की समस्या का समाधान करता है। Tailscale का tailnet lock documentation इस तंत्र की व्याख्या करता है: "जब कोई नया node tailnet में शामिल होता है, तो उसके public node key को एक Tailnet Lock key से हस्ताक्षर (signature) की आवश्यकता होती है। Coordination server हस्ताक्षरित public node key को peer nodes तक वितरित करता है।" आपके मौजूदा उपकरण किसी peer को स्वीकार करने से पहले उस signature की पुष्टि करते हैं, इसलिए control plane द्वारा स्वयं बनाई गई node key को अस्वीकार कर दिया जाता है।

tailscale lock status
tailscale lock sign nodekey:1abddef1 tlpub:abcdef12

tailscale lock init इस feature को enable करता है, और आप उसी समय अपने signing nodes को नामित करते हैं। Tailscale को initialisation के समय कम से कम दो signing nodes की आवश्यकता होती है और एक tailnet में अधिकतम 20 nodes की अनुमति देता है। उसके बाद, प्रत्येक नए उपकरण को उनमें से किसी एक से signature की आवश्यकता होती है, जो एक वास्तविक operational लागत है: एक फोन जोड़ने का मतलब है लैपटॉप पर एक command चलाना।

सीमाएं प्रलेखित (documented) हैं, और वे feature के विवरण से अधिक महत्वपूर्ण हैं:

• Disablement secret खो जाने पर कोई recovery संभव नहीं है। Documentation कहता है: "यदि आप अपने disablement secrets खो देते हैं, और आपने Tailscale support को कोई secret प्रदान नहीं किया है, तो tailnet को recover नहीं किया जा सकता है।"
• Signing key आपके स्वामित्व वाले उपकरण पर रहती है, इसलिए यह उस उपकरण की सुरक्षा को विरासत में लेती है। Documentation स्पष्ट है: "यदि उपकरण breach हो जाता है, तो key प्राप्त की जा सकती है।"
• आप दोनों controls एक साथ नहीं चला सकते। Tailscale का कहना है कि tailnet lock और device approval एक-दूसरे के विरोधी हैं, इसलिए एक को enable करने का अर्थ दूसरे को छोड़ना है।
• यह trust on first use (TOFU) है। प्रारंभिक setup अभी भी control plane के माध्यम से होता है, और विश्वास का आधार (anchor of trust) उस पहले चरण के बाद ही आपके अपने नेटवर्क में आता है।

Tailnet lock सदस्यता की सुरक्षा करता है। यह उपलब्धता (availability) की सुरक्षा नहीं करता है, और white paper में यह स्पष्ट लिखा है।

क्या relayed connection मेरे traffic को expose करता है?

नहीं। जब दो devices एक-दूसरे तक सीधे नहीं पहुँच पाते, तो traffic एक DERP (Designated Encrypted Relay for Packets) सर्वर पर चला जाता है। Tailscale का documentation इस विशेषता को स्पष्ट रूप से बताता है: "चूंकि Tailscale private keys कभी भी उस local device से बाहर नहीं जातीं जिसने उन्हें generate किया है, इसलिए DERP सर्वर के लिए आपके traffic को decrypt करना असंभव है। एक DERP सर्वर केवल पहले से encrypted traffic को एक device से दूसरे device तक आँख मूंदकर forward करता है।"

एक relay के उपयोग से आपकी गति कम हो सकती है, और यह metadata को देख सकता है: दो encrypted endpoints, साथ ही उनके बीच गुजरने वाले traffic का समय और मात्रा। यह पता लगाएँ कि आपके पास वास्तव में किस प्रकार का connection है:

tailscale status
tailscale netcheck

tailscale status प्रत्येक peer को direct के रूप में चिह्नित करता है, जिसे direct 203.0.113.10:41641 के रूप में दिखाया जाता है, या relayed के रूप में, जिसे relay name के बाद relay के रूप में दिखाया जाता है और उसके बाद byte counters आते हैं। यदि कोई peer relay पर बना रहता है, तो इसका अर्थ है कि दोनों सिरों के बीच direct path नहीं बन सका। आम तौर पर इसका कारण कहीं UDP का blocked होना या दोनों पक्षों का strict NAT (network address translation) के पीछे होना होता है। tailscale netcheck बताता है कि उस machine से UDP बिल्कुल काम करता है या नहीं, आपका NAT ports को कैसे map करता है और निकटतम relays तक latency कितनी है। इससे पता चलता है कि इन दोनों कारणों में से कौन-सा लागू है। यदि कोई peer पहले से direct है और throughput फिर भी अपेक्षा से कम है, तो relay आपकी समस्या नहीं है। slow WireGuard के पीछे आम तौर पर path MTU mismatch होता है।

Exit node आपके egress को स्थानांतरित करता है, उसे हटाता नहीं है

एक exit node किसी डिवाइस के सभी public internet traffic को tailnet पर मौजूद किसी अन्य डिवाइस के माध्यम से route करता है, जिसके लिए default routes 0.0.0.0/0 और ::/0 का उपयोग किया जाता है। Linux पर, जो मशीन यह सेवा प्रदान करती है, वह इसका विज्ञापन (advertise) करती है और प्रत्येक client इसे चुनने (opt-in) का विकल्प चुनता है:

sudo tailscale set --advertise-exit-node
sudo tailscale set --exit-node=100.101.102.103
sudo tailscale set --exit-node=100.101.102.103 --exit-node-allow-lan-access=true
sudo tailscale set --exit-node=

एक exit node को admin console में Owner, Admin या Network admin द्वारा अनुमोदित (approve) किया जाना चाहिए, और किसी client द्वारा इसका उपयोग करने से पहले आपकी policy को autogroup:internet प्रदान करना होगा। ये दोनों चरण जानबूझकर रखे गए हैं: एक अनधिकृत मशीन चुपचाप आपके पूरे tailnet का निकास द्वार नहीं बन सकती। यही अनुमोदन प्रक्रिया subnet routes पर भी लागू होती है, इसलिए जो मशीन किसी private range का विज्ञापन करती है, वह तब तक निष्क्रिय रहती है जब तक कि कोई admin उसे स्वीकार न कर ले। यह अपने VPS से अपने tailnet पर private network का विज्ञापन करने की दिशा में पहला कदम है।

अब बात आती है भरोसे की। आपके laptop से exit node तक traffic encrypted रहता है। इसके बाद यह उस मशीन से सामान्य internet traffic के रूप में बाहर निकलता है और उस मशीन का IP address धारण करता है। इसलिए, exit node का operator आपके गंतव्यों (destinations) को देख सकता है, और ऐसा ही उस मशीन का hosting provider और उसका upstream network भी कर सकते हैं। आपने अवलोकन बिंदु (observation point) को केवल स्थानांतरित किया है, उसे हटाया नहीं है। जब आप दूरस्थ छोर (far end) को नियंत्रित करते हैं, तो यह एक अच्छा सौदा है, जो कि VPS पर अपना स्वयं का exit node चलाने के पक्ष में तर्क है, लेकिन जब आप ऐसा नहीं करते हैं, तो यह एक बुरा सौदा साबित होता है।

डिफ़ॉल्ट पॉलिसी एक फ्लैट नेटवर्क है

एक नया tailnet डिफ़ॉल्ट रूप से अनुमत (permissive) होता है। Tailscale का एक्सेस कंट्रोल डॉक्यूमेंटेशन कहता है कि डिफ़ॉल्ट पॉलिसी फ़ाइल "tailnet के भीतर सभी डिवाइसों के बीच संचार को सक्षम बनाती है"। हर डिवाइस हर दूसरे डिवाइस तक किसी भी पोर्ट पर पहुँच सकता है। यह एक फ्लैट नेटवर्क है। आपने इसे टनल के अंदर स्थानांतरित कर दिया है, जो बाहरी लोगों से तो सुरक्षा करता है, लेकिन संक्रमित लैपटॉप के खिलाफ कुछ नहीं करता।

इसे tailnet पॉलिसी फ़ाइल में सख्त करें, जो एक्सेस कंट्रोल लिस्ट (ACLs) या नए grants को स्वीकार करती है। दोनों को JSON के एक ऐसे प्रकार में लिखा जाता है जो टिप्पणियों (comments) की अनुमति देता है:

{
  "acls": [
    {"action": "accept", "src": ["group:eng"], "dst": ["tag:prod:22"]},
    {"action": "accept", "src": ["autogroup:member"], "dst": ["autogroup:internet:*"]}
  ]
}

यह पॉलिसी एक समूह को प्रोडक्शन सर्वर पर SSH करने की अनुमति देती है, सदस्यों को exit node का उपयोग करने देती है, और बाकी सब कुछ डिफ़ॉल्ट रूप से अस्वीकार कर देती है। Tailscale यह सूचीबद्ध करता है कि कौन से नियम लक्ष्य (rule targets) किस प्लान पर उपलब्ध हैं, इसलिए tags या autogroups के आधार पर डिज़ाइन करने से पहले इसे जाँच लें, और देखें कि फ्री प्लान में वास्तव में क्या शामिल है। जिस डिवाइस को कभी भी इनकमिंग कनेक्शन स्वीकार नहीं करना चाहिए, जैसे कि पर्सनल फ़ोन, उसके लिए tailscale set --shields-up उन्हें क्लाइंट स्तर पर ब्लॉक कर देता है।

Headscale के साथ control plane को self-host करने से क्या बदलता है

Headscale "Tailscale control server का एक open source, self-hosted implementation है।" इसका README इसके दायरे को स्पष्ट रूप से बताता है: "यह एक सीमित दायरे को लागू करता है, जो एक single Tailscale network (tailnet) के लिए है, और व्यक्तिगत उपयोग या छोटे open-source संगठन के लिए उपयुक्त है।" इसकी feature list में ACLs और grants, subnet routers, exit nodes, एक embedded DERP server, Tailscale SSH, और Taildrop शामिल हैं। यदि यह सीमित दायरा आपके लिए समस्या है, तो NetBird दूसरा ऐसा mesh है जो self-hostable control plane प्रदान करता है, और अपने VPS पर NetBird server चलाना उसी नामांकन (enrolment) निर्णय को आपके स्वयं के हार्डवेयर पर स्थानांतरित कर देता है।

जो बदलता है वह उस पक्ष की पहचान है जो किसी rogue node को नामांकित कर सकता है। Headscale के साथ, key directory और policy आपके सर्वर पर रहती है। कोई भी तीसरा पक्ष कभी भी आपके device public keys की सूची नहीं रखता है, और किसी भी तीसरे पक्ष को इसे सौंपने या इसमें हस्ताक्षर करने के लिए मजबूर नहीं किया जा सकता है।

जो नहीं बदलता, वह data plane है। यह वही WireGuard है, जिसमें वही end-to-end encryption और direct path असंभव होने पर वही relay fallback रहता है। आपको वे जिम्मेदारियाँ भी संभालनी होंगी, जो पहले Tailscale संभालता था: uptime, patching, backups और server की physical security। यदि वह server rented VPS है, तो अंतिम जिम्मेदारी आपके नियंत्रण के बजाय किसी अन्य पक्ष के वादे पर निर्भर होगी, क्योंकि hypervisor आपके guest memory को पढ़ सकता है और उसके साथ key directory को भी, जब तक hardware ऐसी encrypted memory का समर्थन न करे, जिसकी attestation की जा सके।

Compromised Headscale host हमलावर को वही अधिकार देता है, जो compromised coordination server देता: node को enrol करने और policy वितरित करने की क्षमता। Tailnet lock, Headscale की feature list में उपलब्ध नहीं है। इसलिए इस विशिष्ट risk के लिए compensating control वहां उपलब्ध नहीं है। Cost भी कुछ tailnet को इसी दिशा में ले जाती है, क्योंकि Tailscale प्रति device के बजाय प्रति user billing करता है और छोटी team के free plan से बड़ी होते ही यह गणना बदल जाती है। यदि ownership का प्रश्न आपके निर्णय का मुख्य आधार है, तो Headscale के साथ control plane को self-host करना setup की पूरी प्रक्रिया बताता है।

Tailscale किन खतरों से सुरक्षा प्रदान करता है

• Public listening ports. Tailnet address पर bind की गई service internet से सुलभ नहीं होती है, इसलिए जो scanners हर VPS के port 22 को scan करते हैं, उन्हें यह service कभी दिखाई नहीं देती। इसका अपवाद वह है जिसे आप स्वयं चालू करते हैं, क्योंकि Funnel जानबूझकर एक tailnet service को open internet पर publish करता है। यही कारण है कि किसी भी command को चलाने से पहले यह जानना महत्वपूर्ण है कि serve कहाँ समाप्त होता है और funnel कहाँ शुरू होता है। फिर भी host firewall को चालू रखें, क्योंकि एक published Docker port अपने स्वयं के rules लिखता है और public interface पर ufw को bypass कर देता है।
• Exposed logins पर password guessing. जब port केवल tunnel के अंदर ही response देता है, तो brute-force attack के लिए कुछ भी उपलब्ध नहीं होता। यह open port पर rate limiting लगाने से कहीं अधिक सुरक्षित स्थिति है, हालाँकि public रहने वाली किसी भी चीज़ पर Ubuntu 24.04 पर fail2ban चलाना अभी भी उचित है।
• Path में मौजूद अविश्वसनीय networks. आपके machines के बीच का traffic café network या shared provider LAN पर end-to-end encrypted रहता है, और relay होने पर भी यह encrypted ही रहता है।
• Hand-managed key distribution. WireGuard config में हाथ से जोड़ा गया प्रत्येक peer एक ऐसी संभावना है जहाँ आप गलती से address reuse कर सकते हैं या गलत key paste कर सकते हैं। यह mesh network आपके लिए वह bookkeeping का काम खुद कर देता है, जो WireGuard बनाम Tailscale के बीच का मुख्य व्यावहारिक अंतर है।

Tailscale किन खतरों से सुरक्षा प्रदान नहीं करता है

• compromised endpoint: Tailnet उपकरणों पर भरोसा करता है। किसी स्वीकृत लैपटॉप पर मौजूद मैलवेयर को टनल, tailnet पते और आपकी पॉलिसी द्वारा उस उपयोगकर्ता को दी गई अनुमतियों का एक्सेस मिल जाता है। यह सबसे बड़ी कमी है और कोई भी VPN इसे पूरी तरह से नहीं रोक सकता।
• दुर्भावनापूर्ण या लापरवाह administrator: जो कोई भी पॉलिसी फ़ाइल को संपादित कर सकता है, वह खुद को किसी भी चीज़ का एक्सेस दे सकता है। जो कोई भी Owner के identity account पर नियंत्रण पा लेता है, वह भी ऐसा ही कर सकता है। पॉलिसी में किए गए बदलावों की समीक्षा उसी तरह करें जैसे आप कोड की समीक्षा करते हैं।
• Traffic analysis: आपका ISP (internet service provider) यह देख सकता है कि किसी endpoint पर एन्क्रिप्टेड UDP ट्रैफ़िक जा रहा है, साथ ही वे ट्रैफ़िक का समय और मात्रा भी देख सकते हैं। Tailscale के flow logs यह दिखाते हैं कि किन peers के बीच और कब बात हुई। इनमें से कोई भी सामग्री (contents) को नहीं देख सकता, लेकिन कनेक्शन होने की बात छिपी नहीं रहती है। इसलिए उस कार्य के लिए टूल चुनने से पहले Tor और VPN में क्या अंतर है पढ़ें।
• खोया हुआ उपकरण: Key expiry एक धीमा सुरक्षा उपाय है जो डिफ़ॉल्ट रूप से 180 दिनों पर सेट होता है। admin console में उपकरण को हटाना एक तेज़ उपाय है, इसलिए ज़रूरत पड़ने से पहले ही जान लें कि वह बटन कहाँ है।

अपने tailnet की जाँच करें

1. किसी डिवाइस पर tailscale status चलाएँ और peer list को पढ़ें। यदि आपको कोई ऐसी मशीन दिखती है जिसे आप नहीं पहचानते, तो यही वह स्थिति है जिसे रोकने के लिए device approval की सुविधा मौजूद है।
2. यह देखने के लिए कि क्या tailnet lock सक्षम है, tailscale lock status चलाएँ, और फिर तय करें कि क्या हर नए डिवाइस को sign करने की प्रक्रिया आपके tailnet के लिए उपयोगी है।
3. admin console खोलें और उन सभी मशीनों को नोट करें जिनमें key expiry अक्षम है, साथ ही उन सभी reusable auth keys को भी देखें जो अभी भी मौजूद हैं। ये दोनों ही बिना किसी समय-सीमा वाले credentials हैं।
4. अपनी policy file पढ़ें। यदि यह अभी भी default स्थिति में है, तो हर डिवाइस हर दूसरे डिवाइस तक किसी भी port पर पहुँच सकता है, और एक संक्रमित laptop सभी तक पहुँच बना सकता है।

Tailscale अपनी प्रतिष्ठा data plane के कारण अर्जित करता है, जहाँ डिज़ाइन के अनुसार operator के पास आपके traffic को पढ़ने का कोई तरीका नहीं होता। इस दावे को वैसे ही स्वीकार करें जैसे vendor ने दस्तावेज़ों में बताया है, और फिर उन हिस्सों का audit करें जो आपके नियंत्रण में हैं: identity accounts, approval setting, expiry list, और policy file। Tailscale का security page SOC 2 Type II certification और Latacora के साथ चल रहे सुरक्षा कार्यों की जानकारी देता है, जो उनकी प्रक्रिया के बारे में प्रमाण है, न कि आपके configuration के बारे में कोई बयान।

FAQ

क्या Tailscale मेरे traffic को पढ़ सकता है?

नहीं। Traffic उन WireGuard keys से encrypt होता है जो आपके devices पर generate होती हैं, और Tailscale का security page स्पष्ट करता है कि "Private keys कभी भी device से बाहर नहीं जाती हैं। सारा traffic हमेशा end-to-end encrypted रहता है।" यह उन connections पर भी लागू होता है जो DERP relay का उपयोग करते हैं, क्योंकि relay "पहले से encrypted traffic को एक device से दूसरे device तक आँख मूंदकर forward करता है" और उसके पास ऐसी कोई key नहीं होती जिससे वह उसे decrypt कर सके। Tailscale का infrastructure केवल metadata देख सकता है: कौन से devices मौजूद हैं, और उनमें से कौन सा, कब, किससे जुड़ा।

एक compromised Tailscale coordination server वास्तव में क्या कर सकता है?

वह एक node को enrol कर सकता है। Tailscale की अपनी tailnet lock घोषणा में एक गुप्त रूप से जोड़े गए node के जोखिम का वर्णन है जो "आपके मौजूदा nodes को traffic भेज या उनसे प्राप्त कर सकता है", जहाँ encryption मदद नहीं करता "क्योंकि peer स्वयं malicious होगा"। एक compromised control plane ऐसी policy भी distribute कर सकता है जो यह बदल दे कि आपके devices कहाँ तक पहुँच सकते हैं, और tailnet lock white paper नोट करता है कि यह नई node keys को distribute करने में विफल होकर connectivity को तोड़ सकता है। वह आपके मौजूदा devices के बीच के traffic को decrypt नहीं कर सकता, क्योंकि उसके पास कभी भी उनकी private keys नहीं होती हैं।

क्या exit node मेरे ISP से मेरी browsing को छिपाता है?

यह आपके द्वारा उपयोग किए जा रहे network से destinations को छिपाता है, जिसमें आपका home या café ISP भी शामिल है, क्योंकि सब कुछ आपके device से exit node के लिए encrypted traffic के रूप में निकलता है। यह आपको anonymous नहीं बनाता है। इसके बजाय, exit node उन destinations को देख सकता है, और ऐसा ही उसका hosting provider और upstream network भी कर सकते हैं, जबकि जिन sites पर आप जाते हैं, उन्हें exit node का IP address दिखाई देता है। आपने एक अलग observer चुना है, इसलिए किसी ऐसे व्यक्ति को चुनें जिस पर आप वास्तव में भरोसा करते हैं।

क्या Headscale, Tailscale के coordination server से अधिक सुरक्षित है?

यह पूरी तरह से अधिक सुरक्षित होने के बजाय एक अलग trust decision है। Headscale के साथ, key directory और policy आपके पास होती है, इसलिए किसी बाहरी party को आपके tailnet में device enrol करने के लिए मजबूर नहीं किया जा सकता। आप उस server को चलाने की जिम्मेदारी भी लेते हैं: patching, uptime, backups, और स्वयं host की सुरक्षा। एक compromised Headscale host हमलावर को वही enrolment power देता है जो एक compromised coordination server देता, और tailnet lock, Headscale की feature list में नहीं है, इसलिए उस host को उसी अनुसार सुरक्षित रखें।

क्या मुझे उस VPS पर firewall की आवश्यकता है जो मेरे tailnet में है?

हाँ। Public network interface अभी भी मौजूद रहता है, और 0.0.0.0 पर bind की गई कोई भी service internet से पहुँच योग्य रहती है, चाहे Tailscale चल रहा हो या नहीं। Services को tailnet address पर bind करें, public interface पर default deny policy रखें, और अपने published container ports की जाँच करें, क्योंकि Docker अपने स्वयं के rules डालता है और ऐसे port को expose कर सकता है जिसे आपने बंद माना था।