VPS वर Tailscale Subnet Router कसे सेट करावे

Tailscale subnet router काय करते

Tailscale subnet router हे एक असे मशीन आहे जे खाजगी IP पत्त्यांची संपूर्ण श्रेणी तुमच्या tailnet ला घोषित करते, ज्यामुळे tailnet वरील प्रत्येक डिव्हाइस त्या श्रेणीतील पत्त्यांपर्यंत पोहोचू शकते, जरी तिथे कुठेही Tailscale चालत नसले तरीही. तुमचे tailnet हे तुमचे खाजगी Tailscale नेटवर्क आहे: एका खाजगी खात्यात किंवा संस्थेत साइन-इन केलेल्या उपकरणांचा संच. Exit node हे एक असे फिचर आहे ज्याबद्दल लोक गोंधळतात, आणि ते याच्या अगदी उलट काम करते. ते डिव्हाइसचे सर्व ट्रॅफिक VPS द्वारे बाहेर पाठवते, त्यामुळे VPS हे त्या डिव्हाइससाठी सार्वजनिक इंटरनेटचा मार्ग बनते.

प्रत्येक वाक्याचा अर्थ खालीलप्रमाणे आहे. Subnet router मुळे एक खाजगी नेटवर्क tailnet वरून उपलब्ध होते. Exit node तुमच्या सार्वजनिक ट्रॅफिकचा बाहेर पडण्याचा मार्ग बदलते. जर तुम्हाला दुसरे फिचर हवे असेल, तर त्याऐवजी how to run a Tailscale exit node on a VPS वाचा. हे दोन्ही स्वतंत्र flags आहेत आणि एक VPS एकाच वेळी दोन्ही कामे करू शकतो, परंतु ते वेगवेगळ्या समस्या सोडवतात आणि त्यांच्या अपयशाची कारणेही वेगळी असतात.

जेव्हा VPS ला सबनेट राउटरची गरज असते

एक सामान्य परिस्थिती म्हणजे तुमच्या प्रोव्हायडरने तुम्हाला दिलेले खाजगी नेटवर्क. तुमच्या VPS कडे एक सार्वजनिक पत्ता आणि खाजगी सेगमेंटवर दुसरे इंटरफेस असते, आणि त्या सेगमेंटवरील इतर सर्व्हरकडे कोणताही सार्वजनिक पत्ता नसतो: जसे की 10.0.0.20 वर डेटाबेस, 10.0.0.30 वर बॅकअप टार्गेट. एका VPS वर Tailscale इन्स्टॉल करा, 10.0.0.0/24 ॲडव्हर्टाइज करा आणि तुमचा लॅपटॉप थेट त्या खाजगी पत्त्यांपर्यंत पोहोचू शकेल. त्या सेगमेंटवर इतर काहीही बदलत नाही आणि डेटाबेसकडे अजूनही कोणताही सार्वजनिक पत्ता नसतो.

दुसरी परिस्थिती म्हणजे VPS च्या पलीकडील नेटवर्क. स्वतःच्या राउटरच्या मागे असलेले घरचे किंवा ऑफिसचे LAN (लोकल एरिया नेटवर्क), किंवा अशा उपकरणांची रॅक जी Tailscale चालवू शकत नाहीत, जसे की मॅनेज्ड स्विच किंवा लॉक केलेले फर्मवेअर असलेला जुना NAS. त्या नेटवर्कवरील एक Linux बॉक्स त्यावरील इतर सर्व गोष्टींसाठी सबनेट राउटर बनतो.

दोन्ही परिस्थितींमध्ये एक समान गरज असते. सबनेट राउटरला त्याने ॲडव्हर्टाइज केलेल्या रेंजपर्यंत पोहोचता येणे आवश्यक आहे, त्यासाठी त्याने स्वतःचे राउटिंग टेबल आणि स्वतःचा फायरवॉल वापरणे गरजेचे आहे. Tailscale ते कनेक्शन तयार करत नाही. ते ट्रॅफिक राउटरपर्यंत पोहोचवते आणि फॉरवर्ड करण्यासाठी कर्नलकडे सोपवते.

