VPS पर Tailscale subnet router कैसे सेटअप करें

Tailscale subnet router क्या करता है

Tailscale subnet router एक ऐसी मशीन है जो आपके tailnet को private IP addresses की पूरी रेंज advertise करती है, ताकि tailnet का हर device उस रेंज के addresses तक पहुँच सके, भले ही वहाँ कोई भी device Tailscale न चला रहा हो। आपका tailnet आपका निजी Tailscale network है: उन devices का समूह जो एक ही account या organisation में sign in हैं। Exit node वह feature है जिसके साथ लोग अक्सर भ्रमित हो जाते हैं, और यह बिल्कुल विपरीत काम करता है। यह किसी device के पूरे traffic को VPS के माध्यम से बाहर भेजता है, जिससे VPS उस device के लिए public internet का route बन जाता है।

हर वाक्य का अर्थ अलग है। एक subnet router एक private network को tailnet से पहुँचने योग्य बनाता है। एक exit node यह बदलता है कि आपका public traffic कहाँ से बाहर निकलता है। यदि आप दूसरा विकल्प चाहते हैं, तो इसके बजाय VPS पर Tailscale exit node कैसे चलाएं पढ़ें। ये अलग-अलग flags हैं, और एक VPS एक साथ दोनों काम कर सकता है, लेकिन वे अलग-अलग समस्याओं का समाधान करते हैं और उनके विफल होने के तरीके भी अलग होते हैं।

जब VPS को subnet router की आवश्यकता होती है

सामान्य स्थिति वह निजी नेटवर्क है जो आपके प्रदाता (provider) ने आपको पहले ही दे रखा है। आपके VPS के पास एक public address और एक private segment पर दूसरा interface होता है, और उस segment पर मौजूद अन्य servers के पास कोई public address नहीं होता: जैसे 10.0.0.20 पर एक database, 10.0.0.30 पर एक backup target। एक VPS पर Tailscale डालें, 10.0.0.0/24 advertise करें, और आपका laptop सीधे उन private addresses तक पहुँच जाता है। उस segment पर बाकी कुछ भी नहीं बदलता, और database के पास अभी भी कोई public address नहीं होता। यदि आपको उस segment से केवल एक port पर एक web app की आवश्यकता है, तो पूरी range को advertise करना काम से अधिक है, और Tailscale serve उस एक port पर HTTPS लगा देता है। यही तर्क उस daemon पर भी लागू होता है जो जानबूझकर केवल localhost से bind होता है, जैसे systemd के अंतर्गत headless चलने वाला dsh, जहाँ उस VPS पर एक tailnet address उस SSH tunnel की जगह ले लेता है जिसे आप अन्यथा उसके UI तक पहुँचने के लिए खुला रखते।

दूसरी स्थिति VPS के दूसरी ओर का नेटवर्क है। अपने स्वयं के router के पीछे एक home या office LAN (local area network), या उपकरणों (appliances) का एक rack जो Tailscale बिल्कुल नहीं चला सकते, जैसे managed switch या locked firmware वाला पुराना NAS। उस नेटवर्क पर एक Linux box उस पर मौजूद बाकी सभी चीजों के लिए subnet router बन जाता है। इसके सामने मौजूद home router को इसके लिए किसी forwarded port की आवश्यकता नहीं होती, और Tailscale बिना router port खोले NAT के माध्यम से कैसे काम करता है यह बताता है कि यह क्यों काम करता है और कब यह relay पर वापस चला जाता है। घर पर वह box अक्सर एक hypervisor पर एक छोटा VM होता है जिसे आप पहले से चला रहे हैं, और घर पर Proxmox host की लागत बनाम किराए का VPS वह निर्णय है जिसे आपको यह तय करने से पहले लेना चाहिए कि आपकी services tunnel के किस छोर पर होनी चाहिए।

दोनों स्थितियों में एक आवश्यकता समान है। Subnet router को उस range तक पहुँचने में सक्षम होना चाहिए जिसे वह advertise करता है, अपनी routing table और अपने firewall का उपयोग करके। Tailscale उस connection को नहीं बनाता है। यह traffic को router तक पहुँचाता है और उसे forward करने के लिए kernel को सौंप देता है।

