VPN ट्राफिकमा नीति-आधारित राउटिङले के बदल्छ र के बदल्दैन

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

नियमहरूले तालिका छान्छन्, त्यसपछि तालिकाले मार्ग छान्छ

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

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

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

नियम समूहलाई सूचीका रूपमा नभई क्रमका रूपमा पढ्नुहोस्

नियमहरूलाई तिनका प्राथमिकता र तिनले सन्दर्भ गर्ने तालिकासहित छाप्नुहोस्, त्यसपछि पूर्वनिर्धारित वा टनेल मार्ग भएको प्रत्येक तालिका छाप्नुहोस्। क्रम नै महत्त्वपूर्ण भाग हो, र स्क्रिनसटले सामान्यतया छोड्ने भाग पनि त्यही हो:

ip rule show
ip route show table all | sed -n '1,60p'
ip route get 198.51.100.20 from 10.8.0.2
ip route get 198.51.100.20 from 10.8.0.2 mark 0x1

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

मार्क र सकेट: क्लाइन्टहरूले ट्राफिक बाँड्ने दुई तरिका

केही क्लाइन्टहरू फायरवालमा प्याकेट मार्क गर्छन् र मार्कसँग मिल्ने नियम थप्छन्। अरूले सकेट स्तरको राउटिङ प्रयोग गर्छन्, जोडिनुअघि सकेटमा मार्ग राख्छन्। पहिलो ip rule मा देखिन्छ; दोस्रो देखिँदैन, र सामान्य खोजमा देखा पर्दैन।

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

अर्को नियम थप्नु अघि स्वामित्व पत्ता लगाउनुहोस्

नियमहरू कुनै कुराले स्थापना गर्छ। VPN क्लाइन्ट, नेटवर्क प्रबन्धक र हातले लेखिएको स्क्रिप्टले प्रत्येकले सुरु हुँदा नियम थप्न सक्छन्, र पुनःजडान तर्कले अघिल्लो समूह पछाडि छोड्न सक्छ। पुरानो प्रोफाइलका दुई पुराना नियमले प्रोफाइल मेटिएको धेरै समयपछि पनि ट्राफिक मोडिरहनेछन्।

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

एउटाले होइन, दुई प्रवाहले दायरा प्रमाणित गर्नुहोस्

सुधार प्रभावित हुनुपर्ने प्रवाह र प्रभावित हुनु नपर्ने प्रवाहले मात्र प्रमाणित हुन्छ। नीतिले टनेलमा राउट गर्ने गन्तव्य र बाहिर रहनुपर्ने अर्को छान्नुहोस्, त्यसपछि दुवैका लागि खोज र क्याप्चर तुलना गर्नुहोस्:

ip route get 198.51.100.20 from 192.0.2.44
ip route get 198.51.100.21 from 192.0.2.44
tcpdump -ni any host 198.51.100.21 and port 443

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

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