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 खोल्नु भनेको साँघुरो अनुरोध पछि कसैले हटाउन नसक्ने फराकिलो अनुमति बन्ने बाटो हो।

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