Tailscale इन्स्टॉल करा आणि स्थानिक राउट तपासा

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

ही स्क्रिप्ट ऑपरेटिंग सिस्टिम ओळखते, Tailscale ची पॅकेज रिपॉझिटरी जोडते, tailscale कमांड आणि tailscaled डेमन इन्स्टॉल करते आणि त्यानंतर सर्व्हिस सुरू (enable) करते. 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 चा कोणताही फ्लॅग (flag) ते दुरुस्त करू शकणार नाही. ही समस्या VPS च्या नेटवर्क कॉन्फिगरेशनमध्ये किंवा टार्गेट होस्टवरील फायरवॉलमध्ये आहे. ती आधी दुरुस्त करा, कारण पुढील सर्व चाचण्या त्यावरच अवलंबून आहेत.

IP forwarding सुरू करा आणि ते रीबूटनंतरही कायम ठेवा

जर IP forwarding सुरू नसेल, तर Linux मशीन स्वतःसाठी नसलेले कोणतेही पॅकेट नाकारते. इतर मशीनचे पॅकेट्स फॉरवर्ड करणे हेच सबनेट राउटरचे मुख्य काम आहे, त्यामुळे ही पायरी अनिवार्य आहे.

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 कमांड त्वरित परिणाम देते, परंतु रीबूटनंतर ती सेटिंग निघून जाते. त्यामुळे सबनेट राउटर काही आठवडे व्यवस्थित चालतो आणि कर्नल अपग्रेडनंतरच्या रीबूटनंतर अचानक बंद पडतो. गोंधळात टाकणारी गोष्ट म्हणजे, वरकरणी सर्व काही ठीक दिसते. tailscale status नोड ऑनलाइन असल्याचे दर्शवते, ॲडमिन कन्सोलवर रूट मंजूर असल्याचे दिसते आणि क्लायंटकडे रूट इन्स्टॉल केलेले असते. पॅकेट्स VPS पर्यंत पोहोचतात, परंतु कर्नल कोणतीही नोंद न करता ती पॅकेट्स नाकारते. /etc/sysctl.d/99-tailscale.conf मध्ये व्हॅल्यूज लिहिल्यामुळेच रीबूटनंतर ही सेटिंग कायम राहते.

जर तुम्ही IP forwarding बंद असतानाच रूट्स ॲडव्हर्टाइज केले, तर tailscale up तुम्हाला त्या वेळी चेतावणी देते, जी Warning: IPv4 forwarding is disabled. Subnet routes and exit nodes may not work correctly. च्या जवळ असते. त्या कमांडचे आउटपुट दुर्लक्षित न करता नीट वाचा.

राउट्सची जाहिरात करा (Advertise the routes)

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

तुमच्या tailnet मध्ये आधीच साइन-इन असलेल्या VPS वर, सेटिंग्जमध्ये थेट बदल करा:

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

पुढील प्रत्येक बदलासाठी tailscale set वापरा. केवळ एका फ्लॅगसह tailscale up पुन्हा चालवल्यास, तुम्ही न दिलेले इतर फ्लॅग्स रीसेट होतात. अशा प्रकारे सेटिंग्ज बदलताना सर्व नॉन-डिफॉल्ट फ्लॅग्स नमूद करणे आवश्यक असते, अन्यथा CLI त्रुटी (error) दर्शवून प्रक्रिया थांबवते. tailscale set केवळ एक सेटिंग बदलते आणि बाकीच्या सेटिंग्ज तशाच ठेवते.