Tailscale इंस्टॉल करें और सबसे पहले local route की जाँच करें

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

यह script distribution का पता लगाती है, Tailscale का package repository जोड़ती है, tailscale command और tailscaled daemon को इंस्टॉल करती है, और फिर service को enable करती है। systemctl is-active tailscaled के साथ इसकी पुष्टि करें, जिसे active प्रिंट करना चाहिए।

किसी भी अन्य कार्य से पहले, यह सुनिश्चित करें कि VPS उस network तक पहुँच सकता है जिसे आप advertise करना चाहते हैं।

ip route show
ping -c3 10.0.0.20

ip route show को एक वास्तविक interface पर private range को सूचीबद्ध करना चाहिए, जो कुछ इस तरह दिखेगा: 10.0.0.0/24 dev enp7s0 proto kernel scope link src 10.0.0.5। यदि यहाँ, router पर ही, ping विफल हो जाता है, तो कोई भी Tailscale flag इसे ठीक नहीं कर पाएगा। समस्या VPS के network configuration या target host पर मौजूद firewall में है। सबसे पहले उसे ठीक करें, क्योंकि बाद के सभी परीक्षण उसी पर निर्भर करते हैं।

IP forwarding को चालू करें और इसे reboot के बाद भी सक्रिय रखें

यदि forwarding चालू न हो, तो Linux मशीन किसी भी ऐसे packet को drop कर देती है जो स्वयं उसके लिए नहीं है। अन्य मशीनों के packets को forward करना ही एक subnet router का मुख्य कार्य है, इसलिए यह चरण अनिवार्य है।

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf

इसे sysctl net.ipv4.ip_forward के साथ जाँचें, जिसे net.ipv4.ip_forward = 1 प्रिंट करना चाहिए।

अक्सर लोग इस चरण को आधा ही पूरा करते हैं। sudo sysctl -w net.ipv4.ip_forward=1 तुरंत काम करता है, लेकिन अगले reboot पर हट जाता है। इस कारण subnet router हफ्तों तक चलता है और kernel upgrade के बाद reboot होने पर अगली सुबह बंद हो जाता है। भ्रम की स्थिति यह है कि कुछ भी टूटा हुआ नहीं दिखता। tailscale status अभी भी node को online दिखाता है, admin console में route approved दिखता है, और clients में route install रहता है। Packets VPS पर पहुँचते हैं और kernel उन्हें बिना किसी log के drop कर देता है। /etc/sysctl.d/99-tailscale.conf में मान (values) लिखने से ही वे reboot के बाद वापस आते हैं।

यदि आप forwarding बंद होने पर भी routes advertise करते हैं, तो tailscale up उस समय आपको चेतावनी देता है। Linux पर यह line Warning: IP forwarding is disabled, subnet routing/exit nodes will not work. के करीब होती है। उस command के output को scroll करके छोड़ने के बजाय उसे पढ़ें।

Routes को advertise करें

sudo tailscale up --advertise-routes=10.0.0.0/24

एक ऐसे VPS पर जो पहले से ही आपके tailnet में sign-in है, इसके बजाय सेटिंग को सीधे बदलें:

sudo tailscale set --advertise-routes=10.0.0.0/24

बाद के हर बदलाव के लिए tailscale set का उपयोग करें। किसी एक flag के साथ tailscale up को दोबारा चलाने से वे flags reset हो जाते हैं जिन्हें आपने दोहराया नहीं है, और CLI आपको एक error के साथ रोकता है कि इस तरह से सेटिंग बदलने के लिए सभी non-default flags का उल्लेख करना आवश्यक है। tailscale set एक सेटिंग को बदलता है और बाकी को वैसा ही रहने देता है।

