Tailscale क्या है और यह कैसे काम करता है?

Tailscale क्या है?

Tailscale एक VPN है जो आपके सभी मशीनों को सीधे एक-दूसरे से जोड़ता है, बजाय इसके कि सारा traffic किसी एक gateway के माध्यम से भेजा जाए। प्रत्येक node WireGuard चलाता है, इसलिए packets एक सर्वर से दूसरे सर्वर तक encrypted होकर जाते हैं और रास्ते में कोई भी उन्हें पढ़ नहीं सकता। एक hosted coordination server परिचय (introductions) का काम संभालता है। यह public keys को स्टोर और वितरित करता है और प्रत्येक node को बताता है कि दूसरे nodes कहाँ हैं। यह आपके द्वारा लिखे गए access rules को भी लागू करता है।

यह विभाजन ही इसका पूरा design है। Data plane peer-to-peer है और nodes के बीच encrypted रहता है। Control plane वह service है जिसे Tailscale आपके लिए चलाता है। Tailscale के बारे में हर महत्वपूर्ण सवाल, जिसमें विश्वास (trust) से जुड़े कठिन सवाल भी शामिल हैं, इन्हीं दो तथ्यों से उत्पन्न होते हैं। यदि आपने पहले ही VPS पर हाथ से WireGuard VPN बनाया है, तो Tailscale वही tunnel है जिसमें key distribution और firewall traversal का काम आपके लिए पहले से हो जाता है।

Tailscale कैसे काम करता है?

नोड्स का आपका निजी नेटवर्क tailnet कहलाता है। जब कोई मशीन इसमें शामिल होती है, तो चार चीजें होती हैं।

1. tailscaled डेमन शुरू होता है, एक WireGuard की-पेयर (key pair) बनाता है, और अपनी स्थिति को /var/lib/tailscale/tailscaled.state में रखता है। प्राइवेट की (private key) उस मशीन पर ही रहती है। Tailscale के अपने शब्द स्पष्ट हैं: "प्राइवेट की कभी भी, किसी भी स्थिति में अपने नोड से बाहर नहीं जाती है।"
2. नोड कोऑर्डिनेशन सर्वर में लॉग इन करता है और अपनी पब्लिक की (public key) अपलोड करता है, साथ ही वे पते भी जहाँ उसे संपर्क किया जा सकता है। Tailscale उस सर्वर को "पब्लिक कीज़ के लिए एक साझा ड्रॉप बॉक्स" के रूप में वर्णित करता है।
3. कोऑर्डिनेशन सर्वर एक नेटवर्क मैप वापस भेजता है: पब्लिक की, tailnet पता, मशीन का नाम और उन सभी नोड्स के संभावित एंडपॉइंट्स जिनसे इसे जुड़ने की अनुमति है।
4. इसके बाद नोड्स की प्रत्येक जोड़ी आपस में एक सीधा WireGuard टनल बनाने का प्रयास करती है। जब यह विफल हो जाता है, तो वे पैकेट्स को एक रिले के माध्यम से भेजते हैं।

प्रत्येक नोड को 100.64.0.0/10 से एक स्थिर पता मिलता है, जो 100.64.0.0 से 100.127.255.255 तक चलने वाली कैरियर-ग्रेड NAT रेंज है। Tailscale इस रेंज का उपयोग इसलिए करता है क्योंकि यह प्रदाता के बुनियादी ढांचे के लिए आरक्षित है, इसलिए यह आपके सर्वर द्वारा पहले से उपयोग किए जा रहे निजी पतों के साथ शायद ही कभी टकराता है। Linux पर टनल tailscale0 नामक इंटरफ़ेस के रूप में दिखाई देता है।

