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

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

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

प्रत्येक के लिए एक वाक्य। Subnet router एक private network को tailnet से पहुँचने योग्य बनाता है। Exit node यह बदलता है कि आपका public traffic कहाँ से बाहर निकलता है। यदि आप दूसरा विकल्प चाहते हैं, तो इसके बजाय how to run a Tailscale exit node on a VPS पढ़ें। ये अलग-अलग 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 नहीं होता है।

दूसरी स्थिति VPS के दूसरी ओर का network है। एक home या office LAN (local area network) जो अपने स्वयं के router के पीछे है, या appliances का एक rack जो Tailscale नहीं चला सकता, जैसे कि managed switch या locked firmware वाला पुराना NAS। उस network पर मौजूद एक Linux box उस पर मौजूद बाकी सभी चीजों के लिए subnet router बन जाता है।

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

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

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

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

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

ip route show
ping -c3 10.0.0.20

ip route show को किसी वास्तविक इंटरफ़ेस पर private range को लिस्ट करना चाहिए, जैसे कि 10.0.0.0/24 dev enp7s0 proto kernel scope link src 10.0.0.5। यदि यहाँ ping विफल हो जाता है, तो राउटर पर ही, कोई भी Tailscale फ्लैग इसे ठीक नहीं करेगा। समस्या VPS नेटवर्क कॉन्फ़िगरेशन या target host पर मौजूद फ़ायरवॉल की है। इसे पहले ठीक करें, क्योंकि बाद के सभी परीक्षण इसी पर निर्भर करते हैं।

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

यदि IP forwarding चालू न हो, तो एक Linux मशीन उन सभी packets को 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 में लिखने से ही वे reboot के बाद वापस आते हैं।

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

Advertise the routes

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

On a VPS that is already signed in to your tailnet, change the setting in place instead:

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

Use tailscale set for every later change. Re-running tailscale up with a single flag resets the flags you did not repeat, and the CLI stops you with an error saying that changing settings this way requires mentioning all non-default flags. tailscale set changes one setting and leaves the rest alone.

Several ranges go in one comma separated list with no spaces: --advertise-routes=10.0.0.0/24,192.168.50.0/24. Each entry must be a network address in CIDR notation (classless inter-domain routing, the 10.0.0.0/24 form). Writing your own host address by mistake, 10.0.0.5/24, is rejected because the bits after the prefix are not zero, and the error names the prefix you probably meant. To stop advertising, set an empty list with sudo tailscale set --advertise-routes=.

एडमिन कंसोल में रूट को अप्रूव करें

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

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

अप्रूवल प्रति प्रीफिक्स (prefix) होता है। यदि आप आज 10.0.0.0/24 एडवर्टाइज करते हैं और अगले महीने 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 के साथ लाएं, और रूट एडवर्टाइज होते ही अप्रूव हो जाएगा। टैग का उसी पॉलिसी फाइल के tagOwners सेक्शन में पहले से मौजूद होना आवश्यक है। यदि आप स्क्रिप्ट से VPS को रीबिल्ड करते हैं तो इसे सेट करना फायदेमंद है, क्योंकि एक रीबिल्ड किया गया नोड एक नया नोड होता है और उसके रूट फिर से बिना अप्रूवल के शुरू होते हैं।

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

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

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

sudo tailscale set --accept-routes

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

ip route show table 52
ip route get 10.0.0.20

Linux पर Tailscale accepted 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 पर advertised range को list करना चाहिए।

एक अपवाद जानने योग्य है। यदि यह Linux node स्वयं अपने local network के लिए एक दूसरा subnet router है, तो --accept-routes इसे अपने सीधे जुड़े subnet के लिए traffic को अपने interface के बजाय दूसरे router के माध्यम से भेजने के लिए मजबूर करता है। High availability pair में standby router पर, --accept-routes को off रखें और केवल 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 उसी mechanism को कवर करता है, बिना ऊपर मौजूद coordination layer के।

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

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

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

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

निजी नेटवर्क पर मौजूद hosts को फिर 100.64.0.0/10 (वह रेंज जो Tailscale डिवाइसों को असाइन करता है) तक वापस जाने के लिए एक route की आवश्यकता होती है, जो subnet router की ओर इशारा करता हो। इस return route के बिना, उनके जवाब डिफ़ॉल्ट गेटवे पर चले जाते हैं और कभी नहीं पहुँचते, जिससे पहला पैकेट आने के बाद कनेक्शन अटक जाता है। निजी नेटवर्क के गेटवे पर 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 पर उसकी अपनी रेंज के साथ संबंधित कमांड चलाएँ। दोनों रेंज अलग-अलग होनी चाहिए। यदि बड़ी फ़ाइलें ट्रांसफर करते समय कनेक्शन अटक जाता है, जबकि ssh और ping ठीक काम कर रहे हैं, तो इसका कारण MSS (maximum segment size) है, जो TCP पैकेट द्वारा ले जाया जाने वाला डेटा का सबसे बड़ा हिस्सा होता है। टनल के ओवरहेड के कारण forwarded पैकेट बीच में किसी लिंक के लिए बहुत बड़े हो जाते हैं, और clamping इसे ठीक कर देता है:

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

उस नियम को 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 कर रहा है, तो VPS के लिए आवश्यक ufw rules में इसका 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 वहीं रहती हैं। Headscale, self-hosted Tailscale control server को run करने से यह आपके अपने VPS पर रहता है, लेकिन इसके लिए आपको इसे maintain करना होगा। यदि आप अभी भी इस model और हाथ से लिखी गई config के बीच निर्णय ले रहे हैं, तो WireGuard और 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 खाता समस्या के बजाय network fault जैसा दिखता है।

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

समान ranges को नहीं। अलग-अलग prefix lengths वाली overlapping ranges ठीक हैं, और सबसे विशिष्ट (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 करें।