जवाफ टनेलबाट होइन, LAN बाट निस्कन्छ: किन र कसरी

गेटवेमार्फत प्रकाशित सेवा इन्टरनेटको अधिकांश भागबाट काम गर्छ र एउटा कार्यालयबाट असफल हुन्छ। कसैले टनेल जाँच्छ, अनुरोध आएको देख्छ र जवाफ पनि उही बाटोबाट फर्कनुपर्ने निष्कर्ष निकाल्छ। Linux त्यसरी काम गर्दैन, र टनेलको जति जाँच गरे पनि जवाफ बदलिँदैन। जवाफ गन्तव्यअनुसार रुट हुन्छ, र त्यो एक असफल कलर त्यस्तो सबनेटमा छ जहाँ होस्ट पहिले नै सिधै पुग्छ।

बाहिर जाने प्याकेट वास्तवमा केले निर्धारण गर्छ

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

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

स्थानीय सबनेट किन जित्छ

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

यही असमानताले निदानलाई भ्रमित बनाउँछ। फराकिलो इन्टरनेटका कलरहरू काम गर्छन् किनभने तिनीहरू कुनै स्थानीय रुटसँग मिल्दैनन्, जबकि कार्यालयको प्रिफिक्स साझा गर्ने एकमात्र कलर असफल हुन्छ, र कसैले परीक्षण गर्न प्रयोग गर्ने ठ्याक्कै त्यही कलर हो।

पीयर कभरेज र स्थापित रुट एउटै होइनन्

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

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

स्रोत ठेगानाअनुसार तालिका छान्नुहोस्

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

ip -6 route add default dev wg0 table 200
ip -6 rule add priority 32000 from 2001:db8:aa::20/128 lookup 200
ip -6 rule add priority 32001 from 2001:db8:aa::20/128 unreachable

अन्तिम लाइनले अनुपस्थित रुटलाई स्थानीय लिङ्कमा फर्कनुको सट्टा देखिने गरी असफल बनाउँछ। स्रोत साँच्चै होस्टमा तोकिएको हुनुपर्छ, र सामान्य स्थानीय तथा मुख्य खोजहरू आफ्नै पहिलेको स्थानमा रहनुपर्छ। नियमले स्रोतअनुसार तालिका छान्छ; यसले तालिकाहरूबीच प्रिफिक्स लम्बाइ तुलना गर्दैन।

पहिले बाटो, त्यसपछि सेवा पुष्टि गर्नुहोस्

क्याप्चरबाट अनुमान गर्नुको सट्टा कर्नेललाई के गर्ने थियो भनेर सोध्नुहोस्, सेवा ठेगानालाई स्रोत छनोटकर्ताका रूपमा प्रयोग गरेर। यहाँ सही जवाफले पूरै प्याकेट ट्रेस बचाउँछ।

ip -6 route get 2001:db8:bb::30 from 2001:db8:aa::20

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

यसले के सुधार्दैन

गेटवेमा फर्वार्डिङ, फायरवाल नियम र ICMPv6 व्यवहार पहिलेजस्तै राख्नुहोस्, किनभने स्रोत-रुटले तीमध्ये कुनै पनि बदल्दैन। अनुपस्थित Packet Too Big सन्देशले कुन तालिका खोज जिते पनि ठूला जवाफहरू अझै तोड्छ। रुटिङ नियम थप्नुअघि त्यो सुधार्नुहोस्, नत्र परिवर्तनपछि पनि लक्षण रहिरहनेछ।

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

अन्तमा, नियम नम्बर र तालिका होस्टको कन्फिगरेसन व्यवस्थापनमा लेख्नुहोस्। हातले थपिएको नीति नियम अर्को पुनर्निर्माणमा हराउँछ, र कार्यालयको कलर उही उजुरी लिएर फर्कन्छ।