WireGuard का कार्यान्वयन कर्नल मॉड्यूल के बजाय userspace में tailscaled के अंदर रहता है। यही कारण है कि Tailscale कंटेनर वर्चुअलाइजेशन पर शुरू हो जाता है जहाँ sudo modprobe wireguard, Operation not supported के साथ विफल हो जाता है। इसका मतलब यह भी है कि किसी दिए गए बॉक्स पर थ्रूपुट की सीमा कर्नल WireGuard की तुलना में कम है, जो कि उन ट्रेड-ऑफ्स में से एक है जिन्हें Tailscale बनाम plain WireGuard में विस्तार से समझाया गया है।

दो कमांड्स आपको आपकी स्थिति बताती हैं।

tailscale ip -4
tailscale status

tailscale status प्रति नोड एक लाइन प्रिंट करता है, और अंतिम कॉलम सबसे महत्वपूर्ण है।

100.101.102.103  web-1      you@  linux  -
100.101.102.104  db-1       you@  linux  active; direct 198.51.100.24:41641
100.101.102.105  ci-runner  you@  linux  active; relay "fra"

direct के बाद एक पता और पोर्ट का मतलब है कि दोनों मशीनों ने एक-दूसरे के लिए रास्ता खोज लिया है और ट्रैफ़िक पीयर-टू-पीयर है। relay "fra" का मतलब है कि यह फ्रैंकफर्ट में एक Tailscale रिले के माध्यम से गुजर रहा है। - का मतलब है कि अभी उस नोड के साथ कोई सक्रिय सत्र नहीं है, जो कि सामान्य है।

Coordination server क्या देख सकता है और क्या नहीं

Coordination server के पास public keys और metadata होते हैं। यह आपके machine names, प्रत्येक node का मालिक कौन सा user या tag है, प्रत्येक node का tailnet address, वे public addresses जिन पर आपके nodes उपलब्ध हैं, प्रत्येक node आखिरी बार कब online था, और आपके द्वारा लिखी गई policy file को जानता है। यह आपके पूरे fleet का एक पूर्ण नक्शा है।

इसके पास कोई private key नहीं होती, इसलिए यह दो nodes के बीच के traffic को decrypt नहीं कर सकता। Encryption WireGuard peers के बीच end-to-end होता है, और coordination server एक peer नहीं है।

यह केवल keys प्रदान कर सकता है। किसी भी coordination server, चाहे वह hosted हो या self-run, पर यह भरोसा किया जाता है कि वह आपके nodes को यह बताए कि कौन सी public keys tailnet का हिस्सा हैं। यह नीचे दिए गए threat model का मुख्य आधार है, और यही कारण है कि Headscale, एक open-source coordination server जिसे आप स्वयं host करते हैं मौजूद है।

विभिन्न firewalls के पीछे स्थित दो सर्वर सीधे आपस में कैसे बात करते हैं

NAT (network address translation) वह तकनीक है जो कई मशीनों को एक ही public address साझा करने की अनुमति देती है। आपके VPS का आमतौर पर अपना एक public address होता है, लेकिन जिन अन्य मशीनों को आप tailnet में शामिल करना चाहते हैं, उनके पास अक्सर ऐसा नहीं होता है: जैसे कि एक home server, office network पर स्थित एक build runner, या किसी provider firewall के पीछे स्थित एक box जिसे आप edit नहीं कर सकते।

Tailscale, STUN (session traversal utilities for NAT) और ICE मानकों पर आधारित तकनीकों का उपयोग करके एक path ढूँढता है। प्रत्येक node एक STUN server को एक छोटा UDP packet भेजता है और उस public address और port के बारे में जानता है जो उसके router ने उस socket को assign किया है। दोनों nodes उन candidates की जानकारी coordination server को देते हैं, जो उन्हें दूसरी तरफ भेज देता है। फिर दोनों nodes एक ही समय पर एक-दूसरे को packets भेजना शुरू करते हैं। प्रत्येक router पहले एक outbound packet देखता है, इसलिए वह एक mapping बनाता है और उसी address से आने वाले reply को स्वीकार कर लेता है। किसी भी तरफ inbound firewall rule की आवश्यकता नहीं होती है।