कई ranges को बिना किसी space के एक comma-separated list में डालें: --advertise-routes=10.0.0.0/24,192.168.50.0/24। प्रत्येक entry CIDR notation (classless inter-domain routing, 10.0.0.0/24 format) में एक network address होनी चाहिए। गलती से अपना host address लिखना, जैसे 10.0.0.5/24, अस्वीकार कर दिया जाता है क्योंकि prefix के बाद के bits शून्य नहीं होते हैं, और error उस prefix का नाम बताता है जिसका आप संभवतः मतलब निकाल रहे थे। Advertise करना बंद करने के लिए, sudo tailscale set --advertise-routes= के साथ एक खाली list सेट करें।

एडमिन कंसोल में रूट को स्वीकृत करें

रूट को advertise करना केवल एक अनुरोध है, कोई बदलाव नहीं। जब तक कोई एडमिन इसे स्वीकृत नहीं करता, तब तक किसी भी क्लाइंट को रूट प्राप्त नहीं होता और उस रेंज में कुछ भी एक्सेस नहीं किया जा सकता। यह जानबूझकर किया गया है, क्योंकि कोई भी मशीन जो खुद को हर किसी के राउटिंग टेबल में जोड़ सकती है, वह अपनी पसंद की किसी भी रेंज के लिए ट्रैफिक को कैप्चर कर सकती है।

इसे एडमिन कंसोल के Machines पेज पर स्वीकृत करें। VPS एक subnet बैज के साथ सूचीबद्ध होता है। इसकी रो (row) खोलें, subnets सेक्शन ढूंढें, रूट सेटिंग्स को एडिट करें, रूट को टिक करें और सेव करें।

स्वीकृति प्रति प्रीफिक्स (prefix) होती है। यदि आप आज 10.0.0.0/24 advertise करते हैं और अगले महीने 192.168.50.0/24, तो नया प्रीफिक्स बिना स्वीकृति के आएगा जबकि पुराना काम करता रहेगा। VPS की तरफ से एक स्वीकृत रूट और एक अनदेखा रूट बिल्कुल एक जैसे दिखते हैं, इसलिए किसी और चीज़ को डीबग करने से पहले कंसोल की जाँच करें।

आप tailnet पॉलिसी फ़ाइल में autoApprovers ब्लॉक का उपयोग करके इस मैनुअल चरण को छोड़ सकते हैं:

{
  "autoApprovers": {
    "routes": {
      "10.0.0.0/24": ["tag:subnet-router"]
    }
  }
}

फिर उस टैग, sudo tailscale up --advertise-routes=10.0.0.0/24 --advertise-tags=tag:subnet-router के साथ नोड को अप करें, और रूट advertise होते ही स्वीकृत हो जाएगा। टैग का पहले उसी पॉलिसी फ़ाइल के tagOwners सेक्शन में मौजूद होना आवश्यक है। यदि आप स्क्रिप्ट से VPS को फिर से बनाते हैं तो इसे सेट करना उपयोगी है, क्योंकि एक नया बनाया गया नोड एक नया नोड होता है और उसके रूट फिर से बिना स्वीकृति के शुरू होते हैं।

Linux clients --accept-routes के बिना route को ignore क्यों करते हैं

अब route advertise हो चुका है और स्वीकृत भी है। आपका फोन और Mac 10.0.0.20 तक पहुँच सकते हैं। आपका Linux laptop नहीं पहुँच पा रहा है, और admin console में कोई समस्या नहीं दिख रही है।

Subnet route को स्वीकार करने का अर्थ है client की routing table में entries लिखना। Android, iOS, macOS, tvOS और Windows पर, Tailscale client आपके लिए यह काम करता है। Linux पर ऐसा नहीं होता, क्योंकि Linux machine अक्सर एक server या router होती है जिसकी routing table को किसी ने जानबूझकर configure किया होता है। नेटवर्क से सीखी गई /24 को चुपचाप डालने से वह traffic बाधित हो सकता है जिसे वह machine पहले से संभाल रही है। इसलिए Linux पर आपको प्रत्येक client पर इसे चुनना (opt-in) पड़ता है:

sudo tailscale set --accept-routes

फिर जाँचें कि route कहाँ गया है:

ip route show table 52
ip route get 10.0.0.20

Linux पर Tailscale स्वीकृत routes को main routing table में नहीं डालता है। यह उन्हें routing table 52 में डालता है और policy rules install करता है, जो ip rule show के साथ 5210 से 5270 की priority range में दिखाई देते हैं, जो बेमेल packets को उस table पर भेजते हैं। इसलिए ip route show अकेले कभी भी 10.0.0.0/24 को list नहीं करेगा, और जो पाठक केवल उस command की जाँच करता है, वह यह निष्कर्ष निकालेगा कि --accept-routes ने कुछ नहीं किया। ip route show table 52 वह command है जो सच्चाई दिखाती है, और इसे tailscale0 पर advertise की गई range को list करना चाहिए।

एक अपवाद जानना महत्वपूर्ण है। यदि यह Linux node स्वयं अपने local network के लिए एक दूसरा subnet router है, तो --accept-routes इसे अपने सीधे connected subnet के लिए traffic को अपने interface के बजाय दूसरे router के माध्यम से भेजने के लिए मजबूर करता है। High availability pair में standby router पर, --accept-routes को बंद रखें और केवल advertise करें।

विफलता का प्रकार: दो राउटर जो ओवरलैपिंग रेंज का विज्ञापन करते हैं

दो सबनेट राउटर समान रेंज का विज्ञापन कर सकते हैं, और हाई-अवेलेबिलिटी पेयर इसी तरह काम करते हैं: प्रत्येक राउटर बिल्कुल समान प्रीफिक्स का विज्ञापन करता है, और क्लाइंट एक से दूसरे पर फेलओवर कर सकते हैं। अलग-अलग प्रीफिक्स लंबाई वाली ओवरलैपिंग रेंज भी मान्य हैं, और Tailscale सबसे सटीक मैच को चुनता है। यदि राउटर A 10.0.0.0/24 का विज्ञापन करता है और राउटर B 10.0.0.0/16 का विज्ञापन करता है, तो 10.0.0.20 के लिए ट्रैफिक A के पास जाता है।

जो बात लोगों को हैरान करती है वह A के ऑफलाइन होने पर होने वाला व्यवहार है। Tailscale कम सटीक रूट पर वापस नहीं जाता है, क्योंकि एक ऑफलाइन राउटर अपने विज्ञापन को वापस नहीं ले सकता और क्लाइंट अधिक सटीक प्रीफिक्स को प्राथमिकता देना जारी रखते हैं। 10.0.0.20 के लिए ट्रैफिक रुक जाता है, जबकि 10.0.1.20 के लिए ट्रैफिक, जिसे केवल B का /16 कवर करता है, B के माध्यम से काम करना जारी रखता है। यह लक्षण ऐसा दिखता है जैसे प्राइवेट नेटवर्क का एक हिस्सा डाउन है, और इसका कारण एक ऑफलाइन नोड का अधिक सटीक प्रीफिक्स को होल्ड करना है। यदि आप फेलओवर चाहते हैं, तो व्यापक राउटर से भी संकीर्ण प्रीफिक्स का विज्ञापन करवाएं, ताकि दोनों समान पतों को कवर करें।

दूसरा ओवरलैप क्लाइंट के करीब होता है। 192.168.1.0/24 पर होटल नेटवर्क का उपयोग करते समय यदि आपका सबनेट राउटर 192.168.1.0/24 का विज्ञापन करता है, तो इसका मतलब है कि दोनों समान डेस्टिनेशन के लिए प्रतिस्पर्धा करते हैं, और कौन जीतेगा यह प्लेटफॉर्म पर निर्भर करता है। Linux पर, Tailscale के अपने नियम से पहले एक नियम इंस्टॉल करें ताकि लोकल पते मुख्य टेबल का उपयोग करें:

sudo ip rule add to 192.168.1.0/24 priority 2500 lookup main

