Tailscale का स्वीकृत सबनेट रूट फिर भी समय-सीमा क्यों पार करता है

एडमिन कंसोल में स्वीकृति अंतिम चरण जैसी लगती है, और वह है नहीं। पहले एप्लिकेशन समय-सीमा पार करता है, और उसके बाद ही आपको राउटर ऑनलाइन और रूट स्वीकृत मिलता है। स्वीकृति एक वितरण चरण है, न अनुमति और न फ़ॉरवर्डिंग की गारंटी। किसी पैकेट के सबनेट राउटर के पीछे के होस्ट तक पहुँचने से पहले चार चरण मेल खाने चाहिए, और हर चरण सफल हो सकता है जबकि अगला विफल हो। उन्हें क्रम से करें और पहले ऐसे चरण पर रुकें जो टिकता नहीं।

चार चरण, एक विफलता

राउटर प्रीफ़िक्स की घोषणा करता है, tailnet उस घोषणा को स्वीकृत करता है, क्लाइंट प्राप्त रूट स्वीकार करता है, और एक्सेस नीति विशिष्ट कनेक्शन की अनुमति देती है। ये तीन अलग-अलग घटकों द्वारा लिए गए चार अलग निर्णय हैं। इसलिए स्वीकृत रूट केवल यह कहता है कि नेटवर्क अब tailnet की रूटिंग तालिका का हिस्सा है।

चौथा चरण सबसे अधिक छोड़ा जाता है, क्योंकि पहले तीन दृश्य स्थिति पैदा करते हैं। राउटर के अपने tailnet पते को कवर करने वाली अनुमति उसके पीछे के निजी सबनेट को स्वतः कवर नहीं करती। ये अलग गंतव्य हैं, और नीति हर गंतव्य के लिए अलग मूल्यांकित होती है।

Linux पर तीसरे चरण में एक डिफ़ॉल्ट भी है जो लोगों को चौंकाता है: सबनेट रूट स्वीकार करना वैकल्पिक है। कई GUI क्लाइंट घोषित रूट डिफ़ॉल्ट रूप से स्वीकार करते हैं, इसलिए मिश्रित फ़्लीट में एक मशीन विफल दिख सकती है जबकि बाकी काम करती हैं।

प्लेटफ़ॉर्म मानने के बजाय विफल मशीन पर सेटिंग की पुष्टि करें। काम करने वाली मशीनों पर रूट कभी गायब टुकड़ा नहीं था, इसलिए उन्हें साबित करने दें कि tailnet पक्ष स्वस्थ है। Tailscale का सबनेट राउटर दस्तावेज़ीकरण स्वीकृति, क्लाइंट द्वारा रूट स्वीकृति और नीति चरण को कवर करता है।

रूट वहाँ जाँचें जहाँ क्लाइंट चलता है

राउटर से नहीं, विफल क्लाइंट से शुरू करें। पुष्टि करें कि रूट मौजूद है और क्लाइंट की सेटिंग रूट स्वीकार करने की अनुमति देती है।

tailscale status
tailscale debug prefs | grep -i route
ip route get 10.20.0.42

पहला कमांड पीयर सूची और यह दिखाता है कि सबनेट राउटर पहुँच योग्य है या नहीं, दूसरा रूट-स्वीकृति फ़्लैग सहित क्लाइंट की प्राथमिकताएँ छापता है, और तीसरा कर्नेल से पूछता है कि सबनेट पर किसी वास्तविक होस्ट के लिए वह कौन-सा इंटरफ़ेस इस्तेमाल करेगा। अगर वह अंतिम कमांड Tailscale इंटरफ़ेस के बजाय भौतिक इंटरफ़ेस का नाम लेता है, तो रूट तालिका में कभी नहीं आया। गायब रूट क्लाइंट पक्ष की समस्या है, स्वीकृति की समस्या नहीं। नीति देखने से पहले उसे ठीक करें।

Linux पर रूट स्वीकार करने के लिए, फ़्लैग सेट है ऐसा मानने के बजाय उसके साथ फिर से कनेक्ट करें: tailscale up --accept-routes। अलग फ़्लैग के साथ जुड़ा क्लाइंट उन्हें बदले जाने तक रखता है, इसलिए दूसरा जोड़ने से पहले वर्तमान सेटिंग जाँचें। बदलाव के बाद पहला कमांड फिर चलाने पर रूट तालिका में दिखना चाहिए।