Ports विशिष्ट होते हैं। Direct WireGuard tunnels UDP का उपयोग करते हैं, जिसका source port डिफ़ॉल्ट रूप से 41641 होता है। STUN, Tailscale के relay servers के लिए UDP 3478 पर चलता है। Control connection और कोई भी relayed data TCP 443 पर HTTPS का उपयोग करते हैं। अधिकांश समय आपको कुछ भी inbound open करने की आवश्यकता नहीं होती है, हालाँकि एक कठिन NAT वाले network पर, UDP 41641 को inbound अनुमति देने से direct connection की संभावना बढ़ जाती है।

tailscale netcheck

उस report की दो पंक्तियाँ पढ़ें। UDP: true का अर्थ है कि UDP मशीन से बाहर निकल रहा है, और UDP: false का अर्थ है कि इस node से होने वाला प्रत्येक connection relay किया जाएगा। MappingVariesByDestIP: true का अर्थ है कि router प्रत्येक destination के लिए एक अलग public port assign करता है, इसलिए ऊपर बताई गई address prediction काम नहीं कर सकती और वे nodes आमतौर पर relayed ही रहते हैं।

जब Tailscale इसके बजाय DERP relay का उपयोग करता है

DERP (designated encrypted relay for packets) एक fallback है। Tailscale कई क्षेत्रों में relay चलाता है, जो TCP 443 पर पहुँच योग्य होते हैं। जो node सीधा रास्ता नहीं ढूँढ पाता, वह अपने WireGuard packets को इनमें से किसी एक के माध्यम से भेजता है।

Packets एन्क्रिप्टेड ही रहते हैं। Tailscale इसे स्पष्ट रूप से बताता है: "DERP सर्वर के लिए आपके traffic को decrypt करने का कोई तरीका नहीं है। यह केवल पहले से एन्क्रिप्टेड traffic को एक node से दूसरे node तक आँख बंद करके forward करता है।" एक relay केवल ciphertext देखता है, और यह देखता है कि कौन सा node किससे बात कर रहा है।

Relays अधिकांश connections के पहले packets को भी ले जाते हैं। सीधा रास्ता खोजने में थोड़ा समय लगता है, इसलिए एक session अक्सर relay के साथ शुरू होता है और जैसे ही दोनों nodes एक-दूसरे को ढूँढ लेते हैं, वह सीधे tunnel में upgrade हो जाता है। आप इसे होते हुए देख सकते हैं।

tailscale ping db-1

पहले जवाब via DERP(fra) के रूप में वापस आते हैं, फिर बाद की एक line via 198.51.100.24:41641 जैसा कुछ report करती है। वह बदलाव सीधे tunnel में upgrade होना है। यदि यह कभी नहीं बदलता है, तो दोनों छोरों पर tailscale netcheck चलाएँ। एक relayed path अभी भी काम करता है। इसमें latency अधिक होती है, क्योंकि हर packet को एक तीसरी machine से होकर गुजरना पड़ता है।

अपने VPS को tailnet से जोड़ना

Install script Ubuntu और Debian दोनों के लिए उपलब्ध है।

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

sudo tailscale up एक URL print करता है। इसे खोलें, authenticate करें, और node आपके admin console में दिखाई देने लगेगा। इसके बाद यह सुनिश्चित करें कि reboot के बाद daemon वापस चालू हो जाता है, क्योंकि अक्सर लोग यही चरण भूल जाते हैं।

sudo systemctl is-enabled tailscaled
tailscale status

is-enabled को enabled print करना चाहिए, और tailscale status को नए node को उसके 100.x address के साथ सूचीबद्ध करना चाहिए। स्क्रिप्ट से बनाए गए सर्वर के लिए, interactive URL किसी काम का नहीं होता। Admin console में एक auth key generate करें और उसे एक tag के साथ पास करें, जो यह बताता हो कि यह किस प्रकार की मशीन है।

sudo tailscale up --auth-key=tskey-auth-REPLACE-ME --advertise-tags=tag:server