अनेक रेंज एका स्वल्पविरामाने (comma) वेगळ्या केलेल्या यादीत लिहा, ज्यामध्ये स्पेस नसावी: --advertise-routes=10.0.0.0/24,192.168.50.0/24. प्रत्येक नोंद CIDR नोटेशनमध्ये (classless inter-domain routing, 10.0.0.0/24 फॉरमॅट) नेटवर्क ॲड्रेस असणे आवश्यक आहे. चुकीने तुमचा स्वतःचा होस्ट ॲड्रेस, जसे की 10.0.0.5/24, लिहिल्यास तो नाकारला जातो, कारण प्रीफिक्सनंतरचे बिट्स शून्य नसतात. अशा वेळी, त्रुटीमध्ये तुम्हाला अपेक्षित असलेले योग्य प्रीफिक्स सुचवले जाते. जाहिरात थांबवण्यासाठी, sudo tailscale set --advertise-routes= वापरून रिकामी यादी सेट करा.

admin console मध्ये रूट मंजूर करा

रूट advertise करणे ही केवळ एक विनंती आहे, बदल नाही. जोपर्यंत admin तो मंजूर करत नाही, तोपर्यंत कोणत्याही client ला तो रूट मिळत नाही आणि त्या रेंजमधील कशाशीही संपर्क साधता येत नाही. हे मुद्दाम केले आहे, कारण एखादे मशीन स्वतःला सर्वांच्या routing table मध्ये जोडून कोणत्याही रेंजचा traffic चोरू शकते.

admin console च्या Machines पेजवर जाऊन तो मंजूर करा. VPS समोर एक subnet बॅज दिसेल. त्याची ओळ उघडा, subnets विभाग शोधा, रूट सेटिंग्ज संपादित करा, रूट निवडा आणि सेव्ह करा.

मंजुरी ही प्रत्येक prefix साठी स्वतंत्र असते. जर तुम्ही आज 10.0.0.0/24 advertise केले आणि पुढच्या महिन्यात 192.168.50.0/24 केले, तर नवीन prefix मंजूर न होता येईल, तर जुना prefix काम करत राहील. मंजूर केलेला रूट आणि दुर्लक्षित केलेला रूट VPS वरून सारखेच दिसतात, त्यामुळे इतर कशाचेही debugging करण्यापूर्वी console तपासा.

तुम्ही tailnet policy फाईलमध्ये autoApprovers ब्लॉक वापरून ही मॅन्युअल पायरी वगळू शकता:

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

त्यानंतर त्या tag सह नोड सुरू करा, sudo tailscale up --advertise-routes=10.0.0.0/24 --advertise-tags=tag:subnet-router, आणि रूट advertise होताच तो मंजूर होईल. यासाठी तो tag आधी त्याच policy फाईलच्या tagOwners विभागात अस्तित्वात असणे आवश्यक आहे. जर तुम्ही स्क्रिप्टद्वारे VPS पुन्हा तयार करत असाल, तर हे सेट करणे फायदेशीर ठरते, कारण पुन्हा तयार केलेला नोड हा एक नवीन नोड असतो आणि त्याचे रूट्स पुन्हा मंजूर न केलेल्या स्थितीतच सुरू होतात.

Linux क्लायंट --accept-routes शिवाय राउटकडे दुर्लक्ष का करतात

आता राउट ॲडव्हर्टाइज आणि मंजूर केला आहे. तुमचा फोन आणि Mac 10.0.0.20 पर्यंत पोहोचू शकतात. तुमचा Linux लॅपटॉप पोहोचू शकत नाही आणि ॲडमिन कन्सोलमध्ये कोणतीही समस्या दिसत नाही.

सबनेट राउट स्वीकारणे म्हणजे क्लायंटच्या राउटिंग टेबलमध्ये एन्ट्री करणे. Android, iOS, macOS, tvOS आणि Windows वर, Tailscale क्लायंट हे काम तुमच्यासाठी करतो. Linux वर तो असे करत नाही, कारण Linux मशीन अनेकदा सर्व्हर किंवा राउटर असते ज्याचे राउटिंग टेबल एखाद्याने हेतुपुरस्सर कॉन्फिगर केलेले असते. नेटवर्कवरून मिळालेला /24 नकळतपणे त्यात समाविष्ट केल्यास, मशीनद्वारे आधीच हाताळले जाणारे ट्रॅफिक खंडित होऊ शकते. म्हणून Linux वर तुम्हाला प्रत्येक क्लायंटवर स्वतःहून निवड (opt-in) करावी लागते:

