क्या Tailscale सुरक्षित है? इसका सुरक्षा मॉडल समझें

क्या 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 को शामिल कर सकता है जिसे आपने कभी approve नहीं किया।

यही एक वाक्य में 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 अनुमति देता है तो यह सीधा (direct) संपर्क बनाता है। 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 भेजने या प्राप्त करने के लिए गुप्त रूप से जोड़े गए 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 की प्रक्रिया है। एक phished IdP account का मतलब एक tailnet account है, और हमलावर को कभी भी WireGuard पर हमला करने की आवश्यकता नहीं होती: वे बस एक device जोड़ते हैं और वह सब कुछ प्राप्त कर लेते हैं जो आपकी policy उस user को प्रदान करती है।

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

Device approval: जब तक कोई व्यक्ति अनुमति न दे, तब तक कुछ भी join नहीं होता

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

इसे चालू करने पर, चोरी हुए account का परिदृश्य बदल जाता है। हमलावर sign in करता है, उपकरण register होता है, और फिर वह वहीं रुक जाता है। वह किसी भी चीज़ तक नहीं पहुँच पाता, जबकि आपके admin console में एक बैज यह बताता है कि एक ऐसा उपकरण जिसे आप नहीं पहचानते, वह join करने की अनुमति मांग रहा है। Automation अभी भी काम करता है, क्योंकि auth key generate करते समय उसे pre-approved के रूप में चिह्नित किया जा सकता है, और उपकरणों को API के माध्यम से भी approve किया जा सकता है।

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

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

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

tailscale up --force-reauth

Documentation चेतावनी देता है कि यह "tailnet connection को बंद कर सकता है, इसलिए यदि connection टूटने पर login करने का कोई वैकल्पिक तरीका न हो, तो इसे 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 के हस्ताक्षर की आवश्यकता होती है। Coordination server हस्ताक्षरित public node key को peer nodes तक वितरित करता है।" आपके मौजूदा उपकरण किसी peer को स्वीकार करने से पहले उस हस्ताक्षर की पुष्टि करते हैं, इसलिए control plane द्वारा स्वयं बनाई गई node key को अस्वीकार कर दिया जाता है।

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

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

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

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

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

tailscale status
tailscale netcheck

tailscale status प्रत्येक peer को या तो direct, जिसे direct 203.0.113.10:41641 के रूप में print किया जाता है, या relayed, जिसे relay नाम के साथ relay के रूप में print किया जाता है, के रूप में चिह्नित करता है, जिसके बाद byte counters होते हैं। यदि कोई peer relay पर ही बना रहता है, तो इसका मतलब है कि दोनों ends एक direct path नहीं बना सके, आमतौर पर इसलिए क्योंकि UDP कहीं block है या दोनों sides strict NAT (network address translation) के पीछे हैं। tailscale netcheck यह report करता है कि क्या उस machine से UDP काम कर रहा है, आपका NAT ports को कैसे map करता है, और निकटतम relays तक latency कितनी है, जिससे आपको पता चलता है कि आप इन दो कारणों में से किसका सामना कर रहे हैं।

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 का निकास द्वार नहीं बन सकती।

अब विश्वास का प्रश्न आता है। आपके 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 यह सूचीबद्ध करता है कि कौन से नियम लक्ष्य किस प्लान पर उपलब्ध हैं, इसलिए 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 निर्णय को आपके अपने hardware पर ले आता है।

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

जो नहीं बदलता है वह data plane है। यह वही WireGuard है जिसमें end-to-end encryption है, और वही relay fallback है जब direct path संभव नहीं होता। आप Tailscale द्वारा किए जा रहे कार्यों की जिम्मेदारी भी खुद लेते हैं: uptime, patching, backups, और box की physical security। एक compromised Headscale host हमलावर को बिल्कुल वही देता है जो एक compromised coordination server देता, यानी किसी node को enrol करने और policy वितरित करने की शक्ति। Tailnet lock, Headscale की feature list में नहीं है, इसलिए उस विशिष्ट जोखिम के लिए compensating control वहां उपलब्ध नहीं है। यदि स्वामित्व का प्रश्न ही आपके लिए निर्णायक है, तो Headscale के साथ control plane को self-host करना setup की प्रक्रिया को विस्तार से समझाता है।

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

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

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

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

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

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

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

FAQ

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

नहीं। Traffic उन WireGuard keys से encrypted होता है जो आपके 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 मौजूद हैं, और उनमें से कौन सा device कब और किससे connect हुआ।

एक 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 आपके पास होती है, इसलिए कोई बाहरी पक्ष आपके 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 insert करता है और ऐसे port को expose कर सकता है जिसे आप बंद मानते थे।