एक tagged node का स्वामित्व उसे चलाने वाले व्यक्ति के बजाय tag के पास होता है, इसलिए उस व्यक्ति का account हट जाने के बाद भी यह काम करता रहता है। Tag को पहले आपकी policy file में tagOwners के अंतर्गत घोषित किया जाना चाहिए, अन्यथा command अस्वीकार कर दी जाएगी। Tagging यह भी बदल देती है कि मशीन आपके plan के तहत कैसे गिनी जाती है, क्योंकि एक tagged resource की कीमत व्यक्ति के अपने उपकरणों से अलग तरह से तय की जाती है, और free tier वास्तव में क्या कवर करता है यह बताता है कि वे सीमाएँ कहाँ हैं।

एक fleet के लिए दो सेटिंग्स महत्वपूर्ण हैं। Node keys डिफ़ॉल्ट रूप से 180 दिनों के बाद expire हो जाती हैं (अगस्त 2026 तक), और जब कोई key expire होती है, तो "दिए गए endpoint से/तक कनेक्शन काम करना बंद कर देंगे" जब तक कि कोई फिर से login न करे। इसलिए unattended servers पर admin console में मशीन की row खोलें और Disable Key Expiry चुनें। MagicDNS, जो 20 अक्टूबर 2022 को या उसके बाद बनाए गए tailnets के लिए डिफ़ॉल्ट रूप से सक्षम है, प्रत्येक node को db-1.yak-bebop.ts.net जैसा एक नाम देता है, जिसे 100.100.100.100 पर एक stub resolver द्वारा resolve किया जाता है। Addresses के बजाय इन नामों का उपयोग करें, क्योंकि एक rebuilt node को नया address मिलता है लेकिन उसका नाम वही रहता है।

यदि install प्रक्रिया apt या repository पर विफल हो जाती है, तो Ubuntu पर सामान्य Tailscale install त्रुटियाँ में इसके समाधान दिए गए हैं।

localhost पर bind की गई service तक पहुँचना

यहीं पर tailnet उपयोगी हो जाता है, और यहीं लोग अक्सर अटक जाते हैं। tailnet से जुड़ने का मतलब यह नहीं है कि loopback service तक पहुँचा जा सके।

ss -tlnp | grep 3000

यदि यह 127.0.0.1:3000 प्रिंट करता है, तो socket केवल उन्हीं packets को स्वीकार करता है जिनका destination 127.0.0.1 है। किसी अन्य node से आने वाली request इस node के 100.x address पर आती है, इसलिए kernel के पास उसके लिए कोई listener नहीं होता और वह TCP reset के साथ जवाब देता है। client Connection refused रिपोर्ट करता है। tunnel ठीक है। समस्या listener में है।

इसके दो सही समाधान हैं। service को node के tailnet address पर bind करें, जो इसे बिना किसी proxy के public interface से दूर रखता है: --bind 100.101.102.104 या अपनी config में समकक्ष option का उपयोग करें, और container के लिए port को -p 100.101.102.104:3000:3000 के रूप में publish करें। या service को loopback पर रहने दें और उसके सामने Tailscale लगा दें।

tailscale serve 3000

यह requests को http://127.0.0.1:3000 पर proxy करता है और उन्हें आपके tailnet के अंदर एक ts.net नाम पर HTTPS के माध्यम से serve करता है, जब tailnet के लिए HTTPS certificates सक्षम हो जाते हैं। यह आपके nodes तक ही निजी रहता है। इसी विचार का public संस्करण Funnel है, और Tailscale serve बनाम funnel में बताया गया है कि आपको किसकी आवश्यकता है।

दो संबंधित कार्यों के अपने अलग पृष्ठ हैं। जिस private network पर Tailscale install नहीं है, उस पूरे network तक पहुँचने के लिए VPS पर subnet router की आवश्यकता होती है, और किसी node के outbound internet traffic को दूसरे node के माध्यम से भेजने के लिए exit node की आवश्यकता होती है।

जिन ports की अब आवश्यकता नहीं है उन्हें बंद करना