sudo tailscale set --accept-routes

त्यानंतर राउट कुठे सेट झाला आहे ते तपासा:

ip route show table 52
ip route get 10.0.0.20

Linux वरील Tailscale स्वीकारलेले राउट्स मुख्य राउटिंग टेबलमध्ये टाकत नाही. ते त्यांना राउटिंग टेबल 52 मध्ये ठेवते आणि पॉलिसी नियम इन्स्टॉल करते. हे नियम ip rule show वापरून 5210 ते 5270 या प्रायोरिटी रेंजमध्ये दिसतात, जे न जुळणारे पॅकेट्स त्या टेबलकडे पाठवतात. त्यामुळे केवळ ip route show वापरल्यास 10.0.0.0/24 कधीही दिसणार नाही आणि जो वाचक फक्त ती कमांड तपासतो, त्याला वाटेल की --accept-routes ने काहीही केले नाही. ip route show table 52 ही कमांड खरी स्थिती दर्शवते आणि त्यात tailscale0 वर ॲडव्हर्टाइज केलेली रेंज दिसली पाहिजे.

एक अपवाद लक्षात ठेवण्यासारखा आहे. जर हे Linux नोड स्वतःच्या स्थानिक नेटवर्कसाठी दुसरे सबनेट राउटर असेल, तर --accept-routes मुळे ते स्वतःच्या थेट कनेक्ट केलेल्या सबनेटचे ट्रॅफिक स्वतःच्या इंटरफेसऐवजी दुसऱ्या राउटरद्वारे पाठवते. हाय-अव्हेलेबिलिटी जोडीमधील स्टँडबाय राउटरवर, --accept-routes बंद ठेवा आणि फक्त ॲडव्हर्टाइज करा.

अपयशाचा प्रकार: दोन राउटर्स ओव्हरलॅपिंग रेंजची जाहिरात करत आहेत

दोन सबनेट राउटर्सनी कधीही एकसारख्या रेंजची जाहिरात करू नये. वेगवेगळ्या प्रिफिक्स लांबी असलेल्या ओव्हरलॅपिंग रेंजला परवानगी असते आणि Tailscale सर्वात विशिष्ट (most specific) मॅच निवडते. जर राउटर A ने 10.0.0.0/24 ची जाहिरात केली आणि राउटर B ने 10.0.0.0/16 ची जाहिरात केली, तर 10.0.0.20 कडे जाणारी ट्रॅफिक A कडे जाते.

जेव्हा A ऑफलाइन जातो, तेव्हा होणारी वागणूक लोकांना चकित करते. Tailscale कमी विशिष्ट असलेल्या मार्गावर (less specific route) परत जात नाही. 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 ला देखील खंडित करतो: अधिक विशिष्ट स्थानिक मार्ग जिंकतो, त्यामुळे ट्रॅफिक कधीही टनेलमध्ये प्रवेश करत नाही.

अपयशी मोड: DNS अशा पत्त्यावर रिझॉल्व्ह होते ज्यासाठी कोणताही मार्ग (route) उपलब्ध नाही

हे डीबग करणे कठीण असते, कारण कोणतीही त्रुटी (error) नोंदवली जात नाही. नाव रिझॉल्व्ह होते, परंतु कनेक्शन टाइम आउट होते.

समजा db.internal.example.com हे तुमच्या खाजगी नेम सर्व्हरद्वारे 10.0.5.20 वर रिझॉल्व्ह होते आणि तुम्ही 10.0.0.0/24 जाहिरात (advertise) केली आहे. लुकअप यशस्वी होतो, कारण 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 सह उत्तर देत नसेल, तर नाव बरोबर आहे आणि मार्ग (route) गहाळ आहे. असा रेंज advertise करा जो त्या पत्त्याला कव्हर करेल, एकतर 10.0.0.0/16 किंवा दुसरा स्पष्ट प्रीफिक्स, त्यानंतर कन्सोलमध्ये नवीन प्रीफिक्स मंजूर करा.

