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 बारे केही पनि भन्दैन, र दुवै अङ्क समान विश्वसनीय देखिने हुनाले यो अमेल कुनै पनि स्थिति आउटपुटमा देखिँदैन। बिग्रेको रुटका अधिकांश रिपोर्ट यहीँ टुंगिन्छन्। तल कुनै पनि कुरा छुनुअघि घोषणा सुधार्नुहोस्।

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

होस्टनाम अघि निजी ठेगाना जाँच्नुहोस्

राउटरको आफ्नै 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 जोडी चलाउनुहुन्छ भने यसलाई पादटिप्पणी नभई डिजाइन सीमा मान्नुहोस्, र दुवैमा स्वीकृति दिनुअघि प्रिफिक्स कुन नोडको हो निर्णय गर्नुहोस्। एउटै राउटरमा त्यही चेतावनीले स्वीकृति क्लाइन्टहरूको हो, घोषणा गर्ने मेसिनको होइन भनेर सम्झाउँछ। कुन ढोका बन्द थियो लेख्नुहोस्।

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