एक बार जब प्रत्येक administrator tailnet के माध्यम से सर्वर तक पहुँच जाता है, तो public port 22 का कोई काम नहीं रह जाता। यही इसका व्यावहारिक लाभ है: जो port बंद है, उस पर brute force हमला नहीं किया जा सकता, और आपके logs में बार-बार होने वाले login प्रयासों का भरना बंद हो जाता है।

क्रम महत्वपूर्ण है। पहले tailnet access जोड़ें, दूसरे session से login करके इसकी पुष्टि करें, और उसके बाद ही public rule को हटाएँ।

sudo ufw allow in on tailscale0
sudo ufw status verbose

उसके बाद, public SSH rule को delete करें और MagicDNS नाम का उपयोग करके reconnect करें। ध्यान दें कि ufw allow in on tailscale0 वास्तव में क्या करता है: यह tunnel पर आने वाले हर traffic पर भरोसा करता है, इसलिए ufw के बजाय आपकी Tailscale policy file ही access control बन जाती है। इस बात को ध्यान में रखते हुए policy लिखें।

containers चलाने वाले किसी भी व्यक्ति के लिए एक चेतावनी। एक published Docker port अपने स्वयं के NAT rules install करता है और ufw को bypass कर देता है, इसलिए ufw deny उसे बंद नहीं करता है। ufw को bypass करने वाले Docker published ports इस प्रक्रिया को समझाता है। जैसा कि ऊपर बताया गया है, tailnet address पर publish करने से यह समस्या नहीं होती।

Tailscale क्या सुरक्षित करता है, और क्या नहीं

इसे स्पष्ट रूप से बताना आवश्यक है, क्योंकि मार्केटिंग संस्करण इस रेखा को धुंधला कर देता है।

सुरक्षित: दो nodes के बीच का traffic WireGuard के साथ end-to-end encrypted होता है, और बीच में कोई भी relay इसे पढ़ नहीं सकता। Private keys कभी भी उस machine से बाहर नहीं जातीं जिसने उन्हें generate किया है। Nodes को किसी inbound public port की आवश्यकता नहीं होती, इसलिए internet के स्कैन करने के लिए 22 या 5432 पर कुछ भी उपलब्ध नहीं होता। Nodes के बीच access का निर्णय किसी address को जानने वाले व्यक्ति के बजाय एक policy file द्वारा लिया जाता है।

सुरक्षित नहीं: coordination server आपके device graph को देख सकता है। वह metadata अपने आप में संवेदनशील है, क्योंकि machine के नाम, मालिक, addresses और online रहने का समय आपके infrastructure का विवरण देते हैं। यह keys भी distribute करता है, जो कि अधिक गंभीर जोखिम है। Tailscale इसे सीधे कहता है: "यदि Tailscale दुर्भावनापूर्ण हो, और चुपके से आपके network में नए nodes डाल दे, तो Tailscale आपके मौजूदा nodes को plaintext में traffic भेज या प्राप्त कर सकता है।" आपका single sign-on provider भी उसी trust path में स्थित है, क्योंकि जो कोई भी वहां identity बना सकता है, वह एक node जोड़ सकता है। और एक compromised node tailnet के भीतर एक peer होता है, इसलिए वह आगे क्या access कर सकता है, यह आपकी policy पर निर्भर करता है। क्या यह एक स्वीकार्य जोखिम है, यह इस पर निर्भर करता है कि आप किससे बचाव कर रहे हैं, और पूर्ण trust model उन सभी स्थितियों का विश्लेषण करता है, जिसमें यह भी शामिल है कि एक चोरी हुआ identity account वास्तव में क्या कर सकता है।

Key distribution जोखिम के दो उत्तर हैं। पहला है tailnet lock, जिसके लिए आवश्यक है कि आपके अन्य nodes द्वारा स्वीकार किए जाने से पहले मौजूदा trusted nodes एक नए node को cryptographically sign करें। एक control plane जो बिना valid signature के node जोड़ता है, उसे ignore कर दिया जाता है। Admin console आपके signing nodes के लिए सटीक tailscale lock init line generate करता है, और हर node पुष्टि कर सकता है कि वह क्या देख रहा है।