नेम सर्व्हरवरच एक जुळणारा सापळा (trap) आहे. जर तुम्ही ॲडमिन कन्सोलमध्ये 10.0.0.53 सारख्या खाजगी पत्त्यावर ग्लोबल नेम सर्व्हर सेट केला, तर तो पत्ता मंजूर केलेल्या मार्गाच्या आत असणे आवश्यक आहे, अन्यथा तुमची उपकरणे रिझॉल्व्हरपर्यंत पोहोचू शकणार नाहीत. ज्या रिझॉल्व्हरपर्यंत कोणीही पोहोचू शकत नाही, तिथे पॉइंट करताना स्थानिक DNS सर्व्हर ओव्हरराइड करण्याचा पर्याय चालू करा, आणि tailnet मधील प्रत्येक उपकरणाचे नाव रिझोल्यूशन त्वरित बंद होईल, ज्यामध्ये काही सेकंदांपूर्वी काम करणारी उपकरणेही समाविष्ट आहेत. प्रथम रिझॉल्व्हरचा मार्ग advertise करा आणि मंजूर करा, त्यानंतर DNS सेटिंग बदला. जर टनेलच्या आतील DNS ही समस्या तुम्ही वारंवार सोडवत असाल, तर WireGuard टनेलवर DNS कसे खंडित होते हे त्याच यंत्रणेबद्दल माहिती देते, ज्यामध्ये वरच्या स्तरावरील समन्वयाचा समावेश नाही.

Source NAT आणि site-to-site लिंक्स

डीफॉल्टनुसार, सबनेट राउटर फॉरवर्ड केलेल्या प्रत्येक पॅकेटचा सोर्स ॲड्रेस स्वतःच्या प्रायव्हेट ॲड्रेसमध्ये बदलतो. याला SNAT (source network address translation) म्हणतात. हे यासाठी असते जेणेकरून प्रायव्हेट नेटवर्कवर काहीही बदल न करता रिप्लाय (replies) व्यवस्थित मिळतील: 10.0.0.20 वरील डेटाबेस VPS ला उत्तर देतो, कारण त्याला VPS पर्यंत कसे पोहोचायचे हे आधीच माहित असते. याचा तोटा असा की, डेटाबेस प्रत्येक tailnet कनेक्शन VPS कडून येत असल्याचे पाहतो, त्यामुळे सोर्स-आधारित फायरवॉल नियम आणि ॲक्सेस लॉग्समधून कोणतीही उपयुक्त माहिती मिळत नाही.

जेव्हा तुम्हाला क्लायंटचा खरा tailnet ॲड्रेस जतन करायचा असेल, तेव्हा Linux वर हे बंद करा:

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

त्यानंतर प्रायव्हेट नेटवर्कवरील होस्ट्सना 100.64.0.0/10 कडे परत जाणारा मार्ग (route) असणे आवश्यक आहे. हा तो रेंज आहे जो Tailscale उपकरणांना नियुक्त करते आणि तो सबनेट राउटरकडे निर्देशित असावा लागतो. हा रिटर्न रूट नसल्यास, त्यांचे रिप्लाय डीफॉल्ट गेटवेकडे जातात आणि कधीही पोहोचत नाहीत, त्यामुळे पहिल्या पॅकेटनंतर कनेक्शन हँग होते. प्रायव्हेट नेटवर्कच्या गेटवेवर स्टॅटिक रूट जोडा, किंवा SNAT सुरू ठेवा.

site-to-site लिंक म्हणजे दोन सबनेट राउटर एकाच वेळी हे काम करत असतात, जिथे प्रत्येक राउटर स्वतःचे नेटवर्क ॲडव्हर्टाइज करतो आणि दुसऱ्याचे नेटवर्क स्वीकारतो:

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