फ़ॉरवर्डिंग और वापसी मार्ग साबित करें

स्वीकृति राउटर को पैकेट फ़ॉरवर्ड करने के लिए सेट नहीं करती, और जवाब की व्यवस्था नहीं करती। दोनों राउटर के LAN पक्ष पर होस्ट-स्तर की बातें हैं। उन्हें क्लाइंट पर नहीं, राउटर पर जाँचें।

sysctl net.ipv4.ip_forward
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni any host 10.20.0.42 and port 443

पहला कमांड 1 बताना चाहिए, वरना कर्नेल फ़ॉरवर्ड किया गया पैकेट गिरा देगा। दूसरा दिखाता है कि सबनेट-रूट मास्करेडिंग स्रोत को फिर से लिख रही है या नहीं, जो डिफ़ॉल्ट व्यवहार है और आमतौर पर वही जो आप चाहते हैं। तीसरा दिखाता है कि अनुरोध गंतव्य तक पहुँचता है और कुछ वापस आता है या नहीं; बिना जवाब का अनुरोध वापसी मार्ग की समस्या है, स्वीकृति की नहीं। इनमें से कोई भी बदलने से पहले तीनों परिणाम साथ पढ़ें।

अगर मास्करेडिंग बंद कर दी गई है, तो गंतव्य नेटवर्क को tailnet के पतों तक वापसी रूट चाहिए, और बीच के हर हॉप को यह पता होना चाहिए। मास्करेडिंग फिर चालू करना एक सेवा के लिए तेज़ समाधान है, पर गंतव्य से मूल क्लाइंट पता छिपाने की कीमत पर। यह अदला-बदली तब मायने रखती है जब गंतव्य ऑडिट के लिए स्रोत पते लॉग करता है, इसलिए घटना के दौरान फ़्लैग पलटने के बजाय जानबूझकर निर्णय लें। दस्तावेज़ करें कि आपने कौन-सा विकल्प चुना, क्योंकि अगला व्यक्ति दो व्यवहारों में से केवल एक देखेगा।

संसाधन के लिए एक्सेस नियम पढ़ें

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

tailscale status --json | head -40
tailscale ping <router-name-or-tailnet-ip>
ping -c 3 10.20.0.42

स्थिति आउटपुट क्लाइंट के अपने पतों और उन पीयर की पहचान करता है जिन्हें वह देख सकता है, और नीति के स्रोत-चयनकर्ता को इन्हीं से मेल खाना चाहिए। tailscale ping स्वयं सबनेट राउटर तक tailnet मार्ग साबित करता है; यह पीयर नाम और tailnet पते हल करता है, घोषित सबनेट के भीतर के होस्ट नहीं। तीसरा कमांड सबनेट रूट से एक सामान्य ICMP इको भेजता है, इसलिए उसका परिणाम राउटर के बजाय गंतव्य का वर्णन करता है। tailnet-स्तर का इनकार आमतौर पर इनकार के रूप में लौटता है, जबकि निकलकर कभी न लौटने वाला पैकेट समय-सीमा पार करता है।

विफल नाम विफल पते से अलग प्रश्न है; रूट को दोष देने से पहले होस्ट को सीधे हल करें। अनुमति पूरे सबनेट के बजाय संसाधन की वास्तविक आवश्यकता के अनुसार लिखें। एक एप्लिकेशन के काम करने के लिए पूरा /24 खोलना वह तरीका है जिससे संकीर्ण अनुरोध चौड़ी अनुमति बन जाता है जिसे बाद में कोई हटाने की हिम्मत नहीं करता।

अगर लक्ष्य निजी सबनेट नहीं बल्कि इंटरनेट इग्रेस था, तो सही घटक एक्ज़िट नोड है, सबनेट राउटर नहीं, और नीति तथा रूटिंग तदनुसार अलग होती हैं। अनुमति चौड़ी करने से पहले वह निर्णय जाँचें। एक्ज़िट नोड डिफ़ॉल्ट रूट बदलता है; सबनेट राउटर केवल प्रीफ़िक्स की घोषणा करता है।