वह नियम स्थायी नहीं है और अगले बूट पर हट जाता है। इसका वास्तविक समाधान एक ऐसी प्राइवेट रेंज चुनना है जो आपको बाहर कहीं न मिले। 192.168.0.0/24 और 192.168.1.0/24 अधिकांश होम राउटर पर डिफॉल्ट होते हैं, इसलिए 10.0.0.0/8 के भीतर कुछ ऐसा चुनें जिसे आपने जानबूझकर चुना हो। यही टकराव हाथ से कॉन्फ़िगर किए गए साधारण WireGuard VPN को भी तोड़ देता है, उसी कारण से: अधिक सटीक लोकल रूट जीत जाता है, इसलिए ट्रैफिक कभी टनल में प्रवेश नहीं करता है।

विफलता का प्रकार: DNS ऐसे पते पर रिज़ॉल्व होता है जिसके लिए कोई रूट उपलब्ध नहीं है

इस समस्या को डीबग करना कठिन है, क्योंकि कोई भी टूल त्रुटि की रिपोर्ट नहीं करता है। नाम रिज़ॉल्व हो जाता है, लेकिन कनेक्शन टाइम आउट हो जाता है।

मान लीजिए कि db.internal.example.com आपके प्राइवेट नेमसर्वर के माध्यम से 10.0.5.20 पर रिज़ॉल्व होता है, और आपने 10.0.0.0/24 को एडवर्टाइज़ किया है। लुकअप सफल होता है, क्योंकि DNS (domain name system) रिज़ॉल्यूशन और IP रूटिंग अलग-अलग चरण हैं और इनमें से कोई भी दूसरे की जाँच नहीं करता है। इसके बाद 10.0.5.20 के लिए भेजा गया पैकेट tailnet पर कोई मेल खाता हुआ रूट नहीं ढूँढ पाता है, इसलिए यह क्लाइंट के डिफ़ॉल्ट गेटवे से बाहर निकल जाता है और गायब हो जाता है।

दो कमांड इन दोनों हिस्सों को अलग-अलग जाँचते हैं:

nslookup db.internal.example.com
ip route get 10.0.5.20

यदि लुकअप एक पता देता है लेकिन ip route get, dev tailscale0 के साथ उत्तर नहीं देता है, तो नाम सही है और इस क्लाइंट पर रूट गायब है। Linux क्लाइंट पर, सबसे पहले पुष्टि करें कि --accept-routes चालू है, क्योंकि इसके बिना कोई भी सबनेट रूट इंस्टॉल नहीं होता है, भले ही कोई स्वीकृत प्रीफ़िक्स उस पते को कवर करता हो। यदि यह चालू है और कोई भी स्वीकृत प्रीफ़िक्स उस पते को कवर नहीं करता है, तो एक ऐसी रेंज एडवर्टाइज़ करें जो उसे कवर करे, या तो 10.0.0.0/16 या दूसरा स्पष्ट प्रीफ़िक्स, और फिर कंसोल में नए प्रीफ़िक्स को स्वीकृत करें।

नेमसर्वर पर ही एक समान समस्या हो सकती है। यदि आप एडमिन कंसोल में 10.0.0.53 जैसे प्राइवेट पते पर ग्लोबल नेमसर्वर सेट करते हैं, तो वह पता किसी स्वीकृत रूट के भीतर होना चाहिए, अन्यथा जो डिवाइस उस प्राइवेट नेटवर्क पर नहीं हैं, वे रिज़ॉल्वर तक बिल्कुल नहीं पहुँच पाएंगे। यदि आप उस विकल्प को चालू करते हैं जो लोकल DNS सर्वर को ओवरराइड करता है और साथ ही ऐसे रिज़ॉल्वर की ओर इशारा करता है जहाँ कोई नहीं पहुँच सकता, तो tailnet के सभी डिवाइस का नाम रिज़ॉल्यूशन तुरंत बंद हो जाएगा, जिसमें वे डिवाइस भी शामिल हैं जो एक सेकंड पहले काम कर रहे थे। पहले रिज़ॉल्वर के लिए रूट एडवर्टाइज़ और स्वीकृत करें, फिर DNS सेटिंग बदलें। यदि टनल के अंदर DNS ही वह हिस्सा है जिससे आप लगातार जूझ रहे हैं, तो WireGuard टनल पर DNS कैसे टूटता है उसी तंत्र को कवर करता है, बिना ऊपर मौजूद कोऑर्डिनेशन लेयर के।