दुसऱ्या राउटरवर त्याच्या स्वतःच्या रेंजसह संबंधित कमांड चालवा. दोन्ही रेंज वेगळ्या असणे आवश्यक आहे. जर ssh आणि ping व्यवस्थित असताना मोठ्या फाईल्सचे ट्रान्सफर थांबत असेल, तर त्याचे कारण MSS (maximum segment size) हे असते, जो TCP पॅकेट वाहून नेणारा डेटाचा सर्वात मोठा तुकडा असतो. टनेलच्या ओव्हरहेडमुळे फॉरवर्ड केलेले पॅकेट मार्गातील एखाद्या लिंकसाठी खूप मोठे होतात, आणि क्लॅम्पिंग (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 वरील की कालबाह्य होते, तेव्हा तो नोड लॉग आउट होतो आणि संपूर्ण जाहिरात केलेली (advertised) रेंज पोहोचण्यायोग्य राहत नाही, ज्याचे कोणतेही स्पष्टीकरण कॉन्फिगरेशनमध्ये बदल केल्यामुळे मिळत नाही. admin console च्या Machines पेजवर जाऊन या मशीनसाठी key expiry अक्षम करा आणि तुम्ही हे केल्याची नोंद ठेवा.

Tailscale पीअर्समध्ये थेट कनेक्शनला प्राधान्य देते आणि जेव्हा ते शक्य नसते तेव्हा relay servers चा वापर करते. हे relays काम करतात, परंतु त्यामुळे latency वाढते. सार्वजनिक पत्ता असलेला VPS हा सोपा प्रकार आहे: येणाऱ्या UDP 41641 ट्रॅफिकला परवानगी द्या, म्हणजे बहुतेक पीअर्स थेट कनेक्ट होतील. जर ufw फायरवॉल व्यवस्थापित करत असेल, तर VPS साठी आवश्यक ufw नियम मध्ये त्याचे सिंटॅक्स दिले आहेत.

Access rules हा दुसरा महत्त्वाचा भाग आहे. डीफॉल्ट tailnet वर तुमचे प्रत्येक डिव्हाइस एकमेकांशी संपर्क साधू शकते, त्यामुळे मंजूर केलेला मार्ग (route) थेट काम करतो. एकदा तुम्ही ACL पॉलिसी लिहिली की, नियमाच्या डेस्टिनेशन बाजूला खाजगी रेंजचा उल्लेख करणे आवश्यक असते, कारण 10.0.0.20 हा tailnet पत्ता नाही आणि तो tailnet IPs किंवा tags नुसार लिहिलेल्या नियमांच्या कक्षेत येत नाही.

शेवटी, तुम्हाला असा coordination server हवा आहे का जो तुम्ही स्वतः चालवत नाही, हे ठरवा. Tailscale चा control plane ही एक होस्ट केलेली सेवा आहे. तुमच्या की तुमच्या मशीनवरच राहतात, परंतु खाते आणि पॉलिसी फाईल तिथे (सर्व्हरवर) असतात. Headscale, स्व-होस्ट केलेला Tailscale control server चालवल्यास ते तुमच्या स्वतःच्या VPS वर राहते, परंतु त्यासाठी देखभालीची जबाबदारी तुमची असते. याच चिंतेवर दुसरा उपाय म्हणजे Tailscale चे क्लायंट वापरणे सोडून देणे आणि NetBird VPN server स्व-होस्ट करणे, जे coordination लेयर आणि त्याचे स्वतःचे मेश क्लायंट तुमच्या नियंत्रणाखाली असलेल्या एका मशीनवर ठेवते. जर तुम्ही अजूनही या मॉडेल आणि मॅन्युअली लिहिलेल्या कॉन्फिगरेशनमध्ये निर्णय घेत असाल, तर WireGuard आणि Tailscale ची तुलना तुम्हाला coordination लेयर काय देते आणि त्याची किंमत काय आहे, हे स्पष्ट करते.

FAQ

सबनेट राउटर आणि एक्झिट नोडमध्ये काय फरक आहे?

सबनेट राउटर खाजगी पत्त्यांची एक श्रेणी (range) ॲडव्हर्टाइज करतो, ज्यामुळे Tailscale न चालवणारी यंत्रे देखील tailnet मधील उपकरणांना पोहोचू शकतात. एक्झिट नोड स्वतःला संपूर्ण इंटरनेटसाठी मार्ग म्हणून ॲडव्हर्टाइज करतो, ज्यामुळे एखादे उपकरण आपला सर्व ट्रॅफिक त्या नोडच्या सार्वजनिक पत्त्यावरून पाठवते. एक VPS दोन्ही भूमिका बजावू शकतो. हे स्वतंत्र फ्लॅग्स आहेत, --advertise-routes आणि --advertise-exit-node, आणि प्रत्येकाला ॲडमिन कन्सोलमध्ये स्वतंत्र मंजुरीची आवश्यकता असते.

माझा Linux क्लायंट ॲडव्हर्टाइज केलेला सबनेट रूट का दुर्लक्षित करतो?

जोपर्यंत तुम्ही सांगत नाही, तोपर्यंत Linux क्लायंट सबनेट रूट्स स्वीकारत नाहीत. क्लायंटवर sudo tailscale set --accept-routes रन करा. त्यानंतर ip route show ऐवजी ip route show table 52 वापरून तपासा. Tailscale स्वीकारलेले रूट्स routing table 52 मध्ये इन्स्टॉल करते आणि पॉलिसी नियमांद्वारे त्यापर्यंत पोहोचते, त्यामुळे मुख्य टेबलमध्ये ते कधीही दिसत नाहीत आणि कार्यरत रूट गहाळ असल्याचे वाटते.

रीबूटनंतर माझा सबनेट का बंद पडला? काय बिघडले?

बहुतेकदा IP forwarding मुळे असे होते. sysctl -w सह सेट केलेले मूल्य रीबूटनंतर टिकत नाही, म्हणून ते /etc/sysctl.d/99-tailscale.conf मध्ये लिहा आणि sysctl net.ipv4.ip_forward सह खात्री करा. जर फॉरवर्डिंग सुरू असेल आणि रेंज अजूनही पोहोचण्यायोग्य नसेल, तर ॲडमिन कन्सोलमधील नोड तपासा. नोड की (keys) डीफॉल्टनुसार 180 दिवसांनंतर कालबाह्य होतात आणि कालबाह्य झालेला सबनेट राउटर हा खात्यातील समस्येऐवजी नेटवर्क दोष असल्यासारखा वाटतो.

दोन सबनेट राउटर एकाच रेंजची ॲडव्हर्टाइज करू शकतात का?

समान रेंजची नाही. वेगवेगळ्या प्रिफिक्स लांबी असलेल्या ओव्हरलॅपिंग रेंज चालतात आणि सर्वात विशिष्ट (specific) रेंजला प्राधान्य मिळते. फेलओव्हरसाठी काळजी घेणे आवश्यक आहे: जेव्हा अधिक विशिष्ट प्रिफिक्स असलेला राउटर ऑफलाइन जातो, तेव्हा Tailscale आपोआप व्यापक रूटवर परत येत नाही, त्यामुळे तो ट्रॅफिक थांबतो. खऱ्या स्टँडबाय जोडीसाठी, दोन्ही राउटर्सनी समान विशिष्ट प्रिफिक्स ॲडव्हर्टाइज करणे आवश्यक आहे.

होस्टनेम रिझॉल्व्ह होते पण कनेक्शन टाइम आउट होते. का?

DNS रिझोल्यूशन आणि राउटिंग या स्वतंत्र पायऱ्या आहेत. एखादे नाव अशा पत्त्यावर रिझॉल्व्ह होऊ शकते ज्यासाठी कोणताही मंजूर रूट नाही, आणि अशा वेळी पॅकेट क्लायंटच्या डीफॉल्ट गेटवेद्वारे बाहेर पडते. क्लायंटवर ip route get <address> रन करा. जर उत्तरात dev tailscale0 समाविष्ट नसेल, तर त्या पत्त्याला कव्हर करणारी रेंज ॲडव्हर्टाइज करा आणि ॲडमिन कन्सोलमध्ये नवीन प्रिफिक्स मंजूर करा.