tailscale lock status

सभी nodes को trusted signing keys का एक ही set रिपोर्ट करना चाहिए। दूसरा उत्तर है control plane को स्वयं चलाना। एक self-hosted Headscale coordination server उन्हीं clients के साथ उसी protocol पर बात करता है, जो device graph और key distribution को आपके स्वामित्व वाले hardware पर ले आता है। तब उस server के uptime की जिम्मेदारी भी आपकी होती है। यदि आप अभी भी self-hosted control planes की तुलना कर रहे हैं, तो NetBird एक अलग mesh VPN है जिसका server आप पूरी तरह से एक single VPS पर चला सकते हैं।

पहले दिन ही एक default setting को ठीक करें। एक नया tailnet permissive रूप में आता है: "default tailnet policy file tailnet के भीतर सभी devices के बीच संचार को सक्षम बनाती है।" जैसे ही आप एक acls section जोड़ते हैं, model 'deny by default' पर बदल जाता है और केवल आपके द्वारा बनाए गए rules ही काम करते हैं।

{
  "tagOwners": {
    "tag:server": ["autogroup:admin"]
  },
  "acls": [
    {"action": "accept", "src": ["autogroup:member"], "dst": ["tag:server:22"]}
  ]
}

वह policy tailnet सदस्यों को tagged servers पर SSH तक पहुँचने देती है और कुछ नहीं। Wildcard को वैसे ही छोड़ने के बजाय प्रति service एक rule जोड़ें, क्योंकि wildcard का मतलब है कि एक चोरी हुआ laptop key आपके database तक पहुँच सकता है।

विफलता के प्रकार और दिखाई देने वाले संदेश

tailscale status हमेशा relay कहता है। दोनों नोड्स के बीच कभी सीधा रास्ता नहीं बना। दोनों सिरों पर tailscale netcheck चलाएं। UDP: false का अर्थ है कि UDP आउटबाउंड ब्लॉक है, इसलिए केवल एक रिले ही काम कर सकता है। MappingVariesByDestIP: true का अर्थ है कि बीच में एक हार्ड NAT है, और जिस तरफ आपका नियंत्रण है वहां UDP 41641 इनबाउंड की अनुमति देने से अक्सर यह ठीक हो जाता है।

एक नोड जो महीनों तक काम कर रहा था, वह गायब हो गया। इसका नोड की (node key) 180 दिनों की डिफ़ॉल्ट अवधि पर समाप्त हो गई। मशीन एडमिन कंसोल में एक्सपायर्ड दिखाई देती है, और बॉक्स पर sudo tailscale up चलाने से यह वापस आ जाता है। सर्वर पर की एक्सपायरी को डिसेबल करें ताकि यह दोबारा न हो।

पीयर्स सूचीबद्ध हैं लेकिन कनेक्शन टाइम आउट हो जाते हैं। कनेक्टिविटी काम कर रही है और पॉलिसी ट्रैफिक को अस्वीकार कर रही है। इस स्रोत, गंतव्य और पोर्ट को कवर करने वाले नियम के लिए acls अनुभाग देखें। अस्वीकृत पैकेट का उत्तर देने के बजाय उसे ड्रॉप कर दिया जाता है, यही कारण है कि आपको Connection refused के बजाय टाइम आउट मिलता है।

MagicDNS नाम रिज़ॉल्व नहीं होते हैं। ping db-1 विफल हो जाता है जबकि ping 100.101.102.104 काम करता है। किसी चीज़ ने /etc/resolv.conf को बदल दिया है, इसलिए क्वेरी कभी भी 100.100.100.100 पर स्टब रिज़ॉल्वर तक नहीं पहुँचती हैं। 100.100.100.100 के लिए cat /etc/resolv.conf की जाँच करें, और देखें कि बॉक्स पर और क्या है जो उस फ़ाइल को लिखता है। यह WireGuard टनल के अंदर DNS टूटने जैसी ही समस्या है।