Source NAT और site-to-site लिंक

डिफ़ॉल्ट रूप से, subnet router हर forwarded packet के source address को अपने निजी पते (private address) में बदल देता है। इसे SNAT (source network address translation) कहते हैं। यह इसलिए होता है ताकि निजी नेटवर्क पर किसी भी बदलाव के बिना जवाब (replies) मिल सकें: 10.0.0.20 पर मौजूद डेटाबेस VPS को जवाब देता है, क्योंकि उसे पता है कि VPS तक कैसे पहुँचना है। इसका नुकसान यह है कि डेटाबेस को हर tailnet कनेक्शन VPS से आता हुआ दिखता है, इसलिए source-आधारित firewall rules और access logs से कोई जानकारी नहीं मिलती।

जब आप client के वास्तविक tailnet address को सुरक्षित रखना चाहते हैं, तो Linux पर इसे बंद कर दें:

sudo tailscale set --snat-subnet-routes=false

निजी नेटवर्क पर मौजूद hosts को फिर 100.64.0.0/10 (वह रेंज जो Tailscale उपकरणों को असाइन करता है) के लिए एक वापसी मार्ग (route back) की आवश्यकता होती है, जो subnet router की ओर इशारा करता हो। इस वापसी मार्ग के बिना, उनके जवाब डिफ़ॉल्ट गेटवे पर चले जाते हैं और कभी नहीं पहुँचते, जिससे पहला packet जाने के बाद कनेक्शन अटक जाता है। निजी नेटवर्क के गेटवे पर static route जोड़ें, या SNAT को चालू रहने दें।

Site-to-site लिंक का मतलब है कि दो subnet routers एक साथ ऐसा कर रहे हैं, जहाँ प्रत्येक अपने नेटवर्क का विज्ञापन (advertise) करता है और दूसरे के नेटवर्क को स्वीकार करता है:

sudo tailscale up --advertise-routes=10.0.0.0/24 --snat-subnet-routes=false --accept-routes

दूसरे router पर उसकी अपनी रेंज के साथ संबंधित कमांड चलाएँ। दोनों ranges अलग-अलग होनी चाहिए। यदि बड़ी फ़ाइलें ट्रांसफर करते समय कनेक्शन रुक जाता है, जबकि ssh और ping ठीक काम कर रहे हैं, तो इसका कारण MSS (maximum segment size) है, जो TCP packet द्वारा ले जाया जाने वाला डेटा का सबसे बड़ा हिस्सा होता है। टनल के ओवरहेड के कारण forwarded packets बीच के किसी लिंक के लिए बहुत बड़े हो जाते हैं, और clamping इसे ठीक कर देता है:

sudo iptables -t mangle -A FORWARD -o tailscale0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

उस rule को iptables-persistent के साथ सेव करें, अन्यथा अगले बूट पर वह हट जाएगा।

रखरखाव जो इसे चालू रखता है

इस मशीन की key expire होगी या नहीं, यह इस पर निर्भर करता है कि आपने इसे कैसे sign in किया है। ऊपर दिए गए autoApprovers उदाहरण की तरह, किसी tag के तहत लाए गए node के लिए key expiry डिफ़ॉल्ट रूप से बंद रहती है, जैसे ही उसे पहली बार tag और authenticate किया जाता है, इसलिए उस सेटअप में यहाँ कुछ भी करने की आवश्यकता नहीं है। आपके द्वारा sign in किए गए node पर tailnet की key expiry अवधि लागू होती है, जो अक्टूबर 2026 तक एक नए tailnet पर डिफ़ॉल्ट रूप से 180 दिन है और इसे 1 से 180 दिनों के बीच कहीं भी सेट किया जा सकता है। जब इस तरह के subnet router की key expire हो जाती है, तो उससे आने-जाने वाले कनेक्शन रुक जाते हैं और पूरी advertise की गई range अगम्य (unreachable) हो जाती है, बिना किसी कॉन्फ़िगरेशन बदलाव के। एक user के रूप में sign in किए गए router के लिए, admin console के Machines पेज पर उसकी row के अंत में दिए गए मेनू से key expiry को disable करें, और फिर इसे नोट कर लें।

