Linux का Tailscale क्लाइंट घोषित सबनेट रूट को क्यों अनदेखा करता है

आप Linux लैपटॉप पर हैं, tailscale status दूसरी मशीनों की सूची दिखाता है, और 10.80.0.25 पर NAS अब भी समय-सीमा पर रुकता है। tailnet स्वस्थ है, सबनेट राउटर ऑनलाइन है, और क्लाइंट के आउटपुट में कुछ भी नहीं बताता कि उसके पीछे का LAN क्यों पहुँच से बाहर है। नीचे का विवरण उसी लक्षण से बाहर की ओर बढ़ता है: इस क्लाइंट पर फ़्लैग, फिर राउटर पर घोषणा, फिर मंज़ूरी, फिर नीति, और तभी गंतव्य स्वयं। हर द्वार उसी समय-सीमा से विफल होता है, इसलिए क्रम आदेशों से अधिक मायने रखता है।

Linux क्लाइंट क्या इंस्टॉल करने से इनकार करता है

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

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

इस मशीन के लिए रूट स्वीकृति चालू करें

क्लाइंट पर वरीयता सेट करें, और फिर यह मानने के बजाय कि आदेश लागू हो गया, देखें कि क्या बदला। मौजूदा रूप लॉगिन प्रवाह दोहराए बिना सेटिंग लागू करता है, जो सत्र के बीच में होने पर मायने रखता है।

sudo tailscale set --accept-routes
tailscale status
ip route show table 52

Tailscale Linux पर स्वीकृत रूट अपनी अलग तालिका में इंस्टॉल करता है, इसलिए तालिका 52 में दिखना सीधा प्रमाण है कि इस क्लाइंट ने घोषणा इंस्टॉल की। अगर आपकी रेंज उस तालिका में नहीं है, तो रुकें: समस्या स्थानीय है और राउटर पर कोई भी काम उसे नहीं बदलेगा।

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

घोषणा और मंज़ूरी अलग-अलग जाँचें

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

sudo tailscale up --advertise-routes=10.80.0.0/24
sysctl net.ipv4.ip_forward
ip -br addr

घोषित प्रीफ़िक्स की उस पते से अक्षर-दर-अक्षर तुलना करें जहाँ आप वास्तव में पहुँचना चाहते हैं। 10.70.0.0/24 घोषित करने वाला राउटर 10.80.0.25 पर NAS के बारे में कुछ नहीं कहता, और यह असंगति हर स्टेटस आउटपुट में अदृश्य है क्योंकि दोनों संख्याएँ समान रूप से विश्वसनीय दिखती हैं। टूटे रूट की अधिकांश रिपोर्टें यहीं खत्म होती हैं। नीचे कुछ भी छूने से पहले घोषणा ठीक करें।

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

होस्टनाम से पहले निजी पता जाँचें

राउटर के अपने tailnet पते से सफल कनेक्शन साबित करता है कि tailnet काम करता है, जो आप पहले से जानते थे। उपयोगी परीक्षण वह सेवा है जिसकी आपको वास्तव में ज़रूरत है, पहले निजी पते पर, ताकि DNS विफलता रूटिंग विफलता का रूप न ले सके।

tailscale ping 10.80.0.1
ping -c 2 10.80.0.25
nc -vz 10.80.0.25 445
getent hosts nas.internal.example

अगर पता जवाब देता है और होस्टनाम नहीं, तो आपकी नाम-समाधान की समस्या है और इसे रूट समस्या मानना बंद करें। अगर दोनों में से कोई जवाब नहीं देता, तो एक अनुभाग पीछे जाएँ और पुष्टि करें कि घोषणा पते को कवर करती है। दोनों विफलताएँ ऐप से एक जैसी दिखती हैं और अलग-अलग जगहों पर ठीक होती हैं।

tailnet को दोष देने से पहले एक स्थानीय जाँच करना उचित है। जब आपका मौजूदा LAN दूरस्थ सबनेट जैसा ही प्रीफ़िक्स उपयोग करता है, कर्नेल सीधे जुड़े रूट को वरीयता देता है और ट्रैफ़िक कभी मशीन नहीं छोड़ता; ऐसा तब होता है जब घर और दफ़्तर दोनों 192.168.1.0/24 चुन लेते हैं।

क्लाइंट फ़्लैग राउटर सेटिंग क्यों नहीं है

ये अलग-अलग आवश्यकताओं वाली अलग भूमिकाएँ हैं, और क्लाइंट फ़्लैग को राउटर पर कॉपी करना ही वह तरीका है जिससे काम करता tailnet लूप पकड़ लेता है। रूट घोषित करने वाली मशीन को फ़ॉरवर्डिंग, फ़ॉरवर्ड किए गए ट्रैफ़िक की अनुमति देने वाले फ़ायरवॉल नियम और यह निर्णय चाहिए कि कौन-से प्रीफ़िक्स घोषित करे। इनमें से कुछ भी --accept-routes से निहित नहीं है।

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

साधारण क्लाइंट के लिए क्रम उस ऐप परीक्षण पर समाप्त होता है जो शुरू में विफल हुआ था। राउटर के लिए फ़ॉरवर्डिंग, घोषणा, मंज़ूरी और फ़ायरवॉल इसी क्रम में देखें, क्योंकि पहला अनुपस्थित तत्व ठीक वही समय-सीमा पैदा करता है जिससे आपने शुरू किया था।