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 की आवश्यकता हो

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

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

दोनों स्थितियों में एक आवश्यकता समान है। Subnet router को अपनी routing table और अपने firewall का उपयोग करके उस range तक पहुँचने में सक्षम होना चाहिए जिसे वह advertise करता है। 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 कर देती है। अन्य मशीनों के packet को 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 अभी भी installed रहता है। Packet VPS तक पहुँचते हैं और kernel बिना किसी log के उन्हें drop कर देता है। मानों को /etc/sysctl.d/99-tailscale.conf में लिखना ही उन्हें reboot के बाद वापस लाता है।

यदि आप forwarding बंद होने के दौरान routes advertise करते हैं, तो tailscale up उस समय आपको चेतावनी देता है, जो Warning: IPv4 forwarding is disabled. Subnet routes and exit nodes may not work correctly. के समान एक पंक्ति होती है। उस command के output को अनदेखा करने के बजाय उसे ध्यान से पढ़ें।

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.1.0.20 के लिए ट्रैफिक 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 को भी तोड़ देता है, उसी कारण से: अधिक सटीक स्थानीय रूट जीत जाता है, इसलिए ट्रैफिक कभी टनल में प्रवेश नहीं करता है।

Failure mode: DNS एक ऐसे पते पर resolve होता है जिसे कोई route cover नहीं करता

इसे debug करना कठिन है, क्योंकि कोई भी error report नहीं होता। नाम resolve हो जाता है। Connection time out हो जाता है।

मान लीजिए db.internal.example.com आपके private nameserver के माध्यम से 10.0.5.20 पर resolve होता है, और आपने 10.0.0.0/24 advertise किया है। Lookup सफल हो जाता है, क्योंकि DNS (domain name system) resolution और IP routing अलग-अलग चरण हैं और कोई भी दूसरे की जाँच नहीं करता। फिर 10.0.5.20 के लिए packet को tailnet पर कोई matching route नहीं मिलता, इसलिए यह client के default gateway से बाहर निकल जाता है और गायब हो जाता है।

दो commands इन दोनों हिस्सों को अलग करती हैं:

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

यदि lookup एक पता लौटाता है लेकिन ip route get, dev tailscale0 के साथ उत्तर नहीं देता है, तो नाम ठीक है और route गायब है। एक ऐसी range advertise करें जो उस पते को cover करती हो, या तो 10.0.0.0/16 या दूसरा स्पष्ट prefix, फिर console में नए prefix को approve करें।

nameserver पर ही एक matching trap है। यदि आप admin console में global nameserver को 10.0.0.53 जैसे private पते पर set करते हैं, तो वह पता एक approved route के भीतर होना चाहिए, अन्यथा आपके devices resolver तक बिल्कुल नहीं पहुँच पाएंगे। उस विकल्प को चालू करें जो local DNS servers को override करता है, जबकि ऐसे resolver की ओर इशारा करता है जहाँ कोई नहीं पहुँच सकता, तो tailnet में हर device का name resolution तुरंत बंद हो जाएगा, जिसमें वे भी शामिल हैं जो एक सेकंड पहले काम कर रहे थे। पहले resolver के लिए route advertise और approve करें, फिर DNS setting बदलें। यदि tunnel के अंदर DNS वह हिस्सा है जिससे आप जूझ रहे हैं, तो the way DNS breaks over a WireGuard tunnel ऊपर मौजूद coordination layer के बिना उसी mechanism को cover करता है।

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 के साथ सेव करें, अन्यथा अगले बूट पर वह हट जाएगा।

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

अगस्त 2026 से, Node keys डिफ़ॉल्ट रूप से 180 दिनों के बाद समाप्त हो जाती हैं। जब subnet router पर key समाप्त हो जाती है, तो node sign out हो जाता है और पूरी advertised range तक पहुंच समाप्त हो जाती है, जबकि इसके पीछे कोई configuration बदलाव नहीं होता। Admin console के Machines पेज पर इस मशीन के लिए key expiry को disable करें, और फिर इसे नोट कर लें।

Tailscale peers के बीच सीधा connection पसंद करता है और जब ऐसा संभव न हो तो अपने relay servers का उपयोग करता है। Relays काम करते हैं, लेकिन वे latency बढ़ाते हैं। Public address वाला VPS एक आसान स्थिति है: inbound UDP 41641 को allow करें और अधिकांश peers सीधे connect हो जाएंगे। यदि ufw firewall को manage कर रहा है, तो the ufw rules a VPS actually needs में आवश्यक syntax दिया गया है।

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

अंत में, यह तय करें कि क्या आप एक ऐसा coordination server चाहते हैं जिसे आप स्वयं run नहीं करते। Tailscale का control plane एक hosted service है। आपकी keys आपकी मशीनों पर रहती हैं, लेकिन account और policy file वहां रहती हैं। एक compromised control plane या चोरी हुई identity login के साथ कोई वास्तव में क्या कर सकता है, यह तय करना महत्वपूर्ण है इससे पहले कि आप इसे अपने private network का route सौंपें, और Tailscale's trust model उस सीमा को स्पष्ट करता है। लागत शायद ही कभी लोगों को इससे दूर करती है, क्योंकि the free plan covers up to six users with unlimited devices of their own, हालांकि tag के तहत लाया गया subnet router आपके द्वारा sign in किए गए router से अलग गिना जाता है। उस बिंदु के बाद, बिल मशीनों के बजाय लोगों की संख्या पर आधारित होता है, इसलिए what a household or a five person team actually pays once the free plan runs out को उस account को जोड़ने से पहले समझ लेना चाहिए जो आपको limit से बाहर ले जाएगा। Headscale, the self hosted Tailscale control server को run करने से यह आपके अपने VPS पर रहता है, लेकिन इसके रखरखाव की जिम्मेदारी आपकी होती है। इसी चिंता का दूसरा समाधान Tailscale के clients को छोड़ना है, और self-hosting the NetBird VPN server coordination layer और उसके mesh clients को एक ऐसी मशीन पर रखता है जिसे आप नियंत्रित करते हैं। यदि आप अभी भी इस model और hand written config के बीच निर्णय ले रहे हैं, तो the comparison of WireGuard and Tailscale यह समझाता है कि coordination layer आपको क्या देता है और इसकी क्या लागत है।

FAQ

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

Subnet router private addresses की एक range को advertise करता है, ताकि tailnet devices उन मशीनों तक पहुँच सकें जिन पर Tailscale नहीं चल रहा है। Exit node खुद को पूरे internet के लिए एक route के रूप में advertise करता है, जिससे device अपना सारा 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 में install करता है और policy rules के माध्यम से उन तक पहुँचता है, इसलिए main table में वे कभी दिखाई नहीं देते और एक कार्यशील route गायब लग सकता है।

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

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

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

समान ranges को नहीं। अलग-अलग 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 cover नहीं करता है, और फिर packet client के default gateway के माध्यम से बाहर निकल जाता है। Client पर ip route get <address> चलाएँ। यदि उत्तर में dev tailscale0 शामिल नहीं है, तो उस address को cover करने वाली एक range advertise करें और admin console में नए prefix को approve करें।