Tailscale peers के बीच सीधा कनेक्शन पसंद करता है और जब ऐसा नहीं हो पाता, तो यह अपने relay servers का उपयोग करता है। Relay काम करते हैं, लेकिन वे latency बढ़ाते हैं। Public address वाला VPS एक आसान स्थिति है: inbound UDP 41641 को अनुमति दें और अधिकांश peers सीधे कनेक्ट हो जाएंगे। जब private range का traffic VPS link की क्षमता से धीमा हो, तो यह जाँच करना कि क्या आपका client subnet router तक सीधे पहुँच रहा है या relay के माध्यम से सबसे पहला कदम है। यदि ufw firewall को manage कर रहा है, तो VPS को वास्तव में जिन ufw नियमों की आवश्यकता होती है में syntax दिया गया है।

Access rules दूसरा महत्वपूर्ण हिस्सा हैं। डिफ़ॉल्ट tailnet पर आपका हर device दूसरे तक पहुँच सकता है, इसलिए एक स्वीकृत route तुरंत काम करता है। एक बार जब आप ACL policy लिख लेते हैं, तो नियम के destination पक्ष को private range को कवर करना होगा, या तो उसका नाम देकर या * wildcard के साथ, जिसमें स्वीकृत subnet routes शामिल होते हैं, क्योंकि 10.0.0.20 एक tailnet address नहीं है और यह tailnet IPs या tags के विरुद्ध लिखे गए नियमों द्वारा कवर नहीं होता है।

अंत में, तय करें कि क्या आप एक ऐसा coordination server चाहते हैं जिसे आप खुद run नहीं करते। Tailscale का control plane एक hosted service है। आपकी keys आपकी मशीनों पर रहती हैं, लेकिन account और policy file वहीं रहती है। किसी compromised control plane या चोरी हुई identity login के साथ कोई वास्तव में क्या कर सकता है, यह तय करना महत्वपूर्ण है इससे पहले कि आप इसे अपने private network का route सौंपें, और Tailscale का trust model उस सीमा को स्पष्ट करता है। लागत शायद ही कभी लोगों को इसे छोड़ने के लिए मजबूर करती है, क्योंकि free plan छह उपयोगकर्ताओं तक को उनके अपने असीमित उपकरणों के साथ कवर करता है, हालाँकि एक subnet router जिसे आप tag के तहत लाते हैं, उसे आपके द्वारा sign in किए गए router से अलग तरह से गिना जाता है। उस बिंदु के बाद, बिल मशीनों के बजाय लोगों पर आधारित होता है, इसलिए free plan समाप्त होने के बाद एक परिवार या पाँच लोगों की टीम वास्तव में कितना भुगतान करती है यह पता लगाना उचित है, इससे पहले कि आप वह account जोड़ें जो आपको सीमा से बाहर ले जाए। Headscale, self-hosted Tailscale control server को run करने से यह आपके अपने VPS पर रहता है, लेकिन इसे maintain करने की लागत चुकानी पड़ती है। इसी चिंता का दूसरा समाधान Tailscale के clients को छोड़ना है, और NetBird VPN server को self-host करना coordination layer और उसके अपने mesh clients को एक ऐसी मशीन पर रखता है जिसे आप नियंत्रित करते हैं। दोनों ही अंदरूनी तौर पर WireGuard का उपयोग करते हैं, इसलिए इस सेटअप के वे हिस्से जो बदलने पर प्रभावित होते हैं, उन्हें NetBird और Tailscale की तुलना में तौला गया है: control plane कौन चलाता है, आप अपनी private range को कवर करने वाला access rule कैसे लिखते हैं, और जब peers सीधे कनेक्ट नहीं हो पाते तो traffic को कैसे relay किया जाता है। यदि आप अभी भी इस मॉडल और हाथ से लिखे गए कॉन्फ़िगरेशन के बीच निर्णय ले रहे हैं, तो WireGuard और Tailscale की तुलना यह बताती है कि coordination layer आपको क्या देता है और इसकी क्या लागत है।

