का मंजूर केलेला 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 उघडणे म्हणजे अरुंद विनंती नंतर कोणीही काढण्याची हिंमत न करणारी रुंद परवानगी बनण्याचा मार्ग.

ध्येय खाजगी सबनेट नसून इंटरनेट इग्रेस असेल, तर योग्य घटक म्हणजे एक्झिट नोड, सबनेट राउटर नाही, आणि धोरण व राउटिंग त्यानुसार वेगळे असतात. परवानगी रुंदावण्यापूर्वी तो निर्णय तपासा. एक्झिट नोड डीफॉल्ट मार्ग बदलतो; सबनेट राउटर फक्त प्रीफिक्सची जाहिरात करतो.