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 जोडी चालवत असाल, तर तिला तळटीप नव्हे तर रचना मर्यादा माना, आणि दोन्हींवर मंजुरी देण्यापूर्वी प्रीफिक्स कोणत्या नोडचा आहे ते ठरवा. एकाच राउटरवर तोच इशारा स्वीकृती क्लायंटची आहे, जाहीर करणाऱ्या मशीनची नाही याची आठवण करून देतो. कोणते दार बंद होते ते लिहून ठेवा.

सामान्य क्लायंटसाठी क्रम सुरुवातीला अयशस्वी झालेल्या अ‍ॅप चाचणीने संपतो. राउटरसाठी फॉरवर्डिंग, जाहिरात, मंजुरी आणि फायरवॉल या क्रमाने तपासा, कारण पहिले गहाळ असलेलेच तुम्ही सुरू केलेली तीच वेळ मर्यादा निर्माण करते.