tailscale up आपके टैग को अस्वीकार करता है। टैग पॉलिसी फ़ाइल में tagOwners के अंतर्गत घोषित नहीं है। इसे वहां जोड़ें, फिर कमांड को दोबारा चलाएं।

FAQ

क्या Tailscale एक VPN है या mesh network?

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

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

सामग्री को नहीं। ट्रैफिक नोड्स के बीच WireGuard के साथ end-to-end एन्क्रिप्टेड होता है, private keys कभी भी नोड्स को नहीं छोड़ती हैं, और एक DERP relay उन पैकेटों को फॉरवर्ड करता है जिन्हें डिक्रिप्ट करने का उसके पास कोई तरीका नहीं है। Tailscale मेटाडेटा जरूर देखता है: मशीन के नाम, मालिक, public keys, endpoint पते और यह कि प्रत्येक नोड कब ऑनलाइन है। यह कुंजियों को भी वितरित करता है, इसलिए एक compromised coordination server एक ऐसा नोड डालने की कोशिश कर सकता है जिस पर आपका फ्लीट भरोसा करेगा। Tailnet lock इसे रोकता है क्योंकि इसके लिए आपके अपने विश्वसनीय नोड्स से हस्ताक्षर की आवश्यकता होती है, और Headscale होस्ट किए गए कंट्रोल प्लेन को पूरी तरह हटा देता है।

क्या मुझे Tailscale के लिए firewall ports खोलने की आवश्यकता है?

इनबाउंड के लिए लगभग कभी नहीं। Tailscale का अपना मार्गदर्शन यह है कि "ज्यादातर समय, आपको कोई firewall port खोलने की आवश्यकता नहीं है।" आउटबाउंड के लिए, एक नोड को coordination server और relays के लिए TCP 443, और STUN के लिए UDP 3478 की आवश्यकता होती है। डायरेक्ट टनल UDP का उपयोग करती हैं, जिसका source port डिफ़ॉल्ट रूप से 41641 होता है। UDP 41641 को इनबाउंड अनुमति देना वैकल्पिक है, और यह केवल कठिन नेटवर्क पर सीधे कनेक्शन को सफल बनाने में मदद करता है।

अन्य नोड्स मेरी सर्विस को port 3000 पर क्यों नहीं पहुँच सकते?

सबसे पहले ss -tlnp के साथ bind address की जाँच करें। 127.0.0.1:3000 पर एक listener उन कनेक्शनों को अस्वीकार कर देता है जो नोड के 100.x tailnet पते पर आते हैं, क्योंकि वह socket केवल loopback डेस्टिनेशन को स्वीकार करता है, और क्लाइंट को Connection refused दिखाई देता है। सर्विस को tailnet पते पर bind करें, या इसे प्रॉक्सी करने के लिए tailscale serve 3000 चलाएँ। यदि listener पहले से ही 0.0.0.0 पर है और कनेक्शन अस्वीकार होने के बजाय टाइम आउट हो जाता है, तो इसका कारण bind address के बजाय कोई policy rule या host firewall है।

क्या मुझे Tailscale के coordination server के बजाय Headscale चलाना चाहिए?

Headscale तब चलाएँ जब device graph या key distribution को आपके द्वारा नियंत्रित इंफ्रास्ट्रक्चर पर रहना हो, या जब tailnet को किसी बाहरी सर्विस पर निर्भरता के बिना काम करना हो। क्लाइंट और प्रोटोकॉल समान हैं। इसकी कीमत यह है कि अब आप coordination server का संचालन करते हैं, और इसके बंद होने से नए नोड्स का जुड़ना और नीतियों का लागू होना रुक जाता है। एक छोटे फ्लीट के लिए, tailnet lock सक्षम के साथ होस्ट किया गया कंट्रोल प्लेन आमतौर पर बेहतर विकल्प है।