FAQ

Subnet router और exit node में क्या अंतर है?

Subnet router private addresses की एक रेंज को advertise करता है, ताकि tailnet devices उन मशीनों तक पहुँच सकें जिन पर Tailscale नहीं चल रहा है। एक exit node खुद को पूरे इंटरनेट के लिए एक route के रूप में advertise करता है, जिससे डिवाइस अपना सारा traffic उस node के public address के माध्यम से भेजता है। एक VPS दोनों हो सकता है। ये अलग-अलग flags हैं, --advertise-routes और --advertise-exit-node, और प्रत्येक को admin console में अलग से approval की आवश्यकता होती है।

मेरा Linux client advertise किए गए subnet route को ignore क्यों कर रहा है?

Linux clients subnet routes को तब तक स्वीकार नहीं करते जब तक आप उन्हें ऐसा करने के लिए न कहें। Client पर sudo tailscale set --accept-routes चलाएं। फिर ip route show के बजाय ip route show table 52 के साथ जांचें। Tailscale स्वीकार किए गए routes को routing table 52 में इंस्टॉल करता है और उन्हें policy rules के माध्यम से एक्सेस करता है, इसलिए main table में वे कभी दिखाई नहीं देते और एक काम करने वाला route भी गायब लग सकता है।

Reboot के बाद मेरा subnet काम करना बंद कर गया। क्या खराब हुआ?

संभवतः IP forwarding। sysctl -w के साथ सेट किया गया मान reboot के बाद सुरक्षित नहीं रहता, इसलिए इसे /etc/sysctl.d/99-tailscale.conf में लिखें और sysctl net.ipv4.ip_forward के साथ पुष्टि करें। यदि forwarding चालू है और रेंज अभी भी पहुंच से बाहर है, तो admin console में node को देखें। एक user के रूप में sign-in किए गए router की key डिफ़ॉल्ट रूप से 180 दिनों के बाद समाप्त हो जाती है, और एक expired subnet router अकाउंट की समस्या के बजाय network fault जैसा दिखता है। एक tag के तहत लाए गए router में key expiry डिफ़ॉल्ट रूप से अक्षम होती है, इसलिए उस स्थिति में कहीं और जांच करें।

क्या दो subnet routers एक ही रेंज को advertise कर सकते हैं?

हाँ। समान ranges ही वह तरीका है जिससे high availability pair काम करता है: दोनों routers बिल्कुल एक जैसे prefixes advertise करते हैं। अलग-अलग prefix lengths वाली overlapping ranges भी ठीक हैं, और सबसे विशिष्ट (most specific) वाली जीतती है। Failover के लिए वहां सावधानी बरतने की आवश्यकता है: जब अधिक विशिष्ट prefix वाला router offline हो जाता है, तो Tailscale व्यापक route पर वापस नहीं जाता है, इसलिए वह traffic रुक जाता है। एक वास्तविक standby pair के लिए, दोनों routers से समान विशिष्ट prefixes advertise करवाएं।

Hostname resolve हो रहा है लेकिन connection time out हो रहा है। क्यों?

DNS resolution और routing अलग-अलग चरण हैं। एक नाम ऐसे address पर resolve हो सकता है जिसे कोई भी approved route कवर नहीं करता है, और फिर packet client के default gateway के माध्यम से बाहर निकल जाता है। Client पर ip route get <address> चलाएं। यदि उत्तर में Linux client पर dev tailscale0 शामिल नहीं है, तो पहले जांचें कि --accept-routes चालू है या नहीं। यदि यह चालू है, तो एक ऐसी रेंज advertise करें जो उस address को कवर करती हो और admin console में नए